SC-Backdoor: Neue WordPress-Malware repariert sich nach jeder Bereinigung selbst

Veröffentlicht: 02.10.2026 · Letzte Aktualisierung: 02.10.2026

Eine WordPress-Infektion, die innerhalb von Sekunden nach jeder Bereinigung zurückkehrt: Das Sicherheitsunternehmen Sucuri hat am 30.09.2026 eine Malware-Familie dokumentiert, die intern den Namen „SC“ trägt, benannt nach den „SC_“-Markierungen im eingeschleusten Code. Das Besondere: Die Backdoor existiert an mindestens acht Stellen gleichzeitig, verteilt über Dateien, die Datenbank und den Shared Memory des Servers. Jede dieser Kopien kann alle anderen wiederherstellen. Es gibt keinen einzelnen Punkt, den man entfernen könnte, um das System zu stoppen.

Ein „selbstheilendes Netz“: So funktioniert SC

Die Analysten beschreiben die Architektur als zirkuläres System. Sucuri-Researcher Gabriel Barbosa bringt es auf den Punkt:

„Delete the plugin and a drop-in rewrites it. Delete the drop-in and the theme rewrites it.“

Übersetzt: „Löschen Sie das Plugin, schreibt ein Drop-in es neu. Löschen Sie das Drop-in, schreibt das Theme es neu.“

Und selbst wenn Sie jede Datei auf dem Server bereinigen, stellt der nächste Seitenaufruf das komplette Set aus der Datenbank oder aus einem Shared-Memory-Segment im RAM wieder her.

Die acht Komponenten im Überblick. Wichtig: Der Hex-Dateiname c1b12371 stammt aus dem von Sucuri dokumentierten Fall und variiert pro Infektion.

1. .user.ini: setzt per auto_prepend_file einen Loader, der vor jeder PHP-Anfrage ausgeführt wird, auch außerhalb von WordPress.
2. Sichtbarer Shim (z. B. wp-content/c1b12371.php): unauffällige Datei, die nur eine versteckte Schwester-Datei einbindet.
3. Versteckter Loader (z. B. wp-content/.c1b12371.php, mit Punkt-Präfix): baut das Fake-Plugin aus drei Quellen wieder auf: Plugin-Ordner, kodierter Stub im Cache-Verzeichnis, ZIP-Archiv mit zufälligem Hex-Namen.
4. wp-content/db.php: legitimes WordPress-Drop-in, missbraucht. Es trägt die komplette Backdoor als gzip+Base64-Blob in sich und deployt sie neu, sobald das Plugin fehlt.
5. wp-content/advanced-cache.php: die gefährlichste Position, da sie vor allen normalen Plugins lädt. Kann das Plugin aus fünf unabhängigen Quellen rekonstruieren, darunter ein System-V-Shared-Memory-Segment und eine direkte Datenbank-Verbindung.
6. Theme-Injektion: ein markierter Code-Block am Ende der functions.php des aktiven Themes, der das Plugin bei jedem Aufruf neu schreibt.
7. Fake-Plugin als Must-Use-Plugin (wp-content/mu-plugins/): die eigentliche Schadsoftware, lädt automatisch und unsichtbar.
8. Identische Kopie als normales Plugin (wp-content/plugins/): redundante Zweitkopie, inklusive überzeugender Fake-Einstellungsseite, die wie ein harmloses Caching-Plugin aussieht.

Der Code selbst ist stark verschleiert: keine lesbaren Funktionsnamen, kein eval, stattdessen eine Tabelle verwürfelter Strings und ein Dekoder mit Substitutions-Chiffre.

Steuerung über die Ethereum-Blockchain

Statt eines einzelnen Command-&-Control-Servers nutzt SC rund zwanzig öffentliche Ethereum-RPC-Gateways, um Befehle aus einem Smart Contract auszulesen. Das ist perfide: Die Gateways sind legitime Blockchain-Infrastruktur, die auch von unzähligen seriösen Anwendungen genutzt wird. Klassisches IP- oder Domain-Blocking läuft damit ins Leere. Blockiert man nur das eine in den Logs sichtbare Gateway, weichen die Angreifer auf die übrigen aus; wirksam ist nur das Blockieren der gesamten Gateway-Liste.

Was die Backdoor auf der Website tut

Einmal aktiv, kann die Backdoor:

• sich selbst verstecken: sie filtert die Plugin-Liste im WordPress-Admin, Update-Checks und sogar die Benutzerübersicht;
• einen versteckten Administrator anlegen: direkt in die Datenbank geschrieben, aus allen Benutzerlisten herausgefiltert, mit gefälschten Login-Cookies ohne Passwort nutzbar. Zusätzlich sammelt sie aktive Administrator-Session-Tokens ein;
• beliebiges JavaScript ausliefern: in Online-Shops ermöglicht das Checkout-Skimming, also den Diebstahl von Zahlungsdaten Ihrer Kunden direkt im Browser;
• Sicherheits-Plugins gezielt deaktivieren und löschen;
• das gesamte Netz neu aufbauen: inklusive Cron-Jobs mit zufälligen Namen, die die Neuinstallation zeitgesteuert auslösen.

Für Shop-Betreiber hat das eine zweite Dimension: Werden Zahlungsdaten über eingeschleuste Skripte abgegriffen, steht neben dem technischen Schaden ein PCI-DSS-Verstoß und eine meldepflichtige Datenschutzverletzung nach Art. 33 DSGVO im Raum, mit entsprechenden Fristen (72 Stunden) und Haftungsrisiken.

Wer ist betroffen?

Technisch ist jede WordPress-Installation anfällig, denn SC nutzt keine einzelne Schwachstelle aus, sondern wird nach einer bereits erfolgten Kompromittierung installiert. Den konkreten Einstiegsvektor konnte Sucuri im dokumentierten Fall nicht abschließend bestimmen; auch eine Zahl betroffener Installationen ist nicht veröffentlicht. Beides ist damit ausdrücklich offen.

Besonders gefährdet sind erfahrungsgemäß Installationen mit veralteten Plugins und Themes, Websites auf Shared Hosting ohne Dateiintegritätsprüfung sowie WooCommerce-Shops, bei denen sich der Angriff über Zahlungsdaten-Skimming direkt monetarisieren lässt.

Warum eine normale Bereinigung scheitert

Die wichtigste Erkenntnis aus dem Fall: Persistenz ist nicht auf Dateien beschränkt. Sucuri fand lebende Kopien der Schadsoftware an drei Orten außerhalb des Dateisystems:

• Datenbank: Der komplette Payload liegt als gzip+Base64-Blob in einer Options-Zeile mit zufälligem Namen. Eine perfekte Datei-Bereinigung ist damit wertlos, der nächste Seitenaufruf stellt alles wieder her.
• Shared Memory: Auf Servern mit System-V-Shared-Memory liegt der Payload in einem RAM-Segment mit festem numerischem Schlüssel. Er überlebt Datei- und Datenbank-Bereinigung. Auf Shared Hosting kann das Segment sogar einem fremden Account gehören.
• Cron-Jobs: Geplante Tasks mit zufälligen Namen triggern die Neuinstallation, ausgelöst vom System-Cron, nicht von Besucher-Traffic.

Verwandte SC-Varianten nutzen zusätzlich Datenbank-Trigger, die gelöschte Admin-Konten automatisch neu anlegen. Die überleben sogar eine komplette Datei-Wiederherstellung aus dem Backup.

Checkliste: Daran erkennen Sie eine SC-Infektion

• Unerwartete PHP-Blöcke in wp-content/db.php oder wp-content/advanced-cache.php mit „SC_“-Markern
• Ein eingezäunter Code-Block am Ende der functions.php Ihres aktiven Themes
• .user.ini, php.ini oder .htaccess mit einer auto_prepend_file-Direktive auf eine versteckte Punkt-Datei
• Dasselbe unbekannte Plugin in mu-plugins und plugins
• ZIP-Dateien mit zufälligen Hex-Namen in wp-content, uploads oder Theme-Ordnern
• Große Base64-Blobs in der Options-Tabelle, Options/Transients mit „sc_“-Präfix
• Administratoren, die in der Benutzerliste fehlen, obwohl die Benutzer-Zählung nicht stimmt
• Ausgehende Anfragen Ihres Webservers an öffentliche Ethereum-RPC-Gateways
• Das deutlichste Signal: Malware, die nach einer Bereinigung immer wieder zurückkehrt

Bereinigung: Die Reihenfolge entscheidet

Weil jede Komponente die anderen wiederherstellen kann, ist die Reihenfolge wichtiger als das Löschen selbst. Sucuri empfiehlt diesen Ablauf, und das deckt sich mit unserer Erfahrung aus der Notfall-Bereinigung gehackter WordPress-Seiten:

