Introduction

En juillet, Google a annoncé un nouveau mécanisme de protection pour les cookies stockés dans Chrome sur Windows, connu sous le nom de Application-Bound Encryption. Il ne fait aucun doute que cette mise en œuvre de la sécurité a placé la barre plus haut et a eu un impact direct sur l'écosystème des logiciels malveillants. Après des mois d'utilisation de cette nouvelle fonctionnalité, de nombreux voleurs d'informations ont écrit un nouveau code pour contourner cette protection (comme l'avait prédit l'équipe de sécurité de Chrome) afin de rester compétitifs sur le marché et de proposer des fonctionnalités permettant de récupérer de manière fiable les données des cookies des navigateurs Chrome.

Elastic Security Labs a suivi un sous-ensemble de cette activité, identifiant plusieurs techniques utilisées par différentes familles de logiciels malveillants pour contourner l'App-Bound Encryption. Bien que l'écosystème continue d'évoluer à la lumière de cette pression, notre objectif est de partager des détails techniques qui aident les organisations à comprendre et à se défendre contre ces techniques. Dans cet article, nous aborderons les différentes méthodes utilisées par les familles de voleurs d'informations suivantes :

• STEALC/VIDAR
• METASTEALER
• PHEMEDRONE
• XENOSTEALER
• LUMMA

Principaux points abordés dans cet article

• Les dernières versions des voleurs d'informations contournent la récente fonction de protection des cookies de Google en utilisant l'Application-Bound Encryption (cryptage lié aux applications).
• Les techniques comprennent l'intégration de l'outil de sécurité offensive ChromeKatz, l'utilisation de COM pour interagir avec les services Chrome et décrypter la clé de cryptage liée à l'application, et l'utilisation de la fonction de débogage à distance dans Chrome.
• Les défenseurs doivent surveiller activement les différentes techniques de contournement des cookies contre Chrome sur Windows en prévision des futures mesures d'atténuation et de contournement susceptibles d'apparaître à court ou moyen terme.
• Elastic Security fournit des mesures d'atténuation par le biais de signatures de mémoire, de règles comportementales et de possibilités de chasse pour permettre une identification et une réponse plus rapides à l'activité des voleurs d'informations.

Arrière-plan

D'une manière générale, les cookies sont utilisés par les applications web pour stocker des informations sur le visiteur dans le navigateur qu'il utilise pour accéder à l'application web. Ces informations permettent à l'application web de suivre l'utilisateur, ses préférences et d'autres informations d'un endroit à l'autre, et même d'un appareil à l'autre.

Le jeton d'authentification est l'une des utilisations des structures de stockage de données côté client qui permettent une grande partie du fonctionnement de l'interactivité web moderne. Ces jetons sont stockés par le navigateur une fois que l'utilisateur s'est authentifié avec succès auprès d'une application web. Après le nom d'utilisateur et le mot de passe, après l'authentification multifactorielle (AMF) via des codes de passe à usage unique ou des données biométriques, l'application web "se souvient" que votre navigateur est vous via l'échange de ce jeton lors de chaque requête web ultérieure.

Un acteur malveillant qui accède à un jeton d'authentification valide peut le réutiliser pour se faire passer pour l'utilisateur de ce service web, ce qui lui permet de s'approprier des comptes, de voler des informations personnelles ou financières ou d'effectuer d'autres actions en tant qu'utilisateur, comme le transfert d'actifs financiers.

Les cybercriminels utilisent des "infostealers" pour voler et commercialiser ce type d'informations à des fins lucratives.

Sécurité des cookies dans Google Chrome

