ClickFix macht legitime Websites und Systemtools zur Auslieferungskette für Schadsoftware

Mehr als 17.000 URLs zeigten gefälschte Verifizierungsaufforderungen

ClickFix hat sich zu einer bedeutenden Erstzugriffstechnik entwickelt: Die entscheidende Aktion findet nicht mehr durch eine Software-Exploit statt, sondern durch das Opfer selbst. Statt unbemerkt einen Browser zu kompromittieren, bringt der Angriff Nutzer dazu, eigenständig einen Befehl auszuführen.

Bei ihren Untersuchungen identifizierte CTM360 mehr als 17.000 infizierte URLs, auf denen gefälschte Cloudflare-Verifizierungsseiten angezeigt wurden. Zum Zeitpunkt der Auswertung lieferten noch rund 3.000 davon die Köderseite aus.

Die Seiten präsentieren Probleme, die im jeweiligen Kontext plausibel erscheinen: eine fehlgeschlagene Mensch-Verifizierung, einen Darstellungsfehler im Browser, ein nicht zugängliches Dokument oder zu wenig Speicherplatz auf einem Mac. Anschließend wird der Besucher angewiesen, einen Befehl zu kopieren, eine Systemoberfläche zu öffnen, den Inhalt einzufügen und die Eingabetaste zu drücken.

Manche Seiten legen den Befehl direkt in der Zwischenablage ab. Der Nutzer führt ihn dann über eine legitime Oberfläche aus, etwa PowerShell, Terminal, den Windows-Ausführen-Dialog, die Eingabeaufforderung oder die Adressleiste des Datei-Explorers.

Diese Abfolge ist entscheidend für den Erfolg von ClickFix. Ein angemeldeter Nutzer startet ein natives, signiertes Dienstprogramm. So kann der Vorgang Sicherheitskontrollen umgehen, die auf schädliche Anhänge, verdächtige Downloads oder herkömmliche Browser-Exploits ausgerichtet sind.

Microsoft führte 2025 47 % der Erstzugriffs-Incidents, die von seinem Defender-Experts-Team bearbeitet wurden, auf ClickFix zurück. In diesem Datensatz lag die Methode damit vor herkömmlichem Phishing. ESET verzeichnete im ersten Halbjahr 2025 einen Anstieg um 517 % und zwischen dem zweiten Halbjahr 2025 und dem ersten Halbjahr 2026 einen weiteren Anstieg um 108 %.

MITRE nahm das Verhalten im März 2025 als T1204.004, User Execution: Malicious Copy and Paste auf. Die Technik kommt unter Windows, macOS und Linux zum Einsatz.

Der Angriff zielt auf das Verhalten, nicht auf eine verwundbare Softwareversion

ClickFix ist keine Software-Schwachstelle. CTM360 hat weder eine CVE-Kennung noch einen numerischen Schweregrad vergeben; betroffene Produktversionen, die sich durch ein Update beheben ließen, gibt es nicht.

Aus demselben Grund ist eine Aufnahme in den Katalog der Known Exploited Vulnerabilities (KEV) von CISA nicht relevant. Es gibt keine KEV-Frist für Abhilfemaßnahmen, denn der Angriff beruht nicht auf der Ausnutzung einer dort aufgeführten Schwachstelle.

Die untersuchte Kampagne war in erster Linie für Windows ausgelegt. ClickFix ist deshalb jedoch keine reine Windows-Bedrohung. Die serverseitigen Einstellungen enthielten auch Köder für macOS, darunter einen gefälschten Apple-Supportartikel, der angeblich bei zu wenig freiem Speicherplatz helfen sollte. Auch ein Auslieferungsplatz für Linux war vorgesehen, blieb in der untersuchten Konfiguration aber leer. Die Auslieferung an Mobilgeräte war deaktiviert.

Nach der Ermittlung des Betriebssystems und der Version des Geräts konnte der Betreiber festlegen, was dem Besucher angezeigt wurde. Windows-Ziele konnten eine Landingpage erhalten, Mac-Nutzer eine andere; mobilen Besuchern wurde möglicherweise gar nichts Schädliches angezeigt.

Zu den verwandten Methoden zählen FileFix und CrashFix. Bei all diesen Varianten kann sich die Oberfläche und der Vorwand ändern. Der Angriff hängt jedoch weiterhin davon ab, dass das Opfer dazu gebracht wird, vom Angreifer kontrollierte Anweisungen in einen vertrauenswürdigen lokalen Ausführungspfad zu übertragen.

Aktuelle Kampagnen haben außerdem gezeigt, dass ClickFix auch außerhalb gewöhnlicher kompromittierter Websites das Vertrauen von Nutzern ausnutzen kann. Bei einem separaten Vorfall wurde ein gehacktes, verifiziertes Reddit-Konto genutzt, um ClickFix-Anzeigen an Windows- und macOS-Nutzer zu verbreiten.

Polygon, Telegram und Steam machen das Blockieren schwieriger

