Identité Azure : Quand MFA Ne Suffit Pas

Qu'est-ce que la Sécurité des Identités Azure ?

Azure Entra ID est le backbone d'identité pour Microsoft 365, Azure et des milliers d'applications SaaS. Quand les contrôles d'identité sont mal configurés, les attaquants peuvent contourner le MFA, escalader les privilèges et prendre le contrôle d'environnements cloud avec rien de plus qu'un mot de passe volé.

Les deux mauvaises configurations d'identité Azure les plus critiques sont le MFA non appliqué pour les administrateurs et les Security Defaults désactivés. Les deux représentent un échec fondamental de la première ligne de défense — trivialement exploitables avec des kits de phishing disponibles.

Comment ca Fonctionne

La sécurité des identités Azure repose sur deux contrôles fondamentaux :

MFA (Authentification Multifacteur) exige un second facteur — application mobile, clé FIDO2, SMS — en plus du mot de passe. Même si un attaquant obtient un mot de passe via phishing, le MFA empêche l'authentification sans le second facteur.

Security Defaults sont les paramètres de sécurité de base de Microsoft pour les tenants Entra ID — un ensemble préconfiguré de politiques qui activent le MFA pour les admins, bloquent l'authentification legacy et exigent le MFA pour les connexions risquées. Ils sont gratuits, activés en un seul clic.

Quand aucun des deux n'est configuré, tout compte admin est à un email de phishing d'une compromission totale.

La Chaine d'Attaque

Etape 1 - Identifier les Comptes Admin Sans MFA

Connect-MgGraph -Scopes "Directory.Read.All", "UserAuthenticationMethod.Read.All"

$adminRoleIds = (Get-MgDirectoryRole | Where-Object DisplayName -match "Admin").Id
foreach ($roleId in $adminRoleIds) {
    Get-MgDirectoryRoleMember -DirectoryRoleId $roleId | ForEach-Object {
        $methods = Get-MgUserAuthenticationMethod -UserId $_.Id
        if ($methods.Count -le 1) {
            [PSCustomObject]@{
                Utilisateur = $_.AdditionalProperties.userPrincipalName
                MethodesMFA = $methods.Count
            }
        }
    }
}

Etape 2 - Phishing du Compte Admin

Les attaquants utilisent des proxies de phishing adversary-in-the-middle (AiTM) comme Evilginx2 pour intercepter non seulement le mot de passe mais aussi le cookie de session — contournant même les comptes protégés par MFA.

Etape 3 - Authentification en tant qu'Admin

# Utilisation du cookie de session volé — contourne entièrement le MFA
curl -H "Authorization: Bearer {token_vole}" https://graph.microsoft.com/v1.0/me

Etape 4 - Etablir une Persistance

New-MgUser -DisplayName "Support IT" -UserPrincipalName "[email protected]" `
    -PasswordProfile @{Password="BackdoorP@ss123!"} -AccountEnabled $true

New-MgDirectoryRoleMemberByRef -DirectoryRoleId $globalAdminRoleId `
    -OdataId "https://graph.microsoft.com/v1.0/directoryObjects/$newUserId"

Détection

Logs de Connexion Microsoft Entra

Signal	Ce qu'il faut surveiller
Résultat MFA	Connexions avec `mfaDetail: null` pour les comptes admin
Réutilisation de token de session	Même token utilisé depuis différentes IPs rapidement
Niveau de risque	Connexions à risque élevé completées sans re-challenge MFA

Requete SIEM (Elastic KQL)

azure.signinlogs.properties.authentication_details.authentication_method: "Previously satisfied" AND
azure.signinlogs.properties.user_roles: "*Admin*" AND
azure.signinlogs.properties.risk_level_during_sign_in: ("high" OR "medium")

💡 Conseil : Activez Microsoft Entra ID Identity Protection. Il détecte le phishing AiTM, le voyage impossible, les anomalies de token et d'autres signaux d'attaque basés sur l'identité en temps réel.

Remédiation

⚠️ Critique : Activez les Security Defaults ou le MFA Accès Conditionnel immédiatement. C'est l'action à plus fort impact que vous pouvez prendre pour la sécurité des identités Azure.

