PHP2Shell-Angriff erkennen: Diese Spuren bleiben zurück

Der Patch ist eingespielt, die Website läuft wieder. Damit ist die Lücke zu, aber eine Frage bleibt offen: War vorher schon jemand da? Bei PHP2Shell (CVE-2026-109618 und CVE-2026-109619) ist diese Frage berechtigt, denn Angriffe liefen nachweislich schon, bevor der Patch überhaupt verfügbar war. Eine Remote Code Execution hinterlässt Spuren – man muss nur wissen, wo man sucht.

Falls Sie noch nicht gepatcht haben: Das kommt zuerst, nachzulesen unter PHP-Sicherheitslücke PHP2Shell. Dieser Beitrag setzt dort an, wo das erledigt ist.

Vorweg eine ehrliche Einordnung: Zum jetzigen Zeitpunkt gibt es keine bestätigten technischen Erkennungsmerkmale, keine veröffentlichten Dateinamen, keine Liste bekannter Angreiferadressen. Was es gibt, sind Verhaltensmuster. Danach suchen Sie.

Warum man nach Verhalten sucht, nicht nach Dateien

Ein klassisches Schadprogramm kommt als Datei und lässt sich an seinem Fingerabdruck erkennen. Bei einer Remote Code Execution ist das anders: Der Angreifer bringt zunächst gar nichts mit. Er bringt den vorhandenen Webserver dazu, etwas zu tun, das er nicht tun soll. Die erste Spur ist deshalb kein verdächtiges Programm, sondern ein Prozess, der an dieser Stelle nichts verloren hat.

Das ist auch der Grund, warum ein Virenscanner hier wenig meldet. Er sucht nach Bekanntem. Gesucht werden muss nach Unpassendem.

Spur 1: Kindprozesse, die es nicht geben dürfte

Das ist der wichtigste Hinweis. Ein PHP-Arbeitsprozess beantwortet Webanfragen. Er startet keine Befehlszeile.

Sehen Sie nach, ob `php-fpm`, `php-cgi` oder `apache2` Prozesse gestartet haben wie:

Jeder einzelne dieser Funde ist erklärungsbedürftig. Es gibt Anwendungen, die aus PHP heraus legitim ein Programm aufrufen – Bildbearbeitung oder PDF-Erzeugung etwa. Deshalb gilt: nicht jeder Treffer ist ein Angriff, aber jeder Treffer gehört angesehen und zugeordnet.

Für Linux-Systeme gibt es frei verfügbare Werkzeuge, die neu gestartete Prozesse mitschreiben. Sinnvoll ist das vor allem jetzt, in den Tagen nach der Veröffentlichung: Wer mitschreibt, sieht einen zweiten Versuch sofort.

Spur 2: Muster einer Gegenverbindung

Wer Code ausführen kann, will meist eine dauerhafte Verbindung. Üblich ist die Gegenverbindung – der Server baut die Verbindung nach außen auf, weil das durch Firewalls leichter durchkommt als umgekehrt. Typische Zeichenfolgen in Protokollen und Dateien sind:

Diese Zeichenfolgen tauchen in normalem Anwendungscode selten auf. Ein Treffer im Verzeichnis Ihrer Website ist ein deutliches Zeichen.

Spur 3: Jemand sieht sich um

Wer auf einem fremden System landet, orientiert sich zuerst. Die Befehle dafür sind seit Jahrzehnten dieselben: `whoami` und `id` klären, als welcher Benutzer man unterwegs ist, `uname -a` und `ipconfig` verraten System und Netz.

Diese Befehle sind für sich harmlos. Auffällig ist der Zusammenhang: Wenn sie kurz nacheinander und ausgelöst durch einen Webserver-Prozess auftauchen, hat sich jemand umgesehen, der nicht eingeladen war.

Spur 4: Was zurückbleibt

Der Zugang über die Lücke ist flüchtig – nach dem Patch funktioniert er nicht mehr. Deshalb legen Angreifer sich in aller Regel einen zweiten Weg an. Sehen Sie nach:

Der Zeitraum, den Sie prüfen müssen

Die Details sind am 20. Oktober 2026 vorzeitig öffentlich geworden, Angriffsverkehr wurde am 21. Oktober ab 07:43 Uhr UTC beobachtet – vor Veröffentlichung des Patches. Der interessante Zeitraum beginnt also am 20. Oktober und endet dann, wenn Sie aktualisiert haben. Prüfen Sie großzügig: Lieber einen Tag zu viel ansehen als einen zu wenig.

Wenn Sie etwas finden

Dann ändert sich das Vorgehen grundlegend, und zwar sofort.

Nicht aufräumen. Der erste Reflex – verdächtige Datei löschen, Passwörter ändern, Dienst neu starten – vernichtet genau die Spuren, die man für die Rekonstruktion braucht. Und er warnt den Angreifer.

Stattdessen sichern. Protokolle, Dateistände und, wenn möglich, ein vollständiges Abbild des Systems. Erst danach wird eingegriffen.

Vom Beweis her denken. Bis belegt ist, wie jemand hereingekommen ist und was er getan hat, gilt das System als nicht vertrauenswürdig. Wer dabei vorschnell Entwarnung gibt, baut die neue Umgebung unter Umständen auf einem Fundament auf, in dem der Angreifer noch sitzt.

Wie das in der Praxis abläuft, beschreibt unser IT-Notfallplan. Bei einem bestätigten Zugriff ist ein geordnetes Vorgehen mehr wert als Geschwindigkeit. Wer den Ernstfall einmal ohne Ernstfall durchspielen will, findet die Anleitung unter Ransomware-Krisenübung am Tisch.

Haben Sie den Dienst bereits abgeschaltet, beschreibt Website vom Netz genommen den geordneten Weg zurück.

Was ein sauberes Ergebnis wert ist – und was nicht

Wenn Sie nichts finden, ist das eine gute Nachricht, aber kein Freispruch. Protokolle werden überschrieben, Angreifer räumen hinter sich auf, und manche Spuren entstehen erst später. Realistisch formuliert lautet das Ergebnis: „In den vorhandenen Aufzeichnungen des geprüften Zeitraums gibt es keine Hinweise auf einen erfolgreichen Zugriff." Das ist eine belastbare Aussage. „Wir wurden nicht angegriffen" ist es nicht.

Genau hier zeigt sich, wie viel eine zentrale Protokollierung wert ist. Wer Protokolle nur lokal auf dem betroffenen System vorhält, hat im Ernstfall das Beweismittel dort liegen, wo der Angreifer es ändern konnte.

Checkliste: erste Schritte

Wie DAVINCI unterstützt

Wir sehen uns Ihre Systeme auf die hier beschriebenen Spuren an, sichern Beweismittel, bevor etwas verändert wird, und sagen Ihnen klar, was belegt ist und was offen bleibt. Für bestätigte Vorfälle übernimmt unser Incident Response die Aufarbeitung. Im akuten Fall erreichen Sie uns rund um die Uhr über IT-Notfall, sonst über die Kontaktseite.

Verwandte Themen: Wer hier weiterdenkt, liest bei PHP-Sicherheitslücke, Incident Response und Phishing und Ransomware weiter.