Das von CTM360 untersuchte Skript auf kompromittierten Websites enthielt keine fest codierte, vom Angreifer kontrollierte Domain. Stattdessen sendete der Browser des Opfers eine kostenlose, schreibgeschützte Anfrage an einen Smart Contract auf der Polygon-Blockchain.

Der Vertrag lieferte einen codierten Wert zurück, aus dem sich der aktuelle Hostname der Köderseite ermitteln ließ. Besucher benötigten dafür weder eine Kryptowallet noch mussten sie bezahlen oder eine Blockchain-Transaktion durchführen.

Während eines Beobachtungstags lieferte der Vertrag drei verschiedene Hostnamen für Köderseiten aus, obwohl die infizierten Websites unverändert blieben. Durch eine Aktualisierung des On-Chain-Werts konnte der Betreiber alle beteiligten Websites innerhalb von Sekunden auf neue Infrastruktur umleiten.

Dieses Design erschwert das Blockieren anhand von Domains. Sicherheitsverantwortliche können zwar einen Hostnamen der Köderseite entfernen, doch die kompromittierten Seiten können dessen Ersatz abrufen, ohne dass der Angreifer jede Website erneut ändern muss. Auch eine Sperrung der Blockchain-RPC-Dienste wäre problematisch, da diese legitime, gemeinsam genutzte Infrastruktur sind, die auch von anderen Anwendungen verwendet wird.

Andere Phasen der Angriffskette nutzten andere Methoden zur Ermittlung der Zieladresse. In Beschreibungen von Telegram-Kanälen und auf einer Steam-Profilseite konnte die aktuelle Command-and-Control-Adresse der Schadsoftware stehen. Der Ausfall eines einzelnen Mechanismus hätte die gesamte Angriffskette daher nicht zwangsläufig unterbrochen.

Ein System zur Verteilung des Datenverkehrs sorgte für eine weitere Ebene der Widerstandsfähigkeit. Es fragte etwa alle 1,5 Sekunden beim Betreiber nach und konnte entscheiden, ob die schädlichen Anweisungen angezeigt oder Besucher unauffällig als verifiziert eingestuft wurden.

Forscher, Crawler und automatisierte Sandboxes konnten unverfälschte Inhalte erhalten, während ausgewählten Zielen das ClickFix-Overlay angezeigt wurde. Ein Cookie unterdrückte die Einblendung bei wiederkehrenden Besuchern 90 Tage lang. Dadurch sank die Wahrscheinlichkeit zusätzlich, dass eine spätere Prüfung den ursprünglichen Infektionsweg reproduzieren würde.

Maschinen-Fingerprinting verschleiert die finale Payload

Der wiederhergestellte Dropper enthielt im Downloadpfad einen Base64-codierten Maschinen-Fingerprint. Zu den erfassten Daten gehörten die Computer-GUID, die Volume-Seriennummer, der Computername, der BIOS-Hersteller, das Systemmodell, der Grafikprozessor und der Benutzername.

Anhand dieser Informationen konnte der Command-and-Control-Server den anfragenden Computer identifizieren, bevor er die nächste Stufe auslieferte. Der Server konnte eine maschinenspezifische Payload zurückgeben, andere Inhalte bereitstellen oder ganz auf eine Payload verzichten.

Wenn die Ausführung in einer Sandbox fehlschlägt, ist eine Website deshalb nicht automatisch harmlos. Eine automatisierte Umgebung und der echte Arbeitsplatzrechner eines Mitarbeiters können von derselben Adresse völlig unterschiedliche Antworten erhalten.

CTM360 führte zwei unabhängige Untersuchungen mit unterschiedlichen Hosts und Methoden durch. Bei einer davon ließ sich der Ablauf nur bis zum Dropper verfolgen, da die anschließende Auslieferung an den Fingerprint des Rechners gebunden war.

Die zweite Untersuchung verfolgte die Angriffskette über drei Telegram-basierte Dead-Drop-Resolver und zwei AES-Entschlüsselungsebenen. Am Ende wurde Vidar Stealer entdeckt, der per DLL-Sideloading innerhalb einer legitim signierten Microsoft-Binärdatei ausgeführt wurde.

Beim DLL-Sideloading wird ausgenutzt, wie eine Anwendung nach den benötigten Bibliotheken sucht. Dabei lädt eine legitime ausführbare Datei eine schädliche DLL, die an einem Ort abgelegt wurde, an dem das Programm eine Abhängigkeit erwartet. So wird die Schadsoftware im Kontext der vertrauenswürdigen Binärdatei ausgeführt.

Beide Untersuchungen legten dieselbe Struktur der Traffic-Distribution-API offen. CTM360 wertet dies als Hinweis darauf, dass sie dasselbe Kit nutzten.