Les anciennes versions de Google Chrome sur Windows utilisaient l'API de protection des données native de Windows (DPAPI) pour chiffrer les cookies et les protéger des autres contextes d'utilisation. Cela a permis d'assurer une protection adéquate contre plusieurs scénarios d'attaque, mais tout logiciel malveillant fonctionnant dans le contexte de l'utilisateur ciblé pourrait décrypter ces cookies en utilisant directement les méthodes de l'interface DPAPI. Malheureusement, ce contexte est exactement le créneau dans lequel les voleurs d'informations se retrouvent souvent après avoir utilisé l'ingénierie sociale pour obtenir un accès initial. Le système DPAPI est désormais bien connu des attaquants qui disposent de plusieurs vecteurs d'attaque : décryptage local à l'aide de l'API, vol de la clé maîtresse et décryptage à distance, utilisation abusive de la clé DPAPI de secours à l'échelle du domaine dans un environnement d'entreprise.

Avec la sortie de Chrome 127 en juillet 2024, Google a mis en place le chiffrement des données du navigateur en fonction de l'application (Application-Bound Encryption). Ce mécanisme s'attaque directement à de nombreuses attaques DPAPI courantes contre les données du navigateur Windows Chrome, y compris les cookies. Pour ce faire, il stocke les données dans des fichiers cryptés et utilise un service fonctionnant en tant que SYSTEM pour vérifier que les tentatives de décryptage proviennent du processus Chrome avant de renvoyer la clé à ce processus pour le décryptage des données stockées.

