Kurz gesagt: Eine Webshell erkennen Sie an neuen oder veränderten PHP-Dateien an untypischen Orten, an fremden Prozessen des Webserver-Benutzers und an ungewöhnlichen Verbindungen. Sichern Sie Spuren, bevor Sie etwas löschen, und stellen Sie den Code aus einer sauberen Quelle wieder her. Ein Patch allein entfernt keine Hintertür.
Warum Webshells nach PHP2Shell ein Thema sind
Die Lücken CVE-2026-109618 und CVE-2026-109619 in PHP selbst erlauben die Ausführung von Schadcode aus der Ferne ohne Anmeldung. Ein naheliegendes Ziel nach einem erfolgreichen Angriff ist eine dauerhafte Hintertür, also eine Webshell. Sie bleibt auch dann bestehen, wenn PHP inzwischen aktualisiert ist.
Laut Medienberichten wurde ein erster Angriffsversuch schon am 17.10.2026 beobachtet, die Patches folgten am 21.10. Wer in diesem Zeitraum verwundbar war, sollte gezielt nachsehen. Bestätigte Indicators of Compromise sind bisher nicht veröffentlicht. Die Suche stützt sich deshalb auf Auffälligkeiten im Verhalten, nicht auf eine fertige Liste.
Wenn Sie auf einem Server mit Kundendaten eine Webshell finden: nichts überstürzt löschen. Erst Beweise sichern, dann den Server isolieren und die weitere Bearbeitung planen.
Wie Sie eine Webshell erkennen: Dateien prüfen
Die meisten Webshells sind PHP-Dateien im Webverzeichnis. Auffällig sind Dateien, die nach dem 17.10. neu entstanden oder geändert wurden, PHP-Dateien in Upload- und Cache-Ordnern sowie Dateien mit verschleiertem Code. Die folgenden Befehle verändern nichts, sie listen nur auf:
# PHP-Dateien, die seit dem 17.10.2026 geändert wurden
find /var/www -type f -name "*.php*" -newermt "2026-10-17" -ls
# PHP-Dateien in Upload-, Cache- oder Tmp-Ordnern
find /var/www -type f -name "*.php*" \( -path "*upload*" -o -path "*cache*" -o -path "*tmp*" \) -ls
# Typische Verschleierung: eval in Kombination mit Dekodierung
grep -rlE "eval\s*\(\s*(base64_decode|gzinflate|str_rot13|gzuncompress)" /var/www --include="*.php"
# Ungewöhnlich lange Zeilen deuten oft auf gepackten Code hin
grep -rlE ".{3000,}" /var/www --include="*.php"
Treffer sind Hinweise, keine Beweise. Manche Plugins nutzen legitim kodierten Code. Vergleichen Sie verdächtige Dateien mit dem Originalpaket des Herstellers. Am verlässlichsten ist ein Abgleich gegen Prüfsummen oder ein Versionskontrollsystem wie Git:
# Abweichungen zum letzten bekannten Stand im Git-Repository
git -C /var/www/projekt status --porcelain
Ein Zeitstempel kann gefälscht sein. Verlassen Sie sich deshalb nicht allein auf das Änderungsdatum einer Datei.
Welche Merkmale eine Datei verdächtig machen
| Merkmal | Warum es auffällt |
|---|---|
| PHP-Datei in einem Upload- oder Bilderordner | Dort sollten nur Medien liegen |
Doppelte Endung wie .jpg.php oder .php.png |
Tarnung als harmlose Datei |
| Sehr lange Zeilen ohne Umbruch | Typisch für gepackten oder verschlüsselten Code |
| Dateiname ähnlich einer Kerndatei, aber nicht im Originalpaket | Tarnung im bekannten Umfeld |
| Eigentümer oder Rechte weichen von Nachbardateien ab | Datei wurde auf anderem Weg angelegt |
Je mehr Merkmale zusammenkommen, desto höher ist die Wahrscheinlichkeit eines Fundes. Öffnen Sie verdächtige Dateien nur als Text, nie über den Browser, denn ein Aufruf über die Website würde den Code ausführen.
Prozesse, Verbindungen und Cronjobs prüfen
Eine aktive Webshell hinterlässt oft Spuren außerhalb des Dateisystems. Der Webserver-Benutzer, etwa www-data, apache oder nginx, startet normalerweise keine Shells, Netzwerkwerkzeuge oder Kompilierer.
# Prozesse der typischen Webserver-Benutzer
ps -eo user,pid,ppid,lstart,cmd | grep -E "^(www-data|apache|nginx)"
# Offene Netzwerkverbindungen mit zugehörigem Prozess
sudo ss -tunap | grep -E "php|www-data|apache|nginx"
# Geplante Aufgaben des Webserver-Benutzers
sudo crontab -u www-data -l
ls -la /etc/cron.d /var/spool/cron 2>/dev/null
Auffällig sind dauerhafte ausgehende Verbindungen zu unbekannten Zielen, Prozesse mit kryptischen Namen und Cronjobs, die Dateien aus dem Internet nachladen. Prüfen Sie außerdem die Zugriffslogs auf Anfragen an Dateien, die es vorher nicht gab. Wie das geht, beschreibt der Ratgeber Webserver-Logs nach einem Angriff auswerten.
Spuren sichern, bevor Sie entfernen
Wer zuerst löscht, verliert die Antwort auf die wichtigsten Fragen: Wie kam der Angreifer hinein, was hat er gesehen, welche Daten sind betroffen? Diese Antworten brauchen Sie für eine mögliche DSGVO-Meldung, für Versicherer und für die Entscheidung, ob weitere Systeme gefährdet sind.
Sinnvolle Reihenfolge:
- Zustand dokumentieren: Prozessliste, Netzwerkverbindungen, angemeldete Benutzer.
- Verdächtige Dateien und Logs mit Prüfsumme kopieren, ohne sie zu öffnen oder auszuführen.
- Wenn möglich, ein Abbild des Systems oder einen Snapshot der virtuellen Maschine anlegen.
- Den Server vom Netz nehmen oder den Zugriff stark einschränken.
Bei Systemen mit sensiblen Daten oder möglichem Rechtsstreit sollte die Sicherung forensisch sauber erfolgen. Hintergründe dazu finden Sie unter IT-Forensik nach einem Webserver-Angriff.
Webshells sauber entfernen
Das Löschen einer einzelnen Datei ist selten das Ende. Angreifer legen häufig mehrere Zugänge an: weitere Dateien an versteckten Orten, Einträge in Konfigurationsdateien wie .htaccess oder .user.ini, neue Admin-Konten in der Anwendung oder Cronjobs. Eine verlässliche Bereinigung folgt diesen Schritten:
- PHP auf einen behobenen Stand bringen (8.5.12, 8.4.27, 8.3.36, 8.2.35 oder bestätigter Backport) und alle PHP-Prozesse neu starten.
- Anwendungscode aus einer sauberen Quelle neu aufsetzen, statt einzelne Dateien zu reparieren.
- Nur geprüfte Inhalte wie Uploads und Datenbank übernehmen und dort gezielt nach eingeschleustem Code suchen.
- Alle Zugangsdaten wechseln: Datenbank, SSH, FTP, Admin-Konten, API-Schlüssel.
- Schreibrechte des Webservers auf das Nötigste begrenzen und PHP-Ausführung in Upload-Ordnern unterbinden.
Für WordPress gibt es eigene typische Verstecke, die der Ratgeber Backdoors in WordPress finden beschreibt. Danach sollte die Website eine Zeit lang enger überwacht werden, um einen erneuten Zugriff früh zu bemerken.
Wie hilft PHP SOS konkret?
- Wir sichern Logs, Dateien und Systemzustand nachvollziehbar, bevor etwas verändert wird.
- Wir suchen Hintertüren in Dateien, Datenbank, Cronjobs und Konfiguration und ordnen Funde ein.
- Wir setzen die Anwendung aus sauberer Quelle neu auf, wechseln Zugänge und härten den Server.
- Wir dokumentieren den Vorfall, bis er abgeschlossen ist, als Grundlage für Meldungen und Versicherer.
Den Ablauf einer Bereinigung beschreibt die Leistung Malware und Webshells entfernen lassen.
Häufige Fragen
Was ist eine Webshell?
Eine Webshell ist eine eingeschleuste Datei, meist PHP, über die Angreifer den Server aus der Ferne steuern können. Sie tarnt sich oft als harmlose Datei mit unauffälligem Namen und bleibt auch nach einem Update aktiv.
Findet ein Virenscanner jede Webshell?
Nein. Scanner erkennen bekannte Muster, neue oder stark verschleierte Varianten rutschen durch. Zu PHP2Shell gibt es zudem keine veröffentlichten, bestätigten Indicators of Compromise, deshalb ist Verhaltensanalyse wichtiger als eine Signaturliste.
Reicht es, die gefundene Datei zu löschen?
Meist nicht. Angreifer legen oft mehrere Zugänge an, etwa weitere Dateien, Cronjobs oder neue Admin-Konten. Ohne Ursachenanalyse und Wechsel aller Zugangsdaten ist ein erneuter Zugriff wahrscheinlich.
Muss ich nach einem Webshell-Fund etwas melden?
Wenn personenbezogene Daten betroffen sein können, kann eine Meldepflicht nach DSGVO bestehen, in der Regel binnen 72 Stunden. Klären Sie das mit Ihrem Datenschutzbeauftragten oder einem Anwalt; dies ist keine Rechtsberatung.