Forscher von SOCRadar berichten über DOUBLECUP, einen neuen russischen Loader-als-a-Service (LaaS). Das Angebot ist darauf ausgelegt, mit möglichst wenig Reibung schädliche Dateien an Zielbrowser zu liefern. Im Zentrum der Technik stehen ClickFix und Cache-PNGs: Der Angreifer nutzt ClickFix-Umleitungen, um PNG-Dateien mit verstecktem Inhalt in den Browser-Cache der Opfer zu bringen, anschließend deren Daten abzurufen und weitere Schadsoftware zu starten.
DOUBLECUP ist dabei nicht auf eine einzelne Malware beschränkt. Laut Bericht werden u. a. CountLoader sowie ein bislang nicht dokumentierter Remote-Access-Trojaner namens DeviceManager verteilt. Erschwerend kommt hinzu, dass Teile der Entschlüsselung offenbar an Umgebungsdaten des Zielsystems gekoppelt sind.
Wie DOUBLECUP mit ClickFix und Cache-PNGs arbeitet
Die Angriffslogik startet als mehrstufiger Ablauf. In einer ersten Phase wird eine steganografische PNG-Datei in den Browser-Cache abgelegt. Danach wird der versteckte Inhalt aus dieser Datei ausgelesen und an die nächste Stufe übergeben.
Im zweiten Schritt erfolgt die Entschlüsselung und Ausführung des finalen Payload-Inhalts im Speicher. Dabei nutzt DOUBLECUP eine benutzerdefinierte Kombination aus einem Stromchiffre-Ansatz im CTR-Modus sowie einer bitweisen XOR-Verarbeitung. Als kryptografischer Schlüssel dient dabei die öffentliche IP-Adresse des Opfers.
Diese Kopplung an die Zielumgebung bedeutet: Selbst wenn die Payload kopiert oder auf einem anderen System analysiert wird, kann die Entschlüsselung auf Basis eines anderen Schlüssels fehlschlagen.
Welche Payloads werden ausgeliefert?
DOUBLECUP liefert über seine Ladeinfrastruktur mindestens zwei größere Schadsoftware-Pfade aus.
CountLoader für Windows und macOS
Der Loader CountLoader existiert in Varianten für Windows und macOS. Die Funktionen sind darauf ausgerichtet, persistente Zugriffe zu ermöglichen, das System zu erkunden und schrittweise weitere Komponenten zu starten.
Für Windows wird im Bericht u. a. beschrieben, dass CountLoader Scheduled Tasks für Persistenz nutzt. Außerdem prüft er unter anderem, ob Browser-Erweiterungen im Zusammenhang mit Krypto-Wallets installiert sind. Zusätzlich wird untersucht, ob die Desktop-App von Signal vorhanden ist.
Ein weiterer Baustein: CountLoader durchsucht Desktop und Startmenü nach LNK-Dateien beliebter Browser. Anschließend wird das Ziel solcher Verknüpfungen so umgeschrieben, dass beim Doppelklick auf den Browser-Shortcut der gewünschte Browser zwar im Vordergrund erscheint, aber der RAT im Hintergrund heimlich nachgeladen wird.
Allerdings weist der Bericht darauf hin, dass diese Funktion möglicherweise nicht aufgerufen wird. Das kann auf unfertige Entwicklung oder totes Funktionsfragment hindeuten.
DeviceManager als modularer Python-basierter RAT
Die zweite im Rahmen der DOUBLECUP-Infrastruktur genannte Payload ist DeviceManager. Der Trojaner ist als modularer Python-basierter RAT aufgebaut. Auffällig ist die Art der Ermittlung der Kommando- und Kontrollinfrastruktur (C2): Statt klassischer harter Serverlisten setzt DeviceManager auf das Konzept EtherHiding als „Dead-Drop“-Resolver.
Konkret sollen über Ethereum/Polygon Smart Contracts dynamisch die aktiven C2-Knoten aufgelöst werden. Erst danach wird die Kommunikation aufgebaut.
Die Verbreitung erfolgt laut Bericht als Delphi-kompilierter Inno-Setup-Installer, der das verschlüsselte Payload-Paket einbettet. Beim Start wird ein vollständig eingebettetes Python-Umfeld extrahiert, um anschließend die Python-Komponente zu starten.
Anti-Analyse und regionale Selbstlöschung
DeviceManager enthält eine weitere Schutzschicht: Er vermeidet offenbar die Ausführung auf Systemen, deren Sprache/Locale auf Länder der Gemeinschaft unabhängiger Staaten (GUS/CIS) schließen lässt. Wird eine Ziel-Locale erkannt, startet das Schadprogramm eine Selbstlöschroutine: Es entfernt u. a. den geplanten Task, löscht das Installationsverzeichnis über cmd.exe und beendet die Prozesse.
So betreibt DOUBLECUP seine Infrastruktur als LaaS
DOUBLECUP soll seit Anfang Juni 2026 aktiv sein. Die Kernentwickler stellen Operatoren offenbar Lizenzpakete bereit, die u. a. einen einzigartigen Schlüssel enthalten. Außerdem trägt jede Lizenz Metadaten wie die IP-Adresse des Clients, aktive Tage, ein Label und eine Version.
Mehrere Kampagnen lassen sich dem Bericht zufolge mit einer Lizenz koordinieren. Für die praktische Durchführung erhalten Operatoren zusätzlich einen Client-Agent, der beim Erstellen von Kampagnen helfen soll. Zentral ist dabei: Operatoren können erforderlichen Code direkt in ihre ClickFix-Landingpages einbetten.
Die Forscher leiteten die Analyse u. a. aus einem offenen Verzeichnis ab, das später als Teil einer Lizenz-„Panel“-Struktur identifiziert wurde.
Von der Konfiguration bis zur Ausführung im Browser
Ein Go-basierter Windows-Client mit grafischer Oberfläche unterstützt Operatoren dabei, Konfigurationen zu aktualisieren, Softwareversionen zu steuern und Befehle direkt zu senden. Der Bericht nennt zudem Bereiche wie ein Broadcast Pane sowie einen Payload Builder, in dem Operatoren die durch ClickFix ausgelöste Aktion konfigurieren können.
Dazu gehören u. a. die Angabe des Domains und Slugs, das Steganografie-Verfahren, das Embed-Typ und das Archivformat. Zusätzlich werden Parameter wie eine Auslösemethode (Action) und die zugehörigen Payload-URLs definiert.
Aus diesen Angaben entsteht offenbar ein Konfigurationsendpunkt nach dem Muster: https://{domain}/{slug}/api/config. Ein GET-Request auf diese Adresse soll Konfigurationsdaten zurückgeben. Darunter befinden sich u. a. die URL der steganografischen Bilddatei, die Bildgröße, ein Session-Endpunkt sowie browser-spezifische Befehle für unterschiedliche Browser wie Chrome, Edge, Firefox, Brave oder Opera.
Der ClickFix-Ablauf: Cache abgreifen, Code extrahieren, weiterleiten
Die Kampagnen erfordern, dass Operatoren zusätzlich Frontend-Code in ihre ClickFix-Seiten einfügen, um die schädliche Logik anzustoßen. Der Bericht beschreibt dabei mehrere Schritte:
- Abfrage des /api/config-Endpunkts
- Vorabruf (prefetch) der steganografischen PNG-Datei
- Registrierung einer Session und Auswahl der passenden Browserdaten anhand des User-Agent
- Anzeige von ClickFix-Anweisungen, Kopieren eines Browser-Commands in die Zwischenablage und Start einer Polling-Mechanik für den Redirect
Für zusätzliche Abwehrumgehung können Operatoren eigene Verschleierung oder Anti-Analyse-Maßnahmen einbauen. Diese Ergänzungen liegen laut Bericht jedoch in ihrer Verantwortung.
Erwähnt wird außerdem ein Telegram-Bot, der Besuche bei Clients nachverfolgen, Keys ausliefern und Rückmeldungen zu Payload-Callbacks entgegennehmen soll. Der Bot steht offenbar mit einem Akteur in Verbindung, der zudem eine fragwürdige VS-Code-Erweiterung im offiziellen Marketplace veröffentlicht haben soll.
Welche Köder werden genutzt?
Um Zielpersonen in die ClickFix-Umgebung zu lotsen, nutzten Kampagnen laut Bericht eine Reihe scheinbar gefälschter Websites, die CRM-Login-Seiten nachahmen. Genannt werden u. a. NetSuite, Odoo, HubSpot und Salesforce. Die eigentliche Auslieferung des Loaders erfolgt dabei über eingebettete iframe-Elemente.
Nach Ausführung der ClickFix-Befehle durchsucht die Kette den Browser-Cache nach der PNG-Datei. Aus dieser Datei wird dann bösartiges Skriptmaterial extrahiert – je nach Setup kann das in Form von JavaScript, VBScript oder PowerShell erfolgen, um die nächste Stufe zu starten.
Von der ersten Entschlüsselung zur finalen Ausführung
Sobald der zweite Stage beim C2-Server meldet, dass eine erfolgreiche Infektion stattgefunden hat, agiert er als Dropper. Er soll eine verschlüsselte Endpayload bereitstellen, anschließend eine Zielfläche (Destination Page) ansteuern und dabei die weitere Entfaltung vorbereiten.
Ein wichtiges Detail: Der Bericht beschreibt eine Form von Umgebungs-Schlüsselung, bei der die Entschlüsselung nur auf dem vorgesehenen Zielsystem gelingt. Als Seed wird die öffentliche IPv4-Adresse des Opfers verwendet, um den Schlüssel in einer Schlüsselableitungsfunktion zu generieren. Auf anderen Rechnern ergibt sich folglich ein falscher Schlüssel – die Entschlüsselung scheitert.
DeviceManager: C2 über DNS oder HTTP und Aufgabensteuerung
Nach dem Start sammelt DeviceManager umfangreiche Gerätedaten. Danach wird mit EtherHiding die C2-Infrastruktur über die im Blockchain-Mechanismus ermittelten Informationen in Gang gesetzt. Im Bericht wird als ein Beispiel für einen C2-Wert 91.92.240[.]100 genannt.
Für den Datenaustausch nutzt DeviceManager Kommunikationskanäle wie DNS oder HTTP – einschließlich Exfiltration, Polling auf neue Aufgaben und Versand von Ergebnissen ausgeführter Befehle.
Darüber hinaus kann das Schadprogramm PowerShell- und Python-Skripte ausführen. Ebenso kann es Operator-Kommandos in cmd.exe weiterleiten.
Warum das für Verteidiger relevant ist
SOCRadar ordnet DOUBLECUP als ein Beispiel für die wachsende Reichweite von ClickFix-Kampagnen ein. Aus Sicht der Angreifer ist der Prozess offenbar „low-friction“ und zuverlässig, weil steganografische PNGs und die Cache-Verarbeitung den eigentlichen Codeabruf unterstützen. Zudem erschwert die Entschlüsselungslogik mit Umgebungs-Schlüsselung die Analyse und senkt die Wahrscheinlichkeit von Fehlstarts.
Während CountLoader laut Bericht auf dem Kopieren und Manipulieren legitimer Windows-Bausteine setzt, versucht DeviceManager mit Smart-Contract-basierten Mechanismen die C2-Erreichbarkeit robust zu halten.
Fazit
ClickFix und Cache-PNGs sind im aktuellen DOUBLECUP-Case ein zentraler Hebel: Über Browser-Cache wird steganografischer Content bereitgestellt, anschließend werden zweite Stufen entschlüsselt und weitere Module nachgeladen. Betroffen sind dabei u. a. CountLoader (Windows/macOS) und der modular aufgebaute DeviceManager-RAT, der seine C2-Informationen über EtherHiding bezieht und je nach Locale sogar Selbstlöschung ausführen kann.
Quelle: https://thehackernews.com/2026/08/doublecup-uses-clickfix-and-cached-pngs.html
