Le correctif de juillet 2026 pour AD FS, référencé CVE-2026-56155, durcit les ACL du conteneur DKM dans l’Active Directory. Ce correctif remet au premier plan un vieux sujet: la clé de signature des jetons ADFS. Cette clé est le secret qui fait tout tenir en fédération, et celui qui la détient peut se faire passer pour n’importe qui auprès des applications qui font confiance à ADFS. L’attaque qui exploite ce secret porte un nom depuis 2017, quand les chercheurs de CyberArk l’ont décrite: le Golden SAML.
Nous allons voir pourquoi un service provider accepte une assertion dès lors qu’elle est signée avec la bonne clé, où cette clé est réellement stockée et comment elle est protégée, puis ce qu’un attaquant en fait et comment nous pouvons limiter cette confiance.
Pourquoi le SP fait confiance à une signature
Dans une fédération SAML 2.0, le service provider (SP) ne vérifie pas le mot de passe de l’utilisateur et n’interroge pas l’annuaire. Il reçoit une assertion émise par l’Identity Provider (IdP), ici ADFS, et il la valide avec la clé publique de l’IdP qu’il connaît d’avance via les métadonnées. Toute la relation de confiance repose sur un point unique: la signature XML de l’assertion. Si elle est valide au regard du certificat de signature de jetons (Token-Signing) et que les conditions temporelles et d’audience sont respectées, le SP crée une session. Il ne peut pas savoir si l’utilisateur s’est réellement authentifié devant ADFS.
C’est cette asymétrie qu’il faut comprendre. Le SP vérifie qui a signé, pas comment l’utilisateur a été authentifié. Si quelqu’un détient la clé privée du certificat de signature, il produit une assertion qui est indiscernable d’une assertion légitime. Il n’a besoin ni du mot de passe de la victime, ni de la MFA, ni même d’un échange avec ADFS. Nous avions comparé ces flux dans l’article sur OAuth 2.0, OpenID Connect, SAML et WS-Federation; ici c’est le lien de confiance SAML qui est attaqué à sa racine.
Une assertion ADFS typique contient le NameID, une condition d’audience qui désigne le SP, une fenêtre de validité (NotBefore / NotOnOrAfter), un AuthnStatement et les attributs (claims) attendus par l’application. Rien dans cette structure ne prouve une authentification réelle: ce sont des affirmations signées. L’objet signé, c’est le XML lui même.
Où vit la clé: certificat de signature et DKM
La clé de signature des jetons est le cœur du problème, il faut donc savoir où elle se trouve réellement. ADFS gère deux certificats sensibles: Token-Signing et Token-Decrypting. Par défaut, avec l’option AutoCertificateRollover activée, ADFS génère lui même des certificats auto-signés et les renouvelle périodiquement. La documentation Microsoft sur l’obtention des certificats Token-Signing et Token-Decrypting détaille ce comportement et le cas des certificats fournis par une PKI d’entreprise.
Le point important est la protection de la clé privée. Quand AD FS gère ses propres certificats, la clé privée est chiffrée et le matériel de déchiffrement est conservé dans l’Active Directory, dans le conteneur du Distributed Key Manager (DKM). C’est ce conteneur que vise le correctif de juillet 2026: CVE-2026-56155 resserre les ACL du conteneur DKM pour qu’un compte autre que le compte de service ADFS ne puisse pas lire la clé maître.
Côté serveur ADFS, nous pouvons déjà vérifier ce qu’expose le service et quel mode de gestion est en place:
Get-AdfsCertificate -CertificateType Token-Signing
Get-AdfsProperties | Select-Object AutoCertificateRollover, CertificateSharingContainerLa propriété CertificateSharingContainer pointe vers l’emplacement DKM dans l’annuaire. Pour localiser le conteneur et ses objets dans l’AD, nous restons sur des commandes de lecture:
Get-ADObject -SearchBase "CN=ADFS,CN=Microsoft,CN=Program Data,DC=test,DC=local" `
-Filter * -SearchScope Subtree |
Select-Object Name, ObjectClass, DistinguishedNameNous y trouvons un objet conteneur et, en dessous, un objet qui porte l’élément secret dans un attribut non publié. Attention: l’intérêt de la lecture ici est l’inventaire et le contrôle des ACL, pas l’extraction. L’ACL de ce conteneur doit être réservée au compte de service ADFS et aux administrateurs stricts. C’est tout l’objet du correctif de 2026, et c’est le premier réglage à auditer après l’avoir appliqué.
Ce qu’un attaquant en fait
Le scénario de bout en bout est documenté publiquement sous la référence MITRE ATT&CK T1606.002, Forge Web Credentials: SAML Tokens. Je décris ici la mécanique pour faire comprendre le risque, sans donner de recette d’exploitation.
Le point d’entrée, c’est le serveur ADFS ou un compte capable de lire le DKM. Un attaquant qui a compromis le serveur ADFS, ou qui a obtenu le niveau de privilège permettant de lire la clé maître DKM dans l’annuaire, reconstitue la clé privée du certificat de signature. À partir de là, il n’a plus besoin d’ADFS. Il forge hors ligne une assertion SAML où il choisit le NameID, l’audience (le SP ciblé), les attributs, la fenêtre de validité, et il la signe avec la clé volée. Il peut se nommer n’importe quel utilisateur, y compris un administrateur, et ajouter les claims qu’attend l’application.
Le rayon d’impact est large, et c’est ce qui rend ce secret si précieux pour un attaquant. La clé de signature est partagée par toutes les relations d’approbation de la ferme ADFS. Un seul vol permet donc de forger des assertions pour tous les SP qui font confiance à cet IdP: applications internes derrière Shibboleth SP, SaaS fédérés, et selon la configuration, l’accès à des services cloud. Il n’y a pas de mot de passe à casser, donc une rotation de mots de passe ne coupe rien. La MFA portée par ADFS est contournée, puisque l’assertion affirme simplement que l’authentification a eu lieu. Et tant que le certificat de signature reste valide, les assertions forgées restent acceptées: il n’y a pas de révocation d’assertion individuelle.
Avec un SP comme Shibboleth, dont nous avons détaillé l’installation dans l’article Installer Shibboleth SP 3.0 sous IIS 8 ou 10, l’assertion forgée est traitée comme une vraie: la signature est vérifiée contre les métadonnées de l’IdP, les attributs sont extraits, une session est ouverte. Rien ne distingue cette session d’une connexion légitime du point de vue de l’application.
La note que je m’étais faite en acceptant ce sujet était d’aller au bout de la démonstration et de donner un pas à pas. Je le fais pour la partie qui compte en défense: inventorier, détecter et durcir. La forge d’assertion, elle, je la laisse au niveau du mécanisme. Montrer la chaîne offensive complète n’apprend rien de plus sur le risque et arme inutilement.
Détecter et durcir
La détection est difficile, et il faut le dire franchement. Une assertion forgée est un XML correctement signé: le SP n’a aucun moyen de la rejeter. Le signal n’est donc pas côté SP mais dans les écarts entre ce que le SP voit et ce qu’ADFS a réellement émis. La piste la plus solide consiste à corréler les connexions acceptées par les applications avec les événements d’émission de jetons d’ADFS: une session ouverte sur un SP sans événement correspondant côté ADFS est une anomalie. Dans un environnement hybride, la même logique s’applique aux connexions cloud qui n’ont pas de trace d’authentification locale. L’avis de détection publié par CrowdStrike et Microsoft à la suite de la campagne SolarWinds décrit cette corrélation; dans Entra ID, nous avions aussi vu que le rejeu d’un jeton ressemble à une session légitime dans l’article sur le refresh token, le rejeu et la révocation.
Sur le serveur, nous activons l’audit détaillé d’ADFS pour disposer des événements d’émission:
Set-AdfsProperties -AuditLevel Verbose
Get-AdfsProperties | Select-Object AuditLevelLes événements de sécurité associés (notamment 1200 et 1202 pour l’émission et la validation de jetons) donnent la liste de référence des assertions réellement produites. C’est cette liste qu’on compare aux sessions ouvertes côté SP. Un accès en lecture inhabituel au conteneur DKM, lui, se repère via l’audit d’accès aux objets de l’annuaire, à condition de l’avoir activé sur le conteneur en amont.
Pour le durcissement, plusieurs parades se combinent. Attention: la première est d’appliquer CVE-2026-56155 puis de vérifier que l’ACL du conteneur DKM est bien restreinte au seul compte de service ADFS. Sans cette restriction, un compte à privilège modéré peut lire la clé maître et toute la chaîne tombe.
Ensuite, le compte de service ADFS. Un compte utilisateur classique, avec un mot de passe non aléatoire et une expiration désactivée, est un maillon faible: ses clés dérivées sont attaquables et sa compromission ouvre l’accès au DKM. L’usage d’un compte de service managé de groupe (gMSA) est ici la bonne pratique. Le mot de passe est généré par l’annuaire, totalement aléatoire, et renouvelé automatiquement; seules les machines autorisées peuvent le récupérer. Nous avions évoqué l’intérêt des comptes managés pour les SPN dans l’article Configuration pas à pas de IIS8 pour Kerberos, et le raisonnement est le même ici: retirer la robustesse de la clé du choix d’un humain.
Enfin, la clé elle même. Deux leviers réduisent l’intérêt du vol: stocker la clé privée du certificat de signature dans un HSM, de sorte qu’elle ne soit jamais extractible du matériel, et réduire la durée de vie des certificats de signature pour que la fenêtre d’exploitation d’une clé volée reste courte. En cas de suspicion de compromission, la seule réponse efficace est la rotation du certificat de signature, répétée une fois pour purger la clé précédente, suivie de la republication des métadonnées vers tous les SP. Tant que l’ancienne clé reste acceptée, les assertions forgées passent.
Rémi Vernier
Responsable des opérations cybersécurité dans un grand groupe international. Identité, Active Directory, Entra ID, cloud hybride, et désormais SAP, IA et modèles en local.