Gehackter WooCommerce Shop: so haben wir ihn bereinigt

Kurz gefasst: Der Inhaber meldete sich, weil Kunden auf eine fremde Seite weitergeleitet wurden. Ihm selbst erschien der Shop völlig normal. Wir fanden eine Backdoor im Uploads-Ordner, eine veränderte Theme-Datei, einen geplanten Task, der alles wiederherstellte, und ein Administratorkonto, das niemand angelegt hatte. Der Einstieg war ein veraltetes Versand-Plugin. Die Bereinigung dauerte knapp einen Tag, der Shop war nie offline, keine Bestellung ging verloren.

Dies ist die Schilderung eines echten Einsatzes. Angaben, die den Shop identifizierbar machen könnten, wurden verändert, denn darauf hat der Kunde ein Recht. Alles Technische ist so beschrieben, wie es tatsächlich ablief, weil ein konkreter Fall nützlicher ist als allgemeine Ratschläge.

Wie es anfing

Der Anruf kam am späten Nachmittag. Der Shopbetreiber erzählte, zwei Kunden hätten ihn am selben Tag gefragt, warum seine Seite sie auf eine fremde Werbeseite schicke. Er öffnete den Shop sofort auf seinem Rechner, und alles funktionierte einwandfrei. Startseite lud, Produkte waren da, Warenkorb lief. Er nahm an, die Kunden hätten die Seiten verwechselt.

Dann rief ein dritter an.

Ein gehackter WooCommerce Shop verrät das Problem seinem Betreiber selten, und genau das ist die größte Schwierigkeit.

So erfahren Betreiber am häufigsten von einem Problem, und genau deshalb reagieren sie oft nicht sofort. Wenn ein gehackter WooCommerce Shop für den Inhaber weiterhin einwandfrei aussieht, glaubt man leicht, der Fehler liege woanders. Genau das ist die Absicht hinter dem eingeschleusten Code.

Warum der Betreiber nicht sieht, was Kunden sehen

Weiterleitungscode wird fast nie für alle ausgelöst. Bevor er entscheidet, ob jemand weitergeschickt wird, prüft er meist mehrere Dinge: woher der Besucher kommt, ob er ein Mobilgerät nutzt und ob er im Adminbereich angemeldet ist.

Ein Shopbetreiber ist fast immer angemeldet, tippt die Adresse direkt ein und arbeitet am Desktop. Genau diese Kombination überspringt der Code. Ein Kunde, der aus der Suche kommt, mit dem Handy, nicht angemeldet, ist genau das, wonach er sucht.

Deshalb baten wir den Kunden zuerst nicht um ein Passwort, sondern um einen Screenshot von einem dieser Käufer. Damit hatten wir binnen fünf Minuten die Bestätigung und eine grobe Vorstellung davon, wohin die Weiterleitung führte.

Die erste Stunde, bevor wir etwas anfassten

Der Drang, sofort zu löschen, ist immer da. Bei einem Shop ist dieser Drang besonders gefährlich, denn in der Datenbank liegen Bestellungen, Kunden und Zahlungen. Ein falscher Griff bedeutet dort nicht verlorene Inhalte, sondern verlorenes Geld und ein rechtliches Problem.

Eine vollständige Kopie, samt Infektion

Der erste Schritt war eine komplette Kopie von Dateien und Datenbank im vorgefundenen Zustand. Infiziert, ja. Diese Kopie dient als Absicherung, falls bei der Bereinigung etwas schiefgeht, und als Beweismaterial, falls später rekonstruiert werden muss, was wann geschah.

Bei einem Shop wiegt das zusätzlich schwer. Sollte sich herausstellen, dass Kundendaten abgeflossen sind, ist diese Kopie die einzige Möglichkeit festzustellen, was zum Zeitpunkt des Einbruchs tatsächlich in der Datenbank stand.

Schaden stoppen, ohne den Shop abzuschalten

Der Kunde fragte, ob er die Seite abschalten solle. Wir rieten ab. Ein Shop, der einen Tag nicht erreichbar ist, verliert Umsatz, verliert Positionen in der Suche und sendet ein schlechtes Signal an Kunden, die bereits bestellt haben.

Stattdessen haben wir zuerst den Weiterleitungsmechanismus selbst unschädlich gemacht. Damit war der Schaden für Kunden gestoppt, und der Shop lief weiter, während wir den Rest suchten. Das ist nur möglich, wenn man vorher genau weiß, wo der Code sitzt, dieser Schritt kam also faktisch nach dem folgenden.

Umfang bestimmen

Vor der Bereinigung muss klar sein, wie tief es geht. Wir prüften, ob die Weiterleitung auf allen Seiten auftrat oder nur auf einigen, ob sie alle Besucher betraf oder nur einen Teil, und ob auf demselben Hosting-Konto weitere Seiten liegen.

Die letzte Frage wird oft übersprungen und ist wichtig. Liegen weitere Seiten auf demselben Konto, springt eine Infektion häufig von einer zur anderen, und wer nur eine bereinigt, hat in einer Woche alles zurück. In diesem Fall lag dort eine ältere Seite, und sie war ebenfalls betroffen.

Was wir fanden

Jeder gehackte WooCommerce Shop, den wir bisher bearbeitet haben, hatte mehr als einen Zugang.

Die Befunde verteilten sich auf fünf Stellen. Das ist nicht ungewöhnlich. Angreifer hinterlassen regelmäßig mehr als einen Zugang, weil sie damit rechnen, dass der erste gefunden wird.

Eine Backdoor im Uploads-Ordner

Der Ordner wp-content/uploads ist für Produktbilder, Dokumente und Medien gedacht. Dort sollte niemals eine Datei mit der Endung .php liegen. Wir fanden eine in einem Unterordner mit zwei Jahre alten Bildern, mit einem Namen, der wie eine Systemdatei aussah.

Der Inhalt war eine lange Kette aus Buchstaben und Zahlen ohne ein einziges erkennbares Wort, die erst zur Laufzeit entschlüsselt wird. Das ist zugleich die Tarnung und das zuverlässigste Zeichen dafür, dass etwas nicht stimmt, denn legitimer Code hat keinen Grund, unlesbar zu sein.

Eine veränderte Datei im aktiven Theme

In einer Datei, die auf jeder Seite geladen wird, war eine einzelne Zeile ergänzt worden, ganz am Ende, hinter mehreren Leerzeilen. Wer diese Datei öffnet und ohne Scrollen bis nach unten hineinschaut, sieht nichts.

Diese Zeile war der eigentliche Weiterleitungsmechanismus. Sie prüfte, woher der Besucher kam und welches Gerät er nutzte, und schickte nur einen Teil von ihnen weiter.

Ein geplanter Task, der alles wiederherstellte

Das ist der Teil, der erklärt, warum Infektionen nach einer scheinbar erfolgreichen Bereinigung so oft zurückkehren. Im WordPress-System für geplante Aufgaben lag ein Eintrag, der die Backdoor-Datei alle paar Tage neu anlegte, falls sie verschwand.

Hätten wir nur die Datei und die Theme-Zeile gelöscht, wäre der Shop einige Tage sauber gewesen und danach wäre alles zurückgekommen. Der Betreiber hätte geschlossen, dass Bereinigung nicht funktioniert.

Ein Administratorkonto, das niemand angelegt hat

In der Benutzerliste stand ein Konto mit einem Namen, der nach einem Plugin aussah. Das Registrierungsdatum fiel in einen Zeitraum, in dem sich niemand aus der Firma angemeldet hatte. Die hinterlegte Mailadresse war nie zuvor gesehen worden.

Das war die Rückfallebene für den Fall, dass alles andere entfernt wird. Mit vollen Administratorrechten hätte der Angreifer jederzeit zurückkehren können, unabhängig von geänderten Passwörtern.

Eingeschleuster Code in der Datenbank

Der letzte Befund lag in der Datenbank selbst, in Feldern, die bei jedem Aufruf geladen werden. Diese Stelle wird am häufigsten übersehen, weil sie keine Datei ist. Wer nur Dateien bereinigt, lässt das unberührt, und alles kehrt zurück, sobald eine Seite erneut geladen wird.

Wie der Angreifer hereinkam

Diese Frage wiegt schwerer als die Frage, was er hinterlassen hat. Wird die Eintrittsstelle nicht geschlossen, ist der nächste Einbruch eine Frage der Zeit und nicht der Wahrscheinlichkeit.

Die Ursache war ein Plugin zur Berechnung von Versandkosten, das seit fast zwei Jahren nicht aktualisiert worden war. Für diese Version existierte eine öffentlich bekannte Schwachstelle, und zwischen Veröffentlichung und Ausnutzung liegen meist nur wenige Tage, weil automatisierte Skripte Seiten reihenweise genau darauf prüfen.

Der Betreiber hatte dieses Plugin aus einem völlig nachvollziehbaren Grund nicht aktualisiert, den wir ständig hören: Er hatte einmal etwas anderes aktualisiert, der Shop war kaputtgegangen, und seitdem fürchtete er sich davor, irgendetwas anzufassen, das funktionierte. Das ist eine häufige und teure Falle. Die Angst vor Updates kostet mehr als gelegentliche Kompatibilitätsprobleme, denn Schwachstellen häufen sich an.

Die Bereinigung Schritt für Schritt

Die Reihenfolge ist genauso wichtig wie die Schritte selbst.

Weiterleitungsmechanismus entfernen

Zuerst wurde die Zeile aus dem Theme entfernt, womit der Schaden für Kunden gestoppt war. Ab diesem Moment wurde kein Besucher mehr weitergeleitet, obwohl die Bereinigung noch lange nicht abgeschlossen war.

Backdoor-Dateien und geplanten Task entfernen

Danach folgten die Datei im Uploads-Ordner und der geplante Task, und zwar gemeinsam. Die Reihenfolge zählt: Löscht man zuerst die Datei und lässt den Task stehen, ist die Datei sofort wieder da.

Datenbank bereinigen

Der eingeschleuste Code wurde aus der Datenbank entfernt, mit einer Prüfung, ob nichts in weiteren Tabellen zurückblieb. Bei einem Shop braucht das zusätzliche Sorgfalt, denn dieselbe Datenbank enthält Bestelldaten, die unangetastet bleiben müssen.

Falsches Konto löschen und Sitzungen beenden

Das falsche Administratorkonto wurde entfernt, anschließend wurden alle aktiven Sitzungen ungültig gemacht und die Sicherheitsschlüssel erneuert. Dieser Schritt wird am häufigsten übersprungen. Ein geändertes Passwort wirft niemanden hinaus, der zuvor ein Anmelde-Cookie gestohlen hat. Das Beenden der Sitzungen schon.

Eintrittsstelle schließen

Das verwundbare Plugin wurde aktualisiert, mehrere gar nicht genutzte Plugins wurden entfernt. Ein inaktives Plugin mit einer Schwachstelle ist weiterhin verwundbar, denn seine Dateien liegen weiter auf dem Server.

Alle Passwörter ändern

Administratorkonten, Datenbank, Hosting-Panel und FTP-Zugang. Solange die Backdoor aktiv war, hätte der Angreifer all das abgreifen können, also gilt es als kompromittiert, auch ohne Beweis dafür.

Zweite Seite auf demselben Konto bereinigen

Zuletzt wurde die ältere Seite auf demselben Konto bereinigt, da sie sonst zur Quelle einer erneuten Infektion geworden wäre.

Warum ein Shop ein Sonderfall ist

Bei einem gehackten WooCommerce Shop wird die Bereinigung anders geplant als bei einer gewöhnlichen Seite.

Einen Shop zu bereinigen ist nicht dasselbe wie eine gewöhnliche Website, aus mehreren Gründen, die man vorher verstanden haben sollte.

In der Datenbank liegen fremde Daten

Namen, Adressen, Telefonnummern, Bestellhistorie. Wenn der Angreifer genug Zugriff hatte, um Code zu platzieren, hatte er auch darauf Zugriff. In diesem Fall haben wir die Protokolle durchgesehen und festgestellt, dass es keine Hinweise auf einen massenhaften Datenabfluss gab. Aber das ist eine Frage, die man stellen und beantworten muss, nicht annehmen.

Sollte tatsächlich ein Abfluss vorliegen, ist die Benachrichtigung der Kunden keine Frage der Höflichkeit, sondern kann eine rechtliche Pflicht sein. Dieses Gespräch führt man nüchtern und nicht in Panik.

Bestellungen laufen weiter, während Sie bereinigen

Eine gewöhnliche Seite kann eine Stunde im Wartungsmodus stehen, ohne dass etwas passiert. Ein Shop kann das nicht. Deshalb wird die Bereinigung so geplant, dass der Shop erreichbar bleibt, und das bedeutet sorgfältigeres Arbeiten und mehr Kontrollen nach jedem Schritt.

Zahlungsabwicklung darf nicht gestört werden

Zahlungs-Plugins sind der empfindlichste Teil. Sie mitten in einer Bereinigung zu aktualisieren, kann den Bestellvorgang unterbrechen. Also wird zuerst bereinigt, dann zu einem kontrollierten Zeitpunkt alles aktualisiert, was Zahlungen berührt, geprüft mit einer Testbestellung.

Fehler, die wir sehen, bevor man uns anruft

Shopbetreiber versuchen es oft zuerst selbst, was verständlich ist. Das hier verschlimmert die Lage am häufigsten.

Backup blind zurückspielen

Der erste Reflex ist, den Shop eine Woche zurückzusetzen. Das Problem ist doppelt. Ist die Infektion älter als das Backup, spielt man einen infizierten Shop zurück. Und beim Zurücksetzen der Datenbank verschwinden alle seitdem eingegangenen Bestellungen, was ein realer finanzieller und rechtlicher Schaden ist.

Bei einem Shop wird ein Backup erst zurückgespielt, wenn das genaue Einbruchsdatum bekannt ist, und die vollständige Datenbank fast nie.

Alles löschen, was seltsam aussieht

Eine Datei, die Ihnen merkwürdig vorkommt, kann zu einem Plugin gehören, das Sie nutzen. Mit dem Löschen zerstören Sie außerdem die Möglichkeit zu sehen, wann sie platziert wurde und worüber. Immer zuerst ansehen, dann entfernen.

Mehrere Sicherheits-Plugins auf einmal installieren

Kein Sicherheits-Plugin, das nach einem Einbruch installiert wird, entfernt bereits vorhandenen Code. Und in einem Shop, der ohnehin schwerer ist als eine gewöhnliche Seite, bremsen mehrere solcher Plugins spürbar und können mit Zahlungs-Plugins kollidieren.

Zu einem anderen Hoster umziehen

Ein infizierter Shop nimmt das Problem auf den neuen Server mit, und unterwegs gehen die Protokolle verloren, die die nützlichste Spur waren. Zuerst bereinigen, dann über einen Umzug nachdenken, falls er überhaupt nötig ist.

Die ersten 48 Stunden nach der Bereinigung

Der Zeitraum direkt nach der Bereinigung zeigt, ob die Arbeit wirklich abgeschlossen ist. Geplante Tasks und Rückfallzugänge wirken meist verzögert, Übersehenes zeigt sich also erst Tage später.

Bei diesem Shop haben wir in den ersten 48 Stunden mehreres beobachtet. Ob eine neue Datei auftaucht, die vorher nicht da war, ob sich eine Datei ändert, die sich nicht ändern sollte, ob ein neuer Benutzer erscheint, und ob sich in der Datenbank etwas außerhalb des normalen Bestellablaufs ändert.

Es tauchte nichts auf, was das erste belastbare Zeichen dafür war, dass tatsächlich alle Zugänge geschlossen waren. Wäre etwas aufgetaucht, hätte das bedeutet, dass irgendwo noch ein Mechanismus sitzt, und wir hätten weitergesucht.

Wir haben dem Betreiber außerdem geraten, in diesem Zeitfenster keine größeren Änderungen am Shop vorzunehmen. Der Grund ist praktisch: Geht etwas kaputt, während parallel das Theme gewechselt oder Plugins ergänzt werden, lässt sich kaum unterscheiden, ob ein Rest der Infektion oder ein gewöhnlicher Fehler die Ursache ist.

Was das gekostet hat, und was teurer war

Ein gehackter WooCommerce Shop verliert jeden Tag Geld, solange das Problem besteht, und diese Kosten stellt niemand in Rechnung.

Kunden fragen fast immer nach dem Preis der Bereinigung und rechnen viel seltener zusammen, was die Infektion bereits gekostet hat, solange sie lief.

In diesem Fall lief die Weiterleitung knapp zehn Tage, bevor jemand reagierte. In dieser Zeit landete ein Teil der Besucher aus der Suche auf einer fremden Seite statt im Shop. Wie viel Umsatz so verloren ging, lässt sich nicht exakt messen, aber es war mit hoher Sicherheit mehr als der Preis der Bereinigung.

Dazu kommt etwas, das in keiner Zahl auftaucht. Die drei Kunden, die das Problem meldeten, waren Menschen, die dem Shop genug vertrauten, um ihn zu öffnen. Ihr Eindruck nach einem solchen Erlebnis wird durch eine einzelne Bereinigung nicht repariert.

Deshalb ist Reaktionsgeschwindigkeit bei einem Shop mehr wert als bei einer gewöhnlichen Seite. Jeder Tag Verzögerung ist nicht nur zusätzliches Risiko, sondern ein messbarer Verlust.

Was wir nach der Bereinigung getan haben

Mit der Bereinigung ist die Arbeit nicht zu Ende. Was danach folgt, entscheidet darüber, ob sich alles wiederholt.

Erstens eine Prüfung in den Google-Werkzeugen, ob der Shop in den Suchergebnissen markiert wurde. In diesem Fall war er es nicht, weil das Problem früh genug entdeckt wurde. Wäre er markiert gewesen, erfordert das Entfernen der Warnung einen eigenen Antrag und dauert Tage, schnelles Reagieren hat hier also Wochen gespart.

Zweitens wurde eine Überwachung aktiviert, die den Zustand von Dateien und Datenbank täglich mit dem Vortag vergleicht. Die Überlegung dahinter ist einfach: Wenn eine Backdoor gut versteckt war, kann es eine zweite auch sein. Die Überwachung erkennt jede neue Änderung sofort, statt zu warten, bis daraus ein sichtbares Problem wird.

Drittens erhielt der Kunde einen Bericht mit allem, was gefunden wurde, wo es lag, worüber es hereinkam und was geschlossen wurde. Das ist keine Formalität. Ein Betreiber, der versteht, wie der Einbruch zustande kam, denkt anders über Updates als einer, dem nur gesagt wurde, es sei alles erledigt.

Was der Kunde anders hätte machen können

Hier geht es nicht um Schuldzuweisung, sondern um den nützlichsten Teil der ganzen Geschichte für alle, die mitlesen.

Das Aktualisieren der Plugins hätte das gesamte Problem verhindert, bevor es entstand. Die Schwachstelle war bekannt und Monate zuvor behoben. Angst vor Updates ist verständlich, wird aber mit einer Testumgebung und Backups gelöst, nicht mit Aufschieben.

Das Entfernen ungenutzter Plugins verkleinert die Angriffsfläche. In diesem Shop lagen mehrere Plugins, die seit Jahren nicht genutzt wurden und trotzdem auf dem Server standen.

Eine regelmäßige Überwachung hätte das Problem an dem Tag erkannt, an dem die Backdoor platziert wurde, und nicht Wochen später, als Kunden sich beschwerten. Der Abstand zwischen diesen beiden Zeitpunkten ist der Unterschied zwischen einem kleinen Eingriff und dieser ganzen Geschichte.

Das Trennen von Seiten auf verschiedene Hosting-Konten verhindert, dass eine Infektion von einer zur anderen überspringt. Ein gemeinsames Konto ist günstiger, trägt aber dieses Risiko.

Was dieser Fall allgemein zeigt

Drei Dinge wiederholen sich in fast jedem Einsatz.

Der Betreiber bemerkt es selten zuerst. Fast immer meldet es jemand von außen, weil der Code so geschrieben ist, dass er den Betreiber überspringt.

Der Einstieg ist fast immer etwas Veraltetes. Keine ausgefeilte Technik, sondern ein nicht aktualisiertes Plugin, ein Theme aus inoffizieller Quelle oder ein schwaches Passwort.

Der Angreifer hinterlässt immer mehr als einen Weg zurück. Wer das Erstbeste löscht und aufhört, hat sich einige Tage erkauft.

Wenn Ihnen das bekannt vorkommt

Wenn Kunden Ihnen etwas melden, das Sie selbst nicht sehen, oder Sie einfach wissen möchten, wie es um Ihre Seite steht, kostet der erste Schritt nichts. Wer einen gehackten Online-Shop prüfen lassen will, bekommt in unter einer Minute einen Blick auf die öffentlich erreichbaren Inhalte: bekannte Malware-Muster, versteckte Skripte und Weiterleitungen. Ohne Konto, ohne Installation.

Es lohnt sich offen zu sagen, was diese Prüfung nicht kann, denn in einem Fall wie diesem ist das entscheidend. Sie sieht nur, was öffentlich über das Internet erreichbar ist. Von den fünf Dingen, die wir in diesem Shop gefunden haben, hätte eine Fernprüfung nur die Weiterleitung bemerken können. Die Backdoor-Datei, der geplante Task, der falsche Administrator und der Code in der Datenbank bleiben ihr verborgen. Ein sauberes Ergebnis ist deshalb kein Beweis dafür, dass alles in Ordnung ist.

Eine belastbare Antwort erfordert einen Blick auf die Dateien und die Datenbank auf dem Server. Wenn Sie einen Shop betreiben und vermuten, dass etwas nicht stimmt, oder wenn eine Infektion nach einer Bereinigung bereits zurückgekehrt ist, können Sie den gehackten WooCommerce-Shop bereinigen lassen. Schicken Sie die Adresse und eine kurze Beschreibung. Bei Shops versuchen wir die Arbeit so zu organisieren, dass der Verkauf während der Bereinigung nicht stillsteht.