Selbstheilende WordPress-Malware nutzt Blockchain-Backdoor

Eine selbstheilende WordPress-Malware-Familie namens SC kann sich aus acht getrennten Verstecken selbst wiederherstellen, so ein Bericht vom 30. September 2026 des Sucuri-Forschers Gabriel Barbosa. Die Familie verdankt ihren Namen den SC_-Markierungen im eingeschleusten Code. Während einer Bereinigung tauchte dieselbe Backdoor innerhalb von Sekunden nach jeder Entfernung immer wieder auf, egal wie sorgfältig die sichtbaren Dateien gelöscht wurden. Die Nutzlast befindet sich gleichzeitig an mindestens acht Orten, verteilt auf Dateien, die Datenbank und den gemeinsamen Speicher, und jeder dieser Orte kann alle anderen wiederherstellen. Löscht man das Plugin, schreibt eine Drop-in-Datei es neu. Löscht man die Drop-in-Datei, schreibt das Theme sie neu. Löscht man jede Datei auf der Festplatte, stellt der nächste Seitenaufruf den gesamten Satz aus der Datenbank oder einem Shared-Memory-Segment wieder her. Das Ergebnis ist ein zirkuläres System ohne einen einzelnen Punkt, den man entfernen könnte, um es zu stoppen.

Die wiederhergestellten Komponenten verwenden ein gemeinsames Verschleierungsverfahren: kein eval, keine lesbaren Funktionsnamen und keine Markierungen auf den neuesten Teilen. Jede Datei enthält eine Tabelle mit verschlüsselten Zeichenfolgen und einen kleinen Decoder, der einen numerischen Index über eine Positions-Substitutions-Chiffre in einen echten Funktionsnamen auflöst. Eine .user.ini-Datei setzt auto_prepend_file, eine PHP-Direktive, die eine angegebene Datei vor jeder Anfrage in diesem Verzeichnisbaum ausführt. Die Direktive zeigt auf eine harmlos benannte Shim-Datei, üblicherweise in wp-content. Die Shim-Datei bindet einen versteckten, mit Punkt beginnenden Loader ein, falls dieser existiert, und tut stillschweigend nichts, wenn er entfernt wurde, wodurch die Website funktionsfähig bleibt, während eine andere Komponente die versteckte Datei neu erstellt. Dieser versteckte Loader baut ein gefälschtes Must-Use-Plugin aus drei Quellen wieder auf, die der Reihe nach versucht werden: eine vorhandene Plugin-Kopie, ein codierter Stub im Cache-Verzeichnis und ein ZIP-Wiederherstellungspaket mit zufälligem Hex-Namen. Er schreibt über eine temporäre Datei, setzt die Berechtigungen auf 0644 und ruft opcache_invalidate auf, damit die neue Datei sofort ausgeführt wird. Eine db.php-Drop-in-Datei, die WordPress früh beim Start lädt, trägt die gesamte Backdoor als gzip- und base64-Blob und schreibt das Plugin neu, wenn es fehlt oder zu klein ist. Eine advanced-cache.php-Drop-in-Datei, die noch früher geladen wird, wenn Caching aktiviert ist, kann das Plugin aus fünf Quellen wiederherstellen: ein vorhandenes Must-Use-Plugin, eine vorhandene Plugin-Kopie, ein System-V-Shared-Memory-Segment mit PHP, ein ZIP-Paket, das in mehreren Ordnern gesucht wird, und schließlich die Datenbank selbst über eine direkte Verbindung unter Verwendung der eigenen Anmeldekonstanten der Website. Ein Block, der an die functions.php des aktiven Themes angehängt und durch begin- und end-Markierungen eingegrenzt ist, fungiert als theme-interner Zwilling von db.php und schreibt das Plugin neu, wenn es fehlt. Die eigentliche Malware-Nutzlast wird sowohl als Must-Use-Plugin als auch als normales Plugin installiert, mit identischen Kopien, einer überzeugenden Einstellungsseite, einem Shortcode und einem Aktivierungs-Hook.