Bien que nous soyons d'avis que ce système de chiffrement n'est pas la panacée pour protéger toutes les données du navigateur (comme le reconnaît l'équipe de sécurité de Chrome dans son communiqué), nous pensons qu'il a réussi à pousser les auteurs de logiciels malveillants vers des TTP qui sont plus ouvertement malveillants et plus faciles à identifier et à combattre pour les défenseurs de l'environnement.

Résumé des techniques de contournement des voleurs

Les sections suivantes décrivent les techniques spécifiques utilisées par les voleurs d'informations pour contourner la fonction App-Bound Encryption de Google, telles qu'elles ont été observées par Elastic. Bien qu'il ne s'agisse pas d'une compilation exhaustive des contournements, et que le développement de ces familles soit en cours, elles représentent une dynamique intéressante dans l'espace des voleurs d'informations, montrant comment les développeurs de logiciels malveillants ont réagi à la récente mise à jour du contrôle de sécurité de Google. Les techniques observées par notre équipe comprennent

• Débogage à distance via le protocole DevTools de Chrome
• Lecture de la mémoire du processus du service réseau Chrome (ChromeKatz et ReadProcessMemory (RPM))
• Passage à SYSTEM puis décryptage de app_bound_encryption_key avec la méthode DecryptData de GoogleChromeElevationService par COM

STEALC/VIDAR

Notre équipe a observé un nouveau code introduit dans STEALC/VIDAR lié à la technique de contournement des cookies autour du 20 septembre. Il s'agit d'échantillons atypiques qui se distinguent des versions précédentes et qui ont été mis en œuvre sous forme de fichiers PE 64 bits intégrés avec des vérifications conditionnelles. Les valeurs chiffrées dans les bases de données SQLite où Chrome stocke ses données sont désormais préfixées par v20, ce qui indique que les valeurs sont désormais chiffrées à l'aide d'un chiffrement lié à l'application.

STEALC a été introduit en 2023 et a été développé en s'inspirant fortement d'autres voleurs plus connus tels que RACOON et VIDAR. STEALC et VIDAR ont poursuivi leur développement en parallèle et, dans le cas des contournements du chiffrement lié à l'application, ont adopté la même mise en œuvre.

Lors de l'extraction des données cryptées des bases de données, le logiciel malveillant vérifie la présence de ce préfixe. S'il commence par v20, un processus enfant est créé à l'aide du fichier PE intégré dans la section .data du binaire. Ce programme est chargé d'extraire les valeurs non chiffrées des cookies résidant dans l'un des processus enfants de Chrome.

Ce binaire intégré crée un bureau caché via OpenDesktopA / CreateDesktopA puis utilise CreateToolhelp32Snapshot pour analyser et terminer tous les processus chrome.exe. Un nouveau processus chrome.exe est alors lancé avec le nouvel objet de bureau. En fonction de la version installée de Chrome, le logiciel malveillant sélectionne un modèle de signature pour la fonctionnalité CookieMonster de Chromium, un composant interne utilisé pour gérer les cookies.

Nous avons utilisé les signatures pour accéder au code existant développé pour un outil de sécurité offensif appelé ChromeKatz. À l'heure actuelle, les modèles ont été retirés du référentiel ChromeKatz et remplacés par une nouvelle technique. D'après notre analyse, l'auteur du logiciel malveillant semble avoir réimplémenté ChromeKatz dans STEALC afin de contourner la fonction de protection par chiffrement liée à l'application.

Une fois que le logiciel malveillant a identifié une signature correspondante, il énumère les processus enfants de Chrome pour vérifier la présence de l'indicateur de ligne de commande --utility-sub-type=network.mojom.NetworkService. Ce drapeau indique que le processus est le service réseau responsable de la gestion de toutes les communications internet. Il devient une cible privilégiée car il contient les données sensibles recherchées par l'attaquant, comme le décrit l'article de MDSec. Il renvoie ensuite une poignée pour ce processus enfant spécifique.

Ensuite, il énumère chaque module dans le processus enfant du service réseau pour trouver et récupérer l'adresse de base et la taille de chrome.dll chargé en mémoire. STEALC utilise CredentialKatz::FindDllPattern et CookieKatz::FindPattern pour localiser les instances de CookieMonster. Il y a 2 appels à CredentialKatz::FindDllPattern.

Lors du premier appel à CredentialKatz::FindDllPattern, il tente de localiser l'un des modèles de signature (en fonction de la version de Chrome de la victime) dans chrome.dll. Une fois trouvé, STEALC dispose maintenant d'un pointeur de référence vers l'emplacement de mémoire où commence la séquence d'octets, c'est-à-dire la fonction net::CookieMonster::~CookieMonster, destructeur de la classe CookieMonster.

Le deuxième appel à CredentialKatz::FindDllPattern transmet l'adresse de la fonction net::CookieMonster::~CookieMonster(void) comme argument pour la recherche de la séquence d'octets, ce qui permet à STEALC d'avoir un pointeur sur la structure Virtual Function Pointer de CookieMonster.

La méthode suivante utilisée par STEALC est à nouveau identique à celle de ChromeKatz, où il localise les instances CookieMonster en recherchant dans les morceaux de mémoire du module chrome.dll les pointeurs référençant la table virtuelle CookieMonster. Étant donné que la table virtuelle est une constante pour tous les objets d'une classe donnée, tout objet CookieMonster aura le même pointeur de table virtuelle. Lorsqu'une correspondance est identifiée, STEALC traite l'emplacement mémoire comme une instance CookieMonster et stocke son adresse dans un tableau.

Pour chaque instance CookieMonster identifiée, STEALC accède à la structure interne CookieMap située à un décalage de +0x30 et qui est un arbre binaire. Chaque nœud de cet arbre contient des pointeurs vers des structures CanonicalCookieChrome. Les structures CanonicalCookieChrome contiennent des données de cookies non cryptées, ce qui les rend accessibles à l'extraction. STEALC entame alors une traversée de l'arbre en passant le premier nœud dans une fonction de traversée dédiée.

Pour chaque nœud, il appelle ReadProcessMemory pour accéder à la structure CanonicalCookieChrome de la mémoire du processus cible, puis la traite dans jy::GenerateExfilString.

STEALC formate les données extraites des cookies en convertissant la date d'expiration au format UNIX et en vérifiant la présence des drapeaux HttpOnly et Secure. Il ajoute ensuite des détails tels que le nom, la valeur, le domaine et le chemin du cookie, ainsi que les HttpOnly et Secure, dans une chaîne finale destinée à être exfiltrée. Les structures OptimizedString sont utilisées à la place des chaînes, de sorte que les valeurs des chaînes peuvent être soit la chaîne elle-même, soit, si la longueur de la chaîne est supérieure à 23, l'adresse de stockage de la chaîne.

METASTEALER

METASTEALER, observé pour la première fois en 2022, a récemment amélioré sa capacité à voler les données de Chrome, en contournant les derniers efforts d'atténuation de Google. Le 30 septembre, les auteurs du malware ont annoncé cette mise à jour via leur chaîne Telegram, en soulignant sa capacité accrue à extraire des informations sensibles, y compris des cookies, malgré les changements de sécurité dans la version de Chrome 129+.

Le premier échantillon observé dans la nature par notre équipe a été découvert le 30 septembre, le jour même où les auteurs ont fait la promotion de la mise à jour. Malgré les affirmations selon lesquelles le logiciel malveillant fonctionne sans nécessiter de privilèges Administrator, nos tests ont révélé qu'il nécessite un accès élevé, car il tente de se faire passer pour le jeton SYSTEM pendant l'exécution.

Comme le montrent les captures d'écran ci-dessus, la méthode get_decryption comprend désormais un nouveau paramètre booléen. Cette valeur est fixée à TRUE si les données cryptées (cookie) commencent par le préfixe v20, ce qui indique que le cookie est crypté à l'aide de la dernière méthode de cryptage de Chrome. La fonction mise à jour conserve une compatibilité ascendante et permet toujours de décrypter les cookies des anciennes versions de Chrome s'ils sont présents sur la machine infectée.

Le logiciel malveillant tente ensuite d'accéder aux fichiers Local State ou LocalPrefs.json situés dans le répertoire du profil Chrome. Les deux fichiers sont au format JSON et contiennent les clés de chiffrement (encrypted_key) pour les anciennes versions de Chrome et app_bound_encrypted_key pour les plus récentes. Si l'indicateur est réglé sur TRUE, le logiciel malveillant utilise spécifiquement app_bound_encrypted_key pour déchiffrer les cookies conformément à la méthode de chiffrement actualisée de Chrome.

Dans ce cas, le logiciel malveillant commence par se faire passer pour le jeton SYSTEM en utilisant une classe nouvellement introduite appelée ContextSwitcher.

Il déchiffre ensuite la clé en créant une instance via le COM du service Chrome responsable du déchiffrement, nommé GoogleChromeElevationService, en utilisant le CLSID 708860E0-F641-4611-8895-7D867DD3675B. Une fois initialisé, il invoque la méthode DecryptData pour déchiffrer la clé app_bound_encrypted_key qui sera utilisée pour déchiffrer les cookies chiffrés.

METASTEALER utilise une technique similaire à celle démontrée dans un gist partagé sur X le 27 septembre, qui a pu servir d'inspiration aux auteurs du malware. Les deux approches s'appuient sur des méthodes similaires pour contourner les mécanismes de chiffrement de Chrome et extraire des données sensibles.

PHEMEDRONE

Ce voleur de code source ouvert a attiré l'attention du monde entier au début de l'année en exploitant une vulnérabilité de Windows SmartScreen (CVE-2023-36025). Alors que son développement se poursuit sur Telegram, notre équipe a trouvé une version récente (2.3.2) soumise à la fin du mois de septembre qui inclut une nouvelle fonctionnalité de capture des cookies pour Chrome.

Le logiciel malveillant commence par énumérer les différents profils au sein de Chrome, puis effectue une vérification du navigateur à l'aide de la fonction (BrowserHelpers.NewEncryption) en recherchant le navigateur Chrome dont la version est supérieure ou égale à 127.

Si la condition est remplie, PHEMEDRONE utilise une combinaison de fonctions d'aide pour extraire les cookies.

En visualisant la classe ChromeDevToolsWrapper et ses différentes fonctions, on constate que PHEMEDRONE met en place une session de débogage à distance dans Chrome pour accéder aux cookies. Le port par défaut (9222) est utilisé et la position de la fenêtre est réglée sur -2400,-2400, ce qui empêche toute fenêtre visible d'alerter la victime.

Ensuite, le logiciel malveillant établit une connexion WebSocket à l'interface de débogage de Chrome en formulant une demande à l'aide de la méthode Chrome DevTools Protocol (Network.getAllCookies), qui est obsolète.

Les cookies sont ensuite renvoyés en clair à partir de la requête précédente. Vous trouverez ci-dessous une capture de réseau montrant ce comportement :

XENOSTEALER

XENOSTEALER est un voleur d'informations open-source hébergé sur GitHub. Il a été publié en juillet 2024 et est en cours de développement au moment de la publication du présent document. Notamment, la fonction de contournement de Chrome a été mise en place le 26, 2024 septembre.

L'approche adoptée par XENOSTEALER est similaire à celle de METASTEALER. Il analyse d'abord le fichier JSON sous un profil Chrome donné pour en extraire les app_bound_encrypted_key. Cependant, le processus de décryptage se déroule dans le cadre d'un processus Chrome. Pour ce faire, XENOSTEALER lance une instance de Chrome.exe, puis injecte du code à l'aide d'une classe d'aide appelée SharpInjector, en passant la clé cryptée en paramètre.

Le code injecté appelle ensuite la méthode DecryptData de la méthode GoogleChromeElevationService pour obtenir la clé déchiffrée.

LUMMA

À la mi-octobre, la dernière version de LUMMA a mis en œuvre une nouvelle méthode pour contourner la protection des cookies de Chrome, comme l'a signalé @g0njxa.

Nous avons analysé une version récente de LUMMA, confirmant qu'elle parvenait à récupérer les données des cookies de la dernière version de Google Chrome (130.0.6723.70). LUMMA crée d'abord un processus Chrome visible via Kernel32!CreateProcessW.

Cette activité a été suivie dans le débogueur par de multiples appels à NtReadVirtualMemory où nous avons identifié la recherche de LUMMA dans le processus Chrome pour chrome.dll.

Une fois trouvé, le logiciel malveillant copie l'image chrome.dll dans sa propre mémoire de processus en utilisant NtReadVirtualMemory. De manière similaire à la technique ChromeKatz, Lumma utilise l'analyse de modèles pour cibler le composant CookieMonster de Chrome.

Lumma utilise un modèle de signature obscurci pour identifier la fonctionnalité CookieMonster :

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

Vous trouverez ci-dessous la règle YARA après désobfuscation :

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
}

