Un attaquant qui prend pied sur un poste Windows membre d'un domaine Active Directory ne s'arrête pas là. Si l'entreprise utilise Microsoft 365 avec une synchronisation d'identités, ce poste de travail devient la première pièce d'un couloir qui mène directement au cloud. Cette chaîne d'attaque hybride est aujourd'hui l'une des plus redoutables, précisément parce qu'elle franchit une frontière que beaucoup d'équipes de sécurité n'ont pas encore appris à surveiller comme un seul bloc.
Compromission initiale : accès au poste Active Directory
Tout commence souvent de la façon la plus banale qui soit : un email de phishing bien ciblé, un document Office piégé, ou l'exploitation d'un service exposé sans patch récent. L'attaquant obtient une exécution de code sur un poste utilisateur membre du domaine. À ce stade, il ne dispose que des droits d'un utilisateur standard, mais c'est amplement suffisant pour enchaîner.
La première priorité est d'établir une persistance discrète et d'élever les privilèges localement. Des outils offensifs courants permettent d'exploiter des misconfigurations locales comme un service tournant sous un compte privilégié, un token impersonnable, ou un chemin d'exécutable non protégé. Une fois administrateur local, l'espace de jeu s'élargit considérablement.
Extraction de secrets locaux : DPAPI et LSASS
C'est ici que la phase de collecte d'identifiants commence. Deux cibles sont systématiquement visées sur un poste Windows compromis.
LSASS : la mémoire qui garde tout
Le processus LSASS (Local Security Authority Subsystem Service) conserve en mémoire les credentials des sessions actives. Un dump de ce processus, réalisé via des techniques comme l'abus de MiniDumpWriteDump ou le recours à des drivers signés, permet d'extraire des hashes NTLM, des tickets Kerberos ou parfois des mots de passe en clair si WDigest est activé. Les outils de post-exploitation modernes automatisent complètement cette étape.
DPAPI : les coffres-forts du navigateur et du système
La DPAPI (Data Protection API) est le mécanisme que Windows utilise pour chiffrer des secrets locaux : mots de passe sauvegardés dans les navigateurs, credentials stockés dans le gestionnaire Windows, clés privées de certificats. Ces secrets sont protégés par des clés maîtresses dérivées du mot de passe de l'utilisateur. Un attaquant avec un accès administrateur local peut accéder aux blobs chiffrés et, avec le hash NTLM ou le mot de passe de l'utilisateur, les déchiffrer intégralement. Ce vecteur est très souvent sous-estimé dans les audits classiques.
Mouvement latéral vers les contrôleurs de domaine
Armé d'identifiants valides, l'attaquant pivote vers d'autres systèmes. Le Pass-the-Hash ou le Pass-the-Ticket permet de s'authentifier sur d'autres machines sans connaître le mot de passe en clair. L'objectif est d'atteindre un contrôleur de domaine ou un serveur hébergeant le service Azure AD Connect.
Dans de nombreuses architectures, Azure AD Connect tourne sur un serveur membre du domaine avec des permissions étendues. Ce serveur est une cible de premier choix, parce qu'il dispose d'un compte de service qui peut lire tous les hashes du domaine via la réplication DRS, et parce qu'il stocke localement les credentials du compte de synchronisation cloud.
Pivot vers Microsoft 365 et Entra ID
C'est ici que la frontière entre on-premises et cloud devient fictive. Plusieurs chemins mènent au tenant Microsoft 365 depuis un domaine compromis.
Vol du token de session ou des refresh tokens
Sur un poste où l'utilisateur est connecté à des applications Microsoft 365, des refresh tokens OAuth sont stockés localement, souvent dans les profils de navigateur ou dans les caches d'applications comme Teams ou OneDrive. Ces tokens permettent d'obtenir des access tokens sans aucune réauthentification, même si l'utilisateur change son mot de passe après coup, car le refresh token reste valide jusqu'à sa révocation explicite.
Abus de la synchronisation Azure AD Connect
Si l'attaquant accède au serveur Azure AD Connect, il peut extraire les credentials du compte MSOL utilisé pour la synchronisation. Ce compte dispose de droits suffisants pour effectuer une réplication DCSync sur le domaine, puis pour s'authentifier directement dans le tenant Entra ID avec des privilèges élevés. À partir de là, il est possible de créer de nouveaux comptes cloud, de modifier des règles de conditional access, ou d'ajouter des credentials à des applications managées. L'accès est total.
Pour comprendre comment ce type de scénario se joue concrètement dans un contexte de red team, les labs hybrides du catalogue CyberAct permettent de reproduire chaque étape dans un environnement isolé et instrumenté.
Pourquoi AD et le cloud forment un seul périmètre
Cette chaîne d'attaque démontre quelque chose de fondamental : le tenant Microsoft 365 n'est pas un environnement séparé de votre infrastructure on-premises. La synchronisation d'identités qui simplifie la vie des utilisateurs crée un pont permanent entre les deux. Compromettre l'un revient à compromettre l'autre.
La défense doit en tenir compte. Surveiller LSASS uniquement depuis l'EDR sans corréler avec des anomalies d'authentification cloud, c'est observer la moitié du tableau. Un compte synchronisé dont le refresh token est exfiltré ne laisse aucune trace dans les journaux Active Directory : il faut croiser les logs Entra ID Sign-in, les alertes Microsoft Defender for Identity et les événements Windows dans une console unifiée.
Les équipes SOC qui n'ont pas encore mis en place cette corrélation transverse entre leur SIEM on-premises et les logs cloud peuvent réaliser un diagnostic de maturité pour identifier précisément les angles morts de leur couverture de détection.
La segmentation des comptes administrateurs, la désactivation de WDigest, la protection de LSASS via Credential Guard, la mise en place du Conditional Access avec évaluation continue, et la rotation régulière des credentials de synchronisation Azure AD Connect sont des mesures concrètes. Pas suffisantes isolément, mais combinées, elles rendent chaque étape de cette chaîne d'attaque significativement plus coûteuse pour l'attaquant.
Questions fréquentes
Qu'est-ce que la DPAPI et pourquoi est-elle dangereuse en cas de compromission ?
La DPAPI est le mécanisme Windows qui protège des secrets locaux comme les mots de passe de navigateur ou les credentials stockés. Un attaquant disposant d'un accès administrateur local peut déchiffrer ces secrets s'il dispose du hash ou du mot de passe de l'utilisateur, ce qui en fait un vecteur d'exfiltration d'identifiants très fréquent mais souvent ignoré dans les évaluations de sécurité classiques.
Comment un attaquant peut-il accéder à Microsoft 365 à partir d'un poste compromis, même sans connaître le mot de passe cloud de l'utilisateur ?
Via l'extraction de refresh tokens OAuth stockés localement dans les profils de navigateur ou les caches d'applications comme Teams. Ces tokens permettent d'obtenir des access tokens valides sans authentification supplémentaire, et restent exploitables même si l'utilisateur change son mot de passe, jusqu'à leur révocation explicite dans Entra ID.
Quel est le rôle d'Azure AD Connect dans cette chaîne d'attaque ?
Azure AD Connect synchronise les identités entre l'Active Directory on-premises et Entra ID. Si le serveur qui l'héberge est compromis, l'attaquant peut récupérer les credentials du compte de synchronisation, réaliser un DCSync sur le domaine et s'authentifier dans le tenant cloud avec des droits très élevés, ouvrant un accès complet au tenant Microsoft 365.
Comment structurer la détection pour couvrir à la fois l'AD et le cloud ?
Il faut centraliser dans un SIEM les journaux Windows (événements d'authentification, accès LSASS, réplication DRS), les logs Entra ID Sign-in et les alertes Microsoft Defender for Identity. La corrélation entre une anomalie on-premises et une connexion cloud suspecte dans les minutes qui suivent est souvent le seul signal révélateur d'une attaque hybride en cours.