Zum Hauptinhalt springen

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

  1. Erste Manipulation finden: Älteste verdächtige Datei, ältester fremder Benutzer, erste Spam-URL im Index.
  2. Dateizeitstempel (stat) helfen, sind aber fälschbar; ctime ist schwerer zu manipulieren als mtime.
  3. 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

Quellen und Dokumentation