Après le décodage et la recherche du motif dans chrome.dll, on aboutit au destructeur de CookieMonster (net::CookieMonster::~CookieMonster).

Les cookies sont ensuite identifiés dans la mémoire et extraits en texte clair du processus Chrome.

Une fois l'opération terminée, LUMMA envoie les cookies ainsi que les autres données demandées sous la forme de plusieurs fichiers zip (cryptés xor et encodés base64) au serveur C2.

Détection

Les détections comportementales suivantes permettent d'identifier les techniques utilisées par les voleurs d'informations :

• Accès aux informations d'identification du navigateur Web par un processus inhabituel
• Accès aux informations d'identification du navigateur web via un processus non signé
• Access to Browser Credentials from Suspicious Memory
• Failed Access Attempt to Web Browser Files
• Débogage du navigateur à partir d'un parent inhabituel
• Découverte potentielle d'informations sur le navigateur

En outre, les requêtes suivantes peuvent être utilisées pour rechercher divers comportements anormaux :

Accès aux cookies par un procédé inhabituel

Cette requête utilise les événements d'ouverture de fichiers et les accès agrégés par processus, puis recherche ceux qui sont observés dans des hôtes uniques et dont le nombre total d'accès est faible :

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

Vous trouverez ci-dessous des exemples de correspondances entre divers voleurs d'informations, y compris ceux qui ont été mis à jour avec de nouvelles capacités de vol de cookies Chrome :

