Sie haben im Verzeichnis Ihrer Website eine Datei gefunden, die dort nicht hingehört. Vielleicht heißt sie `wp-conf.php` statt `wp-config.php`, vielleicht liegt sie im Uploads-Ordner zwischen den Bildern, vielleicht trägt sie einen völlig unauffälligen Namen und ist nur zwei Tage alt. Der erste Impuls ist, sie zu löschen. Genau das sollten Sie nicht tun – jedenfalls nicht als Erstes.
Dieser Beitrag erklärt, was Sie da vor sich haben und in welcher Reihenfolge Sie vorgehen.
Was eine Webshell ist
Eine Webshell ist eine kleine Datei, die Befehle entgegennimmt und auf dem Server ausführt. Sie wird über den Browser aufgerufen wie jede andere Seite, nur dass sie nicht Inhalte ausliefert, sondern tut, was ihr aufgetragen wird: Dateien lesen und schreiben, Programme starten, Verbindungen aufbauen.
Technisch ist das oft erstaunlich wenig Code – manchmal eine einzige Zeile. Entscheidend ist nicht ihre Größe, sondern wofür sie steht: Jemand hatte Schreibzugriff auf Ihr Website-Verzeichnis. Das ist die eigentliche Nachricht, nicht die Datei selbst.
Bei PHP2Shell war der Weg dorthin die Lücke in PHP. Die ließ sich mit dem Update am 21. Oktober schließen. Die Webshell bleibt davon unberührt – sie ist eine ganz normale Datei und läuft auf einem gepatchten Server genauso gut.
Warum Löschen der falsche erste Schritt ist
Drei Gründe, und jeder für sich würde reichen.
Sie vernichten die Antwort auf die wichtigste Frage. Aus Zeitstempel, Inhalt und den zugehörigen Protokolleinträgen lässt sich rekonstruieren, wann und wie jemand hereinkam. Ohne diese Information wissen Sie hinterher nicht, welche Sicherung noch sauber ist – und spielen womöglich eine ein, in der die Datei schon steckt.
Sie warnen den Angreifer. Wer eine Webshell platziert hat, prüft oft, ob sie noch erreichbar ist. Verschwindet sie, weiß er, dass er entdeckt wurde – und nutzt den zweiten Zugang, den er sich angelegt hat.
Eine gefundene Webshell ist selten die einzige. Das ist die unangenehmste Erfahrung aus solchen Fällen. Wer Schreibzugriff hatte, hat ihn meist mehrfach genutzt: eine offensichtliche Datei, eine versteckte, dazu eine Änderung in einer bestehenden Datei, die beim Durchsehen nicht auffällt. Wer die erste löscht und aufatmet, hat die anderen übersehen.
Die Reihenfolge
Schritt 1: Nichts anfassen, sichern
Bevor Sie irgendetwas verändern: eine Kopie des gesamten Website-Verzeichnisses, der Datenbank und der Protokolle – Webserver, PHP, und falls vorhanden die Systemprotokolle. Ablegen außerhalb des betroffenen Servers.
Wenn es eine virtuelle Maschine ist, genügt ein Schnappschuss. Das ist in Minuten erledigt und der einzige Schritt, den Sie später nicht nachholen können.
Schritt 2: Die Seite vom Netz nehmen
Jetzt, nicht vorher. Solange die Webshell erreichbar ist, kann jemand sie benutzen – auch während Sie prüfen. Abschalten heißt dabei: aus dem Internet nehmen, nicht löschen.
Eine Hinweisseite mit „Wir arbeiten an einem Sicherheitsupdate" ist besser als eine Fehlermeldung und ehrlicher als Schweigen.
Schritt 3: Zeitpunkt bestimmen
Das Änderungsdatum der gefundenen Datei ist der Anfang, aber nicht die Antwort – Zeitstempel lassen sich fälschen. Verlässlicher ist der Abgleich mit den Zugriffsprotokollen: Wann wurde diese Datei zum ersten Mal aufgerufen? Was geschah in den Minuten davor?
Bei PHP2Shell gibt es dafür ein brauchbares Muster: ungewöhnliche multipart-Anfragen, direkt gefolgt von Fehlern wegen überschrittener Speichergrenze. Mehr dazu in PHP2Shell-Angriff erkennen.
Das Ergebnis dieses Schritts ist ein Datum. Alles, was danach entstanden ist, gilt als nicht vertrauenswürdig.
Schritt 4: Suchen, was noch da ist
Jetzt wird vollständig gesucht, nicht punktuell:
- Abgleich mit einer Sicherung von vor dem Zeitpunkt. Der verlässlichste Weg. Was im Vergleich neu oder verändert ist, gehört angesehen.
- Zeitgesteuerte Aufgaben unter Linux und Windows.
- Benutzerkonten – im System, im CMS, im Shop, in der Datenbank.
- Veränderte Konfigurationsdateien, besonders solche, die bei jedem Start gelesen werden.
- Geplante Aufgaben in der Anwendung selbst, etwa WordPress-Cron-Einträge.
Schritt 5: Entscheiden – bereinigen oder neu aufbauen
Hier trennen sich zwei Wege, und die Entscheidung sollte nicht nach Aufwand fallen.
Bereinigen ist vertretbar, wenn der Eintrittsweg belegt ist, der Zeitraum klein, der Fund eindeutig und die Protokolle vollständig. Dann lässt sich sagen, was passiert ist.
Neu aufbauen ist die Antwort, wenn eine dieser Bedingungen fehlt. Der Grund ist unangenehm, aber klar: Sie wissen, was Sie gefunden haben. Sie wissen nicht, was Sie nicht gefunden haben.
Ein Neuaufbau heißt: frisches System, aktuelle PHP-Fassung, Anwendung aus geprüfter Quelle, Inhalte und Datenbank aus einer Sicherung von vor dem Zeitpunkt aus Schritt 3. Wie das geordnet abläuft, steht in Website vom Netz genommen.
Schritt 6: Zugänge erneuern
Alles, was auf dem Server lesbar war: Datenbankzugang, Schnittstellenschlüssel, Mailversand, Administratorkonten der Anwendung. Nicht nur das offensichtliche. Warum das so weit reicht, steht in Vom Webserver ins Firmennetz.
Schritt 7: Prüfen, ob personenbezogene Daten betroffen sind
Enthielt die Datenbank Kundendaten, Bestellungen oder Formularnachrichten, ist das keine rein technische Frage mehr. Dann gelten Fristen. Beziehen Sie Ihren Datenschutzbeauftragten oder Ihre Rechtsberatung früh ein – nicht erst, wenn die Seite wieder läuft.
Woran Sie eine Webshell erkennen
Falls Sie noch suchen: Es gibt keine zuverlässige Liste von Dateinamen, weil sie beliebig sind. Was sich stattdessen lohnt:
- Dateien im Uploads-Verzeichnis, die auf `.php` enden. Dort gehören Bilder und Dokumente hin, kein ausführbarer Code. Das ist der häufigste Fundort.
- Dateien mit Änderungsdatum aus dem fraglichen Zeitraum, ohne dass jemand gearbeitet hat.
- Zeichenfolgen wie `eval(`, `base64_decode(`, `assert(`, `preg_replace` mit `/e`, `system(`, `passthru(` – allein kein Beweis, in Kombination mit einem unerwarteten Fundort aber deutlich.
- Dateien, die viel länger sind, als ihr Zweck vermuten lässt, oder deren Inhalt aus einer einzigen sehr langen Zeile besteht.
Checkliste: erste Schritte
- Nichts löschen, nichts neu starten, nichts überschreiben
- Website-Verzeichnis, Datenbank und Protokolle außerhalb des Servers sichern
- Seite vom Internet nehmen, Hinweisseite setzen
- Zeitpunkt des Eintritts aus den Protokollen bestimmen
- Dateibestand gegen eine Sicherung von vor diesem Zeitpunkt vergleichen
- Zeitgesteuerte Aufgaben und Benutzerkonten in allen Systemen prüfen
- Entscheiden: bereinigen nur bei belegtem Eintrittsweg, sonst Neuaufbau
- Alle auf dem Server lesbaren Zugänge erneuern
- Bei personenbezogenen Daten Datenschutzbeauftragten einbeziehen
Wie DAVINCI unterstützt
Wir sichern die Beweise, bevor etwas verändert wird, bestimmen den Eintrittszeitpunkt und sagen Ihnen schriftlich, ob Bereinigen vertretbar ist oder ein Neuaufbau nötig – mit Prüfumfang, damit die Aussage trägt. Das übernimmt unser Incident Response. Wenn es jetzt brennt: IT-Notfall, rund um die Uhr. Für eine erste Einschätzung ohne Vorfall gibt es den Quick-Check.
Häufige Fragen
Können wir die Datei nicht einfach umbenennen statt löschen?
Besser als löschen, aber es ändert nichts an den Punkten zwei und drei: Der Angreifer merkt es ebenso, und die anderen Zugänge bleiben. Umbenennen ist eine Notmaßnahme, wenn Sie nicht sofort abschalten können – kein Ersatz für die Prüfung.
Unser Virenscanner hat nichts gefunden. Wie kann das sein?
Webshells sind meist auf die jeweilige Umgebung zugeschnitten und entsprechen keinem bekannten Fingerabdruck. Manche bestehen aus einer Zeile, die für sich betrachtet legitimer PHP-Code ist. Ein Scanner erkennt bekannte Schadprogramme, keine missbrauchten Sprachmittel.
Wie lange war die Datei schon da?
Das Änderungsdatum ist ein Hinweis, kein Beweis – es lässt sich setzen. Belastbar wird es erst im Abgleich mit Zugriffsprotokollen und einer Sicherung. Genau deshalb ist zentrale Protokollierung außerhalb des Servers so wertvoll; das BSI behandelt sie im Grundschutz-Baustein zur Protokollierung.
Müssen wir wirklich neu aufbauen? Das ist viel Arbeit.
Nicht zwingend. Wenn Eintrittsweg, Zeitraum und Fund klar sind und die Protokolle vollständig, ist Bereinigen vertretbar. Fehlt eines davon, wetten Sie darauf, dass Sie alles gefunden haben – und diese Wette verliert man in solchen Fällen regelmäßig.
Wir haben die Datei schon gelöscht. Was jetzt?
Dann fehlen Ihnen Informationen, aber nicht alle. Die Protokolle sind meist noch da, und der Abgleich mit einer Sicherung funktioniert weiterhin. Wichtig ist jetzt, nicht auch noch die Protokolle rotieren zu lassen – und ab hier nichts mehr zu verändern.
Verwandte Themen: Wer hier weiterdenkt, liest bei Website gehackt, Remote Code Execution und PHP2Shell weiter.