Auch Sekoias Analyse des ErrTraffic-Frameworks vom Juni 2026 brachte den Polygon-Vertrag mit einem Betreibercluster in Verbindung, dem der ausschließliche Vertrieb von Vidar zugeschrieben wurde. CTM360 bewertete diese Verbindung mit mittlerer Konfidenz, da das Framework für etwa 380 US-Dollar pro Monat an mehrere Affiliates verkauft wird. Dadurch können sich die Infrastruktur und die Grenzen der Cluster verändern.

Der Bericht beschreibt außerdem, dass ClickFix von staatlich unterstützten Akteuren genutzt werde. Eine Regierung wird darin jedoch nicht genannt; auch eine konkrete staatliche Zuordnung fehlt.

Eine WordPress-Kompromittierung kann oberflächliche Bereinigungen überdauern

WordPress-Websites eignen sich als Auslieferungsinfrastruktur, da sie etablierte Domains, gültige Zertifikate und echten Besucherverkehr verbinden. Zudem werden sie möglicherweise nicht so kontinuierlich überwacht wie sensiblere Unternehmenssysteme.

Bei der Untersuchung auf Host-Ebene hängte PHP den schädlichen Loader an jede der untersuchten dynamischen Antworten an. Identische Inhalte fanden sich in HTML-Seiten, RSS-Feeds und JSON-Ausgaben.

Dieses Verhalten deutete auf ein WordPress-Must-Use-Plugin hin. Solche Plugins werden bei jeder Anfrage automatisch geladen und erscheinen nicht in der regulären Plugin-Liste. Dadurch kann das Implantat bei einer routinemäßigen administrativen Prüfung leicht übersehen werden.

Die Ermittler fanden außerdem rund zwei Dutzend von Skripten angelegte Administratorkonten. Die Kombination aus einer dauerhaft aktiven serverseitigen Einschleusung und zahlreichen Konten mit weitreichenden Rechten bedeutet: Wer einen sichtbaren JavaScript-Block löscht, Spam-Seiten entfernt oder ein einzelnes verdächtiges Administratorkonto deaktiviert, bereinigt die Website damit nicht vollständig.

Es wurde weder eine WordPress-Schwachstelle noch eine betroffene WordPress-Version identifiziert. Die Befunde beschreiben kompromittierte Installationen und Persistenzmechanismen, nicht die Ausnutzung einer veröffentlichten WordPress-CVE.

Wer ähnliche Aktivitäten untersucht, sollte Must-Use-Plugins, serverseitige PHP-Änderungen, unerwartete Administratorkonten und eingeschleuste Inhalte in verschiedenen Antwortformaten prüfen. Bei der Bereinigung müssen sowohl die eingeschleusten Inhalte als auch alle Wege beseitigt werden, über die der Angreifer erneut Zugriff erlangen könnte.

Schutzmaßnahmen sollten an den entscheidenden Verhaltensschritten ansetzen

Schnell wechselnde Hostnamen sind für diese Aktivitäten keine verlässlichen primären Indikatoren. CTM360 benennt stattdessen vier Schritte, die jede erfolgreiche Angriffskette durchlaufen muss: Anweisungen in die Zwischenablage schreiben, einen Interpreter starten, diesem Interpreter den Zugriff auf das Internet ermöglichen und Schadsoftware ausführen, die sich dauerhaft einnistet, Daten sammelt oder exfiltriert.

Verwaltete Browser können Schreibzugriffe auf die Zwischenablage standardmäßig blockieren. Die Köderseite ist dann zwar weiterhin sichtbar, doch wenn Nutzer einen verschleierten Befehl von Hand abtippen müssen, steigt der Aufwand – und der Einschleusungsprozess lässt sich möglicherweise unterbrechen.

Unternehmen können Skript-Interpreter und netzwerkfähige Kommandozeilenprogramme außerdem über einen authentifizierten Proxy leiten. So lässt sich die erste ausgehende Anfrage unter Windows, macOS und Linux unterbinden, ohne auf eine aktuelle Liste schädlicher Domains angewiesen zu sein.

Anwendungskontrollen sollten einschränken, welche Programme interaktive Nutzer starten und welche Bibliotheken vertrauenswürdige Dienstprogramme laden dürfen. Die Überwachung sollte sich auf ungewöhnliche Interpreter-Aktivitäten, unerwartete ausgehende Verbindungen nativer Systemtools, verdächtiges DLL-Laden und Befehle konzentrieren, die unmittelbar nach einer Browseraktivität in eine Shell eingefügt werden.

Auch die Schulung der Nutzer bleibt wichtig. Eine legitime Verifizierungsseite, ein Dokumentbetrachter, ein Softwareupdate, ein Videoanruf oder ein Supportartikel sollte niemanden dazu auffordern, einen von einer Website bereitgestellten Befehl in PowerShell, Terminal, den Ausführen-Dialog oder eine andere Betriebssystemoberfläche einzufügen.

Diese eine Aufforderung ersetzt den Exploit. Wer sie verhindert – oder die anschließende Ausführung erkennt –, schützt sich dauerhafter, als wenn er einer Infrastruktur hinterherjagt, die darauf ausgelegt ist, schnell wieder zu verschwinden.