WordPress-Backdoor nutzt acht Wiederherstellungspunkte, um sich nach der Bereinigung neu aufzubauen

Eine kürzlich dokumentierte WordPress-Backdoor kann sich selbst rekonstruieren, nachdem Sicherheitsverantwortliche ihre sichtbaren Dateien gelöscht haben. Dafür nutzt sie redundante Kopien im Dateisystem und in der Datenbank sowie – auf unterstützten Servern – im Shared Memory.

Die Malware erhielt den Codenamen SC, abgeleitet von SC_-Markierungen in eingeschleusten Inhalten. Sucuri beschreibt sie als Blockchain-gesteuertes, „selbstheilendes“ Netzwerk. Der Sicherheitsforscher Gabriel Barbosa berichtet, dass die Payload an mindestens acht Stellen gespeichert ist. Überlebende Komponenten können gelöschte Teile der Infektion wiederherstellen.

Der Bericht zu SC erschien zusammen mit Details zu Angriffen auf eine separate Schwachstelle im wpForo-Forum-Plugin. Die verfügbaren Hinweise stellen keinen Zusammenhang zwischen dieser Schwachstelle und der Verbreitung oder Funktionsweise von SC her. Die beiden Fälle sollten als getrennte Sicherheitsprobleme behandelt werden.

Acht Komponenten bilden ein zirkuläres Persistenzsystem

SC ist nicht auf eine einzelne versteckte Datei angewiesen, sondern verfügt über mehrere Wiederherstellungspfade. Das scheinbare Plugin zu entfernen, bringt wenig, wenn ein Loader, eine Datenbankkopie, ein Wiederherstellungsarchiv oder ein Shared-Memory-Segment weiterhin verfügbar ist.

Sucuri hat acht zentrale Komponenten identifiziert:

1. .user.ini setzt die PHP-Direktive auto_prepend_file. Dadurch wird ein Loader vor PHP-Anfragen innerhalb des betroffenen Verzeichnisbaums ausgeführt.

2. wp-content/c1b12371.php lädt eine versteckte Datei mit vorangestelltem Punkt, sofern sie am selben Speicherort vorhanden ist.

3. wp-content/.c1b12371.php fungiert als Loader der ersten Stufe. Er sucht nach dem gefälschten Plugin und kann es aus drei Quellen unter mu-plugins wiederherstellen: einer normalen Plugin-Kopie, einem kodierten Stub im Cache-Verzeichnis oder einem ZIP-Wiederherstellungspaket mit einem zufälligen hexadezimalen Dateinamen.

4. wp-content/db.php nutzt den von WordPress automatisch geladenen Datenbank-Drop-in-Mechanismus. Die Datei enthält die Backdoor-Payload in komprimierter, Base64-kodierter Form und installiert das Plugin erneut, wenn die erwartete Datei fehlt oder kleiner als ein festgelegter Grenzwert ist.

5. wp-content/advanced-cache.php wird bei aktiviertem Caching vor den regulären Plugins ausgeführt. Die Datei kann die Malware aus fünf Quellen rekonstruieren: dem Must-use-Plugin, einer regulären Plugin-Kopie, PHP-Code im System-V-Shared-Memory, einem ZIP-Paket oder der Datenbank. Anschließend registriert sie einen Hook für plugins_loaded und bindet das wiederhergestellte Plugin ein.

6. wp-content/themes/khorshidi/functions.php sorgt für Persistenz auf Theme-Ebene. Laut Sucuri enthält die Datei dieselbe Backdoor und schreibt das Plugin neu, sobald es fehlt.

7. wp-content/mu-plugins/hyper-engine-kit.php ist die Malware, die als Must-use-Plugin installiert wird – eine Kategorie von Plugins, die WordPress automatisch lädt.

8. wp-content/plugins/hyper-engine-kit/hyper-engine-kit.php enthält eine weitere Kopie derselben Payload im regulären Plugin-Verzeichnis.

Die Backdoor verschleiert ihre Funktionsnamen und verwendet einen Decoder mit Substitutionschiffre, um die Analyse des Codes zu erschweren. Außerdem verbirgt sie sich in der Plugin-Übersicht des WordPress-Administrationsbereichs und vor Update-Prüfungen.

