Ein Blick hinter die Kulissen eines wp2shell- WordPress -Angriffs: Kompromittierung und Wiederherstellung

Im Juli 2026 wurden innerhalb von zwei Stunden zwei „ WordPress “-Websites auf „ InMotion Hosting “-Konten kompromittiert. Eine davon wurde vier Tage später bereinigt, dann aber sechs Tage später erneut infiziert. Das haben unsere Teams herausgefunden: die Persistenz-Ebenen, die Angreifer nach dem ersten Zugriff aufbauen, die konkreten Indikatoren, die du heute auf deinen eigenen Websites überprüfen kannst, und warum das Löschen von betrügerischen Administratorkonten eine Kompromittierung nicht beendet.

Die meisten Berichte über wp2shell haben sich auf den ersten Schritt beschränkt. Über diese Kette verschafft sich ein Angreifer Zugang. Für alle, die für eine WordPress -Seite verantwortlich sind, ist jedoch entscheidend, was in den Minuten und Tagen danach passiert – und genau dieser Teil wurde bisher weitaus weniger dokumentiert.

Unsere Teams haben Anfang August 2026 zwei separate Sicherheitsvorfälle bei Kunden untersucht. Beide Websites wurden bereinigt und sind wieder in Betrieb. Kontonamen, Domains, Server-IDs und Verzeichnispfade wurden hier entfernt. Die Details zum Ablauf wurden jedoch nicht entfernt, da genau diese Informationen anderen Website-Betreibern helfen, das gleiche Problem auf ihren eigenen Installationen zu erkennen.

Die Exploit-Kette ist der Einstiegspunkt, nicht der Vorfall

„wp2shell“ bezieht sich auf die verketteten Sicherheitslücken „ WordPress “ im WordPress-Core CVE-2026-63030 und CVE-2026-60137, die es einem nicht authentifizierten Angreifer gemeinsam ermöglichen, bei einer Standardinstallation von „ WordPress “ Remote-Code auszuführen. Die erste Schwachstelle ist ein Problem mit der Routenverwechslung im REST-Batch-Endpunkt. Die zweite ist eine SQL-Injection in WP_Query. In einer Kette lassen sie eine anonyme HTTP-Anfrage in ein von einem Angreifer erstelltes Administratorkonto, ganz ohne Plugins, ohne Anmeldedaten und ohne dass du etwas tun musst.

Die Versionsgrenzen sind für die Triage wichtig. Die technische Analyse der Release-Notes durch Patchstack zeigt, dass die SQL-Injection-Schwachstelle bereits in „ WordPress “ 6.8 vorhanden war, während die Verwechslungsgefahr beim Batch-Handler, die dazu führt, dass daraus ein nicht authentifizierter, aus der Ferne ausnutzbarer Angriff wird, erst in Version 6.9 eingeführt wurde. Eine Website auf dem 6.8-Zweig weist zwar die Injection-Schwachstelle auf, lässt sich über diesen Weg jedoch nicht zur vollständigen Remote-Code-Ausführung ausnutzen.

WordPress Am 17. Juli 2026 wurden die Notfall-Updates 6.9.5, 7.0.2 und 6.8.6 veröffentlicht und automatische Updates erzwungen. Die CISA hat die Sicherheitslücke am 21. Juli in ihren Katalog „Known Exploited Vulnerabilities“ aufgenommen. Bereits wenige Stunden nach der Bekanntgabe wurden Angriffe in freier Wildbahn gemeldet, und innerhalb weniger Tage kursierten Dutzende funktionierender Proof-of-Concept-Implementierungen.

Beide von uns untersuchten Websites wurden innerhalb der ersten 48 Stunden nach dem Patch angegriffen – von unabhängigen Netzwerken aus, im Abstand von etwa zwei Stunden. Dieser zeitliche Abstand ist bemerkenswert. Niemand hatte es gezielt auf diese Unternehmen abgesehen. Es handelte sich um Scan-Verkehr, der einfach alles aufspürte, was noch nicht gepatcht war.

Keine der beiden Untersuchungen konnte den genauen Autorisierungsfehler, der bei der ersten Anfrage ausgenutzt wurde, schlüssig nachweisen. Diese Einschränkung ist eher struktureller als lokaler Natur. Standardmäßige Apache- und NGINX -Zugriffsprotokolle zeichnen die Anforderungszeile, den Statuscode und den User-Agent auf, und kein weit verbreitetes Protokollformat speichert Anforderungsinhalte, Cookie-Header, Autorisierungs-Header oder REST-Nonces. Genau diese Felder würden den Mechanismus identifizieren, und sie werden von keinem Host gespeichert, der einen herkömmlichen Protokollierungsstack verwendet.

