WordPress gehackt: Wie ich eine gekaperte Domain zurückgeholt habe

In Kürze: Cloaking-Malware zeigt der Suchmaschine Casino-Spam und dir die normale Seite – deshalb bleibt so ein Hack oft monatelang unbemerkt. Das erste sichtbare Zeichen ist meist eine „New owner“-Mail aus der Search Console oder fremde Spam-URLs im Index. Die Bereinigung folgt einer festen Reihenfolge: erst den Angreifer aussperren, dann Malware, Nutzer, Zugangsdaten und die Search Console – in genau dieser Folge, sonst machst du die Arbeit doppelt.

Es hat mich selbst getroffen, einen meiner eigenen Content-Blogs. Die erste Spur war eine Mail von Google mit dem Betreff „New owner for …“: Jemand hatte sich als zusätzlicher Eigentümer meiner Property eingetragen, ohne mein Zutun. Für mich und jeden Besucher sah die Seite völlig normal aus – nur der Googlebot bekam etwas anderes serviert. Ich schreibe das als Fall, den ich durchgearbeitet habe, nicht als Ratgeber aus zweiter Hand: mit der Reihenfolge, die funktioniert hat, und den Fehlern, die mich Zeit gekostet haben.

Woran habe ich gemerkt, dass die Seite gekapert war?

Nicht am Bildschirm – die Seite sah für mich sauber aus. Der Kern des Angriffs ist Cloaking: Inhalte, die nur die Suchmaschine zu sehen bekommt, während echte Besucher die normale Website sehen. Genau diese Zweiteilung ist der Grund, warum so lange niemand etwas merkt.

Die Signale kamen von außen. Diese sechs solltest du kennen:

• Eine „New owner“-Benachrichtigung in der Search Console für einen Eigentümer, den du nicht kennst.
• Fremde Ergebnisse bei site:deine-domain.de – Casino-, Slot- oder Betting-Seiten, die nie zu deinem Content gehörten.
• Directory-Listings im Index, etwa Treffer wie „Index of /wp-content/…“, die du nie erstellt hast.
• Fremde Administrator-Konten in WordPress mit Mustern wie site_admin, wp2_[hex] oder wpsvc_[hex].
• Meldungen deines Sicherheits-Plugins über veränderte Kern-Dateien oder verdächtige PHP-Dateien.
• Unerklärte Traffic-Spitzen, meist von Bots, die frisch indexierte Spam-Seiten crawlen.

Dass es so lange dauert, liegt in der Natur der Tarnung: Ein Angriff, der sich nur dem Crawler zeigt, umgeht jede Sichtprüfung. Wer nicht regelmäßig die indexierten URLs in der Search Console kontrolliert, sieht monatelang nichts.

Wie kommt so ein Botnet überhaupt rein?

In den meisten Fällen steckt kein gezielter Einzelangriff dahinter, sondern ein automatisiertes Botnet. Es scannt das Netz laufend nach angreifbaren Installationen und arbeitet deine Domain als eine unter Millionen ab. Die Einfallstüren sind fast immer dieselben:

• Veraltete WordPress-Version – der häufigste Weg. Bekannte Lücken werden im Massenverfahren ausgenutzt.
• Angreifbare Plugins, besonders ältere File-Manager-Erweiterungen mit bekannten Remote-Code-Lücken.
• Brute-Force auf den Login, oft über xmlrpc.php, das viele Login-Versuche in einer einzigen Anfrage bündeln kann.
• Schwache oder wiederverwendete Passwörter, die in bekannten Datenlecks auftauchen.

In meinem Fall war es durchgehend dieselbe Schwachstelle: eine Installation, die zu lange kein Update gesehen hatte.

Wie sah der Angriff konkret aus?

Das ist der Teil, den kein allgemeiner Ratgeber liefert, weil er einen echten Fall voraussetzt. Der Angriff bestand aus mehreren Bausteinen, die zusammenarbeiten – jeder mit einer eigenen Aufgabe: reinkommen, bleiben, tarnen, Geld verdienen.

