Ich wurde gehackt. Obwohl ich alles richtig gemacht habe.
Was ein kompromittiertes WordPress-Plugin über IT-Sicherheit und Resilienz lehrt.
Ein automatischer Alarm hat mich darauf aufmerksam gemacht, dass mit meiner Website etwas nicht stimmt. Kein Hinweis, kein offensichtlicher Fehler — nur eine Anomalie im Monitoring, die ich mir dann näher angeschaut habe. Was ich gefunden habe: Besucher wurden beim ersten Seitenaufruf still auf externe Seiten weitergeleitet. Alibaba, irgendwas mit Zahlung. Wer die Seite kannte und öfter besuchte, hat zunächst nichts gemerkt. Genau so sind diese Angriffe konzipiert.
Das war riemer-consulting.de. Meine eigene Seite. Und ich berate Unternehmen unter anderem zu genau diesem Thema.

Was war passiert
Das Plugin Slider Revolution hatte eine bekannte Sicherheitslücke, eine CVE, die öffentlich dokumentiert war. Das Plugin war auf dem aktuellen Stand der zu diesem Zeitpunkt verfügbaren Version. Der Patch existierte noch nicht. Automatisierte Scanner hatten die Lücke trotzdem gefunden und ausgenutzt, bevor ich überhaupt von ihr wusste.
Der Schadcode landete in der Datei wp-blog-header.php, tief im WordPress-Core, obfuskiert über eval(base64_decode(…)). Ohne aktives Monitoring wäre das lange unentdeckt geblieben.
Was ich gemacht habe
Ich habe Wordfence installiert und einen vollständigen Scan gestartet. Die infizierte Datei wurde sofort gefunden. Wordfence hat die Core-Datei über die Repair-Funktion wiederhergestellt, dann habe ich Slider Revolution deinstalliert und durch ein natives Avada-Element ersetzt. Anschließend WordPress Secret Keys erneuert, zweiter Scan, null Bedrohungen. Gesamtzeit von Entdeckung bis zur sauberen Seite: unter einer Stunde.
Das war kein Glück. Das war das Ergebnis davon, dass Monitoring und Backup-Strukturen vorher bereits vorhanden waren. Ohne das hätte ich wahrscheinlich noch Tage gebraucht, um überhaupt zu merken, was los ist.
Warum „alles aktuell halten“ allein nicht reicht
Das ist der Punkt, der mich an diesem Vorfall am meisten beschäftigt hat. Ich hatte nichts falsch gemacht. WordPress war aktuell, Plugins waren aktuell, Backups liefen. Und es hat trotzdem gereicht.
CVEs werden veröffentlicht, bevor Patches existieren. Automatisierte Scanner finden betroffene Websites innerhalb von Stunden. Das Angriffsfenster ist real und es betrifft jeden, der öffentlich erreichbare Software betreibt. Die Frage ist nicht ob man getroffen wird, sondern wann und wie schnell man es merkt und reagiert.
Was das mit Business Continuity zu tun hat
In der BCM-Beratung geht es nicht darum, Ausfälle zu verhindern. Es geht darum, handlungsfähig zu bleiben, wenn Prävention nicht gereicht hat. Genau das war hier der Fall.
Erkennungsfähigkeit durch Monitoring, klare Reaktionsschritte ohne Improvisation unter Druck, Wiederherstellung aus sauberen Backups, anschließende Nachbereitung mit konkreten Verbesserungen. Das ist kein Großunternehmensthema. Das ist ein Denkmuster, das auch für eine einzelne Website gilt.
Was ich daraus mitgenommen habe
Security-Scanner gehören installiert, bevor etwas passiert. Externe Backups sind kein Luxus, ein Backup auf demselben Server schützt nicht gegen Kompromittierung. Jedes Plugin ist ein potenzieller Angriffsvektor, und wo eine native Funktion denselben Job macht, sollte man die nehmen.
Und das Wichtigste: Wer im Kopf hat, was er im Ernstfall tut, verliert keine Zeit damit, es erst herauszufinden. Selbst wenn das nur drei aufgeschriebene Schritte sind.