Was die Protokolle jedoch festhalten und was unsere Teams daraus rekonstruieren konnten, ist der Ablauf. In beiden Fällen traf eine Flut von POST-Anfragen auf die REST-Batch-Route „ WordPress “ und erhielt den HTTP-Status 207 zurück, worauf innerhalb von Sekunden die Erstellung eines Administratorkontos folgte. Auf einer Website enthielten die Anfragen einen User-Agent-String, der mit dem veröffentlichten Namen der Exploit-Kette übereinstimmte. Auf derselben Website wurde zum Zeitpunkt der in seinem Namen durchgeführten Aktionen kein erfolgreiches Anmeldeereignis für das ursprüngliche Administratorkonto aufgezeichnet, was eher auf eine nicht authentifizierte Ausnutzung als auf ein gestohlenes Passwort hindeutet.

Die Beweislage passt zu wp2shell. Sie reicht jedoch nicht aus, um eine eindeutige Zuordnung vorzunehmen, und wir geben auch keine solche ab. Wenn man behauptet, dass eine bestimmte CVE zu einem bestimmten Sicherheitsvorfall geführt hat, ohne dass Beweise auf Anfrageebene vorliegen, die das untermauern, führt das dazu, dass falsche Ursachen in die Unterlagen gelangen und falsche Abhilfemaßnahmen priorisiert werden.

Die erste Nutzlast landete in weniger als einer halben Minute

Der Ablauf auf der ersten Website, der anhand der Zugriffsprotokolle und der Aktivitätsaufzeichnungen von „ WordPress “ rekonstruiert wurde, sah folgendermaßen aus:

1. Eine Anfrage ist bei der REST-Batch-Route eingegangen und hat den HTTP-Status 207 zurückgegeben.
2. Zwei Sekunden später wurde unter dem ursprünglichen Administratorkonto der Website eine Aktion von der IP-Adresse des Angreifers aus registriert, bei der ein ungewöhnlicher interner Beitragseintrag geändert wurde.
3. Eine Sekunde später hat derselbe Kontext ein neues Administratorkonto erstellt, dessen Name so gewählt wurde, dass er wie ein Dienstkonto wirkt.
4. Acht Sekunden später war das neue Konto erfolgreich angemeldet.
5. Elf Sekunden später wurde eine ZIP-Datei mit einem Plugin hochgeladen.
6. Drei Sekunden später war das Plugin installiert und aktiviert.
7. Eine Sekunde später hat der Angreifer die ZIP-Datei aus der Medienbibliothek gelöscht.

Von Anfang bis Ende etwa 24 Sekunden. Die zweite Seite folgte dem gleichen Aufbau und durchlief die gleiche Abfolge in etwa 28 Sekunden.

Das Plugin präsentierte sich im Dashboard von „ WordPress “ als Sicherheitsprogramm mit einem plausiblen Namen und einer glaubwürdigen Versionsnummer. Der Name seines Verzeichnisses sah aus wie der eines legitimen Performance-Plugins, an den ein zufälliges Hex-Suffix angehängt war. Wer die Plugin-Liste nur flüchtig überflog, hätte es sicher übersehen.

Dreizehn Sekunden nach der Installation hat der Angreifer die PHP-Hauptdatei des Plugins direkt aufgerufen und ausgeführt id && uname -a && hostname && pwd. Es wurde ein HTTP-Status 200 zurückgegeben. Ab diesem Zeitpunkt konnte der Angreifer Shell-Befehle ausführen, die unter dem Benutzer „ cPanel “ liefen.

Die Ermittlungen decken die Hacker-Kampagne auf

Was der Angreifer als Nächstes überprüft hat, sagt mehr über seine Absichten aus als die Malware selbst. Indem unser Team diese Befehle der Reihe nach durchgesehen hat, konnten wir herausfinden, worum es bei dieser Kampagne ging. In schneller Abfolge wurde die Webshell genutzt, um Folgendes zu testen:

• Der Speicherort und der Typ der sendmail-Binärdatei
• Ob PHPs mail() Die Funktion war verfügbar
• Ob proc_open() war verfügbar
• Der Inhalt der Liste der deaktivierten PHP-Funktionen
• Ob der ausgehende SMTP-Server auf Port 25 erreichbar war
• Auflösung von DNS- und MX-Einträgen
• Ob sich die E-Mail-Umgebung wie eine „Trap“--, „Discard“- oder „Blackhole“-Konfiguration verhalten hat

Dieser letzte Test ist besonders interessant. Der Angreifer hat gezielt geprüft, ob ausgehende E-Mails tatsächlich zugestellt oder vom Host stillschweigend blockiert werden. Das ist eine Erkundung der Spam-Infrastruktur. Anhand der von uns untersuchten Beweise konnte keine erfolgreiche ausgehende Kampagne bestätigt werden, aber die Absicht ist eindeutig.

