Die ClickFix-Masche: Vom CAPTCHA zum Infostealer

Swiss Post Cybersecurity hat eine Infostealer-Kampagne entdeckt und analysiert. Dabei nutzen die Angreifer Clickfix für den initialen Zugriff und DonutLoader für die Auslieferung des Shellcodes. In unserem Blogartikel zeigen wir Ihnen Schritt-für-Schritt, wie Benutzer getäuscht werden.

Die moderne Bedrohungslandschaft ist durch ihre Komplexität gekennzeichnet. Angreifer setzen nicht mehr auf einfache E-Mail-Anhänge, sondern nutzen komplexe Infektionsketten, die legitime Systemtools einbeziehen, um unsichtbar zu bleiben. Der Cybersecurity Analyst, Louis Schürmann von Swiss Post Cybersecurity hat einen Vorfall beobachtet, der mit einer harmlosen E-Mail begann und sich dann zu einem mehrstufigen Angriff entwickelte. Zunächst wurde ein Social-Engineering-Trick eingesetzt, dann folgte ein PowerShell-Dropper und schliesslich eine in-memory Infostealer-Payload.

Dieser Blogartikel erklärt, wie die Kampagne Schritt für Schritt funktioniert. Wir zeigen, wie Angreifer Benutzer täuschen, dynamische Code-Kompilierung nutzen, um ihre Tools zu verbergen, und auf In-Memory-Ausführung setzen, um keine Spuren auf der Festplatte zu hinterlassen. Durch das Zerlegen dieser Taktiken, Techniken und Verfahren (TTPs) können wir moderne Evasion-Techniken besser verstehen und Ansätze zur Erkennung und Verteidigung identifizieren.

Die Köder: Missbrauch des Benutzervertrauens mit "ClickFix"

Der erste Zugang erfolgt über die nutzergetriebene Ausführung eines PowerShell-Befehls, das durch eine Social-Engineering-Taktik namens "ClickFix" ausgelöst wird. Dabei wird der Benutzer auf eine bösartige URL geführt, die ein gefälschtes CAPTCHA anzeigt. Dieses fordert den Benutzer auf, bestimmte Tastenkombinationen (Win + R, Ctrl + V, Enter) einzugeben, wodurch ein zuvor in die Zwischenablage kopierter PowerShell-Befehl ausgeführt wird.

Der Benutzer glaubt, eine Verifizierung durchzuführen, weil er jahrelang CAPTCHAs und Sicherheitsabfragen gewohnt war. In Wirklichkeit führt er den Angriff aber selbst aus. Diese "Human-in-the-Loop"-Ausführung ist eine effektive Evasion-Technik, die darauf abzielt, automatisierte Sicherheitsmechanismen zu umgehen. Weder die E-Mail noch die URL enthalten traditionelle Malware. Dadurch werden viele E-Mail-Sicherheits-Tools und Netzwerkfilter umgangen, da keine bösartige Datei oder Signatur erkannt werden kann.

Der Befehl selbst ist ein kurzer und unauffälliger Einzeiler. Zunächst wird ein Hex-String dekodiert, um eine bösartige URL zu extrahieren. Anschliessend wird ein PowerShell-Skript über Invoke-RestMethod von dieser URL abgerufen und direkt im aktuellen Prozess ausgeführt. Dadurch wird die erste Stufe der Infektion gestartet.

Phase 1: PowerShell-Dropper mit In-Memory-Ausführung

Nach dem initialen Zugriff lädt der PowerShell-Befehl ein Skript, das als In-Memory-Dropper fungiert. Das Skript nutzt dynamisch kompilierten C#-Code und Windows-API-Calls, um sein eigenes Konsolenfenster zu verstecken. Sollte dies nicht funktionieren, wird ein alternativer Mechanismus für den Fenster-Titel verwendet. Dieser wird dann per Prozesssuche gefunden und versteckt. Sobald das Fenster versteckt ist, holt der Dropper eine verschlüsselte Payload von einem Remote-Server. Siehe Powershell Screenshot in den Slides. 

Klicke durch die 4 Schritte:

Phase 2 - Donut Loader: Tarnung durch Memory-Execution

Der PowerShell-Stager injiziert einen kompakten .NET Loader direkt in seinen eigenen powershell.exe-Prozess. Der Zweck dieses Loaders besteht darin, ein Donut-Shellcode-Paket zu entschlüsseln, im Arbeitsspeicher zu verankern und zu starten, ohne dabei eine Datei abzulegen oder einen neuen Prozess zu starten. Ab der ersten Instruktion erfolgen das Entpacken, Mapping und die Übergabe an den nativen Infostealer vollständig innerhalb der ursprünglichen PowerShell-Laufzeitumgebung.

2.1 Vom Wrapper zum Donut in vier nahtlosen Schritten

