CyberAct
Tag

ADFS : attaques et défense en environnement AD

Comprendre ADFS

Définition

ADFS (Active Directory Federation Services) est un rôle Windows Server qui implémente un fournisseur d'identité fédéré basé sur les standards SAML 2.0, OAuth 2.0 et WS-Federation. ADFS permet à des utilisateurs authentifiés dans un domaine Active Directory d'accéder à des ressources tierces sans ressaisir leurs identifiants. Le serveur ADFS émet des tokens signés cryptographiquement à l'aide d'un certificat de signature de token, appelé Token Signing Certificate. Ce certificat constitue la pièce maîtresse de l'infrastructure : quiconque le compromet peut forger des assertions SAML arbitraires pour n'importe quel utilisateur, y compris des comptes à privilèges élevés. ADFS s'appuie sur une base de données de configuration (WID ou SQL Server) et expose plusieurs endpoints HTTP/S comme '/adfs/ls', '/adfs/oauth2' et '/adfs/services/trust'. En environnement hybride Azure AD Connect, ADFS joue souvent le rôle de STS (Security Token Service) principal, ce qui en fait un point de pivot stratégique pour un attaquant cherchant à rebondir vers le cloud depuis l'on-premises.

Détection (Blue Team / SOC)

La détection des attaques sur ADFS repose sur plusieurs sources de logs distinctes. Les événements Windows dans le journal 'AD FS/Admin' sont fondamentaux : l'Event ID 1200 trace chaque token émis, l'Event ID 1202 enregistre les validations de claims, et l'Event ID 510 signale les attributs supplémentaires fournis lors d'une authentification. Une émission massive de tokens SAML pour un même compte, surtout hors horaires habituels, doit déclencher une alerte. Le journal 'Security' du contrôleur de domaine complète cette analyse : un accès inhabituellement fréquent à la clé DPAPI protégeant le Token Signing Certificate génère des Event ID 4662 sur l'objet 'contact' ADFS dans l'Active Directory. Côté réseau, surveiller les connexions sortantes depuis le serveur ADFS vers des endpoints cloud inhabituels est pertinent. Microsoft Sentinel dispose de règles analytiques dédiées à la détection de Golden SAML via la corrélation des logs AAD Sign-in et des journaux ADFS locaux. Enfin, l'outil ADFSDump, souvent utilisé en phase de reconnaissance offensive, effectue des requêtes WMI et des lectures de base de données WID détectables par un EDR correctement configuré.

Exploitation & contre-mesures (Red Team)

L'attaque la plus critique contre ADFS est le Golden SAML, analogue au Golden Ticket Kerberos. Un attaquant ayant compromis un compte Domain Admin ou le compte de service ADFS peut extraire le Token Signing Certificate via DPAPI ou directement depuis la base WID située dans 'C:/Windows/WID/Data/'. L'outil ADFSDump de FireEye (désormais Mandiant) automatise cette extraction. Avec le certificat exporté, l'outil SolarWinds-style forgery ou le framework AADInternals permet de forger un token SAML valide pour n'importe quel utilisateur, y compris des GlobalAdmins Azure AD, sans aucune interaction avec le contrôleur de domaine. Le durcissement passe par plusieurs mesures concrètes : restreindre l'accès au serveur ADFS aux seuls flux nécessaires via des règles de pare-feu strictes, activer l'audit renforcé ADFS avec la commande 'Set-AdfsProperties -AuditLevel Verbose', et activer la fonctionnalité 'Extranet Lockout' pour bloquer les attaques par credential stuffing sur l'endpoint '/adfs/ls'. La rotation régulière du Token Signing Certificate (tous les ans minimum) limite la durée de validité d'un certificat volé. Enfin, surveiller le compte de service ADFS dans un tier model et lui appliquer une politique de mot de passe renforcée réduit significativement la surface d'attaque.

Articles sur ADFS

Red TeamGolden SAML : quand l'ADFS devient la clé de tout votre cloud

La compromission du certificat de signing ADFS permet de forger des jetons SAML valides pour tout utilisateur fédéré, MFA compris.

25 juin 20266 min de lecture