Die zweite Website wies in eine andere Richtung. Sie enthielt SEO-Cloaking-Loader, die je nach User-Agent, Referrer, Sprache, IP-Adresse, Host und Anfrage-URI unterschiedliche Inhalte auslieferten, mit der Möglichkeit, die URL umzuschreiben robots.txt. Das ist „Search Result Poisoning“, ein von Spam-Relay unabhängiger Weg zur Monetarisierung. Kompromittierte WordPress -Seiten werden häufig für folgende Zwecke umfunktioniert: Weiterleitungen, eingeschleuste Skripte und das Ausspähen von Zugangsdaten bei Besuchern, und zwar nicht nur für das, was der Angreifer vom Server selbst haben will.

Die Persistenz wurde in neun unabhängigen Schichten aufgebaut

Neunzig Sekunden, nachdem er sich Befehlsausführungsrechte gesichert hatte, richtete der Angreifer auf der ersten Website einen Cron-Job ein, der alle fünf Minuten ausgeführt wurde. Dieser sollte eine schädliche Plugin-Datei aus einer im Verzeichnis „uploads“ gespeicherten Sicherungskopie wiederherstellen, falls die ursprüngliche Datei verloren gehen sollte.

Das war die erste von neun Schichten. Das komplette Set, das im Laufe der Ermittlungen sichergestellt wurde:

• Vom Angreifer erstellte Administratorkonten – mehrere davon –, die in den folgenden Tagen von verschiedenen IP-Adressen aus angelegt wurden
• Schädliche Standard-Plugins, drei zusätzliche Verzeichnisse zusätzlich zum ursprünglichen, die jeweils funktionierende Webshells enthalten
• Ein unverzichtbares Plugin namens „Guardian“, mit dem du gelöschte Dateien wiederherstellen kannst und das sich nicht über das Dashboard unter „ WordPress “ deaktivieren lässt
• PHP kopiert unter wp-content/uploads, deren Namen den Kernklassendateien von „ WordPress “ nachempfunden sind
• Verschlüsselte Nutzdaten in der Optionstabelle, die unter Namen gespeichert sind, die legitime temporäre Daten zum Zustand der Website imitieren
• Loader-Blöcke, die in … eingefügt wurden wp-config.php, das diese Datenbankoptionen auslas, das gespeicherte PHP entschlüsselte und ausführbare Dateien auf die Festplatte schrieb
• Ausführbare Payloads im temporären Verzeichnis „CageFS“ des Accounts, insgesamt fünf davon
• Zusätzliche Cron-Jobs: fünf separate 30-Minuten-Einträge zur Durchführung von Selbsttests und Wiederherstellungsprüfungen
• Logik, um das vom Angreifer bevorzugte Administratorkonto nachzubilden und die Sitzungstoken anderer Benutzer zu zerstören

Lies dir die Liste noch einmal durch und denk dabei an die Bereinigung. Wenn du das Plugin entfernst, bleibt der Cron-Job bestehen. Wenn du den Cron-Job entfernst, bleiben die Daten in der Datenbank zurück. Wenn du die Daten in der Datenbank entfernst, bleibt das wp-config.php einen Loader, der es neu erstellen würde. Wenn man das Administratorkonto löscht, bleibt die Webshell bestehen, die es erstellt hat.

Nur zwei dieser neun Ebenen befinden sich an Stellen, die ein herkömmlicher Malware-Scanner überprüft. Um die restlichen zu finden, musste man die entschlüsselte Payload-Logik auswerten und mit der crontab sowie der Optionstabelle abgleichen.

Die zweite Seite hat eine erwähnenswerte Variante hinzugefügt: ein Plugin, das man unbedingt nutzen muss und das sich als Komponente zur Begrenzung der Anmeldeversuche tarnt, die sich wp_authenticate, hat bei jedem Anmeldeversuch den Benutzernamen und das Passwort im Klartext erfasst, die Zieladresse über einen Blockchain-Smart-Contract statt über eine fest programmierte Domain ermittelt und die Anmeldedaten an einen entfernten Endpunkt übertragen. Außerdem hat es sich selbst aus der Liste der obligatorischen Plugins entfernt, damit es nicht im Dashboard erscheint.

Jedes Passwort, das in dieses Anmeldeformular eingegeben wurde, während die Datei aktiv war, ist kompromittiert. Nicht gehasht. Nicht erraten. Im Klartext ausgelesen.

Die sechs Tage zwischen der Reinigung und der erneuten Infektion

