Einführung

Im Juli kündigte Google einen neuen Schutzmechanismus für Cookies an, die in Chrome unter Windows gespeichert sind, die sogenannte anwendungsgebundene Verschlüsselung. Es besteht kein Zweifel, dass diese Sicherheitsimplementierung die Messlatte höher gelegt und sich direkt auf das Malware-Ökosystem ausgewirkt hat. Nach Monaten mit dieser neuen Funktion haben viele Infostealer neuen Code geschrieben, um diesen Schutz zu umgehen (wie das Chrome Security Team vorhergesagt hat), um auf dem Markt wettbewerbsfähig zu bleiben und Funktionen bereitzustellen, die Cookie-Daten zuverlässig von Chrome-Browsern abrufen.

Elastic Security Labs hat eine Teilmenge dieser Aktivitäten verfolgt und mehrere Techniken identifiziert, die von verschiedenen Malware-Familien verwendet werden, um die App-gebundene Verschlüsselung zu umgehen. Während sich das Ökosystem angesichts dieses Drucks noch weiterentwickelt, ist es unser Ziel, technische Details zu teilen, die Unternehmen helfen, diese Techniken zu verstehen und sich dagegen zu verteidigen. In diesem Artikel werden wir die verschiedenen Methoden behandeln, die von den folgenden Infostealer-Familien verwendet werden:

• STEALC/VIDAR
• METASTEALER
• PHEMEDRON
• XENOSTEALER
• LUMMA

Wichtigste Erkenntnisse

• Die neuesten Versionen von Infostealern implementieren Umgehungen der aktuellen Cookie-Schutzfunktion von Google mithilfe von Application-Bound Encryption
• Zu den Techniken gehören die Integration des anstößigen Sicherheitstools ChromeKatz, die Nutzung von COM zur Interaktion mit Chrome-Diensten und zur Entschlüsselung des App-gebundenen Verschlüsselungsschlüssels sowie die Verwendung der Remote-Debugging-Funktion in Chrome
• Verteidiger sollten aktiv auf verschiedene Cookie-Umgehungstechniken gegen Chrome unter Windows achten, um zukünftige Abhilfemaßnahmen und Umgehungen zu antizipieren, die wahrscheinlich kurz- bis mittelfristig auftreten werden
• Elastic Security bietet Abhilfemaßnahmen durch Speichersignaturen, Verhaltensregeln und Hunting-Möglichkeiten, um eine schnellere Identifizierung und Reaktion auf Infostealer-Aktivitäten zu ermöglichen

Hintergrund

Im Allgemeinen werden Cookies von Webanwendungen verwendet, um Besucherinformationen in dem Browser zu speichern, mit dem der Besucher auf diese Webanwendung zugreift. Diese Informationen helfen der Web-App, diesen Benutzer, seine Präferenzen und andere Informationen von Standort zu Standort zu verfolgen – sogar über Geräte hinweg.

Das Authentifizierungstoken ist eine Verwendung der clientseitigen Datenspeicherstrukturen, die einen Großteil der Funktionsweise moderner Webinteraktivität ermöglichen. Diese Token werden vom Browser gespeichert, nachdem sich der Benutzer erfolgreich bei einer Webanwendung authentifiziert hat. Nach Benutzername und Passwort, nach Multifaktor-Authentifizierung (MFA) über Einmalpasswörter oder biometrische Daten, "merkt" sich die Webanwendung über den Austausch dieses Tokens bei jeder nachfolgenden Webanfrage an Ihren Browser, wer Sie sind.

Ein böswilliger Akteur, der Zugriff auf ein gültiges Authentifizierungstoken erhält, kann es wiederverwenden, um sich als Benutzer für diesen Webdienst auszugeben und Konten zu übernehmen, persönliche oder finanzielle Informationen zu stehlen oder andere Aktionen als dieser Benutzer auszuführen, z. B. das Übertragen von finanziellen Vermögenswerten.

Cyberkriminelle verwenden Infostealer, um diese Art von Informationen zu stehlen und zu kommerzialisieren, um ihren finanziellen Gewinn zu erzielen.

Google Chrome Cookie-Sicherheit

