NMAP
Eseguo una scansione nmap di tutte le porte con il seguente comando:
nmap -T5 --open -sS -vvv --min-rate=1000 --max-retries=2 -p- -oA full-ports 10.10.10.172
Successivamente lancio una scansione mirata per identificare i servizi utilizzando i flag -sC ed -sV e specificando le porte appena scovate.
Ometterò il risultato di questa scansione nmap per consentire una migliore lettura. Dai risultati della scansione risulta essere attivo il servizio kerberos, si tratta quindi di un domain controller.
USER FLAG
Poiché sono attivi servizi ldap, smb, rpc, con l’ausilio di enum4linux è possibile, in questo caso, enumerare alcune informazioni utili relative agli utenti e ai gruppi presenti sulla macchina senza necessità di immettere delle credenziali. Di seguito è riportato un estratto:
Provando ad accedere ai servizi smb e ldap con gli utenti appena scoperti mi trovo di fronte alla richiesta della password che purtroppo non ho:
Con gli utenti trovati ho creato una lista di username e password, vale la pena fare un tentativo e verificare se l’admin ha utilizzato come password qualche nome utente:
hydra -L pass.txt -P pass.txt ldap3://10.10.10.172 -V
Come ipotizzato, l’utente SABatchJobs utilizza il nome utente come password.
Non è possibile ottenere l’accesso con psexec poiché l’utente in oggetto non ha permessi di scrittura sugli share disponibili:
Così decido di dare un’occhiata a SMB:
smbclient -W MEGABANK -L \\\\10.10.10.172 -U’SABatchJobs’
smbclient -W MEGABANK -L \\\\10.10.10.172\\users$ -U’SABatchJobs’
All’interno del file azure.xml è possibile vedere la configurazione di un Azure Service Principal.
La documentazione di Microsoft riporta:
An Azure service principal is an identity created for use with applications, hosted services, and automated tools to access Azure resources. This access is restricted by the roles assigned to the service principal, giving you control over which resources can be accessed and at which level. For security reasons, it’s always recommended to use service principals with automated tools rather than allowing them to log in with a user identity.
Così provo a vedere se in questo caso fosse possibile accedere con evil-winrm alla macchina utilizzando le credenziali appena scovate.
evil-winrm -i 10.10.10.172 -s ps1 -e exe -p 4n0therD4y@n0th3r$ -u mhope
AZURE AD CONNECT
Con il flag utente in mio possesso inizio a enumerare cercando qualche tipo di privesc. Dal momento che Azure è un topic ricorrente in questa macchina, decido di indirizzarmi verso questa strada.
net user mhope
Come visto anche dall’outpit di enum4linux ho conferma che l’utente mhope fa parte del gruppo “Azure Admins”.
Faccio un po’ di ricerche all’interno della macchina e vedo che la cartella programmi ha del contenuto interessante:
Microsoft Azure AD Sync mi fa venire in mente l’attacco DCSync e le funzionalità di replica del DC, poi l’utente mhope fa proprio parte del gruppo Azure Admins…mmh la cosa mi insospettisce non poco, quindi decido di fare un giro su Google.
La documentazione di Microsoft riporta:
Il servizio di sincronizzazione Azure Active Directory Connect […] Si occupa di tutte le operazioni che riguardano la sincronizzazione dei dati relativi alle identità tra l’ambiente locale e Azure AD.
Reference: https://docs.microsoft.com/en-us/azure/active-directory/hybrid/whatis-azure-ad-connect
Azure AD Connect viene installato un servizio locale che orchestra la sincronizzazione tra Active Directory e Azure Active Directory. Il servizio di sincronizzazione di Microsoft Azure AD Sync (ADSync) viene eseguito in un server in locale nell’ambiente in uso. Le credenziali per il servizio sono impostate per impostazione predefinita in installazioni Express, ma possono essere personalizzate per soddisfare i requisiti di sicurezza dell’organizzazione. Queste credenziali non vengono usate per la connessione per le foreste locali o Azure Active Directory.
E Ancora:
L’account del servizio predefinito durante l’installazione in un controller di dominio è nel formato Domain\AAD_InstallationIdentifier. La password per questo account è generata casualmente e presenta sfide significative per la rotazione di ripristino e la password.
Se infatti controllo gli utenti sulla macchina vedo che c’è l’utenza AAD_987d7f2f57ds che è l’account predefinito per il servizio di sincronizzazione ADSync.
A questo punto è chiaro che c’è un collegamento tra Azure e il Domain Controller, adesso si tratta di capire se è possibile sfruttare in qualche la funzionalità di sincronizzazione.
ROOT FLAG
Facendo un po’ di ricerche mi imbatto in questo articolo che sembra proprio fare al caso mio:
https://blog.xpnsec.com/azuread-connect-for-redteam/
A quanto pare le credenziali che vengono sincronizzate attraverso il servizio risiedono all’interno di un database locale. Ed effettivamente avevo notato che nella macchina è presente SQL Server.
Nell’articolo sopra citato è chiara la possibilità di prelevare le informazioni dal database e decifrare la password attraverso la .dll mcrypt di AD connect. Facendo ulteriori ricerche è possibile trovare un PoC completo da utilizzare:
https://github.com/Hackplayers/PsCabesha-tools/blob/master/Privesc/Azure-ADConnect.ps1
Bingo!
evil-winrm -i 10.10.10.172 -u Administrator -p 'd0m@in4dminyeah!' -s ps1/ -e exe
