---
title: Hunt: the four-request PHP2Shell chain that actually got shells, with header order, body hashes, source IPs and the Apache-to-/bin/sh signal | ctxsec
url: https://ctxsec.com/items/hunt-php2shell-successful-chain-four-stage-fingerprint
description: ""
status: "hunt guidance from a published honeypot evidence report (Karimi, Oct 24)"
published: 2026-10-26
---

> 

[← Threat Hunting](/hunting) · [markdown](/items/hunt-php2shell-successful-chain-four-stage-fingerprint.md)

hunt guidance from a published honeypot evidence report (Karimi, Oct 24)

2026-10-26

### Hunt: the four-request PHP2Shell chain that actually got shells, with header order, body hashes, source IPs and the Apache-to-/bin/sh signal

Based on the Oct 24 packet-to-process report. Success criterion: a shell started by the web server, not an HTTP status code.

1. **Process (strongest):** `/bin/sh` (then `id`, `curl`, `wget` or `php`) whose parent is `apache2`/`httpd` running as the web user, followed within about a second by `AH00052 ... Segmentation fault (11)` for the same worker PID.
2. **Request burst from one source within a few seconds:** (A1) a chunked multipart POST to `/?q..=v` with five numbered query parameters, about 1 MB, mostly `files*` fields; (B1) a chunked multipart POST to `/` of about 33 MB with roughly 900 `x*` fields; (A2) a fixed-length POST of about 280 KB; (B2) a fixed-length POST of about 450 KB with ~500 `s*` and ~495 `t*` fields. All carry `PHPSESSID` and `PHP_SESSION_UPLOAD_PROGRESS`.
3. **Headers:** no `User-Agent`; a ten-character `C` multipart boundary; header order `Host, Content-Type, Transfer-Encoding, Connection` (chunked) or `Host, Content-Type, Content-Length, Connection`.
4. **Responses:** a `Set-Cookie: PHPSESSID` that decodes to 819,200 bytes is the memory leak. Alert on any `Set-Cookie` larger than a few KB.
5. **PHP error log:** `Allowed memory size of ... exhausted ... in Unknown on line 0` right before and after the leak request.
6. **Decoded-body SHA-256 (template, not proof of success):** A1 `8e8fc166e6b326d20bb7611d8ef3cee3bd5da46447985312c1492ab0a44d1eb6`, B1 `b6c547e0e9a2bb26607df1521de96f4d5c9adf4621c28b7ab491587b21ae40f2`, A2 `7af66c8f35c5fa6b47a539da6dca361d19543d9f62d61e4af891c2802bd5e236`. These hash the decoded multipart body, not the wire bytes.
7. **IPs (Oct 24; hosting providers, short-lived):** `15.204.59.70`, `162.35.99.94` confirmed shells; `104.28.208.84` and `144.48.4.242` sent attempts only. Treat a hit as a lead.

```
// Sketch: web server spawning a shell (Defender for Endpoint / Sysmon-style)
DeviceProcessEvents
| where InitiatingProcessFileName in~ ("apache2","httpd","php-fpm","php-cgi")
| where FileName in~ ("sh","bash","dash")
| project Timestamp, DeviceName, InitiatingProcessFileName, ProcessCommandLine
```

Sources: [Adel Karimi (0x4D31): PHP2Shell exploitation observed, packet-to-process RCE evidence (Oct 24)](https://github.com/0x4D31/honeypot-data/blob/main/reports/php2shell/2026-10-24-confirmed-rce.md) · [Datadog Security Labs: PHP2Shell detection, analysis and remediation](https://securitylabs.datadoghq.com/articles/php2shell-critical-vulnerabilities-in-php/)