Die Backdoor versteckt sich, indem sie die Plugin-Liste, den Update-Transienten und die Website- und Netzwerk-Plugin-Ansichten filtert, und sie injiziert Admin-JavaScript, um sich als Fallback selbst aus der Plugin-Tabelle zu entfernen. Für Command-and-Control verwendet sie keinen einzelnen fest codierten Server. Stattdessen enthält sie eine Liste von etwa zwanzig öffentlichen Ethereum-RPC-Gateways und einen Satz von Smart-Contract-Methodenselektoren. Diese legitimen Drittanbieter-Gateways dienen als Transport, sodass das Blockieren nur des im Datenverkehr beobachteten Gateways die anderen verfügbar lässt. Die Nutzlast erstellt einen Fingerabdruck der Website, indem sie die Website-URL und den Host, WordPress- und Plugin-Versionen, Pfad-Hashes, aktive Themes, die Must-Use-Plugin-Liste und aktuelle Administrator-Sitzungstoken sammelt. Sie verschlüsselt dieses Bündel und sendet es an den aufgelösten Endpunkt. Die Antwort kann Frontend-JavaScript zum Injizieren enthalten, das bei einem Online-Shop Checkout-Skimming ermöglicht, neues PHP zum Installieren und Listen von Sicherheits-Plugins zum Deaktivieren und Löschen. Wenn sie angewiesen wird, ein Sicherheits-Plugin zu entfernen, kann sie es deaktivieren, sein Verzeichnis löschen und zuvor ein anderes Konto neu zuweisen oder hochstufen. Sie erstellt auch einen versteckten Administrator, indem sie einen vorhandenen versteckten Admin übernimmt oder einen neuen generiert, und schreibt das Konto direkt in die Tabellen users und usermeta, wenn die normale API nicht verfügbar ist. Sie speichert Berechtigungen unter dem Meta-Schlüssel default capabilities, blendet das Konto aus Benutzerlisten, Zählungen und Rollenansichten aus und fälscht gültige Authentifizierungs-Cookies, damit der Betreiber sich ohne Passwort anmelden kann. Ein magischer Anfrageparameter, ein kurzes Präfix gefolgt von einem festen Wert, wird verarbeitet, bevor WordPress vollständig geladen ist, und gibt eine normale Antwort mit Inhalt zurück, bevor es beendet wird. Schließlich hängt die Nutzlast eine große Menge an Aktionen und Filtern ein, um jede andere Komponente neu zu schreiben: die db.php- und advanced-cache.php-Drop-ins, die Theme-Injektion, den versteckten Loader und seine .htaccess- und .user.ini-Prepend-Direktiven, das ZIP-Wiederherstellungspaket, das Shared-Memory-Segment und die Datenbankkopie. Sie öffnet sogar eine direkte Datenbankverbindung, um ihre Nutzlast-Option direkt einzufügen und WordPress zu umgehen.

Die wichtigste Lehre aus diesem Fall ist, dass Persistenz nicht auf Dateien beschränkt ist. Sucuri stellte Live-Kopien der Nutzlast an drei Nicht-Datei-Orten wieder her, von denen jeder den gesamten Satz bei der nächsten Anfrage neu aufbaut. Die vollständige Nutzlast befindet sich in einer Options-Zeile unter einem zufälligen Namen, gespeichert im gleichen gzip- und base64-Format, und advanced-cache.php liest sie über eine direkte Datenbankverbindung zurück. Auf Servern, die System-V-Shared-Memory unterstützen, wird die Nutzlast in ein Segment geschrieben, das durch einen festen numerischen Schlüssel identifiziert wird. Dieses Segment lebt im RAM und übersteht daher sowohl Dateilöschung als auch Datenbankbereinigung; auf Shared Hosting kann es sogar einem anderen Konto gehören. Die Infektion registriert außerdem Cron-Hooks, darunter zufällige Namen neben einem bekannten Abruf-Hook. Das System-Cron führt die WordPress-Cron-Datei aus, nicht den Besucherverkehr, und löst dann die erneute Bereitstellung nach Zeitplan aus. Verwandte SC-Varianten verwenden Datenbank-Trigger, die beim Einfügen einen Administrator neu erstellen. Ein Trigger läuft innerhalb der Datenbank und übersteht daher eine vollständige Dateiwiederherstellung und sogar die Löschung des Kontos, das er immer wieder neu erstellt, was die Bereinigung von Benutzern sinnlos macht, bis der Trigger entfernt ist.