Die Backdoors sorgen dafür, dass der Angreifer wiederkommt, auch wenn du einzelne Spuren entfernst: versteckte Admin-Accounts mit Fake-Absenderadressen auf Endungen wie .invalid oder .lol und Webshells – kleine PHP-Dateien im Web-Root, in Theme-Ordnern oder tief in Plugin-Verzeichnissen, über die sich Code aus der Ferne ausführen lässt. Typische Namen: prog.php oder die backdoor-kopihitam-*.php-Familie.

Ein selbstlöschender Dropper erschwert die Erkennung: eine Datei wie wp-jquery.php, die ihren Schadcode aus verschleierten Daten entpackt und sich nach der Ausführung selbst löscht. Als Muster erkennbar an einem eval()-Aufruf mit gepackten Daten und einem anschließenden Selbstlöschbefehl – danach suchst du in deinem Dateisystem gezielt.

Modifizierte Kern-Dateien wie index.php oder Loader im wp-includes-Verzeichnis laden bei jedem Seitenaufruf externen Schadcode nach – teils versteckt in Ordnern, die es im echten WordPress-Kern gar nicht gibt.

Die Tarnung steckt in der .htaccess. Eine Regel prüft den User-Agent und leitet nur Suchmaschinen-Crawler auf eine Spam-Datei um. In deiner eigenen Datei suchst du nach genau diesem Muster – einer Weiterleitung, die an den Googlebot gekoppelt ist und die du nie eingebaut hast:

# Fremde Regel — Weiterleitungsziel hier entfernt:
RewriteCond %{HTTP_USER_AGENT} (googlebot|inspectiontool|search\.google) [NC]
RewriteRule ^ /[SPAM-DATEI-ENTFERNT] [L]

Menschliche Besucher fallen nicht unter die Bedingung und sehen die echte Seite – deshalb bleibt der Angriff für dich unsichtbar.

Die Übernahme der Search Console richtet den größten SEO-Schaden an: Über eine hinterlegte HTML-Verifikationsdatei trägt sich der Angreifer als zusätzlicher Eigentümer ein. Damit steuert er, was Google über die Domain erfährt, und kann Spam-Sitemaps einreichen.

Warum reicht ein Malware-Plugin allein nicht?

Ein Sicherheits-Plugin wie Wordfence findet die Webshells zuverlässig – es scannt Dateien und schlägt bei bekanntem Schadcode an. Aber ein reiner Datei-Scan sieht nur einen Teil des Angriffs.

Zwei Elemente überleben ihn: Die Cloaking-Regel in der .htaccess besteht aus gültiger Server-Syntax und ist für einen Malware-Scanner unauffällig. Und die fremden Eigentümer in der Search Console liegen komplett außerhalb dessen, was ein Plugin auf deinem Server überhaupt prüfen kann. Deshalb funktioniert nur die Kombination aus Plugin-Scan und manueller Prüfung von Dateisystem, .htaccess und der Eigentümer-Liste in der Search Console. Wie man solche Signale in der Search Console liest, habe ich in der Anleitung zur Search Console zusammengestellt.

In welcher Reihenfolge räumt man auf?

Die Reihenfolge ist wichtiger als das Tempo. Ich habe früh gelernt, dass ein Fehler in der Abfolge die Arbeit zunichtemacht – löschst du erst die fremden Nutzer und lässt eine aktive Backdoor stehen, legt sie die Konten binnen Minuten neu an.

1. Angreifer aussperren. Bevor du irgendetwas bereinigst, schließt du den aktiven Zugriff. Eine temporäre Regel in der .htaccess lässt nur deine eigene IP durch (die findest du über einen „Was ist meine IP“-Dienst):

# Temporäre Sperre: nur die eigene IP darf rein
RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^DEINE\.IP\.HIER$
RewriteRule ^(.*)$ - [F,L]

Solange die Regel steht, kann niemand sonst neue Dateien hochladen – du räumst in Ruhe auf. Die Punkte in der IP werden mit Backslash maskiert.

2. Bestandsaufnahme. Verschaff dir einen Überblick: fremde Administratoren unter Benutzer, nicht selbst installierte Plugins, verdächtige POST-Zugriffe in den Server-Logs rund um die „New owner“-Mail, und die aktiven Verifikationsmethoden in der Search Console. Das zeigt dir, wie tief die Kompromittierung reicht.