Option 1 : Activer les Security Defaults (Sans Licence Requise)

Entra ID > Propriétés > Gérer les Security Defaults > Activer les Security Defaults = Oui

Option 2 : MFA Accès Conditionnel (Recommandé pour P1/P2)

Politique : Exiger MFA pour Tous les Admins
Utilisateurs : Tous les utilisateurs avec un rôle admin
Applications cloud : Toutes les applications cloud
Contrôles : Exiger MFA + Appareil conforme

Imposer le MFA Résistant au Phishing pour les Admins

Entra ID > Méthodes d'Authentification > Clés de Sécurité FIDO2 = Activé
Accès Conditionnel : Exiger la robustesse d'authentification = MFA résistant au phishing
(Pour Admin Global, Admin de Rôle Privilégié, Admin de Sécurité)

Comment EtcSec Détecte Cela

MFA_NOT_ENFORCED_ADMINS identifie les comptes admin sans méthodes MFA enregistrées — à un email de phishing d'une compromission totale du tenant.

AZ_SECURITY_DEFAULTS_DISABLED signale les tenants où les Security Defaults sont désactivés et aucune politique d'Accès Conditionnel équivalente n'a été configurée.

ℹ️ Note : EtcSec audite les contrôles d'identité Azure automatiquement. Lancez un audit gratuit pour voir quels comptes admin de votre tenant manquent de MFA.

Articles connexes : Failles d'Accès Conditionnel Azure | Accès Privilégié Azure

Priorites de Revue

Sécurité des Identités Azure : Pourquoi le MFA Seul ne Suffit Pas doit etre traite comme une exposition reelle dans votre tenant Entra ID et Azure, pas comme un simple parametre isole. La premiere etape consiste a definir le vrai perimetre de revue : quels admins, comptes invites, service principals, app registrations, exclusions de politiques et comptes break-glass sont concernes, quelles dependances metier existent, quels privileges sont exposes et quelles exceptions d'urgence ont ete ajoutees avec le temps. Ce cadrage evite une remediation superficielle, car le symptome technique est souvent plus petit que le rayon d'impact operationnel. En documentant le chemin complet entre configuration, privilege et usage reel, l'equipe peut prioriser des changements qui reduisent le risque sans bloquer l'activite.

Controles Adjacents a Revoir

Quand un attaquant arrive dans votre tenant Entra ID et Azure, il ne s'arrete presque jamais au premier point faible. Autour de Sécurité des Identités Azure : Pourquoi le MFA Seul ne Suffit Pas, il cherche en general a enchainer avec auth legacy, gouvernance invite insuffisante, consentements trop larges, comptes d'urgence obsoletes et roles jamais revises. Cela signifie que la defense doit revoir non seulement la faiblesse principale, mais aussi toutes les dependances qui transforment un acces initial en persistance ou en escalation. Verifiez quelles identites, quels roles, quelles permissions et quelles hypotheses de confiance peuvent etre reutilises. Si le correctif ferme un seul objet mais laisse intactes les voies adjacentes, le risque reel change peu. Une revue des chaines d'abus est donc indispensable pour obtenir un resultat durable.

Preuves et telemetry a collecter

Une bonne reponse a Sécurité des Identités Azure : Pourquoi le MFA Seul ne Suffit Pas repose sur des preuves que l'ingenierie et la detection peuvent relire ensemble. Collectez journaux de connexion, journaux d'audit, changements de roles, evenements de consentement, rotations de secrets et signaux de risque, comparez les changements recents avec les fenetres de maintenance attendues et isolez les comptes ou objets qui ont change de comportement sans justification claire. Ces elements doivent permettre de repondre a trois questions simples : quand l'exposition est apparue, qui peut encore l'utiliser, et si des variantes similaires existent ailleurs dans votre tenant Entra ID et Azure. La collecte de preuves aide aussi a distinguer une dette technique ancienne d'un usage actif. Cette distinction est essentielle pour choisir le bon niveau d'urgence et la bonne sequence de remediation.

Faiblesses voisines a revoir

