- inventory PHP and other executable types
- compare extension, MIME type, and actual contents
- correlate timestamps with the incident timeline
- rebuild cache from trusted configuration
- inspect backups separately and never overwrite them
Do not delete by directory name alone
Uploads may contain business-critical originals. Preserve and classify first, then remove or replace deliberately.
Where the application does not require it, block PHP execution in data directories. Store backups outside the public web root, restrict access, and verify them through restore tests.
Why are uploads attractive to attackers?
The application often needs write access to uploads, and large numbers of legitimate files provide cover. Double extensions, mismatched MIME types, or obfuscated PHP are indicators, but analysis must consider actual content and server handling.
A .php file is unusual in a media-only directory, yet an unknown file is not automatically executable. Establish whether the web server or PHP handler could execute it and which request path could reach it.
Why should caches be assessed separately?
Caches contain generated copies, bundled scripts, and temporary data. A detection may have been reproduced from compromised source code or may be a stale copy. Preserve useful samples, remove the source, and rebuild from reviewed configuration.
CDN and proxy caches can continue serving a malicious response after local cleanup. Purge them deliberately and verify multiple URLs and request contexts afterwards.
How should backup archives be handled?
Treat backups as separate evidence objects. They may contain malware, database persistence, or publicly reachable archives. Move copies to protected analysis storage, document time and origin, and never unpack them into the live web root.
The guide to compromised backups explains restore-versus-rebuild decisions. After remediation, the hardening checklist covers execution controls, storage separation, and restore tests.