Kurz gesagt: Ob ein Server über PHP2Shell gehackt wurde, lässt sich nicht an einem einzelnen Merkmal ablesen. Es gibt keine veröffentlichten, bestätigten Indicators of Compromise; die Erkennung beruht auf Verhaltensanalyse. Typische Anzeichen sind neue PHP-Dateien, unbekannte Cronjobs und ungewöhnliche Verbindungen. Sichern Sie zuerst die Logs ab dem 20. Oktober, bevor Sie etwas verändern.
Gibt es eindeutige Anzeichen für einen PHP2Shell-Angriff?
Nein, und das ist die ehrliche Antwort. Für viele bekannte Lücken veröffentlichen Hersteller oder Sicherheitsfirmen konkrete Spuren: Dateinamen, Prüfsummen, IP-Adressen. Für PHP2Shell gibt es solche bestätigten Indicators of Compromise bislang nicht.
Was bekannt ist: Laut Medienberichten wurde ein erster Angriffsversuch am 17. Oktober beobachtet, vier Tage vor den Patches vom 21. Oktober. Cloudflare meldete weitere Versuche. Bestätigte erfolgreiche Angriffe in der Breite waren laut BSI zunächst nicht bekannt. Wer zwischen dem 17. Oktober und dem eigenen Patch ungeschützt erreichbar war, sollte deshalb prüfen, statt zu hoffen.
Für die Einschätzung zählt vor allem der Zeitraum. Zwischen dem ersten beobachteten Angriffsversuch am 17. Oktober und den Patches am 21. Oktober gab es kein offizielles Update. Jeder öffentlich erreichbare PHP-Server war in dieser Zeit potenziell angreifbar. Wie lange Ihr Server darüber hinaus offen war, hängt davon ab, wann das Update eingespielt und PHP neu gestartet wurde. Je länger dieser Zeitraum und je sensibler die Daten, etwa Kundenkonten, Bestellungen oder Bewerbungen, desto gründlicher sollte die Prüfung ausfallen.
Typische Anzeichen, dass ein Server gehackt wurde
Nach einer erfolgreichen Codeausführung versuchen Angreifer meist, sich festzusetzen und den Server zu nutzen. Daraus ergeben sich Anzeichen, die nicht spezifisch für PHP2Shell sind, aber für jede Einbruchsprüfung zählen:
- Neue oder veränderte PHP-Dateien, besonders in Upload-, Cache- oder Bildverzeichnissen, in denen sonst keine PHP-Dateien liegen.
- Unbekannte Cronjobs oder geplante Aufgaben, etwa für den Webserver-Benutzer.
- Ungewöhnliche ausgehende Verbindungen zu unbekannten Adressen, hohe Netzlast oder Mailversand, den niemand angestoßen hat.
- Neue Admin-Konten in CMS oder Shop, geänderte Passwörter, unbekannte SSH-Schlüssel.
- Auffällige Last: dauerhaft hohe CPU-Auslastung durch unbekannte Prozesse, häufig ein Hinweis auf Krypto-Mining.
- Sichtbare Folgen: Weiterleitungen auf fremde Seiten, Spam-Seiten im Google-Index, Warnungen im Browser oder in der Search Console.
Keines dieser Zeichen beweist für sich einen Einbruch, und ihr Fehlen beweist nicht das Gegenteil. Entscheidend ist das Gesamtbild.
Erste Prüfungen, ohne Spuren zu zerstören
Bevor Sie etwas löschen oder neu starten: Sichern Sie die Logs. Die Fachpresse rät, Server-Logs ab dem 20. Oktober aufzubewahren. Kopieren Sie Webserver-, PHP- und Systemlogs an einen sicheren Ort außerhalb des Servers.
Danach helfen rein lesende Prüfungen. Pfade und Benutzernamen weichen je System ab:
# PHP-Dateien, die seit dem 17.10. geändert wurden
find /var/www -type f -name "*.php" -newermt "2026-10-17" -ls
# PHP-Dateien in Upload-Verzeichnissen (Beispiel WordPress)
find /var/www -path "*/uploads/*" -name "*.php" -ls
# Cronjobs des Webserver-Benutzers und systemweit
crontab -l -u www-data
ls -la /etc/cron.d /etc/cron.daily /var/spool/cron 2>/dev/null
# aktive Netzwerkverbindungen mit Prozess
ss -tunp
# letzte Anmeldungen
last -n 30
Beachten Sie: Angreifer können Zeitstempel von Dateien fälschen. Ein unauffälliges Ergebnis von find ist deshalb kein Freispruch. Wie Sie Logs gezielt auswerten, beschreibt Webserver-Logs nach einem Angriff auswerten; wie Sie Hintertüren finden, Webshells erkennen und entfernen.
Finden Sie konkrete Hinweise, etwa eine unbekannte PHP-Datei im Upload-Ordner: nicht löschen, nicht neu aufsetzen, nicht die Anwendung „schnell reparieren“. Server vom Netz trennen oder isolieren, Logs und Systemabbild sichern und eine strukturierte Vorfallsbearbeitung beginnen.
Was Sie nicht tun sollten
- Nur patchen und weitermachen. Ein Patch entfernt keine bereits eingeschleuste Schadsoftware.
- Verdächtige Dateien sofort löschen. Damit verschwinden Belege dafür, was passiert ist und welche Daten betroffen sein können.
- Den Server neu aufsetzen, bevor gesichert ist. Die Ursache bleibt unklar, und eine Hintertür in Datenbank oder Zugangsdaten überlebt die Neuinstallation.
- Alte Backups ungeprüft zurückspielen. Auch ein Backup kann die Hintertür bereits enthalten.
- Zugangsdaten vergessen. Nach einer Codeausführung können Datenbank-Passwörter, API-Schlüssel und andere Zugangsdaten aus Konfigurationsdateien abgeflossen sein. Erneuern Sie sie nach der Bereinigung, nicht vorher, damit ein noch aktiver Angreifer die neuen nicht gleich mitliest.
Wenn sich der Verdacht bestätigt
Dann geht es um mehr als Technik. Prüfen Sie mit Ihrem Datenschutzbeauftragten, ob eine Meldung nach DSGVO nötig ist; die Frist beträgt 72 Stunden ab Kenntnis, Details unter DSGVO-Meldepflicht. Informieren Sie früh Ihren Cyberversicherer, falls vorhanden, und klären Sie mit einem Anwalt, ob Anzeige erstattet werden soll. Wir geben dazu allgemeine Hinweise, keine Rechtsberatung.
Wie hilft PHP SOS konkret?
Mit unserer Incident Response arbeiten wir einen Verdacht strukturiert ab:
- Sichern: Logs ab dem 20. Oktober und, wo nötig, ein Abbild des Systems, bevor etwas verändert wird.
- Untersuchen: Verhaltensanalyse von Dateien, Prozessen, Verbindungen und Konten; bei Bedarf gerichtsverwertbar mit IT-Forensik.
- Bereinigen und schließen: Hintertüren entfernen, PHP aktualisieren, Zugangsdaten erneuern, Server härten.
- Dokumentieren, bis der Vorfall abgeschlossen und dokumentiert ist, als Grundlage für Datenschutz, Versicherung und Geschäftsführung.
Häufige Fragen
Beweist das PHP-Update, dass mein Server sauber ist?
Nein. Ein Patch schließt die Lücke für die Zukunft, entfernt aber keine bereits eingeschleuste Schadsoftware. Er sagt auch nichts darüber, ob vor dem Patch jemand eingedrungen ist.
Gibt es einen Scanner, der PHP2Shell-Angriffe sicher erkennt?
Bisher nicht. Es gibt keine veröffentlichten, bestätigten Indicators of Compromise, nach denen ein Scanner gezielt suchen könnte. Malware-Scanner finden bekannte Webshells, die Bewertung eines Servers beruht aber auf Verhaltensanalyse.
Muss ich einen Verdacht der Datenschutzbehörde melden?
Das hängt davon ab, ob personenbezogene Daten betroffen sein können. Die DSGVO sieht für meldepflichtige Datenpannen eine Frist von 72 Stunden ab Kenntnis vor. Klären Sie das früh mit Ihrem Datenschutzbeauftragten oder einem Anwalt; wir geben dazu keine Rechtsberatung.
Soll ich den gehackten Server einfach neu aufsetzen?
Nicht als ersten Schritt. Sichern Sie zuerst Logs und, wenn möglich, ein Abbild des Systems. Wer sofort neu aufsetzt, verliert die Spuren, die zeigen, was passiert ist und welche Daten betroffen sein könnten.