Ältere Versionen von Google Chrome unter Windows verwendeten die native Windows-Datenschutz-API (DPAPI), um Cookies zu verschlüsseln und sie vor anderen Nutzerkontexten zu schützen. Dies bot einen angemessenen Schutz vor mehreren Angriffsszenarien, aber jede bösartige Software, die im Kontext des Zielbenutzers ausgeführt wird, kann diese Cookies direkt mit den DPAPI-Methoden entschlüsseln. Leider ist dieser Kontext genau die Nische, in der sich Infostealer nach dem Social Engineering für den ersten Zugang oft befinden. Das DPAPI-Schema ist Angreifern mit mehreren Angriffsvektoren inzwischen gut bekannt . von der lokalen Entschlüsselung über die API über den Diebstahl des Masterkeys und die Entschlüsselung aus der Ferne bis hin zum Missbrauch des domänenweiten Backup-DPAPI-Schlüssels in einer Unternehmensumgebung.

Mit der Veröffentlichung von Chrome 127 im Juli 2024 hat Google die anwendungsgebundene Verschlüsselung von Browserdaten implementiert . Dieser Mechanismus richtete sich direkt gegen viele gängige DPAPI-Angriffe auf Windows Chrome-Browserdaten, einschließlich Cookies. Dazu werden die Daten in verschlüsselten Datendateien gespeichert und ein Dienst verwendet, der als SYSTEM ausgeführt wird, um zu überprüfen, ob alle Entschlüsselungsversuche vom Chrome-Prozess stammen, bevor der Schlüssel zur Entschlüsselung der gespeicherten Daten an diesen Prozess zurückgegeben wird.

Wir sind zwar der Meinung, dass dieses Verschlüsselungsschema kein Allheilmittel ist, um alle Browserdaten zu schützen (wie das Chrome-Sicherheitsteam in seiner Pressemitteilung einräumt), aber wir sind der Meinung, dass es erfolgreich war, Malware-Autoren zu TTPs zu bewegen, die offenkundiger bösartig sind und für Verteidiger leichter zu identifizieren und darauf zu reagieren sind.

Stealer-Bypass-Techniken, zusammengefasst

In den folgenden Abschnitten werden bestimmte Infostealer-Techniken beschrieben, die verwendet werden, um die App-gebundene Verschlüsselungsfunktion von Google zu umgehen, wie von Elastic beobachtet. Obwohl es sich hierbei nicht um eine vollständige Zusammenstellung von Umgehungen handelt und die Entwicklung dieser Familien noch nicht abgeschlossen ist, stellen sie eine interessante Dynamik im Bereich der Infostealer dar und zeigen, wie Malware-Entwickler auf die kürzlich aktualisierte Sicherheitskontrolle von Google reagiert haben. Zu den von unserem Team beobachteten Techniken gehören:

• Remote-Debugging über das DevTools-Protokoll von Chrome
• Lesen des Prozessspeichers des Chrome-Netzwerkdienstprozesses (ChromeKatz und ReadProcessMemory (RPM))
• Erhöhen auf SYSTEM Entschlüsseln app_bound_encryption_key dann mit der DecryptData Methode der GoogleChromeElevationService über COM

STEALC/VIDAR

Unser Team hat um den 20. September herum einen neuen Code beobachtet, der in STEALC/VIDAR eingeführt wurde, der mit der Cookie-Bypass-Technik zusammenhängt. Dabei handelte es sich um untypische Beispiele, die sich von früheren Versionen abhoben und als eingebettete 64-Bit-PE-Dateien zusammen mit bedingten Prüfungen implementiert wurden. Verschlüsselte Werte in den SQLite-Datenbanken, in denen Chrome seine Daten speichert, haben jetzt das Präfix v20, was darauf hinweist, dass die Werte jetzt mit anwendungsgebundener Verschlüsselung verschlüsselt werden.

STEALC wurde 2023 eingeführt und mit "starker Inspiration" von anderen, etablierteren Stealern wie RACOON und VIDAR entwickelt. STEALC und VIDAR wurden parallel weiterentwickelt und haben sich im Fall von App-Bound Encryption Bypasses auf die gleiche Implementierung festgelegt.

