Le Golden SAML est l'une des attaques les plus sous-estimées qui existent contre les environnements hybrides Microsoft. Elle ne touche pas à Azure AD, ne déclenche pas d'alerte de connexion suspecte sur Entra ID, et contourne le MFA cloud sans même interagir avec l'utilisateur ciblé. Tout cela parce qu'un serveur ADFS mal protégé constitue, dans la pratique, une autorité de confiance absolue pour votre tenant.
Ce qu'est vraiment la fédération SAML et pourquoi elle crée ce risque
Dans une architecture fédérée classique, Azure AD ne valide pas lui-même les identités des utilisateurs synchronisés via ADFS. Il délègue cette responsabilité à l'Identity Provider (IdP) on-premise, c'est-à-dire le serveur ADFS. Lorsqu'un utilisateur s'authentifie, c'est ADFS qui produit une assertion SAML signée cryptographiquement avec son certificat privé de token-signing. Azure AD vérifie la signature et, si elle est valide, accorde l'accès sans poser de question supplémentaire.
Ce mécanisme est conçu pour fonctionner ainsi. Le problème surgit quand un attaquant met la main sur ce certificat privé : il peut alors signer lui-même n'importe quelle assertion SAML, pour n'importe quel utilisateur, avec n'importe quelle valeur d'attribut, y compris l'identifiant d'un Global Administrator. Azure AD reçoit un jeton parfaitement valide sur le plan cryptographique et ouvre les portes sans broncher.
Comment l'attaque se déroule techniquement
La séquence commence sur le serveur ADFS lui-même. L'attaquant qui dispose d'un accès privilégié sur cette machine peut extraire le certificat de token-signing via plusieurs voies : dump de la base de données de configuration ADFS (fichier AdfsConfiguration.mdf), accès au service Windows Identity Foundation, ou encore via l'API DKM (Distributed Key Manager) si les clés sont stockées dans Active Directory. Des outils comme ADFSDump ou des modules PowerShell spécifiques automatisent cette extraction.
Une fois le certificat et sa clé privée exportés, l'attaquant forge une assertion SAML à la main. Cette assertion contient les attributs attendus par Azure AD : l'UPN de la victime, son identifiant immuable (ImmutableID), et les claims de groupe nécessaires. Il signe ce document XML avec la clé volée, le soumet à l'endpoint de fédération d'Azure AD, et obtient un token d'accès valide. L'ensemble de la chaîne se passe entièrement hors ligne, sans connexion au compte cible, sans MFA challenge.
Pourquoi le MFA cloud ne change rien ici
C'est le point que beaucoup de RSSI ne réalisent pas immédiatement. Le MFA configuré dans Azure AD (Conditional Access, Microsoft Authenticator) s'applique aux flux d'authentification gérés par Azure AD. Dans un flux SAML fédéré, Azure AD fait confiance à l'assertion produite par ADFS. Si cette assertion déclare que le second facteur a été validé, ou si la politique de Conditional Access est configurée pour exclure les connexions fédérées de certaines exigences, le MFA ne joue plus aucun rôle de protection. L'attaquant n'interagit jamais avec la pile d'authentification cloud : il arrive avec un billet déjà tamponné.
Pourquoi l'ADFS doit être traité comme un actif Tier 0
Dans le modèle de tiering Active Directory, le Tier 0 regroupe les actifs dont la compromission entraîne la compromission totale de l'infrastructure. Les contrôleurs de domaine en font partie. Le serveur ADFS devrait systématiquement y figurer aussi, pour une raison simple : qui contrôle ADFS contrôle l'identité de tous vos utilisateurs fédérés, cloud inclus.
Pourtant, dans la majorité des environnements audités, l'ADFS est traité comme un serveur applicatif ordinaire. Il tourne parfois sur une VM partagée, avec des droits d'administration accordés à des équipes IT de niveau intermédiaire, sans journalisation renforcée ni segmentation réseau stricte. C'est exactement la surface d'attaque que le Golden SAML exploite. Pour illustrer le risque : un attaquant qui a compromis un poste admin non Tier 0 peut, via un mouvement latéral classique, atteindre l'ADFS et extraire le certificat — offrant ensuite un accès persistant et indétectable au tenant Azure, même après un reset de mot de passe de la victime.
Si vous souhaitez tester la résistance de votre architecture ADFS face à ce type de scénario dans un environnement contrôlé, les labs dédiés aux attaques sur les identités hybrides de CyberAct permettent de rejouer ces chaînes d'exploitation pas à pas.
Les mesures de protection concrètes à mettre en place
La première priorité est de traiter le serveur ADFS avec les mêmes contrôles que vos contrôleurs de domaine : accès limité aux seuls comptes Tier 0, journalisation complète des événements (en particulier les accès à la configuration ADFS et les opérations sur les certificats), et isolation réseau stricte.
Sur le plan technique, activez la fonctionnalité de rotation régulière du certificat de token-signing. Un certificat volé qui a déjà expiré ne peut plus être utilisé pour forger des assertions. Azure AD supporte la rotation automatique si elle est correctement configurée. Vérifiez également que la durée de validité de vos certificats ADFS n'est pas excessive — la valeur par défaut d'un an est souvent trop longue dans des environnements à haute sensibilité.
Ensuite, activez les Smart Heuristics et le logging ADFS avancé (niveau verbose sur les événements 500-503 et 1200-1203). Ces logs permettent de détecter des assertions générées pour des comptes qui ne se sont jamais connectés de cette machine, ou à des heures incohérentes. Côté Azure AD, les Sign-in logs filtrent sur le type d'authentification fédérée et peuvent révéler des connexions anormales si une règle d'alerte est en place.
Enfin, envisagez de migrer les comptes les plus sensibles (Global Admins, Security Admins) vers une authentification gérée directement par Azure AD, en les excluant du périmètre ADFS. Un compte Global Administrator qui n'est pas fédéré n'est tout simplement pas attaquable via Golden SAML.
Détection : ce que les équipes SOC doivent surveiller
Les événements Windows Security 4768 et 4769 sur le serveur ADFS, combinés à une absence de trace d'authentification correspondante dans les logs d'accès physique ou VPN, constituent un signal faible à corréler. Côté Azure AD, une connexion via un token SAML pour un compte qui n'avait jamais utilisé ce flux auparavant mérite investigation. Certains SIEM permettent de corréler ces événements avec des anomalies de géolocalisation ou de user-agent. Si votre équipe SOC ne dispose pas encore de règles de détection sur ces flux hybrides, c'est le bon moment d'y remédier — une évaluation de la maturité de votre capacité de détection peut identifier précisément ces angles morts.
Questions fréquentes
Le Golden SAML s'applique-t-il uniquement aux environnements Microsoft ?
Non. SAML est un standard ouvert et toute infrastructure utilisant un IdP on-premise pour fédérer des accès cloud est potentiellement concernée. Okta, PingFederate, Shibboleth ou d'autres solutions peuvent être exposées si le certificat de signing est compromis. La logique d'attaque reste identique : voler la clé privée, forger l'assertion, contourner l'authentification cloud.
Est-ce que changer le mot de passe de la victime met fin à l'attaque ?
Non, et c'est là toute la dangerosité de cette technique. Puisque l'attaquant forge ses propres assertions sans utiliser le mot de passe du compte cible, un reset de credential n'a aucun effet. Seule la rotation ou la révocation du certificat de token-signing ADFS coupe l'accès. C'est pourquoi la détection rapide est aussi critique que les mesures préventives.
Comment savoir si mon environnement a déjà été compromis via cette méthode ?
Les indicateurs les plus fiables sont des connexions SAML fédérées dans les logs Azure AD pour des comptes sans activité on-premise correspondante, ou des événements d'accès à la base de configuration ADFS sans opération de maintenance planifiée. Un exercice de threat hunting ciblé sur ces traces, idéalement conduit après une analyse des logs des six derniers mois, est la méthode la plus rigoureuse.
La migration vers Azure AD native (Managed Identity) supprime-t-elle complètement le risque ?
Pour les comptes migrés, oui. Un compte dont l'authentification est gérée directement par Azure AD, sans passer par ADFS, ne peut pas être usurpé via Golden SAML, car aucun jeton SAML signé localement n'est accepté pour ce compte. Cette migration est donc une mesure de réduction de risque forte, en particulier pour les comptes à hauts privilèges.