Perché DISA STIG consiglia "Nega l'accesso a questo computer dalla rete" per gli amministratori di dominio?

How does this setting mitigate a "privilege escalation from credential theft" attack?

La risposta alla domanda dipende dai dettagli precisi di come funziona l'impostazione Deny access to this computer from the network . Dobbiamo capire esattamente cosa fa questa impostazione prima di poter dire che è utile per mitigare una potenziale vulnerabilità.

Che cosa fa questa impostazione?

Questa impostazione è un "accesso negato" forzato per le connessioni di rete SMB remote, anche se le connessioni sono consentite tramite altri mezzi. È simile a una voce "Nega" in un elenco di controllo di accesso ed è valutata prima di Allow access to this computer from the network (proprio come con gli elenchi di controllo di accesso in Windows). Inoltre, è importante capire che questa impostazione non si applica alle connessioni RDP. Due esempi comuni di connessioni SMB sono il comando "Net use" e gli snap-in MMC come lo strumento Event View.

Qual è il rischio delle connessioni SMB remote?

Le connessioni SMB remote non espongono le credenziali su un host remoto. Questo significa che se mi collego a un sistema compromesso con un account privilegiato utilizzando solo una connessione SMB remota (ad esempio, uno snap-in MMC), le credenziali dell'account con privilegi non vengono esposte sul sistema compromesso.

In che modo questa impostazione attenua la minaccia di furto di credenziali?

Le connessioni SMB remote non espongono le credenziali, quindi non vi è alcun rischio di furto di credenziali. Pertanto l'impostazione Deny access to this computer from the network non è necessaria per mitigare questa minaccia.

Perché questa impostazione è suggerita come rimedio per prevenire il potenziale furto di credenziali?

Sembra esserci una discreta quantità di incomprensioni su cosa fa Deny access to this computer from the network . Correttamente inteso, questa impostazione non è necessaria per mitigare il furto delle credenziali perché le credenziali non sono esposte dalle connessioni SMB remote.

Spiegazione per analogia

Supponiamo che ci sia una giovane donna di nome Emilia che ha sentito dire che esiste un negozio di borsette con una borsetta che vuole comprare. Il negozio si trova in una parte della città, nota per un gruppo di ladri che ruba furtivamente le carte di credito delle persone a loro insaputa, quindi il negozio ha provato a ridurre alcuni prezzi per aumentare gli affari. Questo accadeva nei giorni precedenti a Internet e ai siti web, e lei sente una pubblicità alla radio che ha una borsa particolare che vuole comprare.

Vuole verificare il prezzo per se stessa, quindi ha due opzioni: 1) Guida fino al negozio e rischia di rubare la carta di credito, oppure 2) chiama il negozio al telefono e verifica il prezzo. (Sta attento e rifiuta di fornire il suo numero di carta di credito al telefono.)

Qual è il rischio che il suo numero di carta di credito venga rubato da lei se non guida fisicamente verso il negozio di borse? Certo, non vi è alcun rischio, dal momento che la sua carta di credito non è mai fisicamente lì da rubare. [Connessione SMB remota: le credenziali non sono esposte] Se scende al negozio, c'è il rischio che i ladri furbi rubino la sua carta di credito. [Accesso interattivo = potenziale furto di credenziali]

Quindi, in altre parole, questa domanda è la seguente: se Emilia solo chiama il negozio al telefono e non fornisce il suo numero di carta di credito per telefono, qual è il rischio del suo credito numero di carta rubato da lei? La risposta è ovviamente che in questo caso non vi è alcun rischio.

Politica del processo vs. politica tecnica

Sembra che DISA raccomandi questa impostazione per aiutare le organizzazioni a far rispettare una buona politica di processo. Questa impostazione può essere utile in quel contesto per impedire ai membri di Domain Admins di connettersi a computer remoti usando connessioni SMB e perseguire altri mezzi amministrativi. Tuttavia, la domanda è chiedere i dettagli tecnici di questa impostazione, non le sue implicazioni processo . Al momento sembra che la raccomandazione DISA fornisca una descrizione tecnica errata di questa raccomandazione, mentre in realtà dovrebbero fornire una valida raccomandazione di processo.

@ HallowProc ha una buona risposta che voglio espandere su più di un commento.

Prima di tutto, i gruppi Enterprise Admins dovrebbero essere vuoti e popolati solo per la rara attività amministrativa.

L'unica posizione in cui devono essere utilizzate le credenziali di amministratore di dominio si trova sul controller di dominio o su una workstation amministrativa dedicata. Questi sistemi dovrebbero avere il più alto livello di fiducia nell'organizzazione. L'accesso dovrebbe essere limitato in modo che il traffico amministrativo (RDP, WinRM, ecc.) Possa essere scambiato solo da questi sistemi affidabili utilizzando IPsec ( Isolamento di server e domini ). Quindi esponendo solo i servizi necessari (Kerberos, LDAP, ecc.) Ai sistemi a un livello di fiducia più basso.

