La plupart des entreprises pensent que leur réseau est sécurisé parce qu’elles ont un antivirus et un pare-feu. La réalité, c’est qu’un attaquant qui met un pied dans le réseau interne peut souvent récupérer les clés du royaume en quelques heures. Active Directory, c’est exactement ça — les clés du royaume.
Tribune HackIta – Après des années de tests d’intrusion sur des environnements Windows, ce qui va être montré ici, ce sont des techniques réellement utilisées lors de missions de pentest, pas de la théorie.
Active Directory : pourquoi tout le monde l’attaque
AD gère tout. Les comptes, les mots de passe, les accès, les politiques. Si vous compromettez un Domain Admin, vous avez le contrôle total de toutes les machines du domaine — serveurs, postes de travail, tout.
Le problème ? La plupart des environnements AD ont été configurés il y a dix ans et n’ont jamais été vraiment audités. Des comptes de service avec des mots de passe qui datent de 2015. Des utilisateurs avec des configurations Kerberos hasardeuses. Des droits accordés « temporairement » qui sont restés là pour toujours.
C’est un terrain de jeu idéal.
Kerberoasting
Voilà comment ça se passe concrètement. Dans AD, n’importe quel utilisateur du domaine peut demander un ticket Kerberos pour un compte de service qui a un SPN. Ce ticket est chiffré avec le hash NTLM du compte de service. L’attaquant le récupère, l’emmène sur sa machine, et le craque hors ligne avec Hashcat.
Pas besoin de droits particuliers. N’importe quel compte du domaine suffit.
GetUserSPNs.py domaine.local/utilisateur:motdepasse -dc-ip 192.168.1.1 -request -outputfile hashes.kerberoast
Si le mot de passe du compte de service est faible — et c’est souvent le cas — il tombe en quelques minutes. Avec cette technique, le crackage de comptes de service SQL en moins de deux minutes sur des missions réelles est réalisable.
Défense : mots de passe 25+ caractères sur les comptes de service, ou mieux, migrer vers les gMSA. Surveiller l’Event ID 4769.
AS-REP Roasting
Moins connue, mais tout aussi efficace. Certains comptes ont la pré-authentification Kerberos désactivée — soit par erreur, soit pour des raisons de compatibilité. Résultat : l’attaquant peut demander un ticket d’authentification sans fournir de mot de passe. Le DC répond avec un ticket chiffré avec le hash de l’utilisateur.
GetNPUsers.py domaine.local/ -usersfile users.txt -no-pass -format hashcat -outputfile hashes.asreproast -dc-ip 192.168.1.1
Craquage hors ligne, même principe que Kerberoasting. La différence, c’est que ça cible des comptes utilisateurs classiques, pas des comptes de service.
Défense : activer la pré-auth Kerberos sur tous les comptes. Auditer avec `Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true}`.
Responder — capturer des hash sans rien demander
Avant même d’attaquer AD directement, si vous êtes sur le réseau local, Responder vous permet de capturer des hash NTLM passivement.
Comment ? Windows utilise des protocoles de résolution de noms comme LLMNR et NBT-NS. Quand une machine cherche un hôte qui n’existe pas, elle broadcast la requête sur le réseau. Responder répond à sa place, se fait passer pour la ressource — et récupère le hash NTLMv2 de la victime.
responder -I eth0 -rdw
Le hash peut être craqué hors ligne ou utilisé dans une attaque NTLM Relay. Sur des réseaux internes mal configurés, cette technique donne des résultats en quelques minutes.
Défense : désactiver LLMNR et NBT-NS via GPO. Activer SMB Signing.
Pass-the-Hash
Windows stocke les hash NTLM en mémoire dans LSASS pour permettre l’authentification transparente. Un attaquant avec des droits admin local peut les extraire avec Mimikatz — et s’en servir directement pour s’authentifier sur d’autres machines, sans jamais connaître le mot de passe en clair.
psexec.py -hashes :hash_ntlm domaine.local/administrateur@192.168.1.10
C’est la technique de mouvement latéral par excellence. Si un admin de domaine s’est connecté sur une machine compromise, son hash est récupérable. Et utilisable partout où il a des droits.
Défense : activer LSA Protection, Windows Defender Credential Guard. Appliquer le principe du moindre privilège.
Mimikatz et DCSync
Le guide complet sur Mimikatz détaille les modules de cet outil — mais la technique la plus dévastatrice qu’il permet, c’est DCSync.
DCSync exploite le mécanisme de réplication d’AD. Un attaquant avec les bons droits peut simuler un contrôleur de domaine et demander au vrai DC de lui envoyer les hash de tous les utilisateurs — y compris krbtgt.
lsadump::dcsync /domain:domaine.local /all /csv
Avec le hash de krbtgt, on peut forger des Golden Tickets valides pendant des années. Game over.
Défense : surveiller l’Event ID 4662. Déployer Microsoft Defender for Identity.
La chaîne complète
En pratique, ces techniques s’enchaînent :
accès initial → Responder pour capturer des hash → Kerberoasting / AS-REP Roasting pour un compte privilégié → Pass-the-Hash pour le mouvement latéral → DCSync pour tout dumper → Golden Ticket pour la persistance.
Chaque étape s’appuie sur la précédente. C’est pour ça qu’un seul compte compromis peut mener à la compromission totale du domaine.
Phishing — le vrai point d’entrée
Toutes ces techniques supposent une chose : l’attaquant est déjà sur le réseau interne. Mais comment il y arrive ?
Dans la grande majorité des cas réels, c’est le phishing. Un mail bien construit, une pièce jointe piégée, un lien vers une fausse page de connexion. L’utilisateur clique, exécute quelque chose, et l’attaquant obtient un premier accès — souvent avec les droits d’un utilisateur standard du domaine.
Ce qui est intéressant, c’est qu’un compte utilisateur standard suffit pour lancer Kerberoasting ou AS-REP Roasting. Pas besoin d’être admin. Le phishing donne ce premier pied dans la porte, et les techniques AD font le reste.
Les attaques de spear phishing ciblées sont encore plus efficaces. L’attaquant se renseigne sur la cible — son poste, ses collègues, ses outils — et envoie un mail parfaitement crédible. Un faux document RH, une notification de sécurité urgente, une facture qui ressemble à celle d’un vrai fournisseur.
En 2026, les campagnes de phishing assistées par IA génèrent des mails quasi indétectables. La sensibilisation des utilisateurs reste la défense la plus efficace — mais aussi la plus difficile à maintenir dans la durée.
Défense : formation régulière des utilisateurs, simulation de phishing interne, MFA sur tous les accès, filtrage des mails entrants. Et surveiller les connexions VPN et RDP depuis des adresses inhabituelles.
Conclusion
Ce qui est frappant dans ces attaques, c’est leur simplicité. Elles n’exploitent pas des zero-days exotiques — elles abusent de fonctionnalités légitimes de Windows, mal configurées ou mal surveillées.
La bonne nouvelle : elles sont toutes détectables et mitigables. Encore faut-il savoir ce qu’on cherche.
Article rédigé par le fondateur de HackIta, blog dédié à l’ethical hacking et au pentesting, orienté vers les professionnels en parcours OSCP et OSCE3.
