Es sind Sommerferien – und mittendrin die Entdeckung, dass eine Website seit Monaten gehackt war, ohne dass es irgendjemand gemerkt hatte.

Wie alles anfing: ein Blogartikel und ein ungutes Gefühl

Vor ein paar Tagen saß ich genau an diesem Blog und habe zum Thema WordPress-Sicherheit recherchiert. Dabei bin ich über Berichte zur aktuellen Angriffswelle gestolpert – eine Agentur schrieb zum Beispiel, dass nach der Lücke rund ein Viertel ihrer betreuten Websites schon kompromittiert war. Das Muster dahinter ist immer dasselbe: erst ein Angriff auf eine einzelne Seite, dann prüft jemand vorsichtshalber alle – und findet prompt die nächsten.

Mein Gedanke war also: Vielleicht sollte ich das auch mal tun. Am Vortag hatte ich schon eine Warnung bei einer Kundin geklärt (die ganze Geschichte dazu steht im Ratgeber-Beitrag). Nur standen an diesem Tag eben Sommerferien und ein Tierparkbesuch auf dem Plan, beide Kinder zu Hause. Also bin ich trotzdem los – aber mit diesem unguten Gefühl im Nacken: Das musst du unbedingt noch prüfen.

17 Uhr: die nüchterne Erkenntnis

Zurück zu Hause habe ich mich dann durch die restlichen Seiten geklickt. Und auf einer davon war es plötzlich so weit: ein Admin-Benutzer, den niemand angelegt hatte, mit so einem verräterischen Namen wie „Nxploited“.

Kein Fehlalarm. Ein bestätigter, echter Angriff.

Warum so ein Angriff so tückisch ist

Das wirklich Unheimliche daran: Die Seite lief im Alltag völlig normal weiter. Keine sichtbaren Fehler, keine Warnung, einfach nichts. Und genau darauf sind solche Angriffe ja ausgelegt – sie wollen unsichtbar bleiben.

Im Rückblick passten sogar ein paar Dinge ins Bild: Mein Backup-Tool hing auf dieser Seite immer wieder, der Server brach öfter ab, und ein Caching-Plugin zerschoss bei der Aktivierung die Seite – auffällig vor allem deshalb, weil das erst nach einem Update plötzlich auftrat. Ob das nun wirklich mit dem Befall zu tun hatte oder einfach am Setup der Seite lag, lässt sich im Nachhinein ehrlich gesagt nicht sicher sagen. Vorher hatte ich es jedenfalls dem günstigen Hosting zugeschrieben – und nicht einem Angriff.

Und dann kam die eigentliche Ernüchterung: Der Scan zeigte gar keinen frischen Angriff von letzter Woche. Die Spuren führten zurück auf den 17. Mai. Das heißt auch: Es war nicht die aktuelle wp2shell-Lücke – die war nur der Anlass, der mich überhaupt hat hinschauen lassen. Reingekommen sind die Angreifer sehr wahrscheinlich über eine kritische Lücke im Plugin „Burst Statistics“, die im Mai bekannt wurde. Über sie konnten Unbefugte sich einfach als Admin ausgeben und neue Admin-Konten anlegen – genau so ein untergeschobenes Konto war ja der erste Hinweis. Hinterlassen haben sie ein gefälschtes Plugin, das als Backdoor diente.

Was ich hatte – und woran es wirklich lag

Auf den ersten Blick sieht das jetzt so aus, als hätte da einfach niemand richtig hingeschaut. Aber so einfach ist es eben nicht, und das ist mir wichtig:

• Serverseitig liefen täglich vollständige Backups. Der Haken dabei: Der Hoster hält sie nur rund zwei Monate vor. Vor dem mutmaßlichen Befall am 17. Mai gab es dadurch schlicht keinen Stand mehr, auf den ich hätte zurückgehen können.
• Und selbst wenn – ein so weit zurückliegendes Backup hätte viel zu viele legitime Änderungen verworfen. Einfaches Zurückspielen war also ohnehin keine echte Option.
• Zusätzlich sichere ich standardmäßig mit UpdraftPlus. Genau dieses System hing auf dieser Seite aber immer wieder – was ich damals dem günstigen Hosting zugeschrieben habe. Im Rückblick war das vermutlich schon ein Symptom des Befalls: Der Angriff hat die normalen Sicherungen ausgebremst.
• Ein Scan lief durchaus – nur eben auf Serverebene über cPanel, und der war unauffällig. Und genau das ist mein wichtigstes Learning: Ein Server-Scan allein reicht nicht. Es braucht ein Tool, das gezielt die WordPress-Dateien prüft und weiß, was da eigentlich nicht hingehört.

Es ist die unbequeme Wahrheit über diese Art Angriff: Er läuft ganz gezielt an Standard-Backups und Server-Scans vorbei – und bremst die Sicherungen dabei sogar noch aus.

Was ich getan habe – und wo ich die Grenze gezogen habe

In so einer Situation zählt vor allem die Reihenfolge, nicht die Geschwindigkeit:

• Sofort eindämmen – alle Seiten in den Wartungsmodus.
• Kundin informieren.
• Beweise sichern und den kompletten Befund sauber dokumentieren.

Und dann kam die unbequeme, aber wichtigste Entscheidung: Eine Bereinigung in diesem Umfang gehört in die Hände eines spezialisierten Dienstes. Denn eine einzige übersehene Hintertür reicht, damit alles wieder von vorn losgeht. Die eigene Grenze zu kennen und kontrolliert zu übergeben, ist für mich Teil der Professionalität – und nicht das Gegenteil davon.

Wie es ausging

Der spannendste Teil ist zum Glück der langweiligste: Der beauftragte Dienst hat die betroffene Seite bereinigt – das gefälschte Plugin und die Backdoor sind weg –, die Website auf den neuesten Stand gebracht (inklusive Theme) und frische, saubere Backups angelegt. Nach ein paar Stunden kam die Entwarnung: Die Seite darf wieder aus dem Wartungsmodus.

Und genau so soll es sein: kein Drama, keine schlaflosen Nächte – weil der Fall rechtzeitig in die richtigen Hände kam. Für mich ist das die eigentliche Bestätigung, dass die Entscheidung zur Übergabe richtig war.

Worauf du danach achten solltest

Wie so eine Bereinigung genau abläuft, ist von Dienstleister zu Dienstleister unterschiedlich – nicht jeder übernimmt automatisch alle Schritte. Sobald die Seite wieder online und sauber ist, lohnt es sich deshalb, gezielt zu prüfen:

• Läuft die Seite auf dem neuesten Stand? Stell sicher, dass das aktuelle Sicherheitsupdate wirklich eingespielt ist – sonst bleibt die eigentliche Lücke offen und der nächste Angriff steht schon vor der Tür.
• Sind alle Zugänge erneuert? Wenn die Hintertüren zu sind, gehören die Passwörter neu gesetzt – für WordPress, den Server und die E-Mail-Postfächer. API-Schlüssel sowie Plugin- und Theme-Anbindungen erneuerst du am besten gleich mit.
• Nutz die Gelegenheit zum Aufräumen. Ungenutzte Plugins und Themes fliegen raus – weniger Ballast heißt weniger Angriffsfläche. (Wie so ein „Website-Frühjahrsputz“ aussieht, zeige ich dir bald in einem eigenen Beitrag.)

Was ich daraus mitnehme

• Ein Angriff kündigt sich nicht an. Eine Seite kann monatelang normal laufen und trotzdem kompromittiert sein.
• Ohne laufenden Sicherheits-Scanner fällt so etwas fast nie rechtzeitig auf. Regelmäßiges Scannen – auf WordPress-Ebene, nicht nur am Server – ist kein „nice to have“.
• Plugins sind ein Haupt-Einfallstor. Selbst ein beliebtes, seriöses Plugin kann über Nacht zur offenen Tür werden – halte deshalb alles aktuell und wirf raus, was du nicht wirklich brauchst.
• Im Ernstfall zählt Reihenfolge statt Tempo: erst eindämmen und sichern, dann analysieren, dann sauber bereinigen (lassen).