Bei der Extraktion verschlüsselter Daten aus den Datenbanken prüft die Malware auf dieses Präfix. Wenn er mit v20beginnt, wird ein untergeordneter Prozess mit der eingebetteten PE-Datei im .data Abschnitt der Binärdatei erzeugt. Dieses Programm ist für das Extrahieren unverschlüsselter Cookie-Werte verantwortlich, die sich in einem der untergeordneten Prozesse von Chrome befinden.

Diese eingebettete Binärdatei erstellt über OpenDesktopA / einen versteckten Desktop CreateDesktopA verwendet dann CreateToolhelp32Snapshot , um alle chrome.exe Prozesse zu scannen und zu beenden. Anschließend wird ein neuer chrome.exe Prozess mit dem neuen Desktop-Objekt gestartet. Basierend auf der installierten Version von Chrome wählt die Malware ein Signaturmuster für die Chromium-Funktion CookieMonster aus, eine interne Komponente zur Verwaltung von Cookies.

Wir haben die Signaturmuster verwendet, um auf vorhandenen Code umzuschwenken, der für ein offensives Sicherheitstool namens ChromeKatz entwickelt wurde. Zu diesem Zeitpunkt wurden die Muster aus dem ChromeKatz-Repository entfernt und durch eine neue Technik ersetzt. Basierend auf unserer Analyse scheint der Malware-Autor ChromeKatz in STEALC neu implementiert zu haben, um die App-gebundene Verschlüsselungsschutzfunktion zu umgehen.

Sobald die Malware eine übereinstimmende Signatur identifiziert hat, listet sie die untergeordneten Prozesse von Chrome auf, um das Vorhandensein des Befehlszeilenflags --utility-sub-type=network.mojom.NetworkService zu überprüfen. Dieses Flag gibt an, dass es sich bei dem Prozess um den Netzwerkdienst handelt, der für die Verarbeitung der gesamten Internetkommunikation verantwortlich ist. Es wird zu einem Hauptziel, da es die sensiblen Daten enthält, nach denen der Angreifer sucht, wie im Beitrag von MDSec beschrieben. Anschließend wird ein Handle für diesen bestimmten untergeordneten Prozess zurückgegeben.

Als Nächstes werden die einzelnen Module im untergeordneten Prozess des Netzwerkdiensts aufgelistet, um die Basisadresse und die Größe der in den Arbeitsspeicher geladenen chrome.dll zu suchen und abzurufen. STEALC verwendet CredentialKatz::FindDllPattern und CookieKatz::FindPattern, um die CookieMonster-Instanzen zu lokalisieren. Es gibt 2 Aufrufe an CredentialKatz::FindDllPattern.

Beim ersten Aufruf von CredentialKatz::FindDllPatternversucht es, eines der Signaturmuster (abhängig von der Chrome-Version des Opfers) in chrome.dllzu finden. Sobald STEALC gefunden wurde, verfügt es nun über einen Referenzzeiger auf den Speicherort, an dem die Bytesequenz beginnt, bei der es sich um die Funktion net::CookieMonster::~CookieMonster, Destruktor der CookieMonster Klasse handelt.

Der zweite Aufruf von CredentialKatz::FindDllPattern übergibt die Funktionsadresse für net::CookieMonster::~CookieMonster(void) als Argument für die Bytesequenzsuche, was dazu führt, dass STEALC einen Zeiger auf die Virtual Function Pointer-Struktur von CookieMonsterhat.

Die folgende Methode, die von STEALC verwendet wird, ist wiederum identisch mit ChromeKatz, wo sie CookieMonster Instanzen lokalisiert, indem sie Speicherblöcke im chrome.dll -Modul nach Zeigern durchsucht, die auf die CookieMonster vtable verweisen. Da vtable eine Konstante für alle Objekte einer bestimmten Klasse ist, hat jedes CookieMonster Objekt denselben vtable-Zeiger. Wenn eine Übereinstimmung identifiziert wird, behandelt STEALC den Speicherort als CookieMonster Instanz und speichert seine Adresse in einem Array.

