Sécurité dans l'Active Directory

Kerberos est un mécanisme de sécurité, mais dans Active Directory sa sécurité dépend surtout de la configuration du domaine, des paramètres Kerberos et des comptes de service.

Afin de comprendre ses vulnérabilités il est recomendé de comprendre son fonctionnnement que nous détaillons dans notre première partie Kerberos dans l'environnment Active Directory.

L’objectif n’est pas d’empêcher Kerberos de fonctionner, mais de réduire les abus possibles et de détecter rapidement les comportements suspects.

1. Kerberoasting

Cette attaque cible les comptes de service associés à un Service Principal Name (SPN). L’attaquant demande un ticket de service, récupère un ticket chiffré avec la clé du compte de service, puis tente de casser ce ticket hors ligne.

Le problème vient surtout des comptes de service faibles, souvent configurés avec des mots de passe trop simples ou jamais renouvelés.

Comment s’en protéger :

Limiter les comptes ayant un SPN et configurer un gMSA, qui assigne automatiquement des mots de passe longs et aléatoires avec rotation automatique sur les comptes de services. Utiliser un algorithme de chiffrement fort (norme de complexité : 128 bits).

Outils d’audit associés :

• GetUserSPN.ps1 et Setspn pour lister les comptes avec SPN.

• BloodHound permet d’identifier les mauvaises configurations, les relations d’accès via groupe ou ACL et les comptes sensibles. Et plus globalement, il est idéal pour repérer visuellement les erreurs de configuration noyées dans la masse d’informations.

• PingCastle afin d’auditer l’AD et notamment les politiques de mot de passe faibles, les privilèges excessifs et les SPN inutiles.

• ADRecon pour inventorier les comptes avec SPN, les comptes privilégiés et les comptes trop exposés.

2. Pass-the-Ticket

Ici, l’attaquant vole un ticket Kerberos déjà présent sur une machine compromise et le réutilise pour se faire passer pour l’utilisateur légitime.

Cette attaque fonctionne surtout quand un poste compromis conserve des tickets exploitables en mémoire.

Comment s’en protéger :

Sur les postes, il faut limiter les droits locaux et éviter de se connecter en administrateur lorsque le poste n'est pas sûr et réduire la durée de vie des tickets si nécessaire. La surveillance des connexions anormales vers les services et l'utilisation d'EDR sur les postes permettent d'identifier ces comportements.

Outils d’audit :

• Windows Event Viewer et Sysmon (ou tout EDR exploitant ces journaux) pour centraliser et corréler les événements des postes et des serveurs dans un SIEM.

• Microsoft Defender for Identity pour détecter les tentatives de Pass-the-Ticket.

• Rubeus pour simuler l’attaque et valider sa détection, voire son blocage.

3. Golden Ticket

L’attaquant forge un faux TGT à partir du hash du compte krbtgt. La clé de ce compte sert à signer les TGT, l'attaquant peut alors demander presque n’importe quel accès dans le domaine.

C’est l’une des attaques les plus graves, car elle donne un contrôle très large sur l’authentification Kerberos.

Comment s’en protéger :

Protéger strictement le compte krbtgt avec un mot de passe fort et, si possible, une rotation de ce dernier. Segmenter l'administration du domaine : réduire le nombre de comptes Domain Admin, utiliser des postes d'administration dédiés.

Surveiller les compromissions AD et faire une rotation des mots de passe du compte en cas d'incident.

Outils d’audit :

• BloodHound afin d’identifier les chemins d’élévation de privilèges (via les postes ou les comptes) et de mettre en évidence les mauvaises délégations et ACL.

• PingCastle pour vérifier la sécurité du compte krbtgt (complexité du mot de passe, renouvellement) et lister les comptes admin du domaine pouvant l’altérer.

• Microsoft Defender for Identity détecte et alerte lorsque l’attaque se produit.

4. AS-REP Roasting

Cette attaque vise les comptes pour lesquels la préauthentification Kerberos est désactivée. L’attaquant peut alors récupérer une réponse chiffrée et tenter de la casser hors ligne.
Le risque vient d’une mauvaise configuration du compte, pas de Kerberos lui-même.

Comment s’en protéger :

– activer la préauthentification sur tous les comptes ;
– supprimer les comptes inutiles ;
– vérifier les configurations héritées.

Outils d’audit :

• Get-ADUser -Filter 'DoesNotRequirePreAuth -eq $true' pour identifier les comptes sans préauthentification.

• BloodHound pour repérer les comptes à la configuration anormalement héritée.

• PingCastle relève les mauvaises configurations et politiques.

5. Délégation Kerberos mal configurée

Une délégation trop permissive peut permettre à un service d’agir au nom d’un utilisateur, ce qui devient dangereux si le service est compromis.
Le problème apparaît souvent avec des droits de délégation trop larges ou mal compris.

Comment s’en protéger :

– éviter la délégation non nécessaire ;
– préférer la délégation contrainte du moindre privilège ;
– auditer les comptes et serveurs autorisés ;
– restreindre les services critiques.

Outils d’audit :

• BloodHound met en évidence les comptes, serveurs et chemins d’attaque exposés. Il est très utile pour repérer les délégations non contraintes, les délégations contraintes mal définies et les services capables d’agir au nom d’utilisateurs sensibles.

• PowerSploit permet de simuler une offensive et de mettre en évidence les mauvaises délégations.

• ADExplorer pour inspecter manuellement les attributs AD et vérifier les comptes ou serveurs autorisés.

• PingCastle pour auditer l’Active Directory et détecter les délégations risquées à l’échelle du domaine.

Bonnes pratiques générales

Pour durcir Kerberos dans Active Directory, il faut surtout :

– utiliser des mots de passe forts et uniques ;
– éviter les comptes de service classiques quand un « est possible ;
– surveiller les tickets, les SPN et les délégations ;
– durcir le compte krbtgt;
– centraliser la journalisation sur les contrôleurs de domaine ;
– vérifier régulièrement les faiblesses AD avec les outils d’audit proposés.

Conclusion

Kerberos reste un protocole solide, mais dans Active Directory, sa sécurité dépend directement de l’hygiène du domaine. La meilleure défense consiste à réduire les comptes sensibles, limiter les délégations, renforcer les mots de passe et auditer régulièrement les configurations Kerberos.