Am 20. Juli wurden durch Aktivitäten von einer anderen IP-Adresse alle vom Angreifer erstellten Administratorkonten auf der ersten Website gelöscht. Alle vier. WordPress Core wurde noch am selben Tag auf eine gepatchte Version aktualisiert.

Das sieht nach einer erfolgreichen Bereinigung aus. Die unerwünschten Konten waren verschwunden, die Sicherheitslücke wurde geschlossen und die Website lief wieder normal.

Die ursprüngliche Webshell wurde nie entfernt.

Am 26. Juli forderte eine bisher unbekannte IP-Adresse die noch vorhandene Plugin-Datei an. Der Angreifer nutzte sie, um einen temporären PHP-Helper zu schreiben, der die Umgebung „ WordPress “ lud, die vorhandene Webshell ausfindig machte, sie in das Verzeichnis „uploads“ kopierte, einen unverzichtbaren Plugin-Guardian erstellte, prüfte, ob das vom Angreifer bevorzugte Administratorkonto noch existierte, es neu anlegte, die Sitzungstoken anderer Nutzer zerstörte und sich selbst löschte.

WordPress Das Ergebnis wurde als neue Benutzerregistrierung protokolliert. Es handelte sich jedoch nicht um eine Registrierung. Es war PHP, das mit vollen Anwendungsrechten lief und genau das tat, was der Code der Website selbst tun darf.

Die Website wurde komplett neu aufgesetzt. Durch das Core-Patch am 20. Juli wurde die Sicherheitslücke geschlossen, die der Angreifer am 18. Juli ausgenutzt hatte – eine Lücke, die der Angreifer zu diesem Zeitpunkt allerdings schon nicht mehr nutzte.

Die Backups waren bereits kompromittiert

Die Wiederherstellung aus einem Backup ist die automatische Reaktion auf einen Sicherheitsvorfall. Beide Untersuchungen ergaben, dass diese automatische Reaktion versagt hätte.

Ein Konto enthielt eine Backdoor-Datei, die von einem früheren Hosting-Anbieter stammte. Sie befand sich in einem in das Konto importierten Migrations-Backup mit Änderungszeitstempeln vom August 2025 sowie in einer zweiten Kopie auf Kontoebene vom Oktober 2025. Diese Malware ist etwa elf Monate älter als die Geschichte des Kontos in unserer Infrastruktur und wurde entdeckt, weil bei der Untersuchung nicht nur der Live-Dokumentenstamm, sondern auch die importierten Backup-Strukturen überprüft wurden.

Ob die Kampagne vom Juli 2026 diesen älteren Zugriffspunkt wiederverwendet hat, lässt sich anhand der vorliegenden Beweise nicht belegen, und wir sind auch nicht davon ausgegangen, dass dies der Fall war. Was sich jedoch eindeutig feststellen lässt, ist, dass das Backup-Archiv nicht sauber war und schon vor der Einrichtung der Website nicht sauber gewesen war.

Die Rollback-Daten des Wartungs-Plugins desselben Accounts enthielten ein Verzeichnis mit zufällig benannten Plugins, das Code aus der Zeit des Angriffs enthielt. Das Rollback-Material konnte nicht als saubere Wiederherstellungsquelle verwendet werden. Das wurde entdeckt, weil der Rollback-Baum überprüft wurde, anstatt ihm einfach zu vertrauen.

Wiederherstellungspunkte erfassen den Zustand der Website zum jeweiligen Zeitpunkt, einschließlich allem, was sich dort bereits versteckt hatte. Eine Wiederherstellung auf einen Zeitpunkt vor dem bekannten Sicherheitsvorfall ist eine Vermutung darüber, wann der Vorfall begann, und in beiden Fällen wäre diese Vermutung falsch gewesen.

Die automatischen Updates haben eine dieser Seiten nicht erreicht

WordPress.org hat für diese Version automatische Updates erzwungen – eine Maßnahme, die normalerweise nur bei den schwerwiegendsten Sicherheitslücken zum Einsatz kommt. Die erste Website lief 28 Stunden später immer noch mit einer anfälligen Version.

Während der Fehlerbehebung hat unser Team ein Plugin zur Update-Verwaltung entdeckt, das so konfiguriert war, dass es Updates für Core, Plugins und Themes blockierte, und hat es deaktiviert. Diese Konfiguration ist eine plausible Erklärung dafür, warum das Notfall-Update nicht installiert wurde, auch wenn die Update-Protokolle nicht eindeutig genug waren, um dies als Tatsache festzustellen.