Für jede identifizierte CookieMonster Instanz greift STEALC auf die interne CookieMap Struktur zu, die sich an einem Offset von +0x30befindet und bei der es sich um einen Binärbaum handelt. Jeder Knoten in dieser Struktur enthält Zeiger auf CanonicalCookieChrome Strukturen. CanonicalCookieChrome Strukturen enthalten unverschlüsselte Cookie-Daten, die für die Extraktion zugänglich sind. STEALC initiiert dann eine Baumdurchlauffunktion, indem der erste Knoten an eine dedizierte Durchlauffunktion übergeben wird.

Für jeden Knoten ruft er ReadProcessMemory auf, um auf die CanonicalCookieChrome Struktur aus dem Speicher des Zielprozesses zuzugreifen und sie dann in jy::GenerateExfilStringweiter zu verarbeiten.

STEALC formatiert die extrahierten Cookie-Daten, indem es das Ablaufdatum in das UNIX-Format konvertiert und das Vorhandensein der HttpOnly - und Secure -Flags überprüft. Anschließend werden Details wie der Name, der Wert, die Domäne, der Pfad und die HttpOnly und Secure des Cookies an eine abschließende Zeichenfolge für die Exfiltration angehängt. OptimizedString Strukturen werden anstelle von Zeichenfolgen verwendet, sodass Zeichenfolgenwerte entweder die Zeichenfolge selbst sein können oder wenn die Zeichenfolgenlänge größer als 23 ist, auf die Adresse verweist, an der die Zeichenkette gespeichert ist.

METASTEALER

METASTEALER, das erstmals im Jahr 2022 beobachtet wurde, hat kürzlich seine Fähigkeit zum Diebstahl von Chrome-Daten verbessert und damit die jüngsten Maßnahmen von Google zur Eindämmung umgangen. Am 30. September kündigten die Malware-Autoren dieses Update über ihren Telegram-Kanal an und hoben die verbesserte Fähigkeit hervor, sensible Informationen, einschließlich Cookies, trotz der Sicherheitsänderungen in der Chrome-Version 129+zu extrahieren.

Die erste Probe , die von unserem Team in freier Wildbahn beobachtet wurde, wurde am 30. September entdeckt, am selben Tag, an dem die Autoren das Update beworben haben. Trotz der Behauptung, dass die Malware ohne Administrator Privilegien arbeitet, haben unsere Tests ergeben, dass sie einen erhöhten Zugriff erfordert, da sie versucht, sich während der Ausführung als das SYSTEM Token auszugeben.

Wie in den obigen Screenshots gezeigt, enthält die get_decryption Methode jetzt einen neuen booleschen Parameter. Dieser Wert wird auf TRUE gesetzt, wenn die verschlüsselten Daten (Cookie) mit dem Präfix v20 beginnen, was darauf hinweist, dass das Cookie mit der neuesten Verschlüsselungsmethode von Chrome verschlüsselt wurde. Die aktualisierte Funktion behält die Abwärtskompatibilität bei und unterstützt weiterhin die Entschlüsselung von Cookies aus älteren Chrome-Versionen, falls diese auf dem infizierten Computer vorhanden sind.

Die Malware versucht dann, auf die Local State oder LocalPrefs.json Dateien zuzugreifen, die sich im Chrome-Profilverzeichnis befinden. Beide Dateien sind JSON-formatiert und speichern Verschlüsselungsschlüssel (encrypted_key) für ältere Chrome-Versionen und app_bound_encrypted_key für neuere. Wenn das Flag auf TRUEgesetzt ist, verwendet die Malware das app_bound_encrypted_key ausdrücklich, um Cookies gemäß der aktualisierten Chrome-Verschlüsselungsmethode zu entschlüsseln.

In diesem Fall nimmt die Malware zunächst die Identität des SYSTEM -Tokens an, indem sie eine neu eingeführte Klasse namens ContextSwitcherverwendet.

Anschließend wird der Schlüssel entschlüsselt, indem über das COM des für die Entschlüsselung verantwortlichen Chrome-Diensts mit dem Namen GoogleChromeElevationServiceunter Verwendung der CLSID- 708860E0-F641-4611-8895-7D867DD3675Beine Instanz erstellt wird. Nach der Initialisierung wird die DecryptData Methode aufgerufen, um den app_bound_encrypted_key Schlüssel zu entschlüsseln, der zum Entschlüsseln der verschlüsselten Cookies verwendet wird.

