WooCommerce gehackt: Vier Wochen unbemerkt, trotz Sicherheits-Plugin (ein echter Fall)

Mehr als drei Wochen lang hatten Fremde die volle Kontrolle über einen WooCommerce-Shop. Das installierte Sicherheits-Plugin hatte die Schadsoftware sogar erkannt und Alarm geschlagen. Nur gelesen hat den Alarm zunächst niemand. Dieser Beitrag zeigt anhand eines realen, vollständig anonymisierten Falls, wie ein Angriff auf einen Onlineshop wirklich abläuft, warum er so lange unentdeckt blieb und weshalb ein Fall auch nach einer sauberen Bereinigung noch nicht abgeschlossen ist.

Die Ausgangslage

Ein mittelständischer WooCommerce-Shop entdeckt eines Tages Werbe-Spam für Online-Casinos auf der eigenen Website. Der Website-Betreuer reagiert schnell und gründlich: Schadsoftware entfernt, fremde Konten gelöscht, Passwörter geändert, System aktualisiert, Sicherheitsregeln verschärft. Ein sauberes Stück Arbeit, das unsere spätere Prüfung ausdrücklich bestätigt hat.

Zur Absicherung beauftragt der Shop zusätzlich eine unabhängige forensische Analyse. Und die fördert zutage, wie viel in den Wochen davor passiert war und welche zwei Risiken auch nach der Bereinigung noch offen waren.

Was ist eine Backdoor in WordPress?

Eine Backdoor ist ein vom Angreifer hinterlegter, versteckter Zugang zu einer Website, der unabhängig von regulären Logins funktioniert. In WordPress wird sie oft als getarntes Plugin oder versteckte Code-Datei eingerichtet. Die Folge: Selbst wenn alle Passwörter geändert werden, behält der Angreifer die Kontrolle, solange der Schadcode auf dem System liegt.

In diesem Fall kam eine Besonderheit dazu: Die Schadplugins blendeten sich selbst aus der Plugin-Übersicht aus und versteckten die von ihnen angelegten Administrator-Konten aus der Benutzerliste. Wer nur in die WordPress-Verwaltung schaute, sah einen völlig normalen Shop.

Der Fall chronologisch: Was die Forensik ergab

Das Vorspiel: Tagelanges Anklopfen

Die Auswertung der Server-Logs über rund 30 Tage zeigte, dass dem Einbruch eine mehrtägige Vorbereitungsphase vorausging. Automatisierte Angriffe versuchten, Admin-Passwörter zu erraten: Im Gesamtzeitraum blockierte der Server über 13.000 Login-Versuche. Parallel klopften Scanner systematisch bekannte Schwachstellen ab, darunter auch Lücken in Plugins, die auf diesem Shop gar nicht installiert waren. Angreifer probieren schlicht alles durch. Das Passwort-Raten blieb erfolglos.

Der Einbruch: Eine Sekunde

Erfolgreich war ein anderer Weg. Der Angreifer schickte eine speziell präparierte Anfrage an eine technische Schnittstelle von WordPress (admin-ajax), die auch ohne Anmeldung erreichbar ist. Eine Sekunde später existierte im Shop ein neues Administrator-Konto, das niemand angelegt hatte. Kein geknacktes Passwort, kein gestohlener Zugang: Die Angreifer-Adresse hat sich im gesamten Zeitraum kein einziges Mal regulär eingeloggt. Ein einziger ungeschützter Endpunkt einer Zusatzfunktion reichte.

Die Einrichtung: Drei versteckte Admins, vier getarnte Schadplugins

Noch am selben Tag richtete sich der Angreifer häuslich ein: drei versteckte Administrator-Konten und vier als harmlose Erweiterungen getarnte Schadplugins, darunter eine Fernsteuerung (Webshell), mit der sich der Shop komplett kontrollieren ließ, und eine Backdoor, die sich nach einer Deaktivierung selbstständig wieder aktiviert. Diese Fernsteuerung wurde in den folgenden drei Wochen nachweislich mehrfach genutzt. Sichtbar wurde davon nichts, bis auf den Casino-Spam, der schließlich zur Entdeckung führte.