Für Agenturen ist dies die operativ nützliche Erkenntnis aus der gesamten Untersuchung. Das Blockieren von Updates ist eine normale, vertretbare Entscheidung auf einer Website, auf der ein Core-Release einmal den Checkout-Prozess unterbrochen hat. Es ist aber auch eine Entscheidung, die eine Website stillschweigend von dringenden Sicherheitsupdates ausschließt, und niemand überprüft sie noch einmal. Wenn dein Wartungs-Stack einen Update-Manager enthält, muss sich jemand darum kümmern, was passiert, wenn WordPress ein erzwungenes Sicherheitsupdate veröffentlicht.

So überprüfst du deine eigenen Websites auf diese Anzeichen

Die folgenden Pfade beziehen sich auf dein Dokumentenstammverzeichnis unter WordPress . Für keinen davon ist ein Serverzugriff erforderlich, der über die Möglichkeiten eines normalen cPanel - oder SFTP-Kontos hinausgeht. Die Dateinamen der Kampagnen ändern sich regelmäßig, daher solltest du die Muster als beständiger betrachten als einzelne Dateinamen.

Namen von Plugin- und Theme-Verzeichnissen

Beide Konten enthielten Verzeichnisse, die diese Namenskonventionen unter wp-content/plugins:

Muster	Wie das aussieht
wp2shell_*	8 Hexadezimalzeichen angehängt, die dem öffentlichen Namen der Exploit-Kette entsprechen
wp2up_*, nx_up_*, h2ok_up_*	Standalone-Datei-Uploader, 8 Hexadezimalzeichen angehängt
galex_*	Webshell-Bundles, 8 Hexadezimalzeichen angehängt
Plausibler Name plus Hex-Suffix	Ein seriös klingender Plugin-Slug, an den eine zufällige Hexadezimalzeichenfolge angehängt ist

Genau dieses letzte Muster ist es, das bei einer oberflächlichen Überprüfung durch die Maschen schlüpft. Ein bösartiges Plugin nutzte einen Slug, der an ein Tool zur Content-Bereitstellung erinnerte, und zeigte sich im Dashboard als „Security Headers Manager 2.1.4“ – komplett mit Versionsnummer. Auf dieselbe Weise wurden auch Theme-Verzeichnisse mit zufällig gewählten Namen verwendet.

Plugins, die du unbedingt nutzen solltest

Dateien in wp-content/mu-plugins Sie tauchen nicht in der normalen Plugin-Liste auf und lassen sich nicht über das Dashboard deaktivieren. Zu den dort gefundenen schädlichen Dateien gehörten ein Credential-Stealer, dessen Name so gewählt war, dass er wie eine Komponente zur Begrenzung der Anmeldeversuche aussah, ein „Recovery Guardian“, dessen Name an ein Tool zur Website-Reparatur erinnerte, sowie zwei kurze PHP-Dateien, die eine komprimierte Payload aus einer zugehörigen .gz Archiv.

Öffne dieses Verzeichnis und zähle jede darin enthaltene Datei namentlich auf. Auf den meisten Seiten sollte die Liste kurz oder leer sein.

Dateien, die als Kernklassen von „ WordPress “ getarnt sind

Die Hilfsdateien wurden unter Namen, die den Kernkonventionen entlehnt wurden, in die Plugin-Verzeichnisse geschrieben:

• class-wp-rest-compat-*.php
• class-wp-http-compat-*.php
• class-wp-cache-helper-*.php
• class-wp-widget-core-*.php

Versteckte Loader bestanden aus einem führenden Punkt, gefolgt von zwölf Hexadezimalzeichen und einem .php Erweiterung. Dateien, die diesen Mustern entsprechen, sind nicht Teil von „ WordPress “ und gehören nicht in ein Plugin-Verzeichnis. Ein JPEG- und PHP-Experte namens 1.php war ebenfalls auf einem Konto vorhanden, zusammen mit einer älteren Backdoor namens wp-mytrack.php das bei der Ausführung ein Administratorkonto erstellt.

Datenbankkennzahlen

Schädliche Payloads wurden in der Optionstabelle unter Namen gespeichert, die so gewählt wurden, dass sie direkt neben legitimen Einträgen zum Zustand der Website standen, wobei das Präfix _site_transient_health_ gefolgt von 8 Hexadezimalzeichen. Dein Tabellenpräfix weicht vom Standard ab. „ WordPress “ erstellt tatsächlich Transienten zum Website-Zustand, daher solltest du nach der abschließenden Hexadezimalzeichenfolge suchen und nicht nur nach dem Präfix allein.

Konfigurationsanzeigen

Beschriftete Blöcke WP_Core_Integrity wurden in … injiziert wp-config.php. Ihre Aufgabe bestand darin, die oben genannten Datenbank-Payloads zu lesen, sie zu dekodieren und ausführbares PHP in das temporäre Verzeichnis des Accounts zu schreiben. Öffnen wp-config.php und lies es von Anfang bis Ende durch. Alles, was nach dem Kommentar „Bearbeitung beenden“ kommt, verdient deine Aufmerksamkeit.