METASTEALER verwendet eine Technik, die derjenigen ähnelt, die in einem am 27. September auf X geteilten Kern demonstriert wird, der den Malware-Autoren als Inspiration gedient haben könnte. Beide Ansätze nutzen ähnliche Methoden, um die Verschlüsselungsmechanismen von Chrome zu umgehen und sensible Daten zu extrahieren.

PHEMEDRON

Dieser Open-Source-Stealer erregte Anfang des Jahres weltweite Aufmerksamkeit durch die Ausnutzung einer Windows SmartScreen-Schwachstelle (CVE-2023-36025). Während die Entwicklung noch auf Telegram stattfindet, hat unser Team eine aktuelle Version (2.3.2) gefunden, die Ende September eingereicht wurde und eine neue Cookie-Grabber-Funktionalität für Chrome enthält.

Die Malware listet zunächst die verschiedenen Profile innerhalb von Chrome auf und führt dann eine Browserprüfung mit der Funktion (BrowserHelpers.NewEncryption) durch, die nach dem Chrome-Browser mit einer Version größer oder gleich 127sucht.

Wenn die Bedingung zutrifft, verwendet PHEMEDRONE eine Kombination von Hilfsfunktionen, um die Cookies zu extrahieren.

Wenn wir uns die Klasse ChromeDevToolsWrapper und ihre verschiedenen Funktionen ansehen, können wir sehen, dass PHEMEDRONE eine Remote-Debugging-Sitzung in Chrome einrichtet, um auf die Cookies zuzugreifen. Der Standardport (9222) wird zusammen mit der Fensterposition auf -2400gesetzt,-2400 die außerhalb des Bildschirms eingestellt ist, um zu verhindern, dass ein sichtbares Fenster das Opfer warnt.

Als Nächstes stellt die Malware eine WebSocket-Verbindung zur Debugging-Schnittstelle von Chrome her und stellt eine Anfrage mit der veralteten Chrome DevTools Protocol-Methode (Network.getAllCookies).

Die Cookies werden dann von der vorherigen Anfrage im Klartext zurückgegeben, unten sehen Sie eine Netzwerkerfassung, die dieses Verhalten zeigt:

XENOSTEALER

XENOSTEALER ist ein Open-Source-Infostealer, der auf GitHub gehostet wird. Es erschien im Juli 2024 und befindet sich zum Zeitpunkt dieser Veröffentlichung in aktiver Entwicklung. Bemerkenswert ist, dass die Chrome-Bypass-Funktion am 26. September 2024begangen wurde.

Der Ansatz von XENOSTEALER ähnelt dem von METASTEALER. Zuerst wird die JSON-Datei unter einem bestimmten Chrome-Profil analysiert, um die app_bound_encrypted_keyzu extrahieren. Der Entschlüsselungsprozess erfolgt jedoch innerhalb eines Chrome-Prozesses. Um dies zu erreichen, startet XENOSTEALER eine Instanz von Chrome.exeund injiziert dann Code mithilfe einer Hilfsklasse namens SharpInjectorund übergibt den verschlüsselten Schlüssel als Parameter.

Der eingefügte Code ruft anschließend die DecryptData Methode aus dem GoogleChromeElevationService auf, um den entschlüsselten Schlüssel abzurufen.

LUMMA

Mitte Oktober wurde in der neuesten Version von LUMMA eine neue Methode zur Umgehung des Chrome-Cookie-Schutzes implementiert, wie @g0njxa berichtet.

Wir haben eine aktuelle Version von LUMMA analysiert und bestätigt, dass es gelungen ist, die Cookie-Daten von der neuesten Version von Google Chrome (130.0.6723.70) wiederherzustellen. LUMMA erstellt zunächst einen sichtbaren Chrome-Prozess über Kernel32!CreateProcessW.

Diese Aktivität wurde im Debugger mit mehreren Aufrufen von NtReadVirtualMemory verfolgt, bei denen wir die LUMMA-Suche innerhalb des Chrome-Prozesses für chrome.dllidentifizierten.

