Domain-Controller-DC-Exploitation-with-Metasploit-Impacket

Exploitation de bout en bout d'un contrôleur de domaine à l'aide de Metasploit et Impacket : découverte de DC10, exploitation de Zerologon (CVE-2020-1472), extraction des hashs NTLM, obtention d'un shell SYSTEM et établissement d'une session Meterpreter.

Résumé exécutif Cet exercice démontre une chaîne d'attaque complète et réaliste contre un contrôleur de domaine vulnérable à CVE-2020-1472 (Zerologon). L'engagement comprenait la découverte, l'enrichissement des services, l'exploitation, l'extraction d'identifiants, le mouvement latéral et la validation post-exploitation. J'ai obtenu avec succès un accès au niveau SYSTEM et établi une session Meterpreter persistante sur le contrôleur de domaine en combinant Zerologon, Impacket secretsdump + pass-the-hash, et des payloads msfvenom/meterpreter. Des captures d'écran et des artefacts de commandes ont été collectés à chaque étape comme preuve.

Vue d'ensemble du lab : Simulation d'une chaîne d'attaque complète sur un contrôleur de domaine Windows en utilisant Metasploit et Impacket ; découverte, Zerologon, secretsdump, pass-the-hash, et une session Meterpreter contrôlée.

Pourquoi c'est important pour les organisations : Parce que le contrôleur de domaine gère l'authentification, les stratégies de groupe et l'identité de l'ensemble du domaine, une compromission peut dégénérer en interruption totale de l'activité, prise de contrôle de comptes, exfiltration de données, déploiement de ransomwares et perte de confiance réglementaire. Protéger les contrôleurs de domaine préserve la disponibilité, les revenus et la réputation en empêchant les attaquants de faire de l'identité un point de défaillance unique.

Exploitation de contrôleur de domaine (DC) avec Metasploit + Impacket

SCÉNARIO

Deux machines vous sont fournies dans un réseau de laboratoire clos. L'un des systèmes est un contrôleur de domaine Windows (DC) nommé DC10 qui héberge les services AD principaux. L'autre système est un poste de travail Kali placé dans le même sous-réseau serveur à des fins de test. On suppose que le contrôleur de domaine expose des services de domaine typiques (par exemple, LDAP, Kerberos, SMB) et peut être vulnérable à des problèmes connus. L'hôte Kali est destiné à être utilisé pour la reconnaissance, l'exploitation, l'accès aux identifiants, le mouvement latéral et la validation post-exploitation. La tâche consiste à identifier le contrôleur de domaine, confirmer les détails du domaine, obtenir un premier point d'appui à l'aide d'une technique appropriée, extraire les identifiants pour permettre un accès administratif, puis démontrer le contrôle du contrôleur de domaine via un shell distant et une session d'agent gérée, tout en s'adaptant aux contraintes de l'environnement telles que des services corrigés, une sortie réseau restreinte ou des défenses de point de terminaison. DC: 10.1.16.1 Kali: 10.1.16.66

Points clés

• Vulnérabilité critique exploitée : CVE-2020-1472 (Zerologon) a été exploitée avec succès pour réinitialiser le mot de passe du compte machine du contrôleur de domaine à vide.
• Compromission d'identifiants : les hashs NTLM ont été extraits du contrôleur de domaine (secretsdump), révélant les identifiants Administrateur permettant le pass-the-hash.
• Contrôle complet du domaine démontré : en utilisant les hashs extraits, un shell SYSTEM sur DC10 a été obtenu (psexec), et un reverse shell Meterpreter stable a été exécuté, confirmant l'exécution de code à distance et la persistance.
• Services exposés : LDAP, Kerberos, SMB et les services RPC associés étaient accessibles depuis l'hôte attaquant, permettant la découverte et l'exploitation.
• Risque de surface d'attaque : le contrôleur de domaine acceptait des opérations à distance qui ont permis la manipulation du compte machine et l'exécution de payload à distance.

1) Découverte et périmètre

J'ai utilisé msfconsole avec le support de la base de données, lancé un balayage nmap depuis MSF, importé les résultats, puis affiné les hôtes et services pour confirmer l'exposition de DC10.

• Lancement de msfconsole avec le support de la base de données et confirmation de la connectivité de la base.
• Exécution d'un scan nmap sur le sous-réseau depuis msfconsole et importation des résultats dans la base de données MSF.
• Nettoyage de la table des hôtes pour retirer mon IP Kali. Examen des services pour repérer les indicateurs probables d'un contrôleur de domaine.
• Utilisation du scanneur de ports SYN de MSF avec une plage de ports restreinte et un threading global pour affiner les données de services.
• Prise d'empreinte SMB (fingerprinting) sur les hôtes Windows pour enrichir les détails du système d'exploitation.
• Confirmation des services LDAP et Kerberos sur 10.1.16.1 et vérification du nom de domaine via une requête LDAP.
• Décision : considérer 10.1.16.1 comme le contrôleur de domaine cible pour l'exploitation et l'accès aux identifiants.

2) Enrichissement des services et confirmation du contrôleur de domaine

J'ai effectué un scan de ports SYN dans MSF, pris l'empreinte SMB, et confirmé LDAP et Kerberos sur 10.1.16.1. J'ai interrogé LDAP pour récupérer le nom de domaine.

### Vérification de la version SMB

• J'ai utilisé le module de version SMB dans msfconsole : auxiliary/scanner/smb/smb_version.
• J'ai défini les cibles à partir de la table des hôtes avec hosts -R .
• J'ai obtenu en retour le dialecte SMB et les détails du système d'exploitation.
• Résultat : 10.1.16.1 a révélé des informations Windows Server, ce qui correspondait au fait qu'il s'agisse du contrôleur de domaine.