Jagen oder gejagt werden: HuntIQ-Jäger stellen sich der Herausforderung „ php2shell“

Was ist geschehen?

Am 20. Oktober 2026 wurden die Kennungen für zwei kritische PHP-Sicherheitslücken einen Tag vor ihrer koordinierten Veröffentlichung im Internet bekannt, woraufhin PHP die Veröffentlichung des Patches auf den nächsten Morgen vorverlegte. Zu diesem Zeitpunkt hatte der erste Angriffsversuch bereits die Honeypots von Amazon auf 17. Oktober getroffen. Der Patch selbst besteht aus einem Paket-Update. Das Schwierige daran war, zu wissen, wo sich jede einzelne PHP-Kopie befand.

PHP ist für einen großen Teil des Internets verantwortlich, weshalb SANS am Tag der Veröffentlichung die Gefahrenstufe seines Internet Storm Center auf „Gelb“ angehoben hat (SANS ISC (öffnet in einem neuen Tab)). Wiz, eines der Teams, das darüber berichtet, schätzt, dass die Sicherheitslücken etwa 70 % des Internets betreffen (Wiz (öffnet in einem neuen Tab)). In den eigenen Sicherheitshinweisen von PHP wird das höchste Risiko für das in Apache integrierte PHP-Modul angegeben, bei dem eine einzelne Anfrage die Schwachstelle erreichen kann, noch bevor Anwendungscode ausgeführt wird, und es wird darauf hingewiesen, dass Konfigurationsänderungen nur eine teilweise Abhilfe darstellen (PHP-Sicherheitshinweis (öffnet sich in einem neuen Tab)).

Wie der erste Tag verlief

Die Jäger von HuntIQ wurden am Abend, an dem die Identifikationsdaten durchgesickert waren, informiert, und das Team von „The Guardian“ richtete noch in derselben Nacht einen Kommunikationskanal für die Reaktion ein. PHP hat die Korrekturen am 21. Oktober. des Monats 14:00 UTC veröffentlicht. Innerhalb einer Stunde umfassten die HuntIQ-Inhalte drei Post-Exploitation-Hunts: Shells und Discovery-Tools, die von einem PHP- oder Webserver-Worker gestartet wurden, von diesen Workern geschriebener PHP-Code und ausführbare Dateien sowie PHP-Binärdateien, die älter waren als die korrigierten Versionen.

In jener Nacht gelang es einem HuntIQ-Forscher in einem abgelegenen Labor, beide Ketten zur Remote-Codeausführung gegen PHP 8,5,11 zu reproduzieren und die Ausführung von Befehlen als Webdienst-Konto von Apache zu erlangen. Innerhalb eines Tages gelang es dem Team, noch einen Schritt weiter zu gehen als die öffentlich bekannten Exploits: Es führte den Angriff ausschließlich über HTTP durch und umging dabei die Adressrandomisierung mithilfe eines In-Band-Speicherlecks – und zwar gegen einen Server, über den es keinerlei Insiderwissen besaß. Bei Tests mit der korrigierten Version von PHP 8,5,12 schlugen dieselben Befehlsketten und deren Varianten fehl, und das Team fand keine Umgehungsmöglichkeit. Daraus konnte HuntIQ gleich zwei Dinge ableiten: Die öffentlich zugänglichen Exploits schlugen fehl, doch ein versierter Angreifer konnte dennoch eine Codeausführung erreichen, sodass das Scheitern der öffentlichen Proof-of-Concepts kein Grund war, abzuwarten; und der Patch selbst war einwandfrei. Der vollständige Forschungsbericht ist am Ende verlinkt.

Gleichzeitig stellte Tanium Guardian ein Dashboard für die beiden CVEs sowie einen neuen Sensor für Windows-PHP-Installationen bereit, der die Version aus jeder PHP-Binärdatei ausliest, ohne diese auszuführen. Der Inhalt erreichte die ersten Tanium-Cloud-Kundenmandanten bei 19:38 UTC und die Bereitstellung für alle Tanium-Cloud-Mandanten bei 21:59 UTC war etwa acht Stunden nach der Veröffentlichung von PHP abgeschlossen. Kunden mit einer lokalen Installation verfügten über ein Importpaket und einen öffentlichen Wissensartikel von 01:58 UTC am 22. Oktober.

Niemand in diesen Tanium Cloud-Mandanten musste eine Frage erstellen oder eine Datei importieren. Das Dashboard wurde nach anfälligen Versionen unter Windows, Linux und macOS sortiert angezeigt, und die HuntIQ-Hunter stellten ihren Kunden eine für Tanium Atlas entwickelte Verhaltenssuche zur Verfügung, sodass die Folgefrage, ob jemand die Schwachstelle bereits ausgenutzt habe, in natürlicher Sprache für die gesamte Infrastruktur gestellt werden konnte.

Warum es so schwierig war, PHP zu entdecken

Versionsscanner haben in zweierlei Hinsicht Schwierigkeiten mit PHP. Linux-Distributionen beheben dieses Problem, indem sie den Patch in eine ältere Versionsreihe zurückportieren: Das korrigierte Paket von Ubuntu 24,04 meldet weiterhin PHP 8,3,6, sodass ein Server bei einer Versionsprüfung als anfällig eingestuft wird, obwohl er gepatcht ist. Unter Windows wird PHP in der Regel aus einer ZIP-Datei entpackt und nicht installiert, sodass es nie in der Liste der installierten Programme erscheint. In der Praxis wurden zahlreiche Windows-Exemplare entdeckt, die in Anwendungen von Drittanbietern eingebettet waren. Die Laboruntersuchungen von HuntIQ deckten eine dritte Lücke auf: Die Bestandsaufnahme der Pakete eines Hosts beschreibt den Host selbst, nicht jedoch die darauf ausgeführten Container-Images, und ein anfälliges PHP-Image kann sich auf einem Server befinden, auf dem die eigene PHP-Version bereits gepatcht ist.

Die Angreifer führten bereits vor der Veröffentlichung des Patches Scans durch. Die Unternehmen, die den Tag der Veröffentlichung unbeschadet überstanden haben, waren diejenigen, die jeden Host, auf dem PHP läuft, ausfindig machen und auflisten, diese nach ihrem Sicherheitsrisiko einstufen und die mit dem Internet verbundenen Hosts zuerst patchen konnten. Diese Frage beantwortet Tanium in einem einzigen Durchgang für den gesamten Bestand, und HuntIQ liefert die Einschätzung, welche Antworten von Bedeutung sind.

• Erfahren Sie, wie Sie mit Tanium Security Operations und HuntIQ dem nächsten Zero-Day-Angriff einen Schritt voraus sein können
• Lesen Sie die vollständige technische Analyse: HuntIQ Tradecraft: „Hunting php2shell – Post-Exploitation mit Tanium“ (wird in einem neuen Tab geöffnet)
• Lesen Sie mehr über unsere Forschungsergebnisse: HuntIQ Tradecraft: Warum „ php2shell “ real ist und dennoch schwer auszunutzen (wird in einem neuen Tab geöffnet)