Im extrahierten .NET-Projekt befindet sich der Einstiegspunkt des Loaders in der Datei sytuczzzsgolfnefxrmr.cs.
Die Hauptmethode (Main()) ist knapp gehalten, aber jede Anweisung wurde gezielt ausgewählt, um die Ausführung unsichtbar zu halten.
Gleich zu Beginn überprüft der Code die Anzeigesprache bzw. Regionseinstellung des Systems und das Programm beendet sich sofort, wenn das System auf Russisch (ru), Belarussisch (by) oder Kasachisch (kz) eingestellt ist. Dieser einfache Test (CultureInfo.CurrentUICulture.TwoLetterISOLanguageName) soll verhindern, dass sich die Schadsoftware versehentlich im Heimatgebiet der Angreifer verbreitet.

Wenn die Regionseinstellung dies zulässt, konzentriert sich der Loader auf einen 1.7 MB grossen ASCII-Hex-String, der direkt im Quellcode unterhalb der Klassendefinition eingebettet ist.

Acht Bytes, die sich nahe am Anfang des Strings befinden, fungieren gleichzeitig als RC4-Schlüssel. Der Loader dekodiert den Text, entschlüsselt ihn mithilfe des extrahierten Schlüssels und leitet das Ergebnis durch einen LZMA-Dekomprimierer. Nach weniger als einer Sekunde liegt ein 0x69300 Byte grosser Speicherpuffer vor, der zwei zusammengefügte Binärdateien enthält: einen Donut-Stub in Version 0.9.3 und direkt dahinter das finale native Payload-Binary.

Nachdem das Paket vollständig in den Speicher geladen wurde, reserviert der Loader per P/Invoke an VirtualAlloc den nötigen Adressbereich. Das anschliessende Kopieren des Pakets, das Setzen von Ausführungsrechte und der Start eines neuen Threads erfolgen vollständig ohne Einsatz von High-Level-Win32-APIs. Stattdessen nutzt der Loader direkte Syscalls, bereitgestellt von einem schlanken Framework, das im nächsten Abschnitt genauer beleuchtet wird.

Sobald der neue Thread mit der Ausführung am Anfang des Donut-Blobs beginnt, versetzt sich der ursprüngliche Loader-Thread in eine Sleep-Endlosschleife. So bleibt der PowerShell-Prozess aktiv und somit auch die Malware.

2.2 Syscalls auf Umwegen

Der Einsatz herkömmlicher Imports wie NtWriteVirtualMemory könnte den Loader potenziell gegenüber User-Mode-Hooks exponieren.

User-Mode Hooks sind Mechanismen, die von EDR-Lösungen (Endpoint Detection and Response) eingesetzt werden, um API-Calls im User-Mode abzufangen, noch bevor sie den Kernel erreichen. Dazu injizieren EDRs häufig einen eigenen Code in Benutzerprozesse, um verdächtige API-Calls wie Speicherzugriffe oder das Erzeugen von Threads zu überwachen. Werden solche Funktionen über reguläre Windows-APIs aufgerufen, können die Hooks sie erkennen, protokollieren oder blockieren – noch bevor sie den Kernel erreichen.

Um das du verhindern, haben die Autoren des Loaders eine eigene Syscall-Lösung implementiert:

• kzxuzlacbtgdylqcgzjz.cs fragt RtlGetVersion ab und konvertiert die Build-Nummern in Tokens wie WINDOWS_10_22H2.
• eiwfcumbsveijxmimpdp.cs sucht z. B. nach "NTWRITEVIRTUALMEMORY" in einem verschachtelten Dictionary, das mit dem Build-Token verknüpft ist, und gibt die passende Syscall-Nummer für das aktuelle OS zurück.
• zhvzoykgdxolwkvykjfs.cs enthält das klassische elf Byte lange x64 Stub-Template: 4C 8B D1 B8 ?? 00 00 00 0F 05 C3.
• bcfsizsukpmqlglwqnzc.cs ersetzt den „??“-Platzhalter mit der zuvor ermittelten OS-Nummer und gibt das einsatzbereite Stub zurück.
• ptieowjalbutmbxcthhv.cs ändert die Speicherschutzrechte der Heap-Seite auf PAGE_EXECUTE_READWRITE, wandelt das Stub in den passenden Delegat-Typ um und ruft es auf, als handle es sich um regulären Managed Code.
  Die Dateinamen wurden von dem extrahierten .NET-Projekt übernommen

Weil alle riskanten Aktionen, etwa das Kopieren von Speicher, das Ändern von Schutzrechten oder das Starten eines Threads, über diese selbstgebauten Syscalls ausgeführt werden, sieht ein typischer EDR-Hook im User-Mode keinen einzigen regulären API-Call, den er überwachen könnte.

2.3 Was im Donut-Stub tatsächlich passiert

Sobald die Kontrolle an den Donut-Code übergeht (bytegenau verifiziert als Donut 0.9.3), führt der Stub folgende Schritte aus:

1. Aufbau einer eigenen Syscall-Thunk-Table, damit spätere Phasen die gleichen Hook-Bypass-Fähigkeiten nutzen können wie der Wrapper zuvor.
2. Entschlüsselung und Dekompression des eingebetteten Binaries mittels identischer RC4→LZMA-Routine.
3. Manuelle Rekonstruktion des Binaries im Speicher, ohne den Windows Loader aufzurufen.
4. Absprung in den Entry Point des Binaries bei RVA 0xB0F8 über einen neuen Thread.
5. Aufruf von Sleep(INFINITE): Ab diesem Zeitpunkt bleibt der Stub inaktiv und hinterlässt kaum Spuren, ausser zwei ausführbare Speicherbereiche.

Da weder LoadLibrary noch CreateProcess zum Einsatz kommen, erscheint das Binary weder in Modullisten noch in ImageLoad-ETW-Events. Die gesamte Aktivität bleibt somit im flüchtigen Arbeitsspeicher verborgen.

Phase 3: Infostealer Payload

Sobald Donut die Ausführung übergibt, entpuppt sich das geladene Binary als massgeschneiderter Infostealer, der keiner bekannten Malware-Familie zugeordnet werden kann. Obwohl statische Bezeichner, die in mehreren Payloads hartcodiert sind, darauf hindeuten, dass dasselbe Toolkit in mehreren Kampagnen zum Einsatz kam, passt keine der üblichen Signaturen. Die Ziele sind jedoch eindeutig.

Der Code konzentriert sich fast ausschliesslich auf den Browser. Bei Firefox greift er direkt auf das aktive Profil zu und lädt die Dateien "cookies.sqlite", "cert9.db", "key4.db" und "places.sqlite". Allein diese vier Dateien enthalten Session-Cookies, gespeicherte Logins, den Zertifikatspeicher und den vollständigen Browserverlauf. Unmittelbar nach dem Dateizugriff wird ein einmaliger Screenshot des aktiven Desktops erstellt und als PNG-Datei mit dem Namen "Screenshot.png" im Arbeitsspeicher abgelegt. Anschliessend wir das Bild direkt über den Command-and-Control-(C2)-Kanal übertragen, ohne den lokalen Datenträger zu berühren.

Chromium-basierte Browser werden anders behandelt. Hier öffnet die Malware einen WebSocket zum Debugging-Port des Browsers und kommuniziert direkt über native Chrome-DevTools-Kommandos, wie beispielsweise Network.getAllCookies.

Dieser Ansatz liefert direkt entschlüsselte Cookie-Objekte, sodass weder der Zugriff auf die Cookie-Datenbank auf der Festplatte noch das Entschlüsseln per DPAPI erforderlich ist. Im Binary sind Pfade hartcodiert, unter anderem BinanceBrowser\Default, was auf ein gezieltes Interesse an Crypto-Sessions hinweist.

Alle gesammelten Daten werden über einen minimalistischen TCP-Dienst an 31.177.108.17:12345 exfiltriert. Das Protokoll beginnt mit Klartext-Steuerwörtern wie «PING», «PONG» und «ACK!», wechselt dann jedoch zu einem XOR-verschlüsselten Datenblock. Jede Übertragung enthält zwei konstante Tags: em1 und eine GUID wie 66f89dce-5240-4124-b3ff-54c731c55507. Dadurch kann der Angreifer seine Ziele über mehrere Kampagnen hinweg eindeutig zuordnen. Die Dateinamen wie «user.txt», «server_info.txt» oder Pfade zu Browserdaten werden im Klartext gesendet, danach folgt der verschlüsselte Inhalt der jeweiligen Datei.

Es wird kein Persistenzmechanismus implementiert, und es bleiben keinerlei Rückstände auf der Festplatte zurück. Nach dem letzten ACK! schläft der Prozess kurz, gibt seine Arbeitsspeicherpuffer frei und beendet sich. Dabei bleiben lediglich der von Donut erzeugte RX-Speicherbereich und ein beendeter Thread im flüchtigen Speicher zurück.

Fazit

Diese Kampagne verdeutlicht, wie ausgeklügelt und professionell moderne Malware inzwischen ist. Was harmlos mit einem gefälschten CAPTCHA beginnt, entwickelt sich zu einer mehrstufigen Angriffskette, die vollständig im Arbeitsspeicher abläuft und klassische Sicherheitsmechanismen elegant umgeht. Sie ist ein Lehrstück für Tarnung, Effizienz und technisches Know-how.

Auch wenn eine eindeutige Zuordnung zu einer bestimmten Gruppe fehlt, sprechen die genutzte Infrastruktur, die wiederkehrenden Codebausteine und das modulare Design eine klare Sprache: Hinter dieser Operation steckt ein erfahrener und gut organisierter Angreifer mit tiefem technischem Verständnis.

Bei Swiss Post Cybersecurity behalten wir solche Bedrohungen und deren Weiterentwicklungen genau im Blick. Eines ist klar: Klassische Indikatoren und dateibasierte Erkennung reichen längst nicht mehr aus. Um Angriffe heute zu erkennen und zu verhindern, muss man auf das Verhalten, die Speicheranalyse und die gezielte Aufklärung der Nutzer setzen.

You can't defend. You can't prevent. The only thing you can do is detect and respond.
- Bruce Schneier

IOC's (Indicators of Compromise)

Referenzen

https://github.com/TheWover/donut
https://github.com/volexity/donut-decryptor
https://3xperience.substack.com/p/bite-sized-insights-diving-into-donut?utm_campaign=post&utm_medium=web
https://malware.tech/posts/unpacking-shellcode-loaders/#thewover-s-donut