Weil jede Komponente die anderen wiederherstellen kann, ist die Reihenfolge der Schritte wichtiger als die einzelnen Löschungen. Sucuris empfohlene Bereinigung beginnt damit, das Prepend zu neutralisieren, bevor dessen Ziel gelöscht wird. Der auto_prepend_file-Wert wird von PHP bis zu 300 Sekunden zwischengespeichert; daher leeren Sie zuerst das Prepend-Ziel zu einem inerten Stub und entfernen dann die Direktive aus .user.ini, php.ini und .htaccess, um zu vermeiden, dass jede PHP-Anfrage auf dem Konto ausfällt. Als Nächstes löschen Sie die Kopien der Nutzlast außerhalb der Festplatte: Entfernen Sie die Nutzlast-Zeile aus der options-Tabelle, leeren Sie das Shared-Memory-Segment und löschen Sie die Steueroptionen und Transienten. Auf Shared Hosting kann ein Shared-Memory-Segment einem anderen Konto gehören; in diesem Fall kann nur dieses Konto oder der Host es entfernen, und es wird harmlos, sobald die Drop-ins, die es lesen, entfernt sind. Danach entfernen Sie die geplanten Aufgaben und alle Datenbank-Trigger: Löschen Sie die bösartigen Cron-Hooks und überprüfen Sie information_schema.TRIGGERS auf jeden Trigger, der beim Einfügen einen Administrator neu erstellt. Entfernen Sie den versteckten Administrator, dessen Berechtigungen unter dem Meta-Schlüssel default capabilities gespeichert sind, und bereinigen Sie die verwaiste Option, die auf seine ID zeigt. Bereinigen Sie die Dateien in einem Durchgang: Entfernen Sie die eigenständigen Loader und die Shim-Datei, löschen Sie beide Kopien des gefälschten Plugins aus mu-plugins und plugins, löschen Sie das ZIP-Wiederherstellungspaket, wo immer es versteckt war, und entfernen Sie die eingeschleusten Drop-ins. Für db.php und advanced-cache.php löschen Sie die bösartigen Dateien; für die functions.php des Themes kürzen Sie nur den eingegrenzten Block zwischen den begin- und end-Markierungen, damit der legitime Theme-Code intakt bleibt. Führen Sie abschließend einen vollständigen Scan durch und überwachen Sie die betroffenen Pfade. Eine zurückkehrende Komponente bedeutet, dass ein Persistenzpunkt überlebt hat oder der ursprüngliche Einstiegspfad noch offen ist.

Sucuri empfiehlt, WordPress und alle Komponenten aktuell zu halten, eine Web Application Firewall zu verwenden, um Exploit-Versuche und ausgehenden Command-Traffic zu blockieren, die options-Tabelle, geplante Aufgaben, Datenbank-Trigger und Benutzerkonten regelmäßig zu überprüfen und jedes erneute Auftauchen als Zeichen eines überlebenden Persistenzpunkts zu behandeln. Für Website-Betreiber, die diese Art von Schutz wünschen, ohne ihn selbst zu warten, kann ein Managed-WordPress-Hosting-Plan wie AEU Hosting einen Teil der Patch- und Plattformhärtungsarbeit übernehmen, obwohl kein Host die oben genannten Bereinigungsschritte ersetzen kann.