I sistemi di membri di dominio hanno un livello di affidabilità inferiore e non dovrebbero mai avere un accesso di amministratore di dominio al sistema. Inoltre, non dovrebbe essere consentito l'accesso a nessun account di dominio con un'ampia gamma di permessi di amministrazione. Un esempio di questo è un account con accesso amministrativo su tutte le workstation dei membri del dominio. L'ampiezza dell'accesso amministratore dovrebbe essere ristretta a un sottoinsieme più piccolo.

Architettando Active Directory in questo modo, l'uso di account con privilegi è limitato a pochi sistemi. Quindi l'implementazione di questo controllo di sicurezza ottiene quanto segue:

1. Difesa in profondità - supponiamo che ci sia uno script che si collega ai controller di dominio per eseguire un'attività ad hoc e c'è un errore di battitura. Indicare lo script su una workstation membro con un livello di attendibilità inferiore. Mentre questo dovrebbe essere fermato dalle regole IPsec e altri controlli, avere un'impostazione come questa sarebbe un altro livello sulla cipolla Difesa in profondità. Impedisce all'account elevato di accedere dove le credenziali potrebbero essere estratte e sfruttate.
2. Limita movimento laterale / contenimento - Mentre la tua domanda riguarda Domain / Enterprise Admins, l'impostazione attuale include anche gli account degli amministratori locali. Questo mi porta a credere che l'impostazione miri a mitigare lo sfruttamento relativo a Mimikatz (token / hash extraction - > Pass-the-Hash / Token). Se viene utilizzato Microsoft LAPS (o qualcosa di simile), non sarei interessato alla limitazione della rete accesso agli account degli amministratori locali. Poiché ogni sistema avrebbe una password univoca per l'account dell'amministratore locale. Tuttavia, se un account con privilegi viene compromesso su una workstation e tenta di accedere a un altro sistema, l'evento di accesso negato dovrebbe generare un avviso. Riduzione al minimo del tempo dallo sfruttamento al contenimento.
3. Miglioramento dei processi - Mentre gli ambienti aziendali di grandi dimensioni sono molto meglio per la separazione dei privilegi, molti utilizzano ancora le credenziali di livello di amministratore di dominio per eseguire compiti amministrativi sui sistemi membri. Avere un'impostazione come questa migliora il processo in quanto indirizza gli amministratori di sistema verso la separazione delle autorizzazioni in più account.

Nel peggiore dei casi in cui le credenziali di amministratore di dominio siano compromesse su una workstation con basso livello di affidabilità, il contenimento è raggiungibile. Dovrebbe essere generato un avviso che mostri l'uso riuscito di tali credenziali seguito da eventi di accesso negato. L'accesso alla rete verrà bloccato sui restanti sistemi membri (tramite questa impostazione) e sui controller di dominio (tramite isolamento del server e del dominio).

È garantito che ci sono modi per superare questo controllo particolare, specialmente quando sono coinvolti account di amministrazione aziendale / dominio. Tuttavia ciò significa un avversario molto più sofisticato. Se è così, c'è di più da preoccuparsi solo di questa particolare impostazione. Credo che questo sia indirizzato a scenari in cui una postazione di lavoro a bassa affidabilità viene utilizzata da helpdesk / sysadmin / one-person-shop. L'avversario usa tecniche come quelle usate con mimikatz per provare e ruotare con quelle credenziali (escalation dei privilegi).

L'impostazione non è perfetta, ma per diventare più specifica sarebbe ingestibile per DISA. Ogni ambiente è diverso e viene fornito con i suoi avvertimenti. Questa impostazione mira a trovare un equilibrio.

Sono d'accordo con la tua affermazione in merito alla rimozione del gruppo Domain Admins dal gruppo degli amministratori locali. Invece, creare un singolo gruppo di sicurezza globale per il gruppo di sistemi amministrati. Qualcosa come gs-localadm-room-007. Ciò si traduce in una riduzione dei compiti amministrativi, quindi se quell'account fosse compromesso, non ci sarebbe alcun effetto su altri silos di sicurezza.

A partire dalla diapositiva 81 di questa presentazione di Sean Metcalf di ADSecurity.org - link - Sean va oltre Livelli di amministrazione AD e Red Forest concetti.

Sebbene Sean non ne parli, penso che si riduca a configurare gli amministratori di dominio una volta in uno scenario Tier-0 / Foresta rossa e quindi utilizzando Politiche di autenticazione e Silos per bloccare definitivamente quel concetto. Mark Russinovich e Nathan Ide della fama Microsoft discutono qui - link - e HD Moore di MetaSploit fame (insieme a Joe Bialek di Microsoft e Ashwath Murthy di Palo Alto Networks) li discute in dettaglio qui - link

