Ghostdrive

News · Academy · November 12, 2026

Academy: patched is not clean. Hunting after a patch

A fix does not remove a web shell planted before it. How to hunt back to the first exploitation date, using the PHP2Shell case as the example.

DRIVE 369 DAO · 2 min read

Academy, organisations, lesson 5. The common mistake after a big vulnerability is to patch and move on. If the flaw was exploited before the patch, the attacker may still be inside.

Why this matters

In the PHP2Shell case, exploitation attempts were logged on October 17, four days before patches shipped on October 21 (AWS). Rubrik's analysis makes the point in its title, "Patched is not clean": a web shell dropped in that window survives the update. The cleanup advice from Wordfence is to preserve logs and backups from October 17 onward (Wordfence).

The method, for any vulnerability

  1. Find the earliest date anyone saw exploitation, not the patch date. Go back at least to that day.
  2. Preserve evidence first: web and error logs, file listings, and backups from that period.
  3. Hunt for what an attacker leaves.
  4. Rotate secrets the server could read.
  5. Restore from a backup made before the window if you find a compromise, and patch before it goes live again.

What to look for on a PHP web server

From Wordfence, Wiz and Unit 42:

  • New or unfamiliar `.php` files in upload and plugin or theme folders, created on or after the first exploitation date.
  • New administrator accounts, unexpected scheduled jobs and cron entries.
  • Web worker processes (Apache, PHP-FPM, php-cgi, LiteSpeed) that start a shell, curl, wget, Python or Perl, or run from /tmp, /dev/shm or an in-memory file.
  • Persistence: new SSH keys in the authorised-keys file, new systemd services, changed cron.
  • Outbound connections from the web server to addresses it never used.
  • For PHP2Shell specifically: unusual multipart requests followed by memory-limit errors, repeated HTTP 500 responses, oversized session cookies and PHP workers restarting. Sources disagree on exact file names and request markers, and the ones we saw came from single vendor blogs, so treat them as leads rather than proof.

Wordfence says attackers who got in used the access to test commands, read secrets from configuration files such as wp-config.php and .env, drop backdoors and download more code. So if you find one, rotate the database password and every key the server held.

A realistic limit

Hunting finds what is known to look wrong. Missing evidence is not proof of safety, and a log that was never switched on cannot help. That is why logging comes before the incident.

How Ghostdrive approaches it

If a server that held your data was exposed, the aim is that its files were never readable there. Ghostdrive nodes keep sealed blocks only. For your own web server, the checklist above applies in full.

Academy: start here · Are you already breached? · PHP2Shell three weeks on