Voler une session authentifiée est plus précieux que voler un mot de passe — elle bypasse le MFA et donne un accès immédiat
Ce qu’il faut retenir
Un mot de passe volé seul ne suffit plus si le MFA est activé — l’attaquant doit encore franchir le second facteur. Un cookie de session volé court-circuite tout le processus d’authentification : il prouve que l’utilisateur a déjà satisfait le MFA, et les services acceptent cette preuve sans demander autre chose.
Les cookies de session Azure (ESTSAUTHPERSISTENT) peuvent rester valides jusqu’à 90 jours. Un Google Refresh Token ne expire pas tant qu’il n’est pas révoqué. La valeur d’un cookie de session dépasse celle d’un mot de passe : elle est immédiatement exploitable, sans friction, et souvent valide bien plus longtemps que prévu.
C’est pour cette raison que les infostealers modernes ciblent les cookies de session en priorité, et que les marchés darknet les vendent séparément des credentials.
Illustrations
Cas 1 : Storm infostealer — cookie restore automatisé (2026)
Ce qui s’est passé : Storm automatise la restauration de session via un panel dédié : l’opérateur fournit un Google Refresh Token et un proxy SOCKS5 géolocalisé, et le panel restaure silencieusement la session authentifiée de la victime. Pas de challenge MFA, pas de mot de passe requis.
Pourquoi c’est arrivé : Les cookies de session sont la preuve que le MFA a déjà été satisfait. Les services (Google, Microsoft, GitHub…) font confiance à cette preuve sans ré-authentifier.
Conséquences : Un seul navigateur compromis suffit à donner accès à tous les services SaaS de la victime. Les logs d’authentification ne montrent pas de nouvelle authentification — la session existante est simplement réutilisée.
Cas 2 : Cookie-Bite — Azure ESTSAUTH/ESTSAUTHPERSISTENT (2025)
Ce qui s’est passé : Varonis Threat Labs a démontré qu’un attaquant ayant volé les cookies ESTSAUTH et ESTSAUTHPERSISTENT d’Azure Entra ID peut accéder à M365, Teams, Azure Portal et aux applications enterprise associées — sans mot de passe, sans MFA. ESTSAUTHPERSISTENT reste valide jusqu’à 90 jours si l’utilisateur a choisi “Rester connecté”.
Pourquoi c’est arrivé : Azure Entra ID traite la présence de ce cookie comme une preuve que “cet utilisateur a déjà fait son MFA sur ce navigateur”. En rejouant ce cookie depuis un autre navigateur avec les bons attributs (OS, version, géolocalisation), l’attaquant hérite de cette confiance.
Conséquences : Accès persistant à toute l’infrastructure M365 d’une organisation. Post-exploitation possible : énumération via Graph API, accès emails, déplacement latéral, escalade de privilèges.
Cas 3 : SessionShark — AiTM phishing kit M365 (2025)
Ce qui s’est passé : SessionShark est un kit de phishing adversary-in-the-middle vendu en SaaS qui intercepte les tokens de session M365 en temps réel pendant l’authentification. L’attaquant reçoit le cookie de session par Telegram en quelques secondes après que la victime a saisi ses credentials ET son code MFA.
Pourquoi c’est arrivé : Le proxy AiTM se positionne entre la victime et Microsoft. Il laisse passer l’authentification complète (credentials + MFA), capture le cookie de session résultant, et le transmet à l’attaquant.
Conséquences : Le MFA a été satisfait par la victime réelle — l’attaquant récupère le cookie post-MFA. Le MFA ne protège plus rien dès lors que la session elle-même est compromise.
Articles liés
- The silent Storm — BleepingComputer — angle : Storm + cookie restore automatisé
- Cookie-Bite — Varonis Threat Labs — angle : analyse technique complète Azure ESTSAUTH, PoC, post-exploitation
- SessionShark — Varonis Threat Labs — angle : phishing kit AiTM, bypass MFA M365 en temps réel
Principes liés
- Le MFA ne protège pas les sessions déjà actives — seule leur révocation contient une compromission en cours
- Un navigateur compromis donne accès à tous les services où l’utilisateur est authentifié sans avoir besoin d’un seul mot de passe
- Les infostealers modernes exfiltrent les données chiffrées pour les déchiffrer côté serveur, rendant la détection endpoint aveugle