Parlando del framework metasploit, è meglio testare i concetti sfruttando il proprio framework di attacco, o altri framework di exploitation come PowerShellEmpire, o framework cross-between come PowerSploit. Sfruttando use incognito e più-recentemente use kiwi da meterpreter, è possibile ottenere l'accesso ai criteri di test necessari per vedere all'interno di tutti gli archivi cred e di tutto il traffico cred. Dopo aver eseguito use kiwi , i comandi kerberos , mimikatz_command -f sekurlsa::logonPasswords -a "full" , msv , livessp , ssp , tspkg e wdigest meterpreter diventano disponibili. Puoi anche mimikatz_command -f crypto::listStores . Anche se un utente come Amministratore di dominio non ha effettuato l'accesso, è possibile prendere il proprio ticket passando-l'hash con il comando sekurlsa::pth pure (sebbene sia necessario l'hash, ad esempio un pacchetto NETNTLMv2 o un'acquisizione lato servizio). Consulta la Guida non ufficiale di Mimikatz per ulteriori informazioni.

Ciò che è interessante di questo consiglio DISA STIG Deny access to this computer over the network non è che ciò impedirà agli amministratori di dominio di inviare traffico NETNTLMv2 tentando di accedere tramite SMB / CIFS (o qualsiasi altro protocollo), ma è una politica che possono Lo faremo in primo luogo (se continuano a tentare di accedere da remoto a una politica in cui rende impossibile farlo, allora si limitano a fare sempre la stessa cosa ripetutamente aspettandosi risultati diversi). Quindi è solo una politica tecnica che rappresenta una politica e una linea guida real-life: gli amministratori di dominio non dovrebbero loggare o tentare di accedere a nulla a meno che non sia necessario impostare cose specifiche del dominio in una speciale foresta rossa o altro scenario di livello 0. / p>

Esistono in realtà modi ancora più interessanti per acquisire credenziali di amministratore di dominio (o altri), come NetRipper , o ancora di più con mimikatz (ancora più non documentato). FRO-DO DAT stesso, Itai Grady, ha parlato di Proteggendo i segreti del browser in un ambiente di dominio di recente presso BsidesTlv a Tel Aviv - vale la pena provarlo.

La risposta alla tua domanda:

What specifically is a "privilege escalation from credential theft" attack in this context, ...

è che un attacco di escalation di privilegi dal furto di credenziali significa che le credenziali con privilegi più elevati sono ottenute (raccolte) da un sistema a cui si ha accesso con un insieme di privilegi di privilegi più bassi. In questo caso, potresti avere un amministratore locale su un sistema, ma se un amministratore di dominio dovesse effettuare il login e ottenere le sue credenziali da quel sistema (tramite Mimikatz, credenziali memorizzate nella cache, ecc.) Ora hai privilegi escalati rubando credenziali di amministratore di dominio.

Parte 2:

and how does enabling this setting mitigate it?

Impedendo ai Domain Admins di accedere alle workstation, si riduce effettivamente il rischio che le credenziali DA possano essere raccolte da una workstation. EDIT Inoltre, anche se le credenziali sono raccolte da una macchina, questo controllo è progettato per " ridurre il rischio di movimenti laterali derivanti da attacchi di furto di credenziali ". Quindi non si tratta solo di proteggere UNA workstation, si tratta di evitare spostamenti laterali da una workstation.

Anche se a volte è difficile decifrare il significato di alcuni degli STIG, credo che il concetto principale qui sia che non dovresti gestire computer con account di amministratore di dominio, data la natura altamente sensibile di questi account.

Questo deriva dallo stesso STIG:

For domain-joined workstations, the Domain Admins group must be replaced by a domain workstation administrator group (see V-36434 in the Active Directory Domain STIG). Restricting highly privileged accounts from the local Administrators group helps mitigate the risk of privilege escalation resulting from credential theft attacks.

Tuttavia, non ho provato questa particolare impostazione, ma non sarei sorpreso se questa restrizione non avesse alcun effetto. Molti dei consigli STIG su diritti e privilegi sono un po 'assurdi e non hanno l'effetto desiderato e vengono automaticamente ripristinati ai valori predefiniti.

Modifica: questo deve essere testato perché non credo che tu possa impedire l'accesso all'amministratore del dominio, indipendentemente dalla politica impostata o dal gruppo in cui si trovano. Gli STIG nella mia esperienza sono scarsamente testati e hanno politiche che non hanno effetto. Ad esempio, togliere agire come parte del sistema operativo dall'account di sistema, il che non ha senso e viene automaticamente ripristinato.

Modifica: poiché questa risposta viene sottoposta a downvoted, voglio chiarire che la mia risposta è che sono d'accordo con @bill_stewart che l'impostazione in questione non impedisce un attacco di furto di credenziali poiché le credenziali non sono esposte direttamente. Ma oltre a questo sto dicendo che l'impostazione probabilmente non ha alcun effetto perché non si può negare a un amministratore di dominio di accedere a un computer. Il mio commento [rimosso] originale sugli accessi memorizzati nella cache era una nota a margine e non voleva essere parte della risposta stessa.