Le comportement de METASTEALER tend à mettre fin à toutes les instances de Chrome en cours d'exécution, puis à appeler CoCreateInstance pour instancier le service d'élévation de Google Chrome, cette série d'événements peut être exprimée à l'aide de la requête EQL suivante :

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"]

La chasse précédente indique des agents suspects mais n'identifie pas le processus source. En activant l'audit de l'accès aux objets du registre via l'événement 4663 sur la clé de registre CLSID du service d'élévation de Chrome {708860E0-F641-4611-8895-7D867DD3675B}, nous pouvons détecter les processus inhabituels qui tentent d'accéder à cette clé :

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

Vous trouverez ci-dessous un exemple de correspondance avec le logiciel malveillant METASTEALER lors de l'appel CoCreateInstance (CLSID_Elevator):

Le voleur de PHEMEDRONE utilise la méthode connue de débogage du navigateur pour collecter des cookies via l'API Chromium, comme le montre la capture d'écran suivante où l'on peut voir une instance de NodeJs communiquer avec une instance de navigateur dont le débogage est activé sur le port 9222:

La requête EQL suivante peut être utilisée pour rechercher des processus inhabituels ayant un comportement similaire :

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.*"]

Le navigateur Chrome est né d'un parent inhabituel

L'échantillon STEALC qui utilise l'implémentation de ChromeKatz génère une instance de Google Chrome pour charger le profil par défaut de l'utilisateur. En recherchant des exécutables parents normaux, il s'avère qu'il est limité aux parents signés Chrome et à Explorer.exe, la requête ES|QL suivante peut être utilisée pour trouver des parents inhabituels :

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