Das macht es unzuverlässig, die Komponenten einzeln zu löschen. Eine vermeintlich nebensächliche Datei kann beim nächsten Ausführungszyklus dazu dienen, alle übrigen Komponenten wiederherzustellen.

Shared Memory erweitert die Persistenz über Dateien und SQL-Datensätze hinaus

Auf Servern, die System-V-Shared-Memory unterstützen, schreibt SC PHP-Code in ein Segment, das über einen festen numerischen Schlüssel adressiert wird. Im Bericht wird der Wert dieses Schlüssels nicht genannt.

Da sich das Segment im RAM befindet, kann es auch nach der Bereinigung der Website-Dateien und Datenbankeinträge verfügbar bleiben. Über den bösartigen Drop-in advanced-cache.php lässt sich der PHP-Code aus diesem Segment auslesen und zum Wiederherstellen des Plugins verwenden.

Shared Hosting kann die Untersuchung und Entfernung erschweren. Laut Sucuri kann das Speichersegment einem anderen Konto gehören und damit außerhalb des üblichen administrativen Zugriffs des kompromittierten Website-Betreibers liegen.

Die Infektion registriert außerdem WordPress-Cron-Hooks, darunter Hooks mit zufälligen Namen und einen bekannten Fetch-Hook. Das vorliegende Material nennt diese Hook-Namen nicht. Ein System-Cronjob führt die WordPress-Cron-Datei aus und ermöglicht so eine erneute Installation nach Zeitplan, ohne auf Besucherzugriffe angewiesen zu sein.

Dateien, Datenbankinhalte, Wiederherstellungsarchive, geplante Aufgaben und Shared Memory bilden somit gemeinsam einen Wiederherstellungsmechanismus. Wer nur das WordPress-Plugin-Verzeichnis bereinigt, lässt mehrere mögliche Quellen zur Rekonstruktion unangetastet.

Ethereum-basierte Steuerung ermöglicht weitere Kompromittierungen

Sucuri beschreibt SC als Blockchain-gesteuerte Backdoor, die über die Ethereum-Blockchain mit einer Command-and-Control-Infrastruktur kommuniziert. Der vorliegende Bericht enthält keine Kennungen von Ethereum-Wallets, Command-and-Control-Adressen oder vergleichbare Infrastrukturindikatoren.

Nach der Ausführung kann die Malware die infizierte Website identifizieren, zusätzliche Payloads abrufen und ein verstecktes WordPress-Administratorkonto anlegen. Zu den gemeldeten Möglichkeiten der Betreiber gehören:

• Beliebigen JavaScript-Code abrufen und in Webseiten einschleusen.
• Skimmer oder andere Malware über eingeschleuste Skripte ausliefern.
• PHP-Code auf dem kompromittierten Server ausführen.
• Ausgewählte Plugins deaktivieren oder löschen.
• Die Infektion erneut installieren, wenn Komponenten entfernt werden.

Diese Funktionen gefährden sowohl die Website als auch ihre Besucher. Die serverseitige Ausführung von PHP-Code gibt Angreifern weitreichende Kontrolle über die WordPress-Installation. Eingeschleuster JavaScript-Code kann zudem schädliche Inhalte in Seiten einfügen, die an Nutzer ausgeliefert werden.

Der zitierte Bericht identifiziert nicht, wer SC betreibt. Auch die Methode der Erstinfektion ist unbekannt. Verwundbare WordPress-Komponenten, schwache Zugangsdaten, kompromittierte Plugin-Lieferketten und unsichere Upload-Funktionen werden lediglich als häufige Möglichkeiten genannt, nicht als bestätigte Einfallstore für diese Malware.

Ausgenutzte SQL-Injection in wpForo ist ein separater Vorfall

Bei der zeitgleich bekannt gewordenen Plugin-Schwachstelle handelt es sich um CVE-2026-1581, eine zeitbasierte, nicht authentifizierte SQL-Injection, die wpForo Forum in den Versionen 0 bis einschließlich 2.4.14 betrifft.

Die Schwachstelle wird über den Parameter wpfob ausgenutzt. Da benutzergesteuerte Daten nicht ausreichend maskiert und eine vorhandene SQL-Abfrage nicht angemessen vorbereitet werden, können nicht authentifizierte Angreifer zusätzliche SQL-Abfragen anhängen und vertrauliche Informationen aus der Datenbank auslesen.

