eladshamir/internal-monologueAttacco Monologo Interno: Recupero degli Hash NTLM senza Toccare LSASS
Mimikatz, sviluppato da Benjamin Delpy (@gentilkiwi), è uno strumento di post-exploitation ben noto, che consente agli avversari di estrarre password in testo chiaro, hash NTLM e ticket Kerberos dalla memoria, nonché di eseguire attacchi come pass-the-hash, pass-the-ticket o costruire un golden ticket. Si può sostenere che l'uso principale di Mimikatz sia il recupero delle credenziali degli utenti dalla memoria del processo LSASS per utilizzarle nel movimento laterale post-exploitation.
Recentemente, Microsoft ha introdotto Credential Guard in Windows 10 Enterprise e Windows Server 2016, che utilizza la sicurezza basata sulla virtualizzazione per isolare i segreti, ed è molto efficace nell'impedire a Mimikatz di recuperare gli hash direttamente dalla memoria. Inoltre, Mimikatz è diventato un obiettivo primario della maggior parte delle soluzioni di protezione degli endpoint, e sono molto aggressive nei loro sforzi per rilevarlo e prevenirlo. Sebbene questi sforzi siano destinati a fallire, stanno diventando sempre più fastidiosi.
NetNTLM è il protocollo challenge-response di Windows utilizzato principalmente dove Kerberos non è supportato. In NetNTLM, il server invia al client un nonce casuale di 8 byte come challenge, e il client calcola una risposta che elabora il challenge con l'hash NTLM come chiave, che è l'hash MD4 della password dell'utente. Esistono due versioni del protocollo di autenticazione NetNTLM, ed entrambe sono vulnerabili a determinati attacchi. Naturalmente, la versione 1 è significativamente più debole della versione 2, e pertanto a partire da Windows Vista/2008 NetNTLM versione 1 è disabilitata per impostazione predefinita.
Poiché l'hash NTLM è la chiave per calcolare la risposta, un avversario non ha necessariamente bisogno di ottenere la password in testo chiaro della vittima per autenticarsi, quindi recuperare l'hash dalla memoria LSASS usando Mimikatz è quasi equivalente a rubare una password in testo chiaro. Chris Hummel ha pubblicato un articolo descrivendo questa tecnica nel 2009 e l'ha chiamata “Pass the Hash” [https://www.sans.org/reading-room/whitepapers/testing/crack-pass-hash-33219].
Al Defcon 2012, Moxie Marlinspike e David Hulton hanno presentato un attacco “Divide and Conquer” contro NetNTLMv1 [https://www.youtube.com/watch?v=sIidzPntdCM]. In NetNTLMv1, il client riceve il challenge di 8 byte e calcola la risposta crittografandolo tre volte usando DES con diverse parti dell'hash NTLM come chiave. La lunghezza della chiave per DES è effettivamente di 56 bit, ovvero 7 byte, mentre l'hash NTLM è di 16 byte. NetNTLMv1 crittografa prima il challenge usando i primi 7 byte dell'hash NTLM come chiave, poi crittografa il challenge usando i successivi 7 byte dell'hash NTLM come chiave, e infine crittografa il challenge usando gli ultimi 2 byte dell'hash NTLM riempiti con byte nulli come chiave. Ciò significa effettivamente che, per recuperare l'hash NTLM dato un challenge e una risposta NetNTLMv1, un avversario deve decifrare due chiavi DES da 56 bit, il che è esponenzialmente più facile che decifrare una singola chiave da 128 bit. Moxie e Hulton hanno sviluppato hardware personalizzato per questo compito e sono riusciti a forzare l'intero spazio delle chiavi DES in meno di 24 ore, il che garantisce il recupero riuscito dell'hash NTLM entro un tempo ragionevole. Nota che, a differenza degli attacchi dizionario o di forza bruta contro la password, che potrebbero non essere fruttuosi, questo attacco garantisce il recupero riuscito dell'hash NTLM.
Come dimostrato da ToorCon su https://crack.sh, è fattibile creare una tabella arcobaleno completa per tutte le possibili risposte NetNTLMv1 a un challenge scelto, come 0x1122334455667788, che consente di decifrare l'hash NTLM per una data risposta in pochi minuti. L'implicazione è che catturare una risposta NetNTLMv1 per il challenge scelto può essere tradotta nell'hash NTLM corrispondente quasi istantaneamente, il che è quasi equivalente all'ottenere la password grazie a Pass the Hash.
Mimikatz viene comunemente eseguito dopo che l'avversario ha ottenuto accesso elevato all'host target. A questo punto, l'avversario può anche modificare le chiavi di registro, come LMCompatibilityLevel, che specifica se l'host deve negoziare NetNTLMv1 o NetNTLMv2. L'avversario può cambiare il valore a 0, 1 o 2, che abilitano NetNTLMv1 come client, e quindi provare ad autenticarsi a un server SMB rogue che catturerà la risposta del client, come descritto nel blog di Optiv [https://www.optiv.com/blog/post-exploitation-using-netntlm-downgrade-attacks].
Due impostazioni aggiuntive possono impedire alla vittima di negoziare una risposta NetNTLMv1:
In ambienti sicuri, dove Mimikatz non dovrebbe essere eseguito, un avversario può eseguire un attacco Internal Monologue, in cui invoca una chiamata di procedura locale al pacchetto di autenticazione NTLM (MSV1_0) da un'applicazione in modalità utente tramite SSPI per calcolare una risposta NetNTLM nel contesto dell'utente connesso, dopo aver eseguito un downgrade NetNTLM esteso.
Il flusso dell'attacco Internal Monologue è descritto di seguito:
Di recente ho ritestato Internal Monologue in ambienti con Credential Guard abilitato e ho ottenuto risultati negativi. Non sono sicuro se Credential Guard non funzionasse correttamente nel mio ambiente di test durante i test iniziali, o forse qualcosa è cambiato da allora. Ho aggiornato l'implementazione per acquisire dinamicamente un token server da AcceptSecurityContext e manometterlo per evitare la trappola di autenticazione locale, in modo che se NetNTLMv1 senza sicurezza di sessione estesa fallisce, almeno una risposta challenge-response NetNTLMv2 possa essere catturata.
L'attacco Internal Monologue è presumibilmente più furtivo dell'esecuzione di Mimikatz perché non c'è bisogno di iniettare codice o scaricare la memoria da/verso un processo protetto. Poiché la risposta NetNTLMv1 viene ottenuta interagendo con NTLM SSP localmente, non viene generato traffico di rete e il challenge scelto non è facilmente visibile. Nessun evento di autenticazione NTLM riuscito viene registrato nei log. Le modifiche al registro per il downgrade NetNTLM e il furto di token/impersonificazione di altri utenti potrebbero attivare indicatori.
Questo strumento è un proof of concept che implementa l'attacco Internal Monologue in C#. Il porting del codice in PowerShell potrebbe sostituire alcuni log di eventi nella traccia di audit con altri. Il codice PoC è lontano dall'essere perfetto. Contributi e miglioramenti positivi sono benvenuti.
Elad Shamir di The Missing Link Security
