Gestion des Identités (Entra ID)

Phishing AiTM : contournement MFA Entra ID — Akuity SOC

5 min de lecture Akuity SOC · Delphisoft Deutschland

Comprenez comment le phishing AiTM vole vos cookies ESTSAUTH malgré Microsoft Authenticator, et détectez le rejeu de session Entra ID via Advanced Hunting (KQL).

Penser que l'authentification multifacteur (MFA) par notification push bloque 99 % des attaques d'identité est devenu le piège stratégique n°1 des RSSI. Face aux attaques Adversary-in-the-Middle (AiTM), l'attaquant ne cherche plus à craquer ou contourner votre second facteur : il demande poliment à l'utilisateur de le valider pour lui.

L'illusion du push mobile et le détournement de session ESTSAUTH

L'architecture d'attaque AiTM (déployée via des frameworks comme Evilginx ou Muraena) repose sur un proxy inverse positionné directement entre le navigateur de la victime et la mire d'authentification légitime de Microsoft Entra ID. Deux sessions TLS étanches sont établies en parallèle : Victime ↔ Proxy et Proxy ↔ login.microsoftonline.com.

Lorsque la victime renseigne son mot de passe et approuve la notification sur Microsoft Authenticator, le flux d'authentification s'exécute sans friction. Microsoft Entra ID valide le challenge et émet en réponse les en-têtes HTTP Set-Cookie contenant les jetons de session critiques : ESTSAUTH et ESTSAUTHPERSISTENT. Le proxy inverse intercepte ces cookies en clair avant de relayer la requête. En moins de deux secondes, l'attaquant injecte ces jetons dans son propre navigateur, dérivant la session active sans jamais déclencher de nouvelle invite MFA, contournant ainsi les politiques de Conditional Access qui ne contraignent pas la conformité de l'appareil (device compliance) ou la liaison cryptographique (FIDO2 / WebAuthn).

L'angle mort natif d'Entra ID et l'échec du triage manuel

Dans la console native de Microsoft Entra ID, l'événement apparaît sous le code statut 0 (Success) : single-factor authentication suivi de « MFA requirement satisfied ». L'intrusion se noie parmi des milliers d'authentifications légitimes.

Pour qualifier ce vol de session, l'analyste SOC doit corréler manuellement dans les Sign-in Logs l'adresse IP source, les empreintes User-Agent, l'ASN et le SessionId. Ce processus d'investigation génère un MTTR moyen de 18 minutes. Pire encore : sous la pression opérationnelle, de nombreux analystes exportent les URL ou payloads vers des décodeurs web publics non sécurisés (type CyberChef en ligne), provoquant des fuites de jetons d'entreprise hors du périmètre sécurisé.

Détection chirurgicale : traquer le SessionId compromis via Advanced Hunting (KQL)

Pour neutraliser ce délai critique, l'analyste doit chasser directement le fork de transport TLS via Advanced Hunting (KQL). Dès que le pirate rejoue le cookie volé, une divergence immédiate d'adresse IP et d'User-Agent apparaît sur le même identifiant de session invariant :

let Lookback = 2h;
AADSignInEventsBeta
| where Timestamp > ago(Lookback) and ErrorCode == 0 and isnotempty(SessionId)
| summarize 
    IPCount = dcount(IPAddress),
    IPList = make_set(IPAddress, 3),
    UserAgents = make_set(UserAgent, 3),
    CountryList = make_set(Country, 3),
    FirstSeen = min(Timestamp),
    LastSeen = max(Timestamp)
    by SessionId, AccountUpn
| where IPCount > 1
| extend TimeDeltaSec = datetime_diff('second', LastSeen, FirstSeen)
| where TimeDeltaSec <= 1800
| project SessionId, AccountUpn, TimeDeltaSec, IPCount, IPList, CountryList, UserAgents
| sort by TimeDeltaSec asc

Recommandation de tuning : Excluez les adresses IP de sortie de vos proxys d'entreprise ou passerelles SASE/CASB légitimes pour isoler exclusivement les divergences géographiques ou d'ASN survenues dans une fenêtre inférieure à 30 minutes.

Neutralisation SOAR Akuity SOC en moins d'une seconde

Akuity SOC élimine les 18 minutes d'investigation manuelle et supprime tout risque de fuite tierce. Depuis le Ticket Panel unifié, l'assistant IA in-app déclenche le Function Call execute_advanced_hunting_kql en tâche de fond pour isoler le fork de session en moins de 2 secondes, désobfusquant les artefacts sans exposition externe.

La remédiation s'opère ensuite en 1 clic : l'analyste déclenche simultanément l'action revokeSessions() pour invalider immédiatement l'ensemble des refresh tokens et cookies ESTSAUTH rejoués, couplée à confirmUserCompromised() pour placer le compte en niveau de risque élevé dans Microsoft Entra ID. Cette riposte SOAR exige une élévation MFA AAL2 obligatoire de l'analyste et s'inscrit dans un journal d'audit immuable certifié NIS 2 et SOC 2 Type II.

Questions fréquentes

Pourquoi Conditional Access ne bloque-t-il pas automatiquement le rejeu de session AiTM ?

Si la stratégie de Conditional Access se limite à exiger un MFA standard sans imposer un appareil conforme (Intune) ou une résistance stricte au phishing (clés de sécurité FIDO2 / Windows Hello), le jeton ESTSAUTH validé est considéré comme pleinement légitime par Entra ID lors de son injection depuis un autre navigateur.

Quelle est la différence entre la révocation de session globale et la réinitialisation de mot de passe ?

Une simple réinitialisation de mot de passe ne révoque pas immédiatement les cookies de session actifs. La commande de révocation SOAR force l'invalidation cryptographique instantanée des jetons d'accès et de rafraîchissement (PRT), expulsant l'attaquant en moins d'une seconde sans attendre l'expiration naturelle du cookie.

Prêt à neutraliser les attaques AiTM en 1 clic ? Connectez Akuity SOC à votre tenant Microsoft Entra ID en moins de 10 minutes. Démarrez votre essai gratuit de 14 jours (sans CB) ou testez notre simulateur d'efficacité SOC.

Page Solution Associée

Gestion des Identités à Risque (Entra ID)

Bloquez les compromissions instantanément avec l'orchestration SOAR sans agent d'Akuity SOC.

Découvrir la solution complète