Eine Bereinigung ohne Ursachenanalyse ist nur eine Pause. Wird die Lücke nicht gefunden und geschlossen, wird die Site mit hoher Wahrscheinlichkeit erneut kompromittiert, oft innerhalb von Tagen.
Zeitleiste aufbauen
- Erste Manipulation finden: Älteste verdächtige Datei, ältester fremder Benutzer, erste Spam-URL im Index.
- Dateizeitstempel (
stat) helfen, sind aber fälschbar;ctimeist schwerer zu manipulieren alsmtime. - Access-Logs rund um diesen Zeitpunkt auswerten: Erster Request auf die Backdoor-Datei, davor auffällige POST-Requests auf Plugin-Endpunkte,
admin-ajax.php-Actions oder REST-Routen.
# Erster Zugriff auf eine bekannte Backdoor
grep -h 'wp-content/uploads/2026/10/cache.php' access.log* | sort | head
# Alles von der Angreifer-IP
grep -h '203.0.113.45' access.log* | sort -k4
Typische Ursachen und ihre Spuren
| Ursache | Spuren |
|---|---|
| Plugin-Schwachstelle | POST auf Plugin-Datei, AJAX-Action oder REST-Route kurz vor der ersten Backdoor; Plugin-Version war zu dem Zeitpunkt verwundbar |
| Gestohlene Admin-Zugangsdaten | Erfolgreicher Login von fremder IP, danach Plugin-Upload oder Editor-Nutzung |
| Gestohlene Session-Cookies (Infostealer) | Admin-Aktivität ohne vorherigen Login, oft mit echtem Benutzer |
| SFTP/SSH/Hosting-Panel | Dateien ohne entsprechende HTTP-Requests; Einträge in Auth-Logs oder Panel-Logs |
| Nulled Plugin/Theme | Backdoor-Code in einem Premium-Plugin aus inoffizieller Quelle |
| Nachbar-Site (Shared Hosting) | Gleichzeitiger Befall mehrerer Sites im selben Konto |
Hilfreich: Die Versionen der Plugins zum Zeitpunkt des Einbruchs mit Schwachstellendatenbanken (Patchstack, Wordfence Intelligence, WPScan) abgleichen.
Wenn keine Logs vorhanden sind
Dann bleibt nur, alle plausiblen Wege gleichzeitig zu schliessen: alle Plugins aktualisieren oder ersetzen, alle Zugangsdaten wechseln, Härtung umsetzen. Und für das nächste Mal: Logs länger aufbewahren und extern speichern.
Prävention: Lessons Learned umsetzen
- Wurde die Lücke zu spät gepatcht? Update-Prozess und Schwachstellen-Monitoring verbessern, virtuelles Patching einführen.
- Zugangsdaten? 2FA/Passkeys erzwingen, Admin-Accounts reduzieren, Geräte der Admins prüfen.
- Konnte sich die Malware ausbreiten? Dateirechte verschärfen (siehe Dateiberechtigungen),
DISALLOW_FILE_MODS, keine PHP-Ausführung in Uploads. - Wurde es spät bemerkt? Integritätsprüfung, Activity-Log und Alarme einrichten.
- Restore schwierig? Backup-Konzept nach 3-2-1 mit langer Aufbewahrung.
Dokumentation
Einen kurzen Incident-Bericht schreiben: Zeitleiste, Ursache, Auswirkungen, Massnahmen. Er ist Grundlage für Datenschutz-Abklärungen, Kundenkommunikation und hilft, beim nächsten Vorfall schneller zu reagieren.
Weiterführende Artikel
- Malware-Bereinigung Schritt für Schritt (Incident Response)
- Monitoring: Uptime, Logs und Integritätsprüfung
- Die WordPress-Bedrohungslandschaft: typische Angriffsvektoren