Tres peu d'environnements contiennent Sécurité des Identités Azure : Pourquoi le MFA Seul ne Suffit Pas seul. Dans la pratique, la meme zone du tenant ou de l'annuaire contient souvent aussi auth legacy, gouvernance invite insuffisante, consentements trop larges, comptes d'urgence obsoletes et roles jamais revises, et ce sont ces faiblesses voisines qui determinent si l'exposition reste limitee ou devient critique. Revoyez les owners communs, les permissions heritees, les exceptions dupliquees et les raccourcis administratifs qui n'ont jamais ete retires. Verifiez si la meme logique de contournement a ete approuvee a plusieurs endroits, car cela revele souvent une faille de processus plus qu'un bug unique. Cette revue elargie donne une meilleure chance d'eliminer le chemin d'attaque complet.

Ordre de remediation recommande

Pour Sécurité des Identités Azure : Pourquoi le MFA Seul ne Suffit Pas, l'ordre de remediation doit privilegier la reduction de risque avant la perfection. Commencez par fermer les chemins qui augmentent le plus vite le privilege, puis verrouillez les objets ou identites a plus forte valeur, et ensuite seulement traitez les ecarts de hygiene secondaires. Utilisez Conditional Access, PIM, moindre privilege, access reviews, validation des owners applicatifs, workflows d'approbation et MFA fort comme ensemble de controles cible. Chaque changement doit avoir un owner, une note de rollback et une etape de validation. Cette discipline evite que les programmes de correction s'arretent apres le premier gain technique. Si une refonte complete n'est pas possible tout de suite, formalisez des controles intermediaires et planifiez le travail structurel dans le prochain revue operationnelle hebdomadaire et revue de durcissement mensuelle.

Validation apres chaque changement

Apres toute modification liee a Sécurité des Identités Azure : Pourquoi le MFA Seul ne Suffit Pas, validez le resultat sous deux angles : administration legitime et chemin d'attaque. Confirmez que les utilisateurs et systemes attendus continuent de fonctionner, puis prouvez que la voie dangereuse ne donne plus le meme levier. Rejouez la collecte sur journaux de connexion, journaux d'audit, changements de roles, evenements de consentement, rotations de secrets et signaux de risque, relisez les approbations et verifiez qu'aucun objet voisin ne conserve une voie de contournement. La validation doit aussi inclure une definition ecrite du succes, afin que tout le monde sache ce qui constitue une fermeture acceptable. Dans les equipes matures, un correctif n'est accepte que lorsque le chemin risque est ferme et que l'etat final correspond vraiment a l'objectif de durcissement.

Ownership, escalade et gouvernance

Les sujets comme Sécurité des Identités Azure : Pourquoi le MFA Seul ne Suffit Pas echouent quand le symptome technique est corrige mais que personne n'assume le controle long terme. Assignez des responsabilites claires entre equipe identite, securite cloud, proprietaires IAM et equipes applicatives, definissez qui approuve les exceptions et decidez quelle equipe doit signer avant qu'un objet risqué soit reintroduit. Cette gouvernance n'est pas de la bureaucratie inutile : elle sert a empecher qu'une urgence, une migration ou une integration tierce recree la meme exposition quelques semaines plus tard. Documentez les points de decision qui ont permis la faiblesse, puis mettez a jour le processus voisin pour que la prochaine demande soit evaluee selon la nouvelle baseline.

Lectures Connexes

Pour traiter ce sujet correctement, reliez-le a Failles d'Accès Conditionnel Azure : Contournement du MFA, Azure Identity Protection : Automatiser la Réponse aux Credentials Divulgués, Acces Privilegie Azure : Trop d'Admins Globaux, Durcissement du Tenant Azure : Corriger les Configs à Risque et Comptes Invités Azure : Risques du Tenant. Cet ensemble montre comment les memes erreurs d'identite, de privileges et de configuration se combinent dans une revue reelle au lieu d'apparaitre comme des constats isoles.

Ces liens internes gardent la remediaton centree sur le chemin d'attaque complet et pas seulement sur un controle pris separement.

Sécurité des Identités Azure : Pourquoi le MFA Seul ne Suffit Pas