Zu den in verschiedenen Payloads immer wieder auftauchenden Code-Zeichenfolgen gehörten _nx_auth, _NX_PERSISTED, und feature=selftest.

Payloads im temporären Verzeichnis

Im temporären Verzeichnis eines Accounts wurden fünf ausführbare Payloads gefunden, die der PHP-eigenen Namenskonvention für temporäre Dateien folgten: die Zeichen php gefolgt von sechs zufälligen alphanumerischen Zeichen. Das ist genau das Muster, das PHP für normale Datei-Uploads verwendet – und genau deshalb ist es nicht aufgefallen. Normale temporäre Upload-Dateien werden nach Beendigung der Anfrage gelöscht. Jede Datei, die diesem Muster entspricht und schon seit Tagen noch da ist, ist eine genauere Untersuchung wert.

Cron-Einträge

Überprüfe die crontab des Accounts, nicht nur den Cron unter WordPress . Ein Account hatte einen fünfminütigen Job, der eine gelöschte Plugin-Datei aus einer Sicherungskopie im Ordner „uploads“ wiederherstellte, sowie fünf separate 30-minütige Jobs, die Selbsttests durchführten. Ein legitimer Cron-Eintrag unter WordPress ruft Folgendes auf: wp-cron.php und sonst nichts. Alle anderen wiederkehrenden PHP- oder cURL-Aufrufe auf deiner eigenen Website sollten berücksichtigt werden.

Benutzerkonten und Tokens

• Aufeinanderfolgende Administrator-IDs. Ein Konto wies 38 nicht autorisierte Administratoren in einem zusammenhängenden Block von Benutzer-IDs auf. Die fortlaufende Erstellung ist ein strukturelles Indiz.
• Muster für Benutzernamen. Zu den beobachteten Präfixen gehörten wpsvc_ und wp2_ gefolgt von „hex“ sowie Accounts, die aus dem Namen der Website mit Suffixen wie _dev, _editor, und _suporte.
• Anwendungspasswörter. Schau dir „Benutzer“ an, dann jedes Profil und anschließend „Anwendungspasswörter“. Die vom Angreifer erstellten Tokens hatten Namen wie zum Beispiel auto-bootstrap und bot-token. Diese bleiben auch nach einer Passwortänderung erhalten und erfordern kein Anmeldeformular.

Protokollsignaturen

Such in den Zugriffsprotokollen nach POST-Anfragen an /?rest_route=/batch/v1 oder /wp-json/batch/v1 die den HTTP-Status 207 zurückgeben, vor allem in Schüben. Bei einem Konto enthielten die Anfragen die User-Agent-Strings wp2shell und wp2shell-uploader. Die Erstellung eines Administratorkontos innerhalb von Sekunden nach einem solchen Ausbruch ist das Muster, auf das du achten solltest.

Beide Konten wiesen das gleiche Muster auf: eine schnelle Abfolge von Batch-Anfragen, gefolgt von einer Anfrage an wp-login.php, dann eine erfolgreiche Anmeldung, dann ein Plugin-Upload über update.php mit dem action=upload-plugin Parameter. Dieser Upload ist eine ganz normale Administratoraktion unter WordPress und wirkt für sich genommen nicht ungewöhnlich. Ungewöhnlich ist er jedoch unmittelbar nach einer Flut von Batch-Anfragen von derselben IP-Adresse.

Beachte, dass die User-Agent-Strings nur geringfügig geändert wurden und spätere Varianten diese möglicherweise nicht mehr verwenden. Die Batch-Route-Anfragen, die einen HTTP-207-Status zurückgeben, sind das zuverlässigere Signal. Falls dein Host die Zugriffsprotokolle in kurzen Abständen löscht oder komprimiert, ruf die archivierten Protokolle für Mitte bis Ende Juli 2026 ab, bevor sie gelöscht werden.

Überprüfung der Serverantwort bei Uploads

Rufe eine PHP-Datei unter wp-content/uploads direkt, mit Cache-Busting, und überprüfe die Antwort. HTTP 403 ist korrekt. HTTP 200 wurde zurückgegeben mit content-type: application/octet-stream bedeutet, dass die Datei als lesbare Quelle bereitgestellt wird und nicht ausgeführt wird.

„Serving“ ist die sicherere der beiden Fehlerarten, da der Code zwar nicht ausgeführt wird, aber dennoch der Inhalt der Datei für jeden sichtbar ist, der die URL aufruft. Beide Konten benötigten eine explizite Ablehnungsregel für ausführbare Dateiendungen im Ordner „uploads“, und beide haben eine erhalten. Wir haben das festgestellt, indem wir von außerhalb des Servers Tests mit Cache-Bust-Anfragen durchgeführt haben – unter Verwendung eines normalen Browser-User-Agents, von Googlebot und anderen –, da manche Konfigurationen je nach Client unterschiedlich reagieren. Hätten wir nur mit einem einzigen Browser getestet, wäre uns das entgangen.

