WordPress-Malware kommt immer wieder? Hier versteckt sie sich
Du hast die infizierten Dateien gelöscht, einen Sicherheits-Scan laufen lassen, und er meldete: sauber. Am nächsten Morgen ist die falsche „Bestätigen Sie, dass Sie ein Mensch sind“-Box wieder da, die Spam-Weiterleitung oder das eingeschleuste Skript. Dass WordPress-Malware immer wieder kommt, ist kein Pech: Moderne WordPress-Malware ist darauf gebaut, eine Bereinigung zu überleben. Entfernt hast du den sichtbaren Teil; der Teil, der ihn zurückbringt, sitzt woanders. Dieser Guide zeigt die acht Orte, an denen sie sich versteckt, warum ein Scanner innerhalb der Website sie übersieht, in welcher Reihenfolge du bereinigst und wie du innerhalb einer Stunde merkst, wenn sie zurückkommt.
Warum WordPress-Malware immer wieder kommt
Eine Neuinfektion bedeutet fast nie, dass der Angreifer erneut eingebrochen ist. Sie bedeutet, dass die Bereinigung eine Schicht übersehen hat. Selbstheilende Malware teilt sich auf: ein kleiner Loader, der bei jeder Anfrage läuft, eine Kopie des Schadcodes an einem Ort, an dem Datei-Scans nicht nachsehen, und ein Weg zurück hinein – ein Konto, ein Schlüssel oder eine geplante Aufgabe. Löschst du die sichtbaren Dateien, schreibt der Loader sie aus der gespeicherten Kopie zurück, oft innerhalb von Minuten. Löschst du den Loader, aber nicht das Konto, installiert der Angreifer ihn einfach von Hand neu.
Was du siehst – ein falsches CAPTCHA, eine Weiterleitung auf eine Apotheken-Website, ein Skimmer im Checkout – ist der Schadcode. Er ist beim Entfernen der unwichtigste Teil und der einzige, auf den die meisten Bereinigungen zielen. Die Infektion ist die Kombination aus Loader, gespeicherter Kopie und dem Weg zurück hinein.
1. Ein Must-Use-Plugin, das bei jeder Anfrage lädt
WordPress führt jede PHP-Datei in wp-content/mu-plugins vor den normalen Plugins aus, bei jeder Anfrage, und Must-Use-Plugins lassen sich im wp-admin nicht deaktivieren. Das macht den Ordner zum Lieblingsort für einen Loader. Ein typischer besteht aus wenigen Zeilen mit harmlosem Namen (wp-cache-helper.php), die einen kodierten String aus der Datenbank lesen und ausführen. In der Datei selbst steckt kein Schadcode, auf den ein Signatur-Scanner anspringen könnte.
Sieh dir jede Datei in mu-plugins an und frag dich, woher sie kommt. Hoster und einige Plugins legen dort legitim Dateien ab; alles, was eval, base64_decode oder gzinflate auf Daten anwendet, die es zurückliest, gehört nicht dazu.
2. Eine Kopie des Schadcodes in der Datenbank
Der Loader braucht etwas zum Laden. Das liegt in wp_options, oft als Transient oder als Option mit systemisch klingendem Namen, als ein langer base64-String oder als PHP-Code. Weil es eine Datenbankzeile ist und keine Datei, rühren Datei-Scanner und Datei-Wiederherstellungen sie nie an – stellst du die Dateien aus einem Backup wieder her, schreibt der Loader (falls er überlebt hat) oder eine geplante Aufgabe die Malware einfach wieder auf die Festplatte.
Optionen, die PHP-Code oder einen einzigen großen kodierten Block enthalten, verdienen einen Blick. Einige legitime Plugins speichern dort Code oder Signaturen (Sicherheits-Plugins legen ihre Malware-Signaturen in Optionen ab), also prüfe vor dem Löschen – aber ein zufällig aussehender Name mit 40 KB base64 ist keine Einstellung.
3. wp-config.php, .htaccess und .user.ini
Diese drei Dateien laufen, bevor WordPress läuft, und sie liegen außerhalb von wp-content – dort sehen viele Scans gar nicht nach. Eine auto_prepend_file-Zeile in .htaccess oder .user.ini lässt PHP vor jeder einzelnen Anfrage eine Datei ausführen, oft eine, die als Bild in uploads getarnt ist. Eine AddHandler-Zeile kann .png- oder .ico-Dateien als PHP ausführen lassen. Ein Paar RewriteCond-Zeilen kann gezielt nur Besucher, die von Google kommen, auf eine Spam-Website schicken, sodass die Website normal aussieht, wenn du die Adresse selbst eintippst. Und wp-config.php kann bei jedem Laden eine Datei aus uploads einbinden oder einen String dekodieren.
Wordfence und NinjaFirewall nutzen auto_prepend_file legitim für ihre Firewalls; für alles andere, was eine Datei voranstellt, braucht es eine Erklärung.
4. Eine Datei zwischen den WordPress-eigenen
Eine PHP-Datei in wp-includes/images oder wp-admin/includes fällt zwischen Tausenden Core-Dateien nicht auf. Eine Neuinstallation von WordPress entfernt sie nicht – wie die FAQ von WordPress.org zu gehackten Websites selbst anmerkt, überschreiben Installer die Dateien, die sie mitbringen, und Hacks fügen meist neue hinzu. WordPress veröffentlicht für jede mitgelieferte Datei eine Prüfsumme, sodass ein Core-Prüfsummen-Check eine veränderte Core-Datei findet; eine hinzugefügte steht in keiner Prüfsummenliste und muss deshalb gesondert gesucht werden.
In wp-admin und wp-includes gehört nichts außer WordPress. Jede PHP-Datei dort, die WordPress nicht mitliefert, ist eine Backdoor, bis das Gegenteil bewiesen ist.
5. Der Plugins-Ordner: eingeschleust, versteckt oder abgeschaltet
Hier passieren drei Dinge. Der Angreifer kopiert ein Plugin als Dateien hinein, statt es zu installieren, sodass in keinem Log je eine Installation auftaucht. Er versteckt es mit dem Filter all_plugins vor der Plugins-Seite, sodass es nie in der Liste erscheint, die du prüfst. Und er benennt den Ordner deines Sicherheits-Plugins um – aus wordfence wird wordfence.disabled_1712 –, woraufhin WordPress es stillschweigend abschaltet. Es findet keine Deaktivierung statt, also schlägt auch kein Deaktivierungs-Alarm an, und das Sicherheits-Plugin existiert für WordPress schlicht nicht mehr.
Wenn das Dashboard deines Sicherheits-Plugins genau dann verstummt ist, als die Probleme anfingen, prüf den Namen seines Ordners auf dem Server.
6. Konten und Anwendungspasswörter
Der dauerhafteste Weg zurück hinein ist gar kein Code. Ein neuer Administrator oder ein bestehendes Kundenkonto, dem still die Administrator-Rolle gegeben wurde, übersteht jede Datei-Bereinigung. Genauso ein Anwendungspasswort: Seit WordPress 5.6 kann ein Administrator Anwendungspasswörter haben, die sich direkt an der REST-API anmelden, ohne das Login-Formular – Zwei-Faktor-Login, Login-Limits und ein geändertes Passwort greifen bei ihnen also nie.
Prüfe jeden Administrator (Benutzer → nach „Administrator“ filtern) und im Profil jedes einzelnen den Abschnitt „Anwendungspasswörter“. Widerrufe alles, was du nicht selbst angelegt hast.
7. Geplante Aufgaben und REST-Routen
Mit WP-Cron läuft Code nach Zeitplan. Ein Loader, der eine geplante Aufgabe registriert, kann die Malware jede Stunde neu herunterladen oder neu schreiben – lange nachdem du die Dateien gelöscht hast, die er geschrieben hat. Eine REST-Route tut dasselbe auf Abruf: ein öffentlicher Endpunkt, den der Angreifer aufruft, um eine neue Kopie aufzuspielen. Beide sehen aus wie jeder andere Hook – verräterisch ist, wo ihr Code liegt: aus einem String ausgeführt, zur Laufzeit erzeugt oder im uploads-Ordner statt in einem Plugin, das du installiert hast.
Plugins wie WP Crontrol listen die geplanten Aufgaben auf; bei jeder unbekannten lautet die Frage, welche Datei sie definiert.
8. Die Browser deiner Besucher
Zwei Dinge leben auf der Seite der Besucher. Ein Service Worker ist ein Skript, das der Browser für eine Website installiert und zwischen Besuchen weiterlaufen lässt; er sieht jede Anfrage, die die Website stellt, und kann sie selbst beantworten. Hat eingeschleuster Code einen registriert, bleibt er in den Browsern deiner Besucher, nachdem die Website bereinigt ist – der eine Ort, den eine Bereinigung auf dem Server nicht erreicht. Und ClickFix, die falsche „Bestätigen Sie, dass Sie ein Mensch sind“-Box, die Besucher auffordert, Win+R zu drücken und einen Befehl einzufügen, bringt Malware auf die Computer deiner Besucher, nicht auf deinen Server – der Schaden geht also weiter, bis die Einschleusung selbst entfernt ist.
Solche Einschleusungen lassen eingeloggte Administratoren oft aus, sodass die Website für dich völlig normal aussehen kann. Prüfe sie in einem privaten Fenster, ausgeloggt.
Warum ein Scanner in der Website sie übersieht
Ein Sicherheits-Plugin läuft innerhalb der Website, die es schützt – Malware, die die Website kontrolliert, kann also kontrollieren, was das Plugin sieht: Ordner umbenennen, und es ist aus; ein Plugin aus der Liste verstecken, und es ist nicht da; den Schadcode in der Datenbank halten, und es gibt keine Datei zum Abgleichen. Signatur-Scans suchen außerdem nach bekanntem Schadcode, und ein Loader, der einen String aus der Datenbank ausführt, enthält keinen.
Deshalb ist Relvato andersherum gebaut. Das Relvato-Plugin meldet nur, was auf der Website ist – Fingerabdrücke, Namen und Orte, nie Inhalte –, und die von dir bestätigte Baseline sowie das Urteil liegen auf den Servern von Relvato, wo Malware auf deiner Website sie nicht verändern kann. Die Prüfungen, die bei dieser Art von Infektion am meisten zählen, sehen deine Website so an wie ein Besucher: von außen. Und wenn das Plugin selbst nicht mehr antwortet – deaktiviert, gelöscht oder blockiert –, bemerkt Relvato das innerhalb von fünf Minuten und markiert die Website in deinen Benachrichtigungen und in der E-Mail-Zusammenfassung als kritisch.
In dieser Reihenfolge bereinigen, sonst schreibt sie sich neu
Die Reihenfolge zählt, weil jede Schicht die anderen wiederherstellt. Versetze die Website in den Wartungsmodus und mach zuerst ein Backup, auch ein infiziertes – du wirst es brauchen, um herauszufinden, wie die Angreifer hereingekommen sind.
Dann: Entferne den Loader (mu-plugins, alles, was außerhalb eines Plugins Code ausführt), dann den gespeicherten Schadcode (die Optionen und Transients, die er liest), dann die Dateien (WordPress-Core aus einem frischen Download neu installieren, PHP-Dateien löschen, die Core nicht mitliefert, Plugins und Themes aus der Originalquelle neu installieren), dann die Wege zurück hinein (unbekannte Administratoren, Anwendungspasswörter, geplante Aufgaben). Gib dem Ordner deines Sicherheits-Plugins seinen Namen zurück und lass seinen Scan erneut laufen. Ändere dann jedes Passwort – WordPress, Hosting, SFTP, Datenbank – und erzeuge neue Sicherheitsschlüssel in wp-config.php, damit jede bestehende Anmeldung abgemeldet wird. WordPress.org rät, die Passwörter noch einmal zu ändern, sobald du sicher bist, dass die Website sauber ist – und das ist der richtige Moment.
Räume zum Schluss auf, was Besucher behalten: Entferne jeden Service Worker, den die Website nicht brauchte, und den Code, der ihn registriert hat.
Die nächsten 48 Stunden beobachten
Wurde eine Schicht übersehen, merkst du es bald: Selbstheilende Malware kommt meist innerhalb von Stunden zurück, nicht nach Wochen. Eine tägliche Prüfung kann einen Tag brauchen, bis sie es sieht – nach einer Bereinigung lohnt es sich daher, zwei Tage lang stündlich dieselben Orte zu prüfen.
Relvato macht das von selbst. Wenn Dateiintegrität, Theme-Integrität oder die Admin-Liste etwas gefunden hat und der nächste Lauf sauber ist, startet eine Überwachung auf Neuinfektion („Reinfection watch“): Diese Prüfungen laufen 48 Stunden lang jede Stunde, und eine Bereinigung während der Überwachung verlängert sie. Du kannst sie auch selbst auf der „Security“-Seite der Website starten. Stündliche Prüfungen gibt es in Tarifen mit geplanten Läufen.
Wo sich selbstheilende Malware versteckt – und was sie findet
| Versteck | Wie es die Infektion zurückbringt | Was Relvato prüft |
|---|---|---|
| mu-plugins | Ein Loader läuft bei jeder Anfrage und lässt sich im wp-admin nicht abschalten | Eine neue Datei in mu-plugins; Malware-Muster darin; Code, den sie ausführt |
| Die Datenbank | Eine kodierte Kopie schreibt gelöschte Dateien zurück | Optionen mit PHP-Code oder einem einzigen großen kodierten Block |
| wp-config.php, .htaccess, .user.ini | Eine Datei, die vor jeder Anfrage läuft; Bilder, die als PHP laufen; Besucher aus der Suche umgeleitet | Ein Fingerabdruck jeder Datei und die Namen der Malware-Muster darin |
| wp-admin und wp-includes | Eine Backdoor neben den Core-Dateien übersteht eine Core-Neuinstallation | PHP-Dateien, die WordPress nicht mitliefert |
| Der Plugins-Ordner | Ein als Dateien hineinkopiertes und verstecktes Plugin; der umbenannte Ordner des Sicherheits-Plugins | Nicht über WordPress installierte Plugins, versteckte Plugins, umbenannte Sicherheits-Plugins |
| Konten | Ein zusätzlicher oder hochgestufter Admin; ein Anwendungspasswort, das Login und 2FA umgeht | Neue und hochgestufte Admins sowie die Anwendungspasswörter jedes Admins |
| Geplante Aufgaben und REST-Routen | Schreibt die Malware nach Zeitplan oder auf Abruf neu | Code, der von dort läuft, wo ihn kein Plugin, kein Theme und nicht WordPress abgelegt hat |
| Browser der Besucher | Ein Service Worker, der die Bereinigung überdauert; ein falsches CAPTCHA (ClickFix) | Service Worker, die die Seiten installieren; falsche Verifizierungsaufforderungen |
Fragen und Antworten
Warum wird meine WordPress-Website nach dem Bereinigen immer wieder gehackt?
Meist wird sie gar nicht erneut gehackt – die Bereinigung hat eine Schicht übersehen. Selbstheilende Malware behält einen Loader (oft in mu-plugins), eine Kopie von sich in der Datenbank und einen Weg zurück hinein (ein Admin-Konto, ein Anwendungspasswort oder eine geplante Aufgabe). Entfernst du nur die sichtbaren Dateien, stellt einer der anderen Teile sie wieder her, oft innerhalb von Stunden.
Entfernt eine Neuinstallation von WordPress die Malware?
Nicht vollständig. Eine Neuinstallation überschreibt die Dateien, die WordPress mitliefert, aber eine in wp-includes oder wp-admin hinzugefügte PHP-Datei bleibt, und nichts in wp-content, wp-config.php, .htaccess oder der Datenbank wird angefasst. Installiere den Core neu, such dann nach Dateien, die WordPress nicht mitliefert, und bereinige die übrigen Schichten.
Was ist das falsche „Bestätigen Sie, dass Sie ein Mensch sind“-Pop-up auf meiner Website?
Das ist ClickFix: Eingeschleuster Code zeigt ein falsches CAPTCHA, das Besucher auffordert, Win+R zu drücken (oder das Terminal zu öffnen), einzufügen und Enter zu drücken. Ein Skript hat bereits einen Befehl in ihre Zwischenablage gelegt, sodass sie Malware auf ihrem eigenen Computer installieren. Es ist eine Infektion deiner Website, keine Firewall, und es versteckt sich oft vor eingeloggten Administratoren – prüfe die Website ausgeloggt.
Kann mein Sicherheits-Plugin das erkennen?
Teilweise. Ein Sicherheits-Plugin läuft innerhalb der Website, also kann Malware, die die Website kontrolliert, den Ordner des Plugins umbenennen (und es so ohne Deaktivierung abschalten), sich vor der Plugins-Seite verstecken und ihren Schadcode in der Datenbank halten, wo Datei-Scans nicht nachsehen. Behalte das Sicherheits-Plugin und ergänze eine Prüfung, deren Aufzeichnung und Urteil außerhalb der Website liegen.
Muss ich Passwörter und Sicherheitsschlüssel ändern?
Ja – nachdem die Website sauber ist, nicht nur, wenn du den Hack entdeckst. Ändere die Passwörter für WordPress, Hosting, SFTP und Datenbank, widerrufe Anwendungspasswörter, die du nicht angelegt hast, und erzeuge neue Sicherheitsschlüssel in wp-config.php, damit jede bestehende Sitzung abgemeldet wird.
Wie lange sollte ich die Website nach einer Bereinigung beobachten?
Mindestens 48 Stunden, und häufiger als täglich: Selbstheilende Malware kommt meist innerhalb von Stunden zurück. Relvatos Überwachung auf Neuinfektion führt die Integritätsprüfungen nach einer Bereinigung 48 Stunden lang jede Stunde erneut aus – in Tarifen mit geplanten Läufen.