Browser Cache Smuggling trifft ClickFix

Angreifer suchen ständig nach Wegen, Schadsoftware auf Systeme zu bringen und diese gewinnbringend auszuführen, ohne dass Sicherheitslösungen oder Nutzer misstrauisch werden. Dieser Beitrag zeigt, wie verschiedene Methoden zusammenspielen, wie verschiedene Browser mit ihrem Cache umgehen und warum das für die Verteidigung relevant ist.

Was ist Browser Cache Smuggling?

Browser Cache Smuggling beschreibt eine Technik, bei der schädliche Dateien unbemerkt im Browser-Cache eines Systems abgelegt werden. Jeder Browser speichert Inhalte besuchter Webseiten zwischen, etwa Bilder oder Skripte, um Seiten beim nächsten Besuch schneller laden zu können. Genau diesen Mechanismus nutzt die Technik aus: Statt den Nutzer bewusst eine Datei herunterladen zu lassen, werden diese beim Seitenaufruf in den Cache geschleust.

Von dort lassen sich diese später weiterverwenden.

Für sich genommen richtet das noch keinen Schaden an. In Kombination mit anderen Techniken entsteht daraus jedoch ein Weg, um Systeme zu kompromittieren.

Was ist ClickFix?

ClickFix ist eine Social-Engineering-Methode.

Dabei wird der Nutzer über eine präparierte Webseite oder eine gefälschte Fehlermeldung dazu gebracht, selbst aktiv zu werden. Typischerweise soll er einen vorgegebenen Befehl kopieren und auf seinem System ausführen, etwa um ein vermeintliches Problem zu beheben oder eine Sicherheitsprüfung zu bestehen. Der Angriff setzt bewusst auf das Vertrauen und die Mithilfe des Nutzers. Führt dieser den Befehl aus, startet er die eigentliche Schadaktion selbst.

In Kombination mit Browser Cache Smuggling ergibt sich ein besonders unauffälliges Vorgehen: Bereits beim Aufruf der präparierten Seite wird die Malware im Cache-Verzeichnis abgelegt. Anschließend genügt der über ClickFix untergeschobene Befehl, um diese Datei aus dem Cache heraus auszuführen. Ein sichtbarer Download findet nicht statt.

Welche Herausforderungen haben Angreifer dabei?

Potenzielle Angreifer werden hierbei mit mehreren Hürden konfrontiert:

• Welchen Browser nutzt das Ziel?
• Wie und an welcher Stelle im Dateisystem legt dieser seine Cache-Dateien ab?
• Wie lässt sich die passende Datei im Cache-Verzeichnis eindeutig identifizieren und wiederverwenden?

Wie Browser mit dem Cache umgehen

Stellvertretend betrachten wir Microsoft Edge als Vertreter für Chromium-Browser unter Windows sowie Mozilla Firefox.

Microsoft Edge / Chromium

Besucht ein Nutzer eine Website, legt Edge deren Inhalte, zum Beispiel Bilder, in einem Cache-Ordner ab:

C:\Users\<Username>\AppData\Local\Microsoft\Edge\User Data\Default\Cache\Cache_Data

Rufen wir etwa die Seite https://www.secuinfra.com/de/company/ auf, lassen sich die dort eingebetteten Bilder im Cache wiederfinden.

Setzen wir eine passende Dateiendung, lässt sich die Datei wie gewohnt öffnen und anzeigen.

Je nach Dateityp zeigen sich Unterschiede. Chromium speichert abhängig von der internen Speicherlogik Ressourcen wie Bilder entweder als eigenständige Dateien mit dem Namensschema f_###### oder gebündelt in den Block-Dateien data_0 bis data_3. Versuchen wir beispielsweise, eine EXE- oder DLL-Datei auf diesem Weg wiederherzustellen, taucht sie nicht als f_-Datei auf, sondern in den data_-Dateien. Um an diese Inhalte zu gelangen, müsste man die Cache-Datenbank direkt bearbeiten. Das ist aufwendig und setzt voraus, dass der Browser-Prozess geschlossen ist.

Das Red Team von SECUINFRA hat dabei beobachtet, dass sich dieses Verhalten beeinflussen lässt: die Dateiendung und die Art der Einbindung in die Seite.

Binden wir ein legitimes Bild in eine einfache HTML-Seite ein, können wir anschließend direkt mit der zugehörigen Datei im Cache interagieren:

<html>   <body>     <b>Please Visit ME</b>     <img src=“picture.jpg „>   </body> </html>

Die Bilddatei wird wie erwartet als f_-Datei abgelegt.