Der ungelesene Alarm

Zwei Tage vor der Entdeckung hatte das installierte Sicherheits-Plugin die vier Schadplugins bei einem Scan korrekt als bösartig erkannt und mit höchstem Schweregrad gemeldet. Die Meldung blieb zunächst unbearbeitet. Die versteckten Admin-Konten meldete das Plugin dagegen gar nicht: Die Backdoors blendeten sie aktiv aus genau den Abfragen aus, mit denen Sicherheits-Tools nach verdächtigen Konten suchen.

Ein Sicherheits-Plugin ersetzt kein Monitoring. Eine Warnung, die niemand liest, schützt genauso wenig wie gar keine Warnung.

Der Schlüsselmoment: Wurden Kundendaten gestohlen?

Die wichtigste Frage jedes Shop-Betreibers. Und die Logs lieferten zunächst ein alarmierendes Bild: regelmäßige, minutengetaktete Massen-Abrufe von Bestelldaten über die Shop-Schnittstelle. Wer hier vorschnell urteilt, meldet einen großen automatisierten Datendiebstahl.

Die genaue Analyse ergab etwas anderes. Die Massen-Abrufe stammten von der legitimen, lange vor dem Angriff eingerichteten Warenwirtschafts-Anbindung des Shops: authentifiziert, regelmäßig, technisch erwartbar. Die einzigen weiteren großen Datenmengen, die den Server verließen, waren Sicherungskopien, die der eigene Betreuer im Zuge der Bereinigung herunterlud. Die Abgriff-Versuche des Angreifers über die Schnittstelle scheiterten dagegen durchweg an fehlenden Zugangsschlüsseln.

Nicht jeder Massen-Abruf von Bestelldaten ist ein Angriff. Legitime Warenwirtschafts-Anbindungen erzeugen ähnlichen Datenverkehr, was eine genaue Unterscheidung in den Logs nötig macht.

Entwarnung ist das trotzdem nicht. Über die Webshell hatte der Angreifer drei Wochen lang vollen Zugriff auf Dateien und Datenbank, und ein Auslesen über dieses Werkzeug hinterlässt in Standard-Logs nicht zwingend Spuren. Die ehrliche, belegbare Antwort lautet deshalb: Ein Datenabfluss ist nicht nachgewiesen, kann aber nicht ausgeschlossen werden und muss datenschutzrechtlich als möglich angenommen werden.

Genau diese Differenzierung ist der Kern professioneller Incident Response: weder „alles gut“ noch „Katastrophe“, sondern eine belastbare Aussage, die vor der Datenschutzbehörde trägt.

Warum „bereinigt“ noch nicht „abgeschlossen“ heißt

Die Bereinigung selbst war fachgerecht. Zwei Punkte blieben trotzdem offen, und beide sind typisch für Fälle wie diesen:

1. Das Restrisiko nach wochenlanger Fremdkontrolle. Wenn ein Angreifer über Wochen Code auf dem System ausführen konnte, lässt sich eine hundertprozentige Sauberkeit einer bereinigten Installation technisch nicht garantieren. Fachlicher Standard ist deshalb ein Neuaufbau auf verifiziert sauberer Basis, kombiniert mit der Rotation sämtlicher Zugangsdaten und Sicherheitsschlüssel, nicht nur der Admin-Passwörter.

2. Die verseuchten Backups. Auf dem Server lagen automatische Sicherungen aus dem Zeitraum der Kompromittierung, inklusive aller Backdoors und versteckten Konten. Wird eine solche Sicherung später versehentlich wieder eingespielt, ist der Angreifer mit einem Schlag zurück im System. Diese Stände müssen sicher gelöscht werden; nur der nachweislich saubere Referenzstand und bewusst als Beweismittel aufbewahrte Kopien (getrennt und offline) bleiben erhalten.

Ein Glücksfall der Forensik verdient noch Erwähnung: Eine ältere Sicherung von vor dem Einbruch war nachweislich sauber. Erst dieser Referenzstand machte es möglich, den Einbruchszeitpunkt präzise einzugrenzen und zu belegen, was der Angreifer verändert hatte.