3. Backup-Restore prüfen. Findest du mehrere Backdoor-Konten und veränderte Kern-Dateien, ist ein Restore oft der schnellste Weg. Wähl einen Stand vor dem ersten Angriffszeichen – bei monatelanger Verweildauer entsprechend älter. Deine Datenbank mit Inhalten, Kommentaren und Kategorien kannst du in der Regel behalten.

4. Malware entfernen. Ein vollständiger Scan mit aktivierter Option „Dateien außerhalb der WordPress-Installation“ fängt die bekannten Signaturen. Ergänzend prüfst du per FTP: alle google*.html außer deiner eigenen Verifikationsdatei, eine HTML-Datei mit deinem Domainnamen (die Cloaking-Spam-Datei), PHP-Dateien in /wp-content/uploads/ (dort gehört keine hin) und fremde, WP-legitim wirkende Dateien im Web-Root.

5. WordPress-Ebene bereinigen. Erst jetzt löschst du die Backdoor-Konten und weist ihre Beiträge deinem echten Admin zu. Entfern alle Plugins, die du nicht selbst installiert hast – File-Manager-Plugins zuerst. Danach Kern, Plugins und Theme auf die aktuelle Version aktualisieren, das Theme im Zweifel aus der Originalquelle neu.

6. Zugangsdaten komplett erneuern. Alle Passwörter neu: WordPress-Admins, Datenbank (auch in der wp-config.php), FTP und Hosting-Panel. Erneuere zusätzlich die Security-Keys in der wp-config.php über den offiziellen Salt-Generator von WordPress – das wirft sofort alle aktiven Sitzungen raus, auch die des Angreifers. Aktivier eine Zwei-Faktor-Authentifizierung.

7. Search Console bereinigen. Fremde Eigentümer und ihre Verifikationsmethoden entfernen – dazu gleich mehr, das ist der Teil, den die reinen Malware-Dienste auslassen.

8. Verifizieren und beobachten. Zweiter vollständiger Scan bis null kritische Funde, dann die IP-Sperre aus der .htaccess entfernen. Beobachte die Seite rund zwei Tage: keine neuen „New owner“-Mails, keine neuen verdächtigen Nutzer. Bleibt es ruhig, ist der Zugang geschlossen. Nach eingespielter Methodik lag ich pro Domain bei 45 bis 90 Minuten.

Wie holst du die Google-Sichtbarkeit zurück?

Eine saubere Website nützt nichts, solange Google noch den Spam kennt und ein Fremder Zugriff auf die Property hat. Der entscheidende Punkt: Die Verifikationsmethode ist wichtiger als der Owner-Eintrag. Löschst du nur den fremden Owner, aber nicht seine hinterlegte HTML-Datei, verifiziert er sich sofort wieder.

• Verifikation zuerst. Unter Einstellungen und Inhaberschaftsbestätigung jede fremde HTML-Datei, jeden fremden DNS-Eintrag und jedes fremde Meta-Tag entfernen – und die zugehörige Datei vom Server nehmen. Danach den fremden Owner löschen.
• Spam aus dem Index holen. Über Indexierung und Entfernungen die fremden URL-Präfixe zur Entfernung einreichen und das Directory-Listing serverseitig abschalten, damit keine neuen nachrücken.
• Den Googlebot-Blick testen. Über die URL-Prüfung kontrollieren, dass die Startseite dem Crawler dieselbe Seite zeigt wie dir – keine Weiterleitung mehr auf die Spam-Datei.

Erst wenn der Googlebot-Test sauber ist, war die Arbeit vollständig. Alles davor behebt nur die halbe Seite des Problems.

Wie verhinderst du, dass es wieder passiert?

Das Einfallstor war jedes Mal dasselbe: eine veraltete Version. Damit ist auch die Prävention klar umrissen, ohne Unmögliches zu versprechen:

• Automatische Updates für Kern, Plugins und Theme – die Zeile define('WP_AUTO_UPDATE_CORE', true); in der wp-config.php schließt den häufigsten Weg.
• Zwei-Faktor-Authentifizierung für alle Administrator-Konten.
• Starke, einzigartige Passwörter pro Website, idealerweise aus einem Passwort-Manager.
• Tägliche Scans mit einem Sicherheits-Plugin, plus ein gelegentlicher Blick in die Eigentümer-Liste der Search Console.
• xmlrpc.php deaktivieren, wenn du es nicht brauchst – einer der Hauptwege für Brute-Force.
• Directory-Listing abschalten per Options -Indexes in der Haupt-.htaccess.
• File-Manager-Plugins meiden und stattdessen FTP oder das Hosting-Panel nutzen.

Ehrlich bleibt: Kein System ist unhackbar. Aber diese Punkte schließen genau das Einfallstor, das in meinem Fall über Monate offen stand. Einen verwandten Fall, in dem nicht Malware, sondern fehlende Substanz Seiten aus dem Index warf, habe ich in meinem Bericht zu Thin Content und der Diagnose per Search Console dokumentiert – dieselbe Methodik, anderer Auslöser.

Häufige Fragen

Wie kommt der Angreifer zurück, obwohl ich schon alles gelöscht habe?

Weil er auf mehreren Ebenen gleichzeitig Persistenz gesichert hat. Solange eine Ebene aktiv bleibt – ein übersehener Backdoor-User, eine versteckte Webshell, eine modifizierte Kern-Datei – baut er die anderen neu auf. Deshalb gilt die Reihenfolge: erst aussperren, dann Malware, dann Nutzer, dann alle Zugangsdaten samt Security-Keys neu setzen.

Reicht es, wenn ich mein Google-Passwort ändere?

Nein. Der Angreifer war nie in deinem Google-Konto. Er hat sich als eigener Eigentümer verifiziert, indem er eine HTML-Datei auf deinem Webserver abgelegt hat. Das Problem sitzt im Server, nicht im Google-Konto – ein Passwortwechsel bei Google ändert daran nichts.

Woran erkenne ich, ob mein Backup schon infiziert ist?

Prüf die Benutzerliste des Backups. Stehen dort bereits fremde Konten mit Mustern wie site_admin oder wp2_[hex], ist das Backup nach dem Einbruch entstanden. Nimm einen älteren Stand, in dem nur deine echten Benutzer vorhanden sind.

Muss ich komplett neu installieren?

Nicht zwingend. Bei begrenzter Kompromittierung ohne veränderte Kern-Dateien reicht meist die manuelle Bereinigung. Bei vielen Backdoor-Konten, modifizierten Kern-Dateien oder mehreren Webshells ist die Neuinstallation oft schneller und sicherer. Deine Datenbank kannst du in beiden Fällen behalten.

Wie lange dauert die Bereinigung?

Mit funktionierendem Backup und klarer Reihenfolge ein bis zwei Stunden. Bei schwer betroffenen Seiten ohne aktuelles Backup eher vier bis sechs. Die meiste Zeit geht erfahrungsgemäß für die Diagnose drauf, bevor der richtige Angriffsweg feststeht – deshalb spart eine feste Methodik so viel.

Straft Google meine Domain dauerhaft ab?

In der Regel nicht dauerhaft, wenn du zügig und vollständig bereinigst. Nach kurzer Cloaking-Phase erholt sich die Sichtbarkeit meist innerhalb von Wochen, sobald die Sicherheitswarnung aufgehoben ist und Google die echten Inhalte wieder als maßgeblich erkennt. Der bleibende Schaden entsteht erst, wenn der Zustand monatelang unbemerkt weiterläuft.

Dein nächster Schritt

Öffne deine Search Console und prüf zwei Dinge: Steht unter Einstellungen und Inhaberschaftsbestätigung eine Methode, die du nicht kennst? Und liefert die URL-Prüfung deiner Startseite dem Googlebot dieselbe Seite wie dir? Beides dauert zwei Minuten und ist der schnellste Weg, einen stillen Angriff zu entdecken.

Wenn dich ein komplexer Fall festhält – mehrere Domains, wiederkehrende Reinfektion –, melde dich, dann schaue ich mit dir drauf.