Sobald die Malware das chrome.dll Image gefunden hat, kopiert sie es mithilfe von NtReadVirtualMemoryin ihren eigenen Prozessspeicher. Ähnlich wie bei der ChromeKatz-Technik nutzt Lumma das Scannen von Mustern, um die CookieMonster Komponente von Chrome ins Visier zu nehmen.

Lumma verwendet ein verschleiertes Signaturmuster, um die CookieMonster Funktionalität zu lokalisieren:

3Rf5Zn7oFA2a????k4fAsdxx????l8xX5vJnm47AUJ8uXUv2bA0s34S6AfFA????kdamAY3?PdE????6G????L8v6D8MJ4uq????k70a?oAj7a3????????K3smA????maSd?3l4

Im Folgenden finden Sie die YARA-Regel nach der Entschleierung:

rule lumma_stealer
{
  meta:
    author = "Elastic Security Labs"
  strings:
    $lumma_pattern = { 56 57 48 83 EC 28 89 D7 48 89 CE E8 ?? ?? ?? ?? 85 FF 74 08 48 89 F1 E8 ?? ?? ?? ?? 48 89 F0 48 83 C4 28 5F 5E C3 CC CC CC CC CC CC CC CC CC CC 56 57 48 83 EC 38 48 89 CE 48 8B 05 ?? ?? ?? ?? 48 31 E0 48 89 44 24 ?? 48 8D 79 ?? ?? ?? ?? 28 E8 ?? ?? ?? ?? 48 8B 46 20 48 8B 4E 28 48 8B 96 ?? ?? ?? ?? 4C 8D 44 24 ?? 49 89 10 48 C7 86 ?? ?? ?? ?? ?? ?? ?? ?? 48 89 FA FF 15 ?? ?? ?? ?? 48 8B 4C 24 ?? 48 31 E1}
  condition:
    all of them
}

Nach der Dekodierung und Suche nach dem Muster in chrome.dllführt dies zum CookieMonster Destruktor (net::CookieMonster::~CookieMonster).

Die Cookies werden dann im Speicher identifiziert und im Klartext aus dem Chrome-Prozess ausgegeben.

Nach Abschluss sendet LUMMA die Cookies zusammen mit den anderen angeforderten Daten in mehreren Zip-Dateien (xor-verschlüsselt und base64-codiert) an den C2-Server.

Erkennung

Im Folgenden finden Sie die folgenden Verhaltenserkennungen, die verwendet werden können, um Techniken zu identifizieren, die von Informationsdieben verwendet werden:

• Zugriff auf Webbrowser-Anmeldeinformationen über einen ungewöhnlichen Prozess
• Zugriff auf Webbrowser-Anmeldeinformationen über einen nicht signierten Prozess
• Zugriff auf Browser-Anmeldeinformationen aus verdächtigem Speicher
• Fehlgeschlagener Zugriffsversuch auf Webbrowser-Dateien
• Browser-Debugging von ungewöhnlichem übergeordneten Element
• Potenzielle Erkennung von Browserinformationen

Darüber hinaus können die folgenden Abfragen für die Suche nach verschiedenen verwandten abnormalen Verhaltensweisen verwendet werden:

Zugriff auf Cookies durch ein ungewöhnliches Verfahren

Diese Abfrage verwendet Ereignisse zum Öffnen von Dateien und aggregierte Zugriffe nach Prozessen und sucht dann nach Ereignissen, die auf eindeutigen Hosts und mit einer geringen Gesamtzugriffsanzahl beobachtet werden:

FROM logs-endpoint.events.file-default*
| where event.category == "file" and event.action == "open" and file.name == "Cookies" and file.path like "*Chrome*"
| keep file.path, process.executable, agent.id
| eval process_path = replace(to_lower(process.executable), """c:\\users\\[a-zA-Z0-9\.\-\_\$]+\\""", "c:\\\\users\\\\user\\\\")
| stats agents_count = COUNT_DISTINCT(agent.id), access_count= count(*) by process_path
| where agents_count <= 2 and access_count <=2

Unten sehen Sie ein Beispiel für Übereinstimmungen von verschiedenen Informationsdiebstählen, einschließlich der aktualisierten mit neuen Funktionen zum Stehlen von Chrome-Cookies:

Das METASTEALER-Verhalten neigt dazu, zuerst alle ausgeführten Chrome-Instanzen zu beenden und dannCoCreateInstance aufzurufen, um den Google Chrome-Höhendienst zu instanziieren. Diese Reihe von Ereignissen kann mit der folgenden EQL-Abfrage ausgedrückt werden:

sequence by host.id with maxspan=1s
[process where event.action == "end" and process.name == "chrome.exe"] with runs=5
[process where event.action == "start" and process.name == "elevation_service.exe"]

Die vorherige Suche zeigt verdächtige Agents an, identifiziert jedoch nicht den Quellprozess. Durch Aktivieren der Überwachung des Zugriffs auf Registrierungsobjekte über das Ereignis 4663 für die CLSID-Registrierungsschlüssel {708860E0-F641-4611-8895-7D867DD3675B}des Chrome Elevation-Diensts können wir ungewöhnliche Prozesse erkennen, die versuchen, auf diesen Schlüssel zuzugreifen:

FROM logs-system.security-default* | where event.code == "4663" and winlog.event_data.ObjectName == "\\REGISTRY\\MACHINE\\SOFTWARE\\Classes\\CLSID\\{708860E0-F641-4611-8895-7D867DD3675B}" and not winlog.event_data.ProcessName in ("C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe", "C:\\Program Files (x86)\\Google\\Chrome\\Application\\chrome.exe") and not winlog.event_data.ProcessName like "C:\\\\Program Files\\\\Google\\\\Chrome\\\\Application\\\\*\\\\elevation_service.exe" | stats agents_count = COUNT_DISTINCT(agent.id), access_count= count(*) by winlog.event_data.ProcessName | where agents_count <= 2 and access_count <=2

Nachfolgend finden Sie ein Beispiel für Übereinstimmungen mit der METASTEALER-Malware beim Aufrufen von CoCreateInstance (CLSID_Elevator):

Der PHEMEDRONE-Stealer verwendet die bekannte Browser-Debugging-Methode, um Cookies über die Chromium-API zu sammeln, dies ist im folgenden Screenshot zu sehen, in dem wir eine Instanz von NodeJs sehen können, die mit einer Browserinstanz kommuniziert, bei der das Debugging über Port 9222aktiviert ist:

Die folgende EQL-Abfrage kann verwendet werden, um nach ungewöhnlichen Prozessen zu suchen, die ein ähnliches Verhalten ausführen:

sequence by host.id, destination.port with maxspan=5s
[network where event.action == "disconnect_received" and
 network.direction == "ingress" and
 process.executable in~ ("C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe",
"C:\\Program Files\\Microsoft\\Edge\\Application\\msedge.exe") and
 source.address like "127.*" and destination.address like "127.*"]
[network where event.action == "disconnect_received" and network.direction == "egress" and not
 process.executable in~ ("C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe",
"C:\\Program Files\\Microsoft\\Edge\\Application\\msedge.exe") and source.address like "127.*" and destination.address like "127.*"]

Der Chrome-Browser wurde von einem ungewöhnlichen Elternteil hervorgebracht

Das STEALC-Beispiel, das die ChromeKatz-Implementierung verwendet, erzeugt eine Instanz von Google Chrome, um das Standardprofil des Benutzers zu laden, während sich bei der Suche nach normalen übergeordneten ausführbaren Dateien herausstellt, dass es auf Chrome-signierte Eltern und Explorer.exe beschränkt ist. die folgenden ES|Die QL-Abfrage kann verwendet werden, um ungewöhnliche Eltern zu finden:

FROM logs-endpoint.events.process-*
| where event.category == "process" and event.type == "start" and to_lower(process.name) == "chrome.exe" and process.command_line like  "*--profile-directory=Default*"
| eval process_parent_path = replace(to_lower(process.parent.executable), """c:\\users\\[a-zA-Z0-9\.\-\_\$]+\\""", "c:\\\\users\\\\user\\\\")
| stats agents_count = COUNT_DISTINCT(agent.id), total_executions = count(*) by process_parent_path
| where agents_count == 1 and total_executions <= 10

