PHP2Shell in the wild: the first 48 hours on a honeypot fleet

The short version

• Nine source addresses in seven countries sent PHP2Shell-shaped requests to the fleet, eight of them between 20 and 22 October.
• Two groups. Five addresses used the session upload progress route that the PHP advisories describe; four sent oversized request bodies consistent with the out-of-memory route. OffSeq attributes the second group with lower confidence, by request shape only.
• It started before the fix. The earliest request with the full memory-pressure pattern reached the fleet at 21:57 UTC on 20 October, about sixteen hours before the fixed releases shipped. One oversized WordPress request, attributed by shape only, arrived on 18 October.
• The trigger was new. The PHP_SESSION_UPLOAD_PROGRESS field name appeared zero times across the fleet in the six weeks before 20 October. Every occurrence falls in the 20 to 22 October window.
• The lead tool labels itself. Its requests carry the literal string p2shell in the multipart boundary, which legitimate traffic does not contain.

How the first two days unfolded

What to search your own logs for

These signals are taken from the detection section of OffSeq's report. None is proof on its own, and a determined attacker can change most of them, so match on several together.

• The string p2shell in a Content-Type header. OffSeq reports that no legitimate traffic contains it.
• A PHP_SESSION_UPLOAD_PROGRESS field in multipart uploads, especially on sites with no upload progress feature. The field name is configurable, so treat it as strong but not sole evidence.
• Form field names with very deep array nesting, far beyond anything your forms use.
• Bursts from one source whose request sizes climb steadily over a minute or two.
• Multipart bodies of several hundred kilobytes or more carrying a single field of repeated characters.
• On the server: a PHP-FPM, Apache or httpd process starting a shell or download tool, and memory-limit errors or worker crashes that line up in time with multipart POST requests.

The detection and response guide explains how to search error logs and what to do if anything matches.

Indicators

OffSeq published the source addresses and strings below. The addresses span VPS, cloud and anonymisation networks and several are shared infrastructure, so investigate matches rather than blocking them outright, and expect the list to age quickly.

Indicators published by Amazon

Amazon's threat intelligence team, which runs the MadPot honeypot network, published the addresses below with its report of the earliest known attempt. Amazon notes they include shared anonymisation infrastructure that is not exclusive to this activity, and advises investigating observations rather than blocking.

What this changes for you

• Exploit tooling was circulating before the patch. Amazon's earliest observation is from 17 October, and it advises starting investigations from at least that date. If a server was internet-facing and unpatched in that window, treat the question "were we reached?" as open until you have looked.
• The traffic is automated and broad. Several sources, different variants, repeated runs against decoys that belong to no particular organisation: this is opportunistic scanning, and Amazon reports broad exploitation in the wild.
• Patching is still the fix. Nothing in the field data changes the remediation: install 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your vendor's fixed package, restart every PHP worker, and use the stop-gaps only where you cannot patch yet.