Der von Wordfence herausgegebene CVE-Programmdatensatz nennt tomdever als Anbieter und führt Youssef Elouaer als Entdecker der Schwachstelle auf. Der Datensatz wurde am 19. Februar 2026 veröffentlicht und am 8. April 2026 aktualisiert.

CVE-2026-1581 ist als HIGH eingestuft und hat einen CVSS-3.1-Score von 7,5. Der zugehörige Vektor lautet:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

Der Vektor beschreibt eine aus der Ferne ausnutzbare Schwachstelle mit geringer Angriffskomplexität, ohne erforderliche Berechtigungen und ohne nötige Interaktion durch Nutzer. Die Auswirkungen auf die Vertraulichkeit werden als hoch bewertet; für Integrität und Verfügbarkeit sind keine Auswirkungen aufgeführt. Die Schwachstelle ist als CWE-89 klassifiziert: unzureichende Neutralisierung von Elementen in einem SQL-Befehl.

Telemetriedaten von Previdian verzeichneten seit dem 3. Juli 2026 weniger als 20 Ausnutzungsversuche. Die Aktivität ging von fünf eindeutigen Angreifer-IP-Adressen aus, die in Bulgarien, der Schweiz, Frankreich, den USA und Jemen geolokalisiert wurden. Die einzelnen Adressen wurden nicht veröffentlicht.

Der Bericht nennt nicht, wer hinter den Versuchen steckt. Ebenso wenig belegt er einen Zusammenhang zwischen CVE-2026-1581 und der SC-Backdoor.

Bei der Incident Response alle Wiederherstellungsquellen prüfen

Bei einem vermuteten SC-Befall reicht es nicht aus, hyper-engine-kit.php oder einen der Loader zu löschen. Das ist kein hinreichender Beleg dafür, dass die Infektion vollständig beseitigt wurde. Bei der Untersuchung sollten alle acht genannten Komponentenpfade und die darin aufgeführten zusätzlichen Wiederherstellungsquellen berücksichtigt werden.

Dazu gehören:

• Reguläre Plugin-Verzeichnisse und Must-use-Plugin-Verzeichnisse.
• Die Drop-ins db.php und advanced-cache.php.
• Die Datei functions.php des betroffenen Themes.
• .user.ini und deren Einstellung auto_prepend_file.
• Cache-Inhalte und Wiederherstellungspakete mit zufälligen Dateinamen.
• Bösartige Daten in der WordPress-Datenbank.
• WordPress- und System-Cron-Aktivitäten.
• System-V-Shared-Memory-Segmente auf Servern, die diese Funktion unterstützen.

Der vorliegende Bericht enthält weder eine validierte Anleitung zur Entfernung von SC noch den numerischen Shared-Memory-Schlüssel, alle Cron-Hook-Namen oder konkrete Command-and-Control-Indikatoren. Administratoren sollten eine Website daher nicht allein deshalb als bereinigt einstufen, weil das sichtbare Plugin nicht mehr angezeigt wird.

Bei CVE-2026-1581 sollten Betreiber prüfen, ob eine WordPress-Installation wpForo Forum 2.4.14 oder älter verwendet. Die bereitgestellten Schwachstellendatensätze nennen weder eine korrigierte Version noch eine Übergangslösung. Sie bieten daher keine Grundlage dafür, eine bestimmte Version als Abhilfe zu empfehlen. Administratoren sollten aktuelle Hinweise des Anbieters beachten und relevante Web- und Datenbankaktivitäten auf verdächtige Anfragen mit wpfob untersuchen.

Die beiden Vorfälle erfordern unterschiedliche Untersuchungen. Bei SC ist eine umfassende Suche nach Persistenzmechanismen über mehrere Speicher- und Ausführungsebenen hinweg nötig. Bei CVE-2026-1581 geht es darum, betroffene Plugins zu ermitteln und mögliche Datenbankabfragen zu untersuchen. Werden die Vorfälle miteinander vermengt, kann das Sicherheitsverantwortliche auf die falsche Einfallstelle oder Bereinigungsstrategie führen.