Nicht vertrauenswürdige Binärdateien aus dem Chrome-Anwendungsordner

Da der Chrome-Dienst für erhöhte Rechte Binärdateien vertraut , die aus dem Chrome program files -Ordner ausgeführt werden, können die folgenden Abfragen verwendet werden, um nach nicht signierten oder nicht vertrauenswürdigen Binärdateien zu suchen, die von dort ausgeführt oder geladen werden:

Nicht signierte DLLs, die aus dem Google Chrome-Anwendungsordner geladen wurden

FROM logs-endpoint.events.library*
| where event.category == "library" and event.action == "load" and to_lower(dll.path) like "c:\\\\program files\\\\google\\\\chrome\\\\application\\\\*" and not (dll.code_signature.trusted == true)
| keep process.executable, dll.path, dll.hash.sha256, agent.id
| stats agents_count = COUNT_DISTINCT(agent.id), total_executions = count(*) by process.executable, dll.path, dll.hash.sha256
| where agents_count == 1 and total_executions <= 10

Nicht signierte ausführbare Datei, die aus dem Google Chrome-Anwendungsordner gestartet wurde

FROM logs-endpoint.events.process*
| where event.category == "library" and event.type == "start" and (to_lower(process.executable) like "c:\\\\program files\\\\google\\\\chrome\\\\application\\\\*" or to_lower(process.executable) like "c:\\\\scoped_dir\\\\program files\\\\google\\\\chrome\\\\application\\\\*")
and not (process.code_signature.trusted == true and process.code_signature.subject_name == "Goole LLC")
| keep process.executable,process.hash.sha256, agent.id
| stats agents_count = COUNT_DISTINCT(agent.id), total_executions = count(*) by process.executable, process.hash.sha256
| where agents_count == 1 and total_executions <= 10

Fazit

Google hat die Messlatte für die Implementierung neuer Sicherheitskontrollen zum Schutz von Cookie-Daten in Chrome höher gelegt. Erwartungsgemäß hat dies dazu geführt, dass Malware-Entwickler ihre eigenen Bypässe entwickeln oder integrieren. Wir hoffen, dass Google weiterhin innovativ sein wird, um Nutzerdaten besser zu schützen.

Organisationen und Verteidiger sollten konsequent auf ungewöhnliche Endpunktaktivitäten überwachen. Diese neuen Techniken können zwar erfolgreich sein, sind aber auch verrauscht und mit den richtigen Sicherheitsinstrumenten, Prozessen und Mitarbeitern erkennbar.

Stealer Bypässe und MITRE ATT&CK

Elastic verwendet das MITRE ATT&CK-Framework , um gängige Taktiken, Techniken und Verfahren zu dokumentieren, die Bedrohungen gegen Unternehmensnetzwerke einsetzen.

Taktiken

Taktiken stellen das Warum einer Technik oder Untertechnik dar. Es ist das taktische Ziel des Gegners: der Grund für die Ausführung einer Aktion.

• Zugriff mit Anmeldeinformationen
• Tarnung
• Discovery
• Ausführung

Techniken

Techniken stellen dar, wie ein Angreifer ein taktisches Ziel erreicht, indem er eine Aktion ausführt.

• Web-Session-Cookie stehlen
• Prozessinjektion
• Anmeldeinformationen aus Passwortspeichern
• Erkennung von Systeminformationen
• Prozess-Erkennung
• Interprozesskommunikation: Komponenten-Objektmodell

YARA

Elastic Security hat YARA-Regeln erstellt, um diese Aktivität zu identifizieren.

• Windows.Trojan.Stealc
• Windows.Infostealer.PhemedroneStealer
• Windows.Trojan.MetaStealer
• Windows.Trojan.Xeno
• Windows.Trojan.Lumma
• Windows.Infostealer.Generic

Beobachtungen

Alle Observables stehen auch im ECS- und STIX-Format zum Download zur Verfügung.

Die folgenden Observablen wurden in dieser Studie diskutiert.

Referenzen

In der obigen Studie wurde auf Folgendes Bezug genommen:

• https://developer.chrome.com/release-notes/127
• https://security.googleblog.com/2024/07/improving-security-of-chrome-cookies-on.html