Webshell gefunden: Was in den ersten zwei Stunden zählt

Auf dem Webspace liegt eine PHP-Datei, die niemand erklären kann: angelegt in der Vorwoche, Name ohne Sinn, beim Öffnen ein Code, der Befehle annimmt. Eine Webshell. Jemand war bereits auf dem System und kann auf vertrautem Weg zurückkehren. Was jetzt zählt, bemisst sich in Stunden. Dieser Ratgeber sortiert die ersten zwei Stunden und zeigt, wie die Sauberkeit danach belegbar wird.

Eine Webshell ist kein Schadprogramm im klassischen Sinn, sondern ein Skript, das den Webserver selbst zum Eingangstor macht. MITRE ATT&CK führt die Technik unter T1505.003: dauerhafter Zugang über ein offen erreichbares Skript. Löschen allein genügt darum nicht; entschieden wird über die Schließung des Weges, der hierher führte.

Erst sichern, dann aufräumen

Die erste Regel klingt gegen die Intuition: Löschen Sie die Datei nicht sofort. Die Webshell ist Hintertür und Beweisstück in einem. Sie erzählt, wann jemand aktiv war, über welche Adresse und auf welchem Weg. Wer überstürzt löscht, verwischt die Spur, die er für Wiederherstellung und Meldung noch braucht.

Die erste Stunde gehört der Mitschrift: Wer hat wann was gefunden, an welchem Pfad. Sichern Sie die Logstände, bevor etwas geändert wird: Webserver, System, CMS, Aufgabenplaner. Das BSI hielt in seiner BeyondTrust-Warnung vom 16. Oktober 2026 fest, dass Angreifer Protokolle als Anti-Forensik löschen; forensische Daten sind vor Änderungen zu sichern. Wer seine Protokolle noch nirgends extern mitführt, exportiert heute den Bestand.

Dann die Grundsatzfrage: Isolation oder Weiterbetrieb? Isolieren Sie, so weit es geht, beschränken Sie die Verwaltungszugänge und beobachten Sie die Seite im Spielbetrieb. Ein Shutdown vernichtet den flüchtigen Zustand; eine Abschaltung nimmt dem Täter den Zugriff, Ihnen aber die Beobachtungschance.

Der Originalvergleich schlägt jede Vermutung

Nächste Frage: Was ist sonst verändert? Der Blick auf Einzeldateien irrt, der Vergleich mit dem Originalpaket ordnet. Prüfen Sie jede Komponente gegen ihre Quelle: Kern gegen Entwicklerpaket, Erweiterungen und Designs gegen Originalarchive, Uploads und Cache gegen Bestandsliste. Das Vorgehen samt Stolperfalle manipulierter Zeitstempel beschreibt der Beitrag Eingeschleuste PHP-Dateien: warum der Vergleich mit dem Originalpaket hilft.

Ein Vergleich zeigt meist mehr als die eine Shell: veränderte Dateien, zweite Kopien unter anderem Namen, bearbeitete Designs. Das BSI nennt dabei neue Administratorkonten, veränderte Erweiterungen und Auffälligkeiten in Änderungssätzen. Ergebnis der Stunde: eine Abweichungsliste mit Pfad, Zeitstempel und Einschätzung.

Ausbreitung prüfen: Ein Treffer ist selten der einzige

Wer eine Webshell hat, bleibt selten bei einem Ordner. Prüfen Sie die Aufgabenplaner unter Linux und Windows, die Autostarts, zusätzliche Konten und Gruppenmitgliedschaften, SSH-Schlüssel, Dienstkonten und API-Passwörter. Und fragen Sie, was sonst auf dem Server läuft: weitere CMS, Shops, Kundendatenbanken. Ein Shared-Server mit einer Webshell ist der Schlüsselbund zu allen Nachbarn.

Der BeyondTrust-Fall zeigt das Ineinandergreifen: Nach dem ersten Zugriff folgten laut BSI Webshell, Tunnel, administrative Kontrolle, Persistenz und der Abgriff gespeicherter Zugangsdaten. Für Ihre Website heißt das: Jeder Teil des Systems gilt als beteiligt, bis das Gegenteil belegt ist.

Zugänge und Schlüssel rotieren

