Red Hot Cyber
La cybersecurity è condivisione. Riconosci il rischio, combattilo, condividi le tue esperienze ed incentiva gli altri a fare meglio di te.
Manuel Roccon : 13 Febbraio 2024 07:33
In questo articolo ci occuperemo di analizzare il movimento laterale tramite lo sfruttamento dell’autenticazione NTLM degli account locali e di dominio nelle reti Microsoft al fine di muoverci tra i dispositivi della rete.
Prima di vedere gli strumenti, configurazioni e approfondimenti vari che potrebbero mitigare i movimenti laterali all’interno di una rete Microsoft vediamo cosa si intente per movimento laterale e gli argomenti annessi.
In questo articolo ci concentreremo poi sulla tecnica pass-the-hash.
Acquista il corso Dark Web & Cyber Threat Intelligence (e-learning version)
Il Dark Web e la Cyber Threat Intelligence rappresentano aree critiche per comprendere le minacce informatiche moderne. Tra ransomware, data breach e attività illecite, le organizzazioni devono affrontare sfide sempre più complesse per proteggere i propri dati e le infrastrutture. Il nostro corso “Dark Web & Cyber Threat Intelligence” ti guiderà attraverso i meccanismi e le strategie utilizzate dai criminali informatici, fornendoti competenze pratiche per monitorare, analizzare e anticipare le minacce.
Accedi alla pagina del corso condotto dall'Prof. Pietro Melillo sulla nostra Academy e segui l'anteprima gratuita.
Per un periodo limitato, potrai utilizzare il COUPON CTI-16253 che ti darà diritto ad uno sconto del 20% sul prezzo di copertina del corso
Per ulteriori informazioni, scrivici ad [email protected] oppure scrivici su Whatsapp al 379 163 8765
Supporta RHC attraverso:
Quando viene compromesso un host, questo dispositivo potrebbe essere non sufficientemente interessante per arrivare agli obiettivi dell’attacco.
Pensiamo a un dispositivo facente parte dello Shadow IT che non viene sufficientemente attenzionato a livello di patch e/o configurazioni, oppure un computer di un utente dove ha questo abboccato a una mail di spam.
L’attaccante ha quindi necessità di spostarsi nei dispositivi adiacenti per recuperare accessi, dati e informazioni più interessanti ed arrivare al “cuore del sistema”, se un ransomware cercherà di raggiungere i server contenenti file dati, database e domain controller.
Per fare questo deve eseguire del movimento laterale, una delle tattiche descritta nel MITRE ATT&CK (TA0008).
Una sotto tecnica utilizzata per fare questo è il pass-the-hash (T1550.002) di cui faremo un focus in questo articolo.
Il privilege escalation è una tattica per cui un attaccante che ha compromesso un device tramite un utente che ha permessi e diritti limitati, cerchi di acquisire il pieno controllo dei dispositivi di solito tramite un utente privilegiato.
Può venir fatto attraverso qualche vulnerabilità oppure impersonalizzando un altro utente.
Per iniziare hash di una password trasforma la tua password (o qualsiasi altro dato) in una breve stringa di lettere e/o numeri utilizzando un algoritmo di crittografia come MD5, NTLM e SHA256.
Password1 -> 2ac9cb7dc02b3c0083eb70898e549b63 (MD5 hash)
Password1 -> 70ccd9007338d6d81dd3b6271621b9cf9a97ea00 (SHA1 hash)
In poche parole, da una password (o qualsiasi altro test) si può creare il suo hash invece dall’hash è impossibile risalire alla testo (password) originale se non tentando di indovinarla.
Solitamente questo hash poi viene salvato sui database o sistemi in quanto è “sicuro” non potendo risalire alla password originale.
Se un sito web viene violato, l’hashing delle password aiuta a impedire ai criminali informatici di accedere alle tue password.
Nelle autenticazioni quando inseriamo la password in chiaro, questa converta nel suo hash e poi confrontata con l’hash generato precedentemente (di solito salvato a database).
Salvare l’hash sui sistemi è sicuramente più sicuro di salvarla in chiaro ma ci sono comunque alcuni rischi.
Pass the hash è una tecnica di attacco in cui avversario generalmente non dispone delle credenziali per accedere ai sistemi adiacenti, ma recupera questi hash visti prima tramite dei software particolari e in seguito vengono utilizzati per eseguire delle autenticazioni sui sistemi, senza necessità di utilizzare la password originale.
Nei sistemi Microsoft in dominio è inoltre possibile recuperare questi hash (NT/NTLM) non solo dagli account locali ma anche dal dominio.
Come accennato prima tecnica permette inoltre di eseguire anche il privilege escalation sulla macchina compromessa, utilizzando hash di un account privilegiato.
Stesso discorso per la tecnica pass-the-ticket, più complessa, che sfrutta l’autenticazione kerberos per garantire l’accesso ai sistemi con la creazione per esempio di silver e gold ticket.
Un particolare rischio legato al l’autenticazione in ambienti Microsoft, è quello che amministratore di dominio o di rete vada a configurare in fase di installazione la stessa password dell’amministratore locale su tutti i dispositivi della rete (server e client), password che poi sarà “dimenticata” e non più cambiata.
Oltre al fatto che la password impostata potrebbe essere semplice o già compromessa con il rischio di poter risalire dall’hash alla password originale tramite cracking.
Recuperare questo hash come vedremo non è così complicato (difese permettendo), e quindi usare quello per poi muoversi diventa un rischio importante.
Vediamo come funziona un semplice pass-the-hash per passare da una macchina compromessa ad un’altra che condividono la stessa password del account “administrator” locale, account administator che è stato abilitato sui dispositivi client in aggiunta a un secondo account “admin” locale.
In questo laboratorio gli utenti di dominio usati nelle rispettive macchine sono anche tutti amministratori.
Ora supponiamo di aver compromesso l’utente di dominio User01 della VM1.
Dalla nostra macchina Kali cerchiamo Mimikatz, creiamo al volo un server web per poter scaricare eseguibile sulla macchina compromessa tramite browser.
Mimikatz ci servirà per recuperare gli hash di autenticazione.
E passiamo i file nella macchina compromessa
Allo stesso modo passiamo anche PsExec64, un tool che ci servirà per ottenere la shell sulla macchina remota.
PsExec è un’applicazione sostitutiva di Telnet, più leggera, che consente di eseguire processi su altri sistemi e offre un’interattività completa per le applicazioni console. Gli usi più avanzati di PsExec includono la possibilità di eseguire prompt di comandi interattivi su sistemi remoti e strumenti di abilitazione in remoto. Ci servirà per utilizzare gli hash trovati per connettersi alle macchine vicine.
Ora tralasciamo su come abbiamo fatto per avere una shell con i completi poteri amministrativi bypassando il UAC, proviamo subito ad usare PsExec per ottenere la shell remota alla VM02 ma ovviamente utente user01 non ha i permessi per farlo nel altro endpoint.
Quindi avviamo mimikatz, un tool che permettere recuperare questi hash, inclusi quelli degli account locali.
Quindi recuperiamo hash NTLM di due account amministratori nella macchina, “administrator” sia di un altro account “admin”, che anche quello è amministrator locale della macchina.
Da notare il RID che è 500 per “administrator” di default (che di solito è disattivato nei client) e il RID 1000 per quello creato successivamente, vedremo poi una differenza sostanziale nell’approfondimento in seguito.
Quindi utilizziamo hash appena trovato di “administrator” per tentare il pass the hash con il comando sekurlsa::pth.
Il comando ci aprirà una nuova shell cmd, con cui questa volta potremmo cercare di muoverci nella seconda macchina utilizzando PsExec, comando visto inizialmente.
A questo punto abbiamo ottenuto la shell come amministratore locale nella macchina remota, ora possiamo procedere cosi su qualunque macchina che abbia le stesse credenziali di amministratore, inclusi i server.
Allo stesso modo se la password dell’amministratore locale del server è identica, possiamo usare lo stesso metodo visto per accedere anche al server.
Teniamo conto, come approfondiremo dopo, che nei server amministratore di default con RID 500 è attivo di default.
Ora le cose si fanno più serie…
Acquisire il controllo del domain controller (DC) vuol dire acquisire il controllo su tutta l’infrastruttura, in quanto questo gestisce tutte le credenziali di dominio e può per esempio distribuire configurazioni centralizzate tramite i criteri di gruppo.
Siamo rimasti nel aver preso il controllo del file server tramite password di amministratore locale riutilizzata in tutti i client.
Nel server non è raro invece che siano usati account di amministratori di dominio per manutenzioni dei server e molte volte lasciati lì disconnessi.
Ora passiamo mimikaz nel file server appena violato ed eseguiamo come prima i comandi privilege::debug e token::elevate elevate, questa volta usiamo però il comando sekurlsa::logonpasswords.
Il comando sekurlsa::logonpasswords ha come target il processo LSASS in memoria per recuperare le credenziali. Vengono recuperate password in testo semplice, hash NTLM e ticket Kerberos degli utenti che hanno attualmente effettuato l’accesso al sistema.
Quindi utilizziamolo in questo server, recuperiamo account di domain admin, che risulta loggato ma inattivo.
Ora non ci resta fare altro che utilizzare il token trovato nel file server per muoverci con i pieni diritti sul server di dominio.
Ora avendo il controllo del domain controller e avendo i pieni diritti possiamo usare un altro comando interessante, dcsync.
Il comando lsadump::dcsync ha obiettivo di “impersonare” effettivamente un controller di dominio e richiede una copia di tutti i dati del dominio autentico, inclusi utenti e hash delle password.
Questa operazione è possibile solo con un account che possiede i diritti Replicating Directory Changes (DS-Replication-Get-Changes), Replicating Directory Changes All (DS-Replication-Get-Changes-All) per poter essere utilizata.
I membri dei gruppi Administrators e Domain Controller del dominio dispongono di questi diritti per impostazione predefinita. Questa operazione può essere seguita in qualunque endpoint in dominio avendo i diritti corretti.
Non ci resta ora recuperare gli hash degli utenti di dominio.
Esistono dei meccanismi e configurazioni che tentano di limitare questa possibilità di muoversi in questo modo tra i dispositivi.
Prima di modificare qualunque configurazione, verificare sempre le impostazioni di autenticazione sui server e sulle applicazioni presenti nel dominio, in quanto questi possono ancora dipendere da NTLM per l’autenticazione, prima di valutare la possibilità di passare a metodi di autenticazione più sicuri.
E’ possibile abilitare l’auditing per l’uso del protocollo NTLM e tramite il registro eventi verificare la presenza del evento 4624.
UAC
L’UAC (User Access Control) limita gli utenti locali che possono eseguire operazioni di amministrazione remota.
E poiché la maggior parte degli attacchi che sfruttano il pass-the-hash si basano su operazioni di amministrazione remota, ciò influisce su questa tecnica.
Ci sono delle chiavi di registro “chiavi” nel limitare questo fenomeno già impostate:
La chiave di registro LocalAccountTokenFilterPolicy è impostata su 0 per impostazione predefinita. Ciò significa che l’account amministratore locale integrato (RID-500, “administrator”) è l’unico account locale autorizzato a eseguire attività di amministrazione remota. Impostandolo su 1 è possibile farlo anche per gli altri amministratori locali.
La chiave di registro FilterAdministratorToken è impostata su 0 per impostazione predefinita. Consente all’account amministratore locale integrato (RID-500, “Amministratore”) di eseguire attività di amministrazione remota. Se impostato su 1, non lo fa.
Quindi, per impostazione predefinita, solo i seguenti account possono sfruttare appieno il pass-the-hash:
Nel caso specifico se proviamo ad usare invece il secondo account admin locale con RID 1000 che avevamo trovato nella VM01 nel esempio, anche se riutilizzato su tutti i device, ci accorgiamo subito l’accesso laterale ci viene bloccato.
C’è da considerare che account “administrator” locale di default (built-in) con RID 500 è solitamente utilizzato di default nei server; quindi, compromettendo invece un server e se le credenziali locali sono riutilizzate, è possibile spostarsi facilmente sui server adiacenti.
Forzare NTLMv2
E’ possibile rifiutare l’autenticazione LM/NTLM in rete da parte dei dispositivi, per cui gli hash NTLM non potrebbero essere sfruttati per l’autenticazione, modificando elemento “Network Security: LAN Manager authentication level” tramite GPEDIT al seguente percorso:
Computer Configuration / Policies / Windows Settings / Security Settings / Local Policies / Security Options
Ci sono 6 opzioni tra cui scegliere nelle impostazioni dei criteri::
Per impostazione predefinita viene utilizzata “Invia solo risposta NTLMv2“, questo vuol dire che i client accetteranno le autenticazioni LM e NTLM.
Utilizzando “Invia solo risposta NTLMv2. Rifiuta LM&NTLM”. Questo criterio fa sì che i controller di dominio rifiutino anche le richieste LM e NTLM.
Disabilitare completamente NTLM nel dominio
E’ possibile disabilitare completamente NTLM sul dominio Active Directory utilizzando il criterio Sicurezza di rete: limitazione di NTLM: autenticazione NTLM nel dominio
Computer Configuration / Policies / Windows Settings / Security Settings / Local Policies / Security Options
La polizza prevede 5 opzioni:
Disabilitare NTLM in entrata e verso server remoti
Sebbene NTLM possa essere disabilitato nel dominio nella configurazione precederete, viene ancora utilizzato per elaborare gli accessi locali ai computer (NTLM viene sempre utilizzato per gli accessi degli utenti locali).
Per disabilitare il traffico NTLM in entrata e in uscita sui computer del dominio è necessario utilizzare queste configurazioni:
Inoltre assicurarsi che il criterio Sicurezza di rete: non archiviare il valore hash di LAN Manager alla successiva modifica della password sia abilitato nella stessa sezione dell’oggetto Criteri di gruppo, in modo che al prossimo cambio password, non vengano salvati localmente gli hash NTLM.
Windows Credential Guard
A partire da Windows 11 Enterprise, versione 22H2 e Windows 11 Education, versione 22H2, i “sistemi compatibili ad alcune specifiche” hanno Windows Defender Credential Guard attivato per impostazione predefinita.
Microsoft Windows Credential Guard è una funzionalità di sicurezza che isola dai furti le informazioni di accesso degli utenti dal resto del sistema operativo. Credential Guard utilizza la sicurezza basata sulla virtualizzazione (VBS) per separare i dati di sistema; solo il software di sistema autorizzato può accedervi.
Utilizzando la sicurezza virtualization-based, Kerberos, NTLM, and Credential Manager le informazioni vengono isolate.
Quando Windows Defender Credential Guard è abilitato, NTLMv1, MS-CHAPv2, Digest e CredSSP non possono utilizzare le credenziali di accesso.
Per abilitarlo sempre dal GPEDIT andare alla voce dal seguente percorso
Configurazione computer / Modelli amministrativi / Sistema /Protezione dispositivo / Device Guard
Per abilitarlo:
Questo sistema è compatibile nelle versioni uguali o successive a Windows 11 Enterprise, versione 22H2 o Windows 11 Education, versione 22H2, essendo usa il TPM è obbligatorio che sia supportata la 1.2 e 2.0 e ci potrebbero essere alcune limitazioni sulla CPU.
https://learn.microsoft.com/it-it/windows/security/identity-protection/credential-guard/configure
LAPS
È chiaro che impostare password locali differenti sarebbe la cosa migliore, ma quando dobbiamo gestire migliaia di device assieme?
LAPS risolve questo problema impostando una password diversa e casuale per l’account amministratore locale comune su ogni computer del dominio.
La funzionalità LAPS (Windows Local Administrator Password Solution) di Microsoft memorizza la password per l’account amministratore locale di ciascun computer in Active Directory, protetta in un attributo riservato nell’oggetto Active Directory corrispondente del computer.
Gli amministratori di dominio che utilizzano la soluzione possono determinare quali utenti, come gli amministratori dell’helpdesk, sono autorizzati a leggere le password.
E’ possibile impostare da policy di dominio GPO il cambio password ad ogni accensione, in modo da avere password diverse per ogni dispositivo.
Una volta configurata tramite GPO le configurazioni si trovano a questo percorso:
Computer Configuration / Policies / Administrative Templates / System / LAPS
Si trovano le voci:
Configure password backup directory: per configurare dove verranno salvati i backup delle password (Active Directory o Azure Active Directory)
Post-Authentication actions: permette di impostare le regole di cambio password locale, per esempio a ogni disconnessione dell’account
Sulla configurazione qui Microsoft ne parla più approfonditamente https://learn.microsoft.com/it-it/windows-server/identity/laps/laps-overview
In questo articolo abbiamo visto dei semplici passaggi per sfruttare gli hash NTLM e la tecnica pass-the-hash in un dominio Microsoft per eseguire il movimento laterale fino ad arrivare al domain controller per capire il funzionamento di questa tecnica.
Il protocollo NTLM è da considerarsi ormai obsoleto e introduce diverse vulnerabilità e tecniche per sfruttarlo per violare i sistemi, bisogna però fare estrema attenzione prima di disabilitarlo.
Potrebbe essere ancora utilizzato all’ interno dell’infrastruttura e disabilitarlo potrebbe comportare disservizi diffusi.
Come avevamo accennato è necessario prestare sempre la massima attenzione e di procedere con le operazioni descritte dopo aver monitorato attraverso l’auditing appropriato l’infrastruttura, per un periodo di tempo sufficientemente lungo.
C’è da dire che anche Microsoft sta cercando di arginare questo fenomeno, disabilitando l’utilizzo di questi protocolli deboli come avevamo parlato tempo fa https://www.redhotcyber.com/post/microsoft-manda-ntlm-in-pensione-kerberos-sara-il-futuro-per-windows-11/
Manuel Roccon