Incident triage
Compromise indicators to check before and after a runtime patch
The exposure window opens before disclosure. Patching closes the door; it doesn’t tell you who was inside.
4 min read
The window opens before the advisory
Amazon’s threat intelligence reported an exploitation attempt on 17 October, four days before public disclosure. Anything exposed in that window deserves a look, not only a patch.
What to check
- Admin and editor accounts you don’t recognise, and recent privilege changes
- PHP files modified in the last few weeks, especially under uploads, cache and theme directories
- Files containing obfuscated code (long encoded strings, eval-style execution) in places code shouldn’t live
- Unexpected changes to .htaccess or web server configuration
- New scheduled tasks or cron entries
- Unfamiliar outbound traffic from the server, if your host exposes it
Order of operations
Take a backup before you change anything, so you keep the evidence. Patch. Then look. If you find something, stop and treat it as an incident: rotate credentials, remove what you can prove is malicious, and get the host involved.
Know the limit of a checklist
A manual review finds the obvious. If the site holds sensitive data and something looks wrong, escalate to someone who does incident response for a living.
Sources
Want this done for you?
Start with the exposure check, or book a call.