Was bei einem Hack-Verdacht wirklich zu tun ist

1. Ruhe bewahren, nichts löschen: Jede vorschnelle Bereinigung vernichtet Beweise, die du für die Aufklärung und eine mögliche Datenschutz-Meldung brauchst.
2. Beweise sichern: Server-Logs, Dateisystem-Zustand und vorhandene Backups sichern, bevor irgendetwas verändert wird.
3. Read-only analysieren: Erstsichtung ohne Eingriff ins Live-System. Einstiegsweg, fremde Konten und getarnte Plugins identifizieren, auch solche, die sich aus den Übersichten ausblenden.
4. Datenlage ehrlich bewerten: In den Logs legitimen Datenverkehr (Warenwirtschaft, eigene Backups) von echten Abgriff-Versuchen unterscheiden, statt vorschnell zu urteilen.
5. Sauber neu aufbauen: Nach wochenlanger Fremdkontrolle ist ein Neuaufbau aus verifiziert sauberem Stand zuverlässiger als Nachbessern. Alle Zugangsdaten und Sicherheitsschlüssel rotieren, Zwei-Faktor-Anmeldung einrichten.
6. Backups prüfen und aufräumen: Sicherungen aus dem kompromittierten Zeitraum sicher löschen, saubere Referenz und Beweismittel getrennt aufbewahren.
7. Datenschutz klären: Betroffene Daten eingrenzen und die Meldefrage mit dem Datenschutzbeauftragten bewerten.

DSGVO: Wann ein Hack meldepflichtig ist

Sobald ein Angreifer Zugriff auf Systeme mit personenbezogenen Daten hatte, steht Artikel 33 DSGVO im Raum: die Meldung an die zuständige Landesdatenschutzbehörde, in der Regel innerhalb von 72 Stunden nach Bekanntwerden. Ob zusätzlich die betroffenen Kundinnen und Kunden nach Artikel 34 DSGVO informiert werden müssen, hängt vom Risiko im Einzelfall ab.

In diesem Fall haben wir die technische Feststellung strikt von der rechtlichen Bewertung getrennt. Unsere Aufgabe: die belegte Timeline, der dokumentierte Vollzugriff über drei Wochen, die ehrliche Einordnung der Datenlage (kein nachgewiesener Abfluss, aber nicht ausschließbar), die Eingrenzung des betroffenen Datenbestands. Die Bewertung, was daraus rechtlich folgt, lag beim Datenschutzbeauftragten. Diese saubere Trennung macht eine Meldung tragfähig: Die Behörde bekommt Fakten statt Vermutungen.

Wichtig: Das ist eine allgemeine Einordnung auf Wissensebene, kein Rechtsrat. Die Bewertung im Einzelfall gehört zu Datenschutzbeauftragten oder Fachanwälten.

Das Ergebnis

Am Ende der Analyse lag vor:

• eine vollständige, log-gestützte Timeline vom letzten sauberen Stand über den Einbruch bis zur Bereinigung
• der belegte Einstiegsweg über einen ungeschützten Schnittstellen-Endpunkt, inklusive sauber ausgeschlossener Alternativ-Hypothesen
• der Nachweis der versteckten Konten und Backdoors über mehrere Backup-Generationen
• die ehrliche Datenlage: kein nachgewiesener Abfluss, aber als möglich anzunehmen
• die fachliche Bestätigung der durchgeführten Bereinigung plus die zwei offenen Punkte Neuaufbau und Backup-Bereinigung
• eine belastbare Grundlage für die Meldung an die zuständige Landesdatenschutzbehörde und für die Entscheidung über die Kundeninformation

Lessons Learned

• Ein Sicherheits-Plugin allein reicht nicht. Die Schadsoftware wurde korrekt erkannt und gemeldet. Ohne jemanden, der die Meldungen liest und reagiert, verpufft der beste Scanner.
• Was du im Backend siehst, ist nicht alles. Moderne Backdoors verstecken sich und ihre Admin-Konten aktiv, auch vor Sicherheits-Tools. Verlässliche Antworten liefern nur Logs, Dateisystem und Datenbank.
• Backups sind Gold und Zeitbombe zugleich. Der saubere Referenzstand machte die gesamte Beweisführung erst möglich. Die Sicherungen aus dem verseuchten Zeitraum wären beim Wiedereinspielen der direkte Weg zur Neuinfektion.
• Ehrlichkeit trägt weiter als Alarmismus. „Nicht nachgewiesen, aber nicht ausschließbar“ ist unbequemer als „alles gut“ oder „alles weg“, aber es ist die einzige Aussage, die vor Behörde und Kunden Bestand hat.

Häufige Fragen

Reicht es, nach einem WordPress-Hack die Passwörter zu ändern?

Nein. Wenn der Angreifer eine Backdoor hinterlassen hat, bleibt der Zugang oft bestehen, auch nach einem Passwortwechsel. Manche Backdoors legen gelöschte Admin-Konten selbstständig neu an, aktivieren sich nach einer Deaktivierung selbst wieder oder funktionieren ganz ohne Login.

Warum hat das Sicherheits-Plugin den Hack nicht verhindert?

Sicherheits-Plugins erkennen vieles, aber nicht alles, und sie handeln nicht von selbst. Im beschriebenen Fall wurde die Schadsoftware beim Scan korrekt gemeldet, die Warnung blieb aber zunächst ungelesen. Die versteckten Admin-Konten blieben sogar unentdeckt, weil die Backdoors sie aktiv aus den Prüf-Abfragen ausblendeten. Ohne aktives Monitoring bleibt jedes Sicherheits-Plugin Stückwerk.

Woran erkenne ich, ob mein Onlineshop noch kompromittiert ist?

Sichtbare Spam-Inhalte sind nur die Oberfläche. Ausschlaggebend ist die Prüfung auf versteckte Dateien, getarnte Plugins, unbekannte Administrator-Konten und ungewöhnliche Einträge in den Server-Logs. Da sich Backdoors aus den normalen Übersichten ausblenden können, reicht ein Blick in die WordPress-Verwaltung nicht aus.

Muss ich Backups nach einem Hack löschen?

Sicherungen aus dem Zeitraum der Kompromittierung enthalten die Schadsoftware und müssen sicher gelöscht werden, sonst droht beim Wiedereinspielen eine Neuinfektion. Aufbewahrt werden sollten nur nachweislich saubere Stände sowie bewusst als Beweismittel gesicherte Kopien, letztere getrennt vom Produktivsystem und offline.

Muss ich einen Hack meines Onlineshops den Behörden melden?

Sobald ein Zugriff auf Systeme mit personenbezogenen Daten möglich war, ist in der Regel eine Meldung an die zuständige Landesdatenschutzbehörde innerhalb von 72 Stunden angezeigt. Ob zusätzlich die betroffenen Kundinnen und Kunden informiert werden müssen, hängt vom Risiko im Einzelfall ab. Das ist eine allgemeine Einordnung, kein Rechtsrat.

Was ist nach einem bestätigten Hack der sicherste Weg?

In vielen Fällen ist ein sauberer Neuaufbau aus einem verifiziert unkompromittierten Stand zuverlässiger als selektives Nachbereinigen. Dazu gehören die Rotation sämtlicher Zugangsdaten und Sicherheitsschlüssel (nicht nur der Admin-Passwörter), Zwei-Faktor-Anmeldung für alle Administratoren und das Aufräumen kompromittierter Sicherungen.

Unsicher, ob dein Shop wirklich sauber ist?

Wenn dein Shop gehackt wurde oder du nach einer Bereinigung wissen willst, was wirklich passiert ist und ob noch etwas offen ist: Wir machen eine forensische Analyse, bevor Beweise verloren gehen, und liefern dir eine belastbare Grundlage für alle weiteren Entscheidungen.

→ WordPress-Notfall? Kurzfristige Erst-Sichtung anfragen

→ Dauerhaft überwacht mit der WordPress-Wartung