WordPress gehackt? Die Checkliste für das, was kein Scanner sieht
Deine Seite wurde gehackt, die Logs zeigen, dass die Änderungen von deinem eigenen Konto kamen — manchmal sogar von deiner eigenen IP-Adresse — und der Sicherheits-Scan findet nichts. Diese Kombination heißt meistens: Der Weg hinein führte gar nicht über den Server. Jeder Scanner und jedes Monitoring, das die Seite prüft, Relvato eingeschlossen, sieht, was auf dem Server liegt und was die Seiten zeigen. Angreifer kommen aber immer öfter über Orte herein, die woanders liegen: den Browser eines Admins, seinen Rechner oder die Konten rund um die Seite. Diese Checkliste geht diese Orte durch, in der Reihenfolge, in der du sie absichern solltest. Wo sich Malware auf dem Server selbst versteckt, steht in wo sich WordPress-Malware versteckt.
Warum ein sauberer Scan keine saubere Seite bedeutet
Ein Sicherheits-Plugin, eine Dateiintegritäts-Prüfung und ein Admin-Audit beantworten dieselbe Frage: Was liegt auf dem Server? Sie finden eine eingeschleuste Datei, eine geänderte Core-Datei, einen unbekannten Administrator. Sie können aber nicht erkennen, ob die Person, die ein echtes Administrator-Konto benutzt, auch der Administrator ist. Nutzt ein Angreifer deine Sitzung oder deine Passwörter, sieht jede seiner Änderungen aus wie deine — die Logs zeigen dein Konto und, wenn der Angriff in deinem eigenen Browser läuft, auch deine IP-Adresse.
Wenn der Server sauber ist, ist die Arbeit also noch nicht fertig. Geh die Orte unten durch — und zwar von einem Gerät, dem du vertraust.
1. Browser-Erweiterungen
Eine Erweiterung kann jede Seite lesen und verändern, die du öffnest, auch wp-admin, solange du angemeldet bist. Erweiterungen werden verkauft, und ein neuer Besitzer kann ein Update ausliefern, das still auf den Seiten handelt, die du verwaltest: einen Admin anlegen, ein Plugin installieren, eine Theme-Datei ändern — alles mit deiner Sitzung, aus deinem Browser, von deiner IP. Das ist die häufigste Erklärung für „das kam von meinem eigenen Konto“.
Öffne auf jedem Rechner, den ein Administrator nutzt, die Erweiterungsseite des Browsers (in Chrome chrome://extensions). Entferne alles, was du nicht kennst, nicht nutzt oder was ohne klaren Grund „alle deine Daten auf allen Websites lesen und ändern“ will. Erledige WordPress-Admin-Arbeit künftig in einem eigenen Browser-Profil ohne Erweiterungen.
2. Der Rechner des Administrators
Passwort-Diebe (Infostealer) kopieren die im Browser gespeicherten Passwörter und die Login-Cookies jeder Seite, bei der du angemeldet bist. Ein gestohlenes Login-Cookie ist eine Sitzung, die die Zwei-Faktor-Authentifizierung schon hinter sich hat — 2FA hält den, der es besitzt, also nicht auf. Solche Infektionen kommen oft von einem gecrackten Programm, einem falschen Update oder einem falschen CAPTCHA, das dich einen Befehl einfügen ließ.
Scanne jeden Rechner, der sich bei wp-admin, beim Hosting oder im E-Mail-Konto angemeldet hat. Solange du nicht sicher bist, dass ein Gerät sauber ist, gilt jedes darin gespeicherte Passwort als dem Angreifer bekannt — ändere Passwörter von einem anderen Gerät aus.
3. Was die Seite in deinem eigenen Browser hinterlassen hat
Ein Service Worker, der registriert wurde, während du in wp-admin warst, lebt in deinem Browser, nicht auf dem Server, und läuft weiter, nachdem die Seite bereinigt ist. Dein Browser hält außerdem die Cookies und zwischengespeicherten Skripte der Seite.
Öffne in jedem Admin-Browser die Seite, dann Entwicklertools → Anwendung (Application) → Speicher → Websitedaten löschen. Das entfernt ihre Service Worker, Cookies und zwischengespeicherten Dateien für diese Seite.
4. Hosting, SFTP, SSH und die Datenbank
Dein Hosting-Konto steht über WordPress. Ein Angreifer, der dort hineinkam, kann einen Nutzer im Kontrollpanel anlegen, ein FTP- oder SFTP-Konto, einen SSH-Schlüssel in authorized_keys, einen Datenbank-Nutzer mit Fernzugriff oder einen Cron-Job im Hosting-Panel, der stündlich Dateien neu schreibt. Nichts davon ist aus WordPress heraus sichtbar, also kann es auch kein WordPress-Plugin melden.
Melde dich im Hosting-Panel an und lass dir alle Nutzer, FTP-Konten, SSH-Schlüssel, Datenbank-Nutzer und geplanten Aufgaben anzeigen. Entferne, was du nicht angelegt hast, und ändere die Passwörter für Hosting, SFTP und Datenbank.
5. Das E-Mail-Postfach
Das Postfach, in dem WordPress-Passwort-Resets sowie Nachrichten von Hoster und Registrar ankommen, ist der Schlüssel zu allem anderen. Eine Weiterleitungsregel, die Reset-Mails an eine fremde Adresse kopiert, oder ein Filter, der Sicherheitswarnungen archiviert, bevor du sie siehst, überlebt jede Änderung deines WordPress-Passworts.
Prüfe Weiterleitungen, Filter, App-Passwörter, verbundene Apps sowie Wiederherstellungs-E-Mail und -Telefonnummer. Schalte die Zwei-Faktor-Authentifizierung ein und melde alle anderen Sitzungen ab.
6. Google, Search Console und Tag Manager
Nach einem Einbruch tragen sich Angreifer oft als Inhaber in der Google Search Console oder den Bing Webmaster Tools ein. Von dort können sie Spam-Sitemaps einreichen, deine echten Seiten aus Google entfernen lassen und deine Suchdaten lesen — und ein Inhaber bleibt Inhaber, auch nachdem die Seite bereinigt ist. Relvatos SEO-Integritäts-Prüfung meldet ein neues Verifizierungs-Token auf der Seite, aber die Liste der Inhaber liegt im Google-Konto, nicht auf deinem Server.
Der zweite Fall ist Google Tag Manager: Wer einen Container veröffentlichen kann, bringt ein Skript auf jede Seite, ohne den Server anzufassen. Prüfe die Nutzer in der Search Console (Einstellungen → Nutzer und Berechtigungen), den Bing Webmaster Tools, Tag Manager und Analytics, und entferne alle, die du nicht kennst.
7. Domain-Registrar, DNS und CDN
Wer die Domain kontrolliert, bestimmt, wohin Seite und E-Mail zeigen. Prüfe die Nutzer und API-Tokens beim Registrar, beim DNS-Anbieter und beim CDN (vor allem Cloudflare), schalte die Zwei-Faktor-Authentifizierung und die Transfersperre des Registrars ein. Relvatos DNS-Monitoring meldet eine Änderung der Nameserver oder Mailserver, sieht aber nicht, wer ein Login zu diesen Konten hat.
8. Deploy-Schlüssel, Integrationen und Backups
Wird die Seite aus GitHub oder einem anderen Repository ausgeliefert, prüfe die Deploy-Schlüssel, die CI-Secrets und wer pushen darf. Prüfe die Integrationen, die einen Schlüssel zur Seite haben: Backup-Dienste, Uptime-Monitore, Cloud-Konten von Page-Buildern, Anwendungspasswörter, die du für Zapier oder eine Mobil-App angelegt hast.
Und die Backups selbst: Ein Backup von nach dem Einbruch spielt den Einbruch wieder ein. In Relvato zeigt die Sicherheitsseite der Website, wann zuletzt alle Integritätsprüfungen gleichzeitig bestanden haben — ein Backup aus diesem Zeitraum ist das sicherste zum Wiederherstellen.
Sichere es in dieser Reihenfolge ab
Die Reihenfolge zählt, weil jedes Konto das nächste zurücksetzen kann. Fang beim Gerät an: einem Rechner, dem du vertraust, oder einem frisch bereinigten. Dann das E-Mail-Postfach, weil dort jeder andere Reset ankommt. Dann Registrar-, DNS- und CDN-Konten, dann Hosting-, SFTP-, SSH- und Datenbank-Nutzer. Dann WordPress: unbekannte Administratoren und Anwendungspasswörter entfernen, das Passwort jedes Administrators ändern und neue Sicherheitsschlüssel in wp-config.php erzeugen, damit jede bestehende Sitzung abgemeldet wird. Zuletzt die Konsolen von Drittanbietern: Search Console, Tag Manager, Analytics und Deploy-Werkzeuge.
Nutze bei jedem Schritt die Option „von allen Sitzungen abmelden“, wo es sie gibt. Ein geändertes Passwort beendet keine Sitzung, die schon gestohlen wurde.
Was Relvato prüft — und was nicht
Relvato prüft die Seite von außen, so wie ein Besucher, und über sein WordPress-Plugin, das meldet, was auf dem Server liegt — nie Dateiinhalte. Es findet eingeschleuste Dateien und Code, der aus der Datenbank ausgeführt wird, in der Nutzerliste versteckte Administratoren, Anwendungspasswörter, von eingeschleustem Code registrierte Service Worker, DNS-Änderungen und neue Search-Console-Verifizierungs-Tokens. Sieht es Anzeichen eines Hacks, zeigt es diese Checkliste daneben und kann die Seite für 48 Stunden in Quarantäne nehmen.
Deinen Browser, deinen Rechner und die Konten auf dieser Liste sieht es nicht. Das kann nichts, was auf einem Server läuft. Diesen Teil musst du selbst prüfen — und oft hat der Angriff genau dort angefangen.
Wo Angreifer hereinkommen, ohne dass ein Server-Scan es sieht
| Wo | Warum der Server es nicht sieht | Was du prüfst |
|---|---|---|
| Browser-Erweiterungen | Sie handeln in wp-admin mit deiner Sitzung, von deiner IP | Unbekannte Erweiterungen entfernen; Admin-Arbeit in einem Profil ohne |
| Der Rechner des Admins | Gestohlene Passwörter und Login-Cookies werden woanders benutzt; ein Cookie umgeht 2FA | Scannen; Passwörter von einem anderen Gerät ändern |
| Browserdaten des Admins | Ein Service Worker oder eine Sitzung lebt im Browser | Websitedaten der Domain in jedem Admin-Browser löschen |
| Hosting, SFTP, SSH, Datenbank | Diese Konten stehen über WordPress | Nutzer, SSH-Schlüssel, Datenbank-Nutzer und Cron-Jobs des Hosters |
| E-Mail-Postfach | Dort kommen Passwort-Resets an | Weiterleitungen, Filter, App-Passwörter, Wiederherstellung |
| Google- und Bing-Konsolen, Tag Manager | Inhaber und Container liegen in Google- und Microsoft-Konten | Inhaber in Search Console und Bing; wer im Tag Manager veröffentlichen darf |
| Registrar, DNS, CDN | Das Steuerpult der Domain liegt woanders | Nutzer, API-Tokens, Zwei-Faktor-Login, Transfersperre |
| Deploy-Schlüssel und Backups | Schlüssel liegen bei anderen Diensten; ein Backup kann die Infektion enthalten | Deploy-Schlüssel, CI-Secrets, Integrationen; aus der Zeit vor dem Einbruch wiederherstellen |
Fragen und Antworten
Warum zeigen meine WordPress-Logs mein eigenes Konto und meine IP-Adresse?
Weil die Änderungen wahrscheinlich aus deinem eigenen Browser kamen: von einer bösartigen Erweiterung mit deiner Sitzung oder von Malware auf deinem Rechner. Der Server sieht einen echten Administrator, der echte Dinge tut, also sieht jedes Log legitim aus. Prüfe deine Erweiterungen und scanne den Rechner, bevor du ihm wieder vertraust.
Verhindert die Zwei-Faktor-Authentifizierung das nicht?
Nicht bei gestohlenen Sitzungen. Zwei-Faktor-Authentifizierung schützt die Anmeldung; ein gestohlenes Login-Cookie ist eine Sitzung, die sie schon passiert hat. Neue Sicherheitsschlüssel in wp-config.php melden jede Sitzung ab, und das Passwort danach zu ändern — von einem sauberen Gerät aus — verhindert, dass sich der Angreifer wieder anmeldet.
Reicht es, mein WordPress-Passwort zu ändern?
Nein. Es beendet keine laufenden Sitzungen, widerruft keine Anwendungspasswörter und berührt weder Hosting noch E-Mail, Registrar oder Google-Konten. Geh die Checkliste in Reihenfolge durch, beginnend mit dem Gerät und dem E-Mail-Postfach.
Welches Backup soll ich wiederherstellen?
Eines von vor dem Einbruch — ein späteres spielt die Infektion wieder ein. Relvato zeigt auf der Sicherheitsseite der Website und in der Warnung, wann zuletzt alle Integritätsprüfungen gleichzeitig bestanden haben („zuletzt sauber“), damit du weißt, aus welchem Zeitraum du wiederherstellst.
Kann Relvato meine Browser-Erweiterungen oder meine Konten sehen?
Nein, und das kann kein Werkzeug, das auf dem Server läuft. Relvato prüft die Seite und das, was sein Plugin vom Server meldet. Sieht es Anzeichen eines Hacks, zeigt es diese Checkliste, weil der Weg hinein oft dort liegt, wo es nicht hinsehen kann.