Jede Berechtigung, die der Täter gesehen haben könnte, wird getauscht: alle CMS-Konten, nicht nur die Verwaltung, dazu Datenbank, SFTP oder SSH, Mailversand, API-Passwörter. Beenden Sie aktive Sitzungen. Bei Gateways gelten auch vermittelte Zugangsdaten als abgeflossen; das BSI verlangt ihre Rotation und die Prüfung nachgelagerter Systeme.

Der Fall „wp2shell" aus dem Juli 2026 zeigt, warum daran kein Weg vorbeiführt. Zwei Schwachstellen der WordPress-Standardinstallation ergaben erst kombiniert einen Angriff ohne Anmeldung: am 17. Juli der Patch, am Wochenende öffentliches Anschauungsmaterial, kurz darauf die ersten Ausnutzungen. Da die Kette mit einer SQL-Injektion begann, lagen danach alle Passwort-Hashes vor. Das BSI rät: Passwörter zurücksetzen, System isolieren, Beweissicherung beginnen, Neuaufsetzen mitdenken. Betroffen war der Kern, nicht eine Erweiterung.

Sauberkeit belegen, nicht erhoffen

Danach die Reparatur: eine Sicherung einspielen, die nachweislich vor der ersten Auffälligkeit entstand, oder neu aufbauen aus sauberer Quelle. Beides endet mit dokumentierter Gewissheit, nicht mit einem Gefühl. Warum eine Sicherung nur so viel wert ist wie ihre überwachte Wiederherstellbarkeit, erklärt der Beitrag Sicherungen überwachen: warum 'Auftrag erfolgreich' nicht reicht.

Dazu gehört das Protokoll: welcher Stand von wann, wohin zurückgespielt, welche Lücke seit wann geschlossen, wie geprüft. Und die Reihenfolge: erst die ausgenutzte Schwachstelle schließen, dann zurücksichern. Wer auf offener Lücke in den Altzustand zurückkehrt, bekommt die Hintertür gratis zurück. Eine Webanwendungs-Firewall ist ein sinnvoller Zwischenschild, das BSI nennt sie für kritische Seiten; Übergangsschutz, nicht Reparatur.

Danach: Dateiüberwachung mit Zeitachse statt stichprobenartigem Nachsehen

Die zweite Stunde endet mit einem reparierten System; die folgenden Tage entscheiden, ob das der letzte Notfall war. Webshells kehren zurück, wo ihre Ursache bleibt: veralteter Kern, verwaiste Erweiterung, breite Schreibrechte, ungelesene Protokolle. Drei Maßnahmen bleiben: eine Dateiüberwachung mit Zeitstempel für Kern, Erweiterungen und Designs, ein monatlich nachgezogenes Inventar und eine feste Wochenstunde für die Abweichungsliste. Die Übersicht Website-Sicherheit zeigt das Zusammenspiel.

PRAEMON übernimmt das Erfassen: Änderungen mit Zeitstempel, Belege neunzig Tage mit Zugriffsprotokoll, jeder Vorfall als Zeitachse. Was es nicht leistet: keine eigene rechtliche Bewertung und keine Rechtsberatung. Ob ein Vorfall meldepflichtig ist, entscheiden die Verantwortlichen; die Zeitachse liefert die Belege.

Checkliste: die ersten zwei Stunden

• Fund notieren: Pfad, Zeitstempel, Finder, Befund. Nichts löschen.
• Logstände sichern: Webserver, System, CMS, Aufgabenplaner; unverändert ablegen.
• Isolation oder Weiterbetrieb entscheiden und festhalten.
• Originalpaket vergleichen; Abweichungsliste mit Pfad und Zeitstempel anlegen.
• Ausbreitung prüfen: Planer, Autostarts, Konten, Schlüssel, Nachbarn auf dem Server.
• Zugänge rotieren: CMS, Datenbank, SFTP, SMTP, API; Sitzungen beenden.
• Schwachstelle schließen und testen, bevor zurückgesichert wird.
• Mit Datumsnachweis wiederherstellen; Prüfergebnis dokumentieren.

Nach dem Notfall bleibt eine Akte, die der nächsten Prüfung sagt, was passiert ist und wie damit umgegangen wurde. In diesem Moment wird Monitoring mehr als eine rote Lampe: nämlich Beleg.

Redaktioneller Hinweis vom 10.11.2026: BSI-Warnungen vom 20. Juli und 16. Oktober 2026, abgerufen am 10. November 2026; MITRE ATT&CK T1505.003 mit Stand 12. Mai 2026. Dieser Beitrag ist keine Rechtsberatung.