1. Prepend-Mechanismus neutralisieren, bevor Dateien gelöscht werden. Achtung: PHP cached den auto_prepend_file-Wert bis zu 300 Sekunden. Wer die Zieldatei einfach löscht, legt jede PHP-Anfrage des Accounts lahm. Richtig: Zieldatei erst durch einen leeren Stub ersetzen, dann die Direktive entfernen.
2. Kopien außerhalb des Dateisystems entfernen: Payload-Zeile aus der Options-Tabelle löschen, Shared-Memory-Segment leeren, Kontroll-Options und Transients entfernen.
3. Cron-Hooks und Datenbank-Trigger beseitigen (information_schema.TRIGGERS prüfen).
4. Versteckten Administrator löschen, inklusive verwaister Options, die auf dessen ID zeigen.
5. Erst jetzt alle Dateien in einem Durchgang bereinigen: Loader, Shim, beide Plugin-Kopien, ZIP-Archiv, Drop-ins. In der Theme-functions.php nur den markierten Block entfernen, damit das Theme intakt bleibt.
6. Erneut scannen und die Pfade überwachen. Kehrt eine Komponente zurück, hat ein Versteck überlebt oder die ursprüngliche Einfallstür ist noch offen.

Prävention: So kommt SC gar nicht erst auf Ihre Website

Der Infektionsweg ist im dokumentierten Fall unbekannt. Die üblichen Verdächtigen sind jedoch bekannte Sicherheitslücken in veralteten Plugins und Themes, schwache Zugangsdaten und unsichere Upload-Funktionen. Daraus folgt:

• Konsequent patchen: Die meisten Kompromittierungen nutzen längst behobene Schwachstellen. Regelmäßige Updates verkürzen das Angriffsfenster drastisch. Genau das leistet eine professionelle WordPress-Wartung.
• Web Application Firewall einsetzen, die Exploit-Versuche und die Beacon-Anfragen der Malware blockiert.
• Regelmäßige Tiefen-Audits: Options-Tabelle, Cron-Tasks, Datenbank-Trigger und Benutzerkonten gehören auf den Prüfplan, nicht nur das Dateisystem.
• Saubere Backups mit Historie: Bei einer Infektion dieser Tiefe ist ein Restore auf einen garantiert sauberen Stand oft der schnellste Weg, vorausgesetzt, die Backups reichen weit genug zurück und liegen außerhalb der kompromittierten Umgebung.

Unser Fazit

SC markiert eine neue Qualitätsstufe bei WordPress-Malware. Sucuri selbst fasst es so zusammen:

„SC is a reminder that a modern WordPress infection can be a system rather than a file.“

Übersetzt: „SC erinnert daran, dass eine moderne WordPress-Infektion ein System sein kann, nicht nur eine Datei.“

Wer nach einem Hack nur die offensichtlichen Dateien löscht, spielt gegen einen Gegner, der sich bei jedem Seitenaufruf selbst repariert. Wenn Ihre Website nach einer Bereinigung immer wieder infiziert wird, ist das kein Pech, sondern ein Hinweis auf genau diese Art von Persistenz-Mechanismen.

Im Verdachtsfall unterstützen wir Sie mit einer strukturierten Notfall-Bereinigung, die Dateisystem, Datenbank, Cron und Benutzerkonten als Einheit behandelt, und mit laufender Wartung, damit die Einfallstür geschlossen bleibt.

Häufige Fragen

Woran merke ich, dass meine WordPress-Seite mit SC infiziert ist?

Das deutlichste Symptom: Malware kehrt nach jeder Bereinigung zurück, oft innerhalb von Sekunden. Prüfen Sie außerdem wp-content/db.php, advanced-cache.php, die functions.php Ihres Themes auf fremde Code-Blöcke sowie mu-plugins auf unbekannte Plugins.

Reicht es, die infizierten Dateien zu löschen?

Nein. SC hält Kopien in der Datenbank, im Shared Memory des Servers und in Cron-Tasks vor. Jede dieser Kopien stellt alle Dateien beim nächsten Seitenaufruf wieder her. Die Bereinigung muss die Verstecke außerhalb des Dateisystems zuerst leeren.

Hilft ein Backup-Restore gegen diese Backdoor?

Nur bedingt. Ein reiner Datei-Restore scheitert, wenn Payload-Kopien in der Datenbank oder im Shared Memory überleben. Datenbank-Trigger verwandter Varianten legen gelöschte Admin-Konten automatisch neu an. Ein Restore muss Dateien und Datenbank gemeinsam auf einen sauberen Stand setzen und die Einfallstür schließen.

Wie schütze ich meine Website präventiv?

Plugins, Themes und WordPress-Core konsequent aktuell halten, starke Zugangsdaten mit Zwei-Faktor-Authentifizierung nutzen, eine Web Application Firewall einsetzen und regelmäßig auch Datenbank, Cron-Tasks und Benutzerkonten auditieren, nicht nur die Dateien.

Quellen: Sucuri, Gabriel Barbosa: SC WordPress Malware. A Self-Healing Mesh (30.09.2026) · The Hacker News (01.10.2026)