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

Scansione Nmap

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:

enum4linux

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:

smb auth

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:

lista password

hydra -L pass.txt -P pass.txt ldap3://10.10.10.172 -V

Come ipotizzato, l’utente SABatchJobs utilizza il nome utente come password.

hydra

Non è possibile ottenere l’accesso con psexec poiché l’utente in oggetto non ha permessi di scrittura sugli share disponibili:

PsExec

Così decido di dare un’occhiata a SMB:

smbclient -W MEGABANK -L \\\\10.10.10.172 -U’SABatchJobs’

smb share

smbclient -W MEGABANK -L \\\\10.10.10.172\\users$ -U’SABatchJobs’

users share

All’interno del file azure.xml è possibile vedere la configurazione di un Azure Service Principal. 

Configurazione 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.

Reference: https://docs.microsoft.com/bs-latn-ba/powershell/azure/create-azure-service-principal-azureps?view=azps-3.5.0

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

net user output

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:

Directory Program Files

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. 

net user output

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

ADSync

 Bingo!

evil-winrm -i 10.10.10.172 -u Administrator -p 'd0m@in4dminyeah!' -s ps1/ -e exe

root flag