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

Sfruttamento end-to-end del Domain Controller con Metasploit e Impacket: scoperto DC10, sfruttata Zerologon (CVE-2020-1472), estratti gli hash NTLM, ottenuta una shell SYSTEM e stabilita una sessione Meterpreter.

Sommario esecutivo Questo esercizio dimostra una catena d'attacco completa e realistica contro un domain controller vulnerabile a CVE-2020-1472 (Zerologon). L'operazione ha incluso discovery, arricchimento dei servizi, sfruttamento, estrazione delle credenziali, movimento laterale e validazione post-exploitation. Ho ottenuto con successo accesso a livello SYSTEM e stabilito una sessione Meterpreter persistente sul DC utilizzando una combinazione di Zerologon, Impacket secretsdump + pass-the-hash e payload msfvenom/meterpreter. Screenshot e artefatti dei comandi sono stati catturati in ogni fase come evidenza.

𝐏𝐚𝐧𝐨𝐫𝐚𝐦𝐢𝐜𝐚 𝐝𝐞𝐥 𝐥𝐚𝐛: Simulata una catena d'attacco completa su un 𝐖𝐢𝐧𝐝𝐨𝐰𝐬 𝐃𝐨𝐦𝐚𝐢𝐧 𝐂𝐨𝐧𝐭𝐫𝐨𝐥𝐥𝐞𝐫 utilizzando 𝐌𝐞𝐭𝐚𝐬𝐩𝐥𝐨𝐢𝐭 e 𝐈𝐦𝐩𝐚𝐜𝐤𝐞𝐭; discovery, Zerologon, secretsdump, pass-the-hash e una sessione Meterpreter controllata.

𝐏𝐞𝐫𝐜𝐡𝐞́ 𝐞̀ 𝐢𝐦𝐩𝐨𝐫𝐭𝐚𝐧𝐭𝐞 𝐩𝐞𝐫 𝐥𝐞 𝐨𝐫𝐠𝐚𝐧𝐢𝐳𝐳𝐚𝐳𝐢𝐨𝐧𝐢: Poiché il DC controlla autenticazione, criteri di gruppo e identità per l'intero dominio, una compromissione può degenerare in una completa interruzione dell'attività aziendale, furto di account, esfiltrazione di dati, diffusione di ransomware e perdita della fiducia normativa. Proteggere i DC tutela uptime, ricavi e reputazione, impedendo agli attaccanti di trasformare l'identità in un punto unico di guasto.

Sfruttamento del Domain Controller (DC) con Metasploit + Impacket

SCENARIO

Ti vengono fornite due macchine in una rete di laboratorio isolata. Un sistema è un Windows Domain Controller (DC) chiamato DC10 che ospita i servizi AD principali. L'altro sistema è una workstation Kali collocata nella stessa subnet del server per i test. Si presume che il DC esponga i tipici servizi di dominio (ad esempio LDAP, Kerberos, SMB) e possa essere vulnerabile a problemi noti. L'host Kali deve essere utilizzato per ricognizione, sfruttamento, accesso alle credenziali, movimento laterale e validazione post-exploitation. Il compito è identificare il DC, confermare i dettagli del dominio, ottenere un primo accesso utilizzando una tecnica appropriata, estrarre materiale credenziale per abilitare l'accesso amministrativo e quindi dimostrare il controllo del DC tramite una shell remota e una sessione con agente gestito, adattandosi a eventuali vincoli ambientali come servizi patchati, egress limitato o difese endpoint. DC: 10.1.16.1 Kali: 10.1.16.66

Risultati chiave

• Vulnerabilità critica sfruttata: CVE-2020-1472 (Zerologon) è stata sfruttata con successo per reimpostare a vuoto la password dell'account macchina del DC.
• Compromissione delle credenziali: gli hash NTLM sono stati estratti dal DC (secretsdump), rivelando le credenziali di Administrator e abilitando il pass-the-hash.
• Controllo completo del dominio dimostrato: utilizzando gli hash estratti, è stata ottenuta una shell SYSTEM su DC10 (psexec) ed è stata eseguita una reverse shell Meterpreter stabile, confermando l'esecuzione remota di codice e la persistenza.
• Servizi esposti: LDAP, Kerberos, SMB e i relativi servizi RPC erano raggiungibili dall'host attaccante, consentendo discovery e sfruttamento.
• Rischio della superficie d'attacco: il DC accettava operazioni remote che hanno permesso la manipolazione dell'account macchina e l'esecuzione remota di payload.

1) Discovery e Scoping

Ho usato msfconsole con supporto DB, eseguito uno sweep nmap da MSF, importato i risultati e affinato host e servizi per confermare l'esposizione di DC10.

• Avviato msfconsole con supporto DB e confermata la connettività al database.
• Eseguita una scansione nmap sulla subnet da msfconsole e importati i risultati nel DB di MSF.
• Pulita la tabella hosts per rimuovere il mio IP Kali. Esaminati i servizi per individuare i probabili indicatori di un DC.
• Usato lo scanner di porte SYN di MSF con un intervallo di porte limitato e threading globale per affinare i dati sui servizi.
• Eseguito il fingerprinting SMB sugli host Windows per arricchire i dettagli sul sistema operativo.
• Confermati i servizi LDAP e Kerberos su 10.1.16.1 e verificato il nome del dominio tramite una query LDAP.
• Decisione: trattare 10.1.16.1 come il DC di riferimento per lo sfruttamento e l'accesso alle credenziali.

2) Arricchimento dei servizi e conferma del DC

Ho eseguito una scansione delle porte SYN in MSF, effettuato il fingerprinting SMB e confermato LDAP e Kerberos su 10.1.16.1. Ho interrogato LDAP per recuperare il nome del dominio.

### Verifica della versione SMB

• Ho usato il modulo per la versione SMB in msfconsole: auxiliary/scanner/smb/smb_version.
• Ho impostato i target dalla tabella hosts con hosts -R .
• Ho ottenuto il dialect SMB e i dettagli del sistema operativo.
• Risultato: 10.1.16.1 mostrava informazioni di Windows Server, in linea con il fatto che fosse il Domain Controller.

Query LDAP

• Per il modulo di query LDAP, ho usato auxiliary/gather/ldap_query.
• Ho impostato rhosts 10.1.16.1 per colpire direttamente DC10.
• L'ho eseguito per recuperare le informazioni di base della directory.
• Risultato: confermato il nome del dominio come “structureality” e che LDAP sul DC rispondeva.