Zum Hauptinhalt springen
How Can We Help?
< All Topics

Eine gründliche Malware-Bereinigung folgt einem festen Ablauf, nicht dem Bauchgefühl. Nach einem Hack ist der Reflex, schnell „die eine böse Datei“ zu löschen. Fast immer hinterlassen Angreifer aber mehrere Backdoors. Wer nicht gründlich vorgeht, ist nach wenigen Tagen wieder infiziert.

1. Eindämmen

  • Site in den Wartungsmodus setzen oder per Webserver/WAF für Besucher sperren (ausser eigene IP), wenn Besucher gefährdet sind (Weiterleitungen, Skimmer).
  • Bei Shops: Zahlungsanbieter informieren, wenn ein Skimmer möglich ist.
  • Keine weiteren Logins mit Admin-Konten von evtl. kompromittierten Rechnern.

2. Beweise sichern

tar czf /root/incident/files-$(date +%F).tgz /var/www/example
wp db export /root/incident/db-$(date +%F).sql
cp /var/log/nginx/*access* /var/log/php*-fpm* /root/incident/

Kopie ausserhalb des Webroots und möglichst ausserhalb des Servers ablegen. Die Logs werden für die Ursachenanalyse gebraucht.

3. Entscheiden: Restore oder Bereinigen

Gibt es ein Backup von vor der Kompromittierung, ist ein Restore meist schneller und sicherer. Aber: Die Lücke, die zum Hack führte, ist im Backup noch vorhanden. Sie muss vor dem erneuten Online-Gehen geschlossen werden. Zwischenzeitliche Inhalte und Bestellungen müssen ggf. manuell übernommen werden.

4. Dateien bereinigen

Bewährt hat sich: alles Bekannte neu installieren, nur Unbekanntes prüfen.

  1. Core ersetzen: wp core download --force --skip-content (Version passend) und danach Dateien im Webroot entfernen, die nicht zum Core gehören.
  2. Plugins und Themes aus offiziellen Quellen frisch installieren (Verzeichnisse löschen und neu herunterladen), nicht „updaten“.
  3. uploads/: alle PHP-, PHTML-, PHAR- und unerwarteten Dateien entfernen; .htaccess-Dateien prüfen.
  4. mu-plugins/, wp-content/-Root (z. B. advanced-cache.php, object-cache.php, db.php), wp-config.php und .htaccess Zeile für Zeile prüfen.
  5. Eigener Code mit Git abgleichen: git status, git diff.
  6. Scanner als Ergänzung (Wordfence CLI, Sucuri SiteCheck, Imunify/Maldet auf Server-Ebene), aber nicht als einzige Prüfung.

5. Datenbank bereinigen

  • Unbekannte Admins und Benutzer entfernen; Capabilities in wp_usermeta prüfen.
  • Injizierte Skripte in Beiträgen, Widgets und Options entfernen (wp db search).
  • Unbekannte Cron-Events löschen.
  • Kritische Optionen prüfen: siteurl, home, admin_email, default_role, users_can_register, active_plugins.

6. Alle Zugangsdaten erneuern

  • Passwörter aller WordPress-Benutzer mit erhöhten Rechten, Sessions beenden
  • Salts: wp config shuffle-salts
  • Datenbank-Passwort, SFTP/SSH (inkl. authorized_keys prüfen), Hosting-Panel
  • Application Passwords widerrufen
  • API-Keys (Zahlung, Mail, KI-Anbieter, Cloud-Speicher), die auf dem Server gespeichert waren

7. Lücke schliessen und wieder online gehen

Ursache gemäss Nach dem Hack: Ursachenanalyse und Prävention ermitteln, betroffene Plugins aktualisieren oder ersetzen, Härtung umsetzen, WAF aktivieren. Danach freischalten und eng überwachen.

8. Nachbereitung

  • Google Search Console: Sicherheitsproblem als behoben melden, Spam-URLs entfernen lassen.
  • Blacklist-Entfernung beantragen.
  • Prüfen, ob Personendaten betroffen sind: Je nach Fall besteht nach nDSG eine Meldepflicht an den EDÖB bzw. nach DSGVO an die Aufsichtsbehörde.

Weiterführende Artikel

Quellen und Dokumentation

Schlagwörter: