Ein Anruf um sieben Uhr morgens, am Telefon der Shop-Inhaber: Die Website leitet auf irgendein Casino weiter, aber nur aus Google heraus, denn nach Eingabe der Adresse sieht alles normal aus. Ein Klassiker. Gehacktes WordPress sieht selten spektakulär aus. Meist arbeitet es leise und kommt zufällig ans Licht, durch eine Kundenbeschwerde oder eine Warnung in den Suchergebnissen. Was Sie in den nächsten zwei Stunden tun, entscheidet darüber, ob die Sache an einem Tag erledigt ist oder ein Quartal lang zurückkommt.
Inhaltsverzeichnis
Die ersten fünfzehn Minuten: Schaden stoppen, Spuren nicht löschen
Der Reflex ist immer derselbe: seltsame Dateien finden und löschen. Und genau da beginnt das Problem, denn mit dem Löschen zerstören Sie das einzige Material, aus dem sich der Einstiegsvektor später rekonstruieren ließe. Ohne Änderungsdatum und ohne den Inhalt des hochgeladenen Skripts bleibt Ihnen nur Raten.
Die Reihenfolge, die funktioniert: zuerst den Traffic abschneiden, über den Wartungsmodus oder eine Regel auf dem Webserver. Dann ein Snapshot des gesamten Verzeichnisses und ein Dump der Datenbank im infizierten Zustand. Erst danach beginnen Sie mit dem Aufräumen, ob selbst oder indem Sie die Virenentfernung von der Website jemandem übergeben, der das täglich macht.
Der Snapshot muss außerhalb des Produktionsservers landen. Ein Archiv neben wp-content verschwindet beim Wiederherstellen zusammen mit dem Rest oder wird, schlimmer noch, selbst vom Angreifer gelesen. Ändern Sie keine Passwörter, bevor Sie die Logs gesichert haben – wer eine aktive Sitzung hat, sitzt ohnehin drin, und Sie verlieren Aufzeichnungen, die der Server nicht unbegrenzt aufbewahrt.
Bestimmen Sie die Art der Infektion: drei typische Szenarien
Die erste Variante ist SEO-Spam, der in der Datenbank lebt. Weiterleitungen greifen nur für den Googlebot oder für Traffic aus der Suchmaschine, versteckte Links sitzen in wp_options und wp_posts, und der Inhaber, der seine eigene Seite ansieht, bemerkt nichts. Daher kommen diese Meldungen von Kunden und nicht aus der Redaktion.
Die zweite ist eine Backdoor in den Dateien: Code, der am Ende von wp-config.php angehängt wurde, eine untergeschobene Datei, die sich als Bestandteil von wp-includes ausgibt, ein einzelnes PHP-Skript im Verzeichnis uploads, wo kein PHP etwas zu suchen hat. Das dritte Szenario ist das einfachste und wird am häufigsten unterschätzt – ein übernommenes Administratorkonto oder ein frisch angelegter Benutzer mit dieser Rolle, meist mit einer E-Mail-Adresse in einer fremden Domain.
Irreführend sind manchmal die Symptome auf dem Hosting. Ein plötzlicher Anstieg des Transfers und eine verstopfte Mail-Warteschlange sind meist keine Serverstörung, sondern Ihre eigene Website, die Spam verschickt. Prüfen Sie das, bevor das Gespräch auf die Wartung von Websites und den Umzug auf ein stärkeres Paket kommt.
Die erste Stunde: Spuren aus Logs und Datenbank
Zugriffslogs, den Änderungsdaten der Dateien gegenübergestellt, können den Zeitpunkt des Einstiegs auf wenige Minuten eingrenzen. Sie suchen POST-Anfragen an Dateien in uploads oder an ungewöhnlich benannte Skripte im Plugin-Verzeichnis. Das ist die häufigste erste Spur und sie führt meist direkt zur verwundbaren Komponente.
In der Datenbank prüfen Sie einige Stellen in einer festen Reihenfolge, beginnend mit der wahrscheinlichsten:
- wp_users und wp_usermeta – die Liste der Konten, Registrierungsdaten, zugewiesene Rollen, vor allem Einträge nach dem Datum aus den Logs.
- wp_options mit autoload = yes – dort landet Code, der bei jeder Anfrage ausgeführt wird, oft base64-kodiert.
- Geplante Cron-Aufgaben – ein Eintrag, der die Backdoor nach jedem Aufräumen wiederherstellt.
- wp_posts und wp_postmeta – eingeschleuste Links, versteckte Blöcke, ausgetauschte Inhalte alter Beiträge.
- API-Schlüssel und Integrationsdaten – alles, was sich exportieren ließ, betrachten Sie als abgeflossen.
Die zweite Stunde: Bereinigen gegen Wiederherstellen aus dem Backup
Manuelles Bereinigen ergibt nur dann Sinn, wenn Sie den Zeitpunkt des Einstiegs kennen und einen sauberen Bezugspunkt haben: originale Dateien von Core und Plugins für den byteweisen Vergleich. Ohne das sichten Sie über zehntausend Dateien mit dem Auge und übersehen eine Zeile. Immer genau diese eine.
Auch ein Backup aus der Zeit vor der Infektion kann eine Falle sein. Wenn die Backdoor wochenlang auf dem Server saß und die Kopie eine Aufbewahrung von wenigen Tagen hat, stellen Sie die Website samt Problem wieder her und stehen nach zwei Tagen wieder am Ausgangspunkt.
Bei Unsicherheit ist der Neuaufbau sicherer: frische Installation von Core und Plugins aus offiziellen Quellen, Übernahme ausschließlich von Inhalten, Medien und geprüftem Code des Child-Themes. Themes und Plugins aus zweifelhaften Quellen, einschließlich „freigeschalteter” Premium-Versionen, kommen auf die Liste zum Wegwerfen, nicht zum Reparieren. Sie waren oft genug der Vektor, sodass es darüber nichts zu diskutieren gibt.
Den Vektor schließen, oder warum eine Website ein zweites Mal gehackt wird
Ein Rückfall nach einigen Tagen bedeutet fast immer eines: Die Folge wurde beseitigt, die Ursache blieb. Die typische nicht geschlossene Tür? Ein nicht aktualisiertes Plugin mit öffentlich verfügbarem Exploit, ein FTP-Konto, das sich drei Firmen teilen, ein Passwort aus einem alten Leak, das erneut verwendet wurde, oder ein im Repository vergessener API-Schlüssel.
Die Rotation der Geheimnisse umfasst alles auf einmal: Benutzerpasswörter, das Datenbankpasswort, die Salt-Schlüssel in wp-config.php, Anwendungspasswörter für die REST API, Zugänge zum Hosting-Panel. Ein halber Austausch erzeugt nur den Anschein von Ordnung.
Wenn auf demselben Hosting-Konto weitere Websites liegen, prüfen Sie diese zusammen mit der angegriffenen. Die Infektion wandert zwischen Verzeichnissen innerhalb des Kontos und kommt von einer Nachbarseite zurück, an die niemand mehr gedacht hat. Bei einem solchen Audit zeigt sich häufig, dass ein Teil der Websites eher für die Modernisierung einer alten Anwendung infrage kommt als für das nächste Flicken.
Folgen außerhalb des Servers: Google, E-Mail, personenbezogene Daten
Die Search Console zeigt eine Sicherheitswarnung und erlaubt es, die Seite nach der Bereinigung zur erneuten Prüfung einzureichen. Eine Meldung vor der tatsächlichen Beseitigung der Infektion verlängert die Sache nur, weil die Prüfung mit einer Ablehnung endet.
Eine Domain, von der Mail-Spam ausging, landet auf Blocklisten und erfordert eine eigene Behandlung. Der Zustand der Website spielt hier keine Rolle mehr, das Delisting läuft parallel. Und wenn der Shop oder die Formulare personenbezogene Daten verarbeitet haben, hat der Vorfall eine formale Dimension und jemand muss die Meldepflicht bewerten. Am besten noch am selben Tag.
Bleibt die Kommunikation. Kunden und Partner erfahren es schneller, als der Inhaber annimmt, meist vom eigenen Browser oder aus einer Warnung in den Ergebnissen. Eine kurze, konkrete Information in eigenen Worten nimmt die Hälfte der Fragen weg. Schweigen erzeugt den Rest.
Was zu tun ist, damit der nächste Vorfall nicht bei null beginnt
Hosting mit regelmäßigen Backups, die außerhalb des Produktionsservers liegen, mit einer Aufbewahrung in Wochen statt in Tagen und mit regelmäßig getesteter Wiederherstellung. Eine Kopie, die niemand je zurückgespielt hat, ist eine Hypothese, keine Absicherung.
Plugin-Updates funktionieren, wenn sie ein Prozess sind: Testumgebung, Durchsicht der Änderungen, Einführung in einem festen Rhythmus. Aktionen einmal im Quartal enden mit einem Sprung über zwanzig Versionen auf einmal und einem zerschossenen Seitenlayout, also wiederholt sie danach niemand.
Der Rest ist gewöhnliche Zugriffshygiene: getrennte Konten statt eines gemeinsamen, Zwei-Faktor-Anmeldung für Panel und Hosting, gesperrte PHP-Ausführung im Verzeichnis uploads. Die Integritätsüberwachung der Dateien und eine Warnung bei Änderung der Anzahl der Administratoren verkürzen die Erkennung von Wochen auf Stunden, und das entscheidet meist über den Umfang des Aufräumens.
Zusammenfassung
Die ersten zwei Stunden entscheiden, ob der Vorfall mit einer einmaligen Bereinigung endet oder sich in Monate voller Rückfälle verwandelt. Die Reihenfolge bleibt unverändert: abschneiden, Spuren sichern, den Vektor bestimmen und erst dann wiederherstellen.
Gehacktes WordPress ist meist ein Symptom vernachlässigter Wartung, kein Pech. Eine nicht aktualisierte Website mit zwei Plugins außerhalb des offiziellen Katalogs und einem Passwort, das sich das ganze Team teilt, findet früher oder später ihren Angreifer. Einem Team, das die Website selbst betreut, helfen Schulungen zu WordPress und WooCommerce sehr, die Updates und die Verwaltung von Zugängen abdecken.
Wenn Sie jemanden brauchen, der einen solchen Vorfall technisch begleitet oder die Wartung der Website dauerhaft übernimmt, melden Sie sich bei uns. Wir kümmern uns auch um Audits, Integrationen, Automatisierung und die Modernisierung von Anwendungen, die ihrem ursprünglichen Entwurf entwachsen sind.