Zu bestätigende Härtungswerte

• wp-config.php Berechtigungen eingestellt auf 0600
• Jede gültige PHP-Datei im Ordner „uploads“ mit den Berechtigungen 0600
• DISALLOW_FILE_EDIT und DISALLOW_FILE_MODS definiert als richtig
• FORCE_SSL_ADMIN definiert als richtig
• Keine Dateien, die für alle schreibbar sind, keine Dateien, die einem anderen Konto gehören, keine unerwarteten symbolischen Links im Dokumentenstammverzeichnis

Was eine zertifizierte Reinigung eigentlich beinhaltet

Die Bereinigung verlief in beiden Fällen nach dem gleichen Schema. Das ist der Ablauf der Arbeit, und er dient als sinnvoller Maßstab für die Bewertung jeder Bereinigung, egal ob sie intern oder von einem Dienstleister durchgeführt wird.

Erst mal eindämmen. Die erste Website wurde während der Untersuchung hinter einer HTTP-403-Sperre versteckt. Eine Website zu bereinigen, die noch erreichbar ist, bedeutet, gegen die Wiederherstellungsmechanismen anzukämpfen, die alle fünf Minuten ablaufen.

Vor dem Löschen sichern. Jede schädliche Datei, jede Datenbank-Payload, jeder Benutzerdatensatz, jeder Crontab-Eintrag und jede Konfigurationsdatei wurde vor dem Löschen archiviert und mit einem Hash versehen. Wenn du Malware löschst, ohne sie zuvor zu sichern, kannst du später keine Fragen mehr beantworten – auch nicht die Frage, ob die Bereinigung erfolgreich war.

Entferne jede Schicht und überprüfe sie dann einzeln. Dateisystem, Datenbankoptionen, wp-config.php Injektionen, Cron-Einträge, temporäre Verzeichnisse, unverzichtbare Plugins, Uploads und Benutzerdatensätze wurden jeweils bereinigt und separat überprüft.

Überprüfe die Integrität von Core und Paketen anhand der offiziellen Prüfsummen. Auf beiden Seiten wurde der Core überprüft. Auf der ersten Seite wurde eine Abweichung bei der Prüfsumme eines Plugins untersucht und das Plugin aus einem vertrauenswürdigen Paket neu installiert; außerdem wurden zwei Themes mit geänderten Dateien durch offizielle Pakete ersetzt, anstatt sie direkt vor Ort zu patchen.

Dreh alles, was der Angreifer lesen könnte. Durch die Ausführung von PHP-Befehlen und den Zugriff auf die Datenbank könnte der Angreifer folgende Daten auslesen: wp-config.php, die Optionstabelle und alle darin gespeicherten Anmeldedaten. Das umfasst WordPress -Administratorpasswörter, cPanel, FTP und SFTP, SSH, Datenbankzugang, SMTP, Schlüssel für Zahlungsdienstleister sowie alle API-Token von Drittanbietern, über die die Website verfügt. In beiden Berichten wurde die regelmäßige Erneuerung als erforderlich und nicht nur als empfohlen aufgeführt.

Reduzier die Administratorliste und bestätige sie. Auf einer Seite sank die Zahl der nicht autorisierten Administratoren von 38 auf drei bereits vorhandene Konten. Für jedes verbleibende Konto muss der Seiteninhaber namentlich bestätigen, dass es autorisiert ist.

Lösche Sitzungen und Anwendungspasswörter. Von Angreifern erstellte Anwendungspasswörter für WordPress , deren Namen auf Automatisierungstoken hindeuten, ermöglichten einen authentifizierten Zugriff, ohne dass das Anmeldeformular jemals aufgerufen wurde. Die meisten Website-Betreiber haben diesen Bildschirm in ihrem Profil noch nie geöffnet. Er bleibt auch nach einer Passwortänderung bestehen.

Lege anschließend eine Basislinie fest. Die nach der Sanierung erfasste Basislinie des ersten Standorts umfasste Hash-Werte für mehr als 36.000 ausführbare Dateien und Konfigurationsdateien. Ohne eine als einwandfrei bekannte Basislinie fängt die nächste Untersuchung wieder bei Null an.

Was Agenturen und Entwickler diese Woche ändern sollten

Drei konkrete Maßnahmen, geordnet nach dem Ausmaß, in dem sie das Risiko verringern:

Überprüfe die installierte Version von „ WordPress “ auf jeder von dir verwalteten Website einzeln. Verlasse dich nicht auf das Update-Dashboard und gehe nicht davon aus, dass das erzwungene Update bereits durchgeführt wurde. Sicherheitsforscher haben immer wieder festgestellt, dass Websites, auf denen automatische Updates deaktiviert waren oder fehlgeschlagen sind, möglicherweise weiterhin gefährdet sind. Überprüfe die Versionsangabe und schau dann nach, ob irgendetwas im Plugin-Stack so konfiguriert ist, dass Updates blockiert werden.

Überprüfe Administrator-Konten und Anwendungskennwörter gemeinsam. Ein böswilliger Administrator fällt auf. Ein Anwendungskennwort, das einem legitimen Konto zugeordnet ist, hingegen nicht – und genau das ist der Mechanismus, der eine überstürzte Bereinigung am ehesten übersteht. Überprüfe beides auf jeder Seite und schau dir anschließend das Verzeichnis der „Must-Use“-Plugins an, das in der normalen Plugin-Liste überhaupt nicht auftaucht.

Behandle jeden bestätigten Sicherheitsverstoß als Anlass für eine vollständige Erneuerung der Zugangsdaten. Wenn ein Angreifer auf dem Konto PHP-Befehle ausführen konnte, sind alle von diesem Konto aus erreichbaren Geheimnisse offengelegt. Bei einer teilweisen Erneuerung bleibt ein funktionierender Schlüssel übrig.

Eine erneute Infektion ist das normale Ergebnis einer unvollständigen Bereinigung, kein ungewöhnlicher Fall. Die Lücke an der ersten Stelle betrug sechs Tage, und während dieser sechs Tage sah die Stelle sauber aus, wurde normal geladen und bestand eine oberflächliche Überprüfung.

Was so eine Untersuchung eigentlich erfordert

Beide Untersuchungen wurden intern von den Teams von „ InMotion Hosting“ selbst durchgeführt, und zwar auf unserer eigenen Infrastruktur, die wir in drei Rechenzentrumsregionen betreiben. Es wurde nichts an einen Scan-Anbieter ausgelagert, und kein Teil der Analyse wurde an Dritte weitergegeben.

Das ist wichtig, weil die Malware sich genau dort versteckt hat. Ein kommerzieller Malware-Scanner findet zwar Dateien, entschlüsselt aber keine Payloads, die in der Optionstabelle unter Namen gespeichert sind, die legitime temporäre Dateien zur Website-Überwachung imitieren. Er verfolgt auch keine Loader-Blöcke, die in wp-config.php zu den ausführbaren Dateien, die sie im temporären Verzeichnis des Accounts neu erstellen. Es wird nicht bemerkt, dass fünf Dateien, die der üblichen Namenskonvention für Uploads bei PHP entsprechen, vor drei Wochen am Ende einer Anfrage hätten gelöscht werden sollen, dies aber nicht geschehen ist.

Diese Erkenntnisse stammen von Mitarbeitern, die den Code gelesen und die Zeitstempel in archivierten Zugriffsprotokollen, den Aktivitätsaufzeichnungen von „ WordPress “ sowie der Crontab des Kontos miteinander abgeglichen haben. Jeder Techniker in unseren Support-Teams absolviert mehr als 280 Stunden Schulung, bevor er Tier-1-Anfragen bearbeitet, und die durchschnittliche Betriebszugehörigkeit im Support beträgt über fünf Jahre. Dieselben Teams stehen rund um die Uhr zur Verfügung, und die Untersuchungen, auf denen dieser Artikel basiert, wurden von Mitarbeitern durchgeführt, die du telefonisch erreichen kannst.

Das deckt sich auch mit unserem Vorgehen bei Bedrohungen auf der Infrastrukturebene. Als im April 2026 eine kritische Sicherheitslücke vor der Authentifizierung in „ cPanel “ und WHM bekannt wurde, hat unser Netzwerkbetriebsteam den Zugriff am Netzwerkrand in allen drei Rechenzentrumsregionen innerhalb weniger Stunden blockiert und anschließend die Serverflotte Server für Server gepatcht. WordPress Core-Updates werden direkt in deiner Anwendung installiert und nicht im Serverstack – deshalb erfordert eine Kompromittierung wie diese eine andere Reaktion und eine andere Art der Untersuchung.

Wenn du WordPress -Seiten für Kunden verwaltest und dir nicht sicher bist, ob eine frühere Bereinigung vollständig war, ist genau diese Unsicherheit schon der Befund. Bring uns den Account, und wir werden jede Ebene unter die Lupe nehmen – nicht nur das Dateisystem.

Sprich mit unserem Team oder schau dir unsere Managed-Hosting-Dienste an.