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