Binaires non fiables du dossier Application de Chrome

Étant donné que le service d'élévation de Chrome fait confiance aux binaires exécutés à partir du dossier Chrome program files, les requêtes suivantes peuvent être utilisées pour rechercher des binaires non signés ou non fiables exécutés ou chargés à partir de ce dossier :

DLL non signées chargées depuis le dossier d'application de Google Chrome

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

Exécutable non signé lancé depuis le dossier d'applications de google chrome

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

Conclusion

Google a relevé la barre en mettant en place de nouveaux contrôles de sécurité pour protéger les données des cookies dans Chrome. Comme on pouvait s'y attendre, cela a incité les développeurs de logiciels malveillants à mettre au point ou à intégrer leurs propres moyens de contournement. Nous espérons que Google continuera à innover pour mieux protéger les données des utilisateurs.

Les organisations et les défenseurs doivent surveiller en permanence les activités inhabituelles des terminaux. Si ces nouvelles techniques peuvent être efficaces, elles sont également bruyantes et détectables avec les instruments de sécurité, les processus et le personnel adéquats.

Contournement des voleurs et MITRE ATT&CK

Elastic utilise le cadre MITRE ATT& CK pour documenter les tactiques, techniques et procédures communes que les menaces utilisent contre les réseaux d'entreprise.

Tactiques

Les tactiques représentent le pourquoi d'une technique ou d'une sous-technique. Il s'agit de l'objectif tactique de l'adversaire : la raison pour laquelle il effectue une action.

• Accès aux identifiants
• Évasion par la défense
• Découverte
• Exécution

Techniques

Les techniques représentent la manière dont un adversaire atteint un objectif tactique en effectuant une action.

• Vol de cookie de session web
• Injection de processus
• Identifiants venant de magasins de mots de passe
• Recherche d'informations sur le système
• Découverte du processus
• Communication inter-processus : Modèle d'objet composant

YARA

Elastic Security a créé des règles YARA pour identifier cette activité.

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

Observations

Toutes les observables sont également disponibles au téléchargement dans les formats ECS et STIX.

Les observables suivants ont été examinés dans le cadre de cette recherche.

Références

Les éléments suivants ont été référencés tout au long de la recherche ci-dessus :

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