Anders verhält es sich bei Anwendungsdateien. Binden wir eine EXE-Datei wie ein Bild ein:

<html>   <body>     <b>Please Visit ME</b>     <img src=“test.exe“>   </body> </html>

so wird sie zwar über das Netzwerk geladen, aber nicht in einem für uns nutzbaren Bereich des Cache abgelegt.

Auch das Umbenennen in test.exe.jpg und das Einbinden per <img>-Tag führt nicht zum Ziel. Ein direkter Zugriff auf die Datei ist weiterhin nicht möglich:

<html>   <body>     <b>Please Visit ME</b>     <img src=“test.exe.jpg“>   </body> </html>

Die geänderte Endung wirkt sich zwar auf den vom Server gemeldeten Content-Type aus, an der Ablage im schwer erreichbaren Cache-Bereich ändert das jedoch nichts.

SECUINFRAs Red Team konnte diese Einschränkung umgehen, indem die Datei stattdessen über ein <iframe> als eingebettete Ressource geladen wurde:

<html>   <iframe src=“test.exe.jpg“></iframe> </html>

Hierdurch landet die als Bild getarnte Anwendung als f_-Datei im Cache und lässt sich weiterverwenden. Wird die Dateiendung .exe ergänzt, ist sie wieder klar als ausführbare Anwendung erkennbar. Inhalt und Größe entsprechen exakt der Datei auf dem Webserver.

Bindet man die Anwendung als unmaskierte EXE-Datei über ein <iframe> ein, funktioniert das grundsätzlich ebenso. Der Unterschied: Der Nutzer wird über den Download informiert und je nach Dateityp und Herkunft gewarnt.

Das Ergebnis ist zwar ähnlich gewinnbringend und die Datei ist erreichbar, die potenziellen, sichtbaren Indikatoren machen diesen Weg jedoch auffällig.

Mozilla Firefox

Bei Firefox sieht der Umgang mit dem Cache etwas anders aus. Die Cache-Dateien liegen in folgendem Verzeichnis:

C:\Users\<Username>\AppData\Local\Mozilla\Firefox\Profiles\<Profil>.default-release\cache2\entries

Die Dateien werden dort unter einem eindeutigen Hash gespeichert. Das Besondere daran: Dieser Name leitet sich aus verschiedenen Eigenschaften ab und ist damit unabhängig von System und Betriebssystem identisch.

Als Beispiel dient dieses Mal das Banner der Seite https://www.secuinfra.com/de/company/, einmal unter Windows und einmal unter MacOS. Dieses liegt jeweils unter demselben Hash im Cache.

Angreifer können also gezielt nach ihrer Datei suchen. Und auch hier genügt das Hinzufügen der passenden Dateiendung, um das Bild wieder sichtbar und nutzbar zu machen.

Das Zusammenspiel mit ClickFix

Wie lässt sich dieses Verhalten nun ausnutzen? An dieser Stelle kommt ClickFix ins Spiel. Der Reiz für Angreifer liegt in drei Punkten: Der bloße Besuch einer Website genügt, es gibt keinen offensichtlichen Download, und die Datei landet an einem vorhersagbaren Ort.

Die Seite des Angreifers kann dabei leicht erkennen, welchen Browser ein Besucher verwendet, und den passenden Inhalt, sowie Befehl ausspielen:

<script>   const userAgent = navigator.userAgent;     if (userAgent.includes(„Edg/“)) {     // -> Edge-spezifischen Payload verwenden   } else if (userAgent.includes(„Firefox/“)) {     // -> Firefox-spezifischen Payload verwenden   } else {     testText.textContent = „Nicht unterstützt.“;   } </script>

Dabei ist die Ablage der Datei im Cache nur ein Teil der Angriffskette. Der Angreifer muss anschließend dafür sorgen, dass die Datei X im Cache-Verzeichnis von Browser Y durch einen entsprechenden Befehl tatsächlich ausgeführt wird – beispielsweise indem er das Opfer durch Social-Engineering zur Ausführung anleitet.

Wird der Nutzer dazu bewegt angepasste Befehle einzugeben und auszuführen, entsteht hierdurch eine Angriffskette, welche sich in einem harmlosen Beispiel nachstellen lässt.

Öffnen wir die Seite https://www.secuinfra.com/de/company/ in Firefox (Stand 02.09.2026) und öffnen CMD.exe unter Windows (Windows-Taste + R -> cmd eingeben und ENTER drücken) und fügen den nachfolgenden Befehl ein:

for /r "%LOCALAPPDATA%\Mozilla\Firefox\Profiles" %F in (A1DC26B5214150BF2CC02A289B6ECC892D205CF6) do move "%F" A1DC26B5214150BF2CC02A289B6ECC892D205CF6.png && A1DC26B5214150BF2CC02A289B6ECC892D205CF6.png

Entsteht folgende Kette:

1. Bild-Datei wird beim Aufrufen der Seite in den Cache geladen
2. Nutzer führt vorgegebenen Befehl aus
3. Bild-Datei wird im Verzeichnis gesucht, umbenannt, in den derzeitigen Ordner verschoben und geöffnet.

Befehle wie diese und auch deutlich ausgefeiltere, lassen sich ohne großen Aufwand durch Angreifer in eigene Seiten einbauen:

<html> <body>   <b> Befehl kopieren und bitte mit CMD ausführen! </b>   <button onclick=“copyText()“>Befehl kopieren</button> <script> function copyText() {     navigator.clipboard.writeText(„Hier könnte Ihr Befehl stehen.“); } </script>   </body> </html>

Ab hier gilt es nur noch ein glaubwürdiges Szenario zu entwickeln, Aktionen bestmöglich zu verschleiern und Payloads auf das Ziel anzupassen. Der Kreativität sind hierbei kaum Grenzen gesetzt.

Doch wie lässt sich dieses Verhalten erschweren, verhindern oder überwachen?

Empfehlungen

Um ClickFix-Angriffe zu erschweren, stehen verschiedene Maßnahmen zur Verfügung, die sich gegenseitig ergänzen und ineinandergreifen können.

Social Engineering

Regelmäßige ClickFix-Schulungen und Sensibilisierungsmaßnahmen gehören zu den wichtigsten Maßnahmen, um Angriffen vorzubeugen. Dabei sollten Benutzer insbesondere lernen:

• Keine Befehle von Webseiten in PowerShell, dem Terminal oder über Win+R zu kopieren und auszuführen.
• Fake-CAPTCHAs und „Verify you are human“-Anweisungen als mögliches Warnsignal zu erkennen. Insbesondere sollte misstrauisch machen, wenn eine Webseite im Rahmen eines vermeintlichen CAPTCHAs dazu auffordert, Befehle zu kopieren, Win+R zu öffnen oder PowerShell bzw. das Terminal zu verwenden.
• Eine Website sollte niemals dazu auffordern, Befehle auszuführen, um ein angebliches technisches Problem zu beheben.

https://commons.wikimedia.org/wiki/File%3AClickFix_Example_English.png?utm_source=chatgpt.com (CC0)

Das Verständnis für diese Manipulationsversuche ist besonders wichtig, da ClickFix darauf ausgelegt ist, legitime Benutzeraktionen auszunutzen.

Programme zur Ausführung von Code einschränken

Es gibt mehrere technische Maßnahmen, mit denen sich die versehentliche Ausführung schädlichen Codes durch Benutzer erschweren lässt:

• Einschränkung von UI-Eingabe-Schnittstellen: Sperrung des Ausführen-Dialogs (Win + R) sowie der Befehlsausführung über die Explorer-Adressleiste. Dies erschwert Social-Engineering-Vektoren (wie ClickFix), bei denen Benutzer verleitet werden, kopierte Befehle manuell in Shell-Eingabefelder einzufügen.
• Application Control: Hier kann festgelegt werden, welche Programme bzw. ausführbaren Dateien Benutzer ausführen dürfen. Beispielsweise könnte der Start von powershell.exe, cmd.exe oder rundll32.exe für bestimmte Benutzergruppen, nach Möglichkeit, eingeschränkt werden.

• Untrusted Content aus Benutzerverzeichnissen verhindern: Die Ausführung nicht vertrauenswürdiger Programme aus Verzeichnissen wie Downloads oder %AppData% kann ebenfalls durch Application-Control-Regeln eingeschränkt werden. Dadurch wird es Angreifern erschwert, dort abgelegte Schadsoftware direkt auszuführen.
• PowerShell Constrained Language Mode: PowerShell kann hierbei weiterhin verwendet werden, während bestimmte fortgeschrittene Funktionen sowie beispielsweise direkte Zugriffe auf .NET- und COM-Schnittstellen jedoch eingeschränkt werden.
• PowerShell Script Block Logging aktivieren: Dadurch können PowerShell-Befehle protokolliert und nachträglich analysiert werden. Dies erleichtert die Erkennung und Aufarbeitung von Angriffen.

Pop-ups & Warnmeldungen

Eine zusätzliche Möglichkeit besteht in einem Warnhinweis, der beispielsweise beim Start von PowerShell angezeigt wird. Dieser könnte Benutzer auf die Gefahr von ClickFix-Angriffen und Social Engineering hinweisen. Für erfahrene Benutzergruppen könnte optional eine Möglichkeit vorgesehen werden, die Warnung auszublenden, um den Arbeitsablauf nicht unnötig zu beeinträchtigen.

Eine solche Erinnerung kann Benutzer dazu veranlassen, ihre Handlung vor der Ausführung eines Befehls noch einmal zu hinterfragen.

Netzwerkebene

Selbst wenn ein Angreifer einen ClickFix-Befehl erfolgreich ausführen lässt, kann der Angriff noch gestoppt werden, wenn die Verbindung zu einer schädlichen Domain frühzeitig blockiert wird. Bekannte schädliche Domains können beispielsweise über DNS-, Web- oder EDR-Schutz blockiert werden. Zusätzlich können Reputations- und Verhaltensmechanismen Verbindungen zu bislang unbekannten, verdächtigen Domains erkennen.

Endpoint Detection & Response (EDR)

Das Verhalten von EDR-Lösungen unterscheidet sich entlang der ClickFix-Angriffskette:

• Cache-Ablage & Schreibzugriffe: Das reine Schreiben der f_######-Dateien durch den Browser wird von EDR-Sensoren als normales Cache-Rauschen gefiltert und gewöhnlich nicht protokolliert oder alarmiert.
• Auslesen der Cache-Datei: Das reine Lesen (FileRead) der f_######-Datei aus dem Cache-Verzeichnis durch Skript-Interpreter (powershell.exe, cmd.exe) hinterlässt bei Standard-EDR-Einstellungen keine Telemetriespuren.
• Kopieren / Erstellen des Ziel-Payload: Der Kopiervorgang besteht technisch aus Lesen und Schreiben. Während das Lesen der Quelle im Cache unsichtbar bleibt, registriert das EDR das Erstellen der neuen Ziel-Datei (z. B. FileCreated für %TEMP%\evil.exe). Der Bezug zur Quell-Datei aus dem Browser-Cache geht dabei in der EDR-Telemetrie jedoch verloren.
• Ausführung & Prozesskette: Sobald die aus dem Cache kopierte Datei (z. B. %TEMP%\evil.exe) gestartet wird, erfasst das EDR die Ausführung und die Eltern-Kind-Prozessbeziehung (powershell.exe -> evil.exe) über ein ProcessCreated-Ereignis (DeviceProcessEvents).

SIEM, Detection Engineering & System-Auditing

Da einzelne Schritte der Angriffskette durch EDR-Telemetrie nicht komplett nachvollziehbar sind, kann die Erkennung durch zusätzliche Windows-Auditierung und Korrelation ergänzt werden:

• Windows Event ID 4663: Über eine SACL auf dem Browser-Cache-Verzeichnis und aktivierte Dateisystem-Auditierung können Zugriffe auf Cache-Dateien detaillierter erfasst werden. Dabei lassen sich sowohl Lese- als auch Schreibzugriffe protokollieren. In unserem Test wurden Lese- und Schreibzugriffe durch powershell.exe als Event ID 4663 erfasst. Auch legitime Schreibzugriffe des Browsers auf den Cache können dabei grundsätzlich unter die Überwachung fallen, weshalb einzelne Cache-Zugriffe allein kein eindeutiges Angriffssignal darstellen. Aussagekräftiger sind Zugriffe durch unerwartete Prozesse wie powershell.exe oder cmd.exe.

• Korrelation der Prozesskette: SIEM-Regeln können einen Cache-Zugriff durch einen Skript-Interpreter mit nachfolgenden Dateioperationen und einer anschließenden Ausführung korrelieren. Dadurch lässt sich die Angriffskette auch dann erkennen, wenn einzelne Schritte durch das EDR nicht erfasst werden.
• PowerShell-Skriptblock-Analyse: Ergänzend können PowerShell Script Block Logs und Prozessdaten auf Zugriffe auf Browser-Cache-Verzeichnisse sowie auf das anschließende Kopieren, Verändern oder Ausführen von Dateien untersucht werden. Dabei sollte die Erkennung insbesondere den zugreifenden Prozess, den Zugriff auf das Browser-Cache-Verzeichnis und nachfolgende Datei- bzw. Prozessaktivitäten berücksichtigen.

Referenz:

Think before you Click(Fix): Analyzing the ClickFix social engineering technique