Huy Kha | Architetto senior per l'identità e la sicurezza

Il dilemma dell'intruso è il rovescio del dilemma del difensore, che spiega le sfide della difesa della cybersecurity. Mentre la difesa di Active Directory (AD) contro ogni possibile tecnica di attacco è la sfida per i difensori, gli aggressori hanno un problema diverso: una volta entrati, devono evitare di essere scoperti.

Gli aggressori possono avere bisogno di trovare un solo punto debole per accedere, ma rimanere inosservati è molto più difficile. Devono mantenere l'accesso, muoversi lateralmente, aumentare i privilegi ed eseguire i loro obiettivi senza far scattare allarmi o essere bloccati.

E se potessimo trasformare il dilemma dell'intruso a nostro vantaggio?

Come trasformare un attacco in una pratica difesa AD

La comprensione dei modi in cui i malintenzionati cercano e utilizzano le vulnerabilità è fondamentale per la difesa dell'AD. Per illustrare il valore di questa conoscenza, vediamo un metodo comune di attacco all'identità che sfrutta le errate configurazioni dei certificati.

Gli attacchi contro i servizi di certificazione di Active Directory (AD CS) hanno ottenuto un'attenzione significativa dopo che SpecterOps ha pubblicato una ricerca su come le configurazioni errate in AD CS possono essere sfruttate per l'escalation dei privilegi e la persistenza. Il rapporto Certified Pre-Owned1 ha delineato diverse tecniche, tra cui ESC1, ESC4 e Golden Certificates, che consentono agli aggressori di abusare dell'autenticazione basata su certificati per compromettere gli account privilegiati. Da quando è stata pubblicata questa ricerca, gli attori delle minacce e i red team hanno sempre più utilizzato questetecniche2 , rendendo AD CS un obiettivo di alto valore.

È qui che i difensori possono ribaltare la situazione. Quando si configura un honeypot, come un modello di certificato esca che sembra vulnerabile, gli attaccanti sono costretti a fare una scelta. Possono tentare di sfruttare quella che sembra una configurazione errata, rischiando di esporsi, oppure ignorarla e cercare un altro modo per aumentare i privilegi.

Immaginiamo che un utente malintenzionato, durante la scansione dei modelli di certificato mal configurati, ne trovi uno con diritti di modifica. Può tentare di abilitare l'opzione Supply in Request che consentirebbe loro di specificare un'identità privilegiata in una richiesta di certificato.

La trappola è scattata.

DISCLAIMER: L'implementazione di un modello di CA decoy e la sua intenzionale vulnerabilità ad attacchi come ESC1 ed ESC4 ampliano la superficie di attacco. Tuttavia, con i giusti meccanismi di sicurezza per rilevare e correggere queste minacce, può essere un approccio efficace.

Creazione di una trappola honeypot con un modello di certificato esca: Esempio 1

La Figura 1 mostra cosa trova un aggressore quando utilizza uno strumento come Certify3 per scansionare i modelli di certificato sfruttabili.

Figura 1. Questo modello di certificato vulnerabile offre ai computer di dominio il controllo completo, consentendone la modifica.

Questo certificato, CiscoSSLVPNsupporta l'autenticazione del cliente e consente ai computer di dominio di iscriversi. Ma poiché msPKI-Certificate-Name-Flag non è impostato su ENROLLEE_SUPPLIES_OBJECTl'attacco ESC1 non funziona.

Quando l'aggressore esamina gli attributi AD dell'oggetto CiscoSSLVPN certificato (Figura 2), vedono che il msPKI-Certificate-Name-Flag è impostato su 134217728che corrisponde a SUBJECT_ALT_REQUIRE_DNS. Ciò significa che il Supply in Request non è abilitata.

Figura 2. Questo output di PowerShell mostra il CiscoSSLVPN attributi del modello di certificato, con msPKI-Certificate-Name-Flag impostato su 134217728, indicando SUBJECT_ALT_REQUIRE_DNS.

Poiché in questo esempio abbiamo concesso ai computer di dominio il controllo completo su questo modello di CA, il nostro aggressore potrebbe trarre vantaggio da msDs-MachineAccountQuota (Figura 3), che è impostato su 10 per impostazione predefinita, per creare un nuovo oggetto computer, autenticarsi come account computer e quindi modificare il modello CA.

Figura 3. Questo output di PowerShell mostra l'uso di Powermad per creare un nuovo account macchina (TestPC) sfruttando msDs-MachineAccountQuotache è impostato su 10 per impostazione predefinita in AD.

Successivamente, l'attaccante si autentica come account del computer e modifica il modello di CA per renderlo vulnerabile all'ESC1(Figura 4).

Figura 4. Questa sessione di PowerShell viene eseguita come TestPC$ modificando l'account della macchina msPKI-Certificate-Name-Flag sul CiscoSSLVPN modello di certificato per renderlo vulnerabile all'ESC1.

Ora l'attaccante controlla gli attributi AD del modello CA modificato. Vede che l'attributo msPKI-Certificate-Name-Flag è cambiato (Figura 5), che riflette la modifica che lo rende sfruttabile.

Figura 5. Questo output di PowerShell mostra la versione modificata di CiscoSSLVPN modello di certificato, dove l'elemento msPKI-Certificate-Name-Flag è cambiato, rendendolo vulnerabile all'ESC1.

Per quanto riguarda la difesa di AD: in Directory Services Protector DSP)è ora possibile vedere una voce che registra la modifica AD sul modello di CA esca(Figura 6), evidenziando l'attributo specifico che è stato modificato.

Figura 6. Il nostro registro DSP mostra la modifica del CiscoSSLVPN modello di certificato, dove l'elemento msPKI-Certificate-Name-Flag è stato modificato, consentendo ulteriori indagini sull'account responsabile dell'azione.

DSP mostra anche chi ha modificato il modello CA(Figura 7), consentendo di indagare sull'account responsabile della modifica e di individuare ulteriori attività sospette.

Figura 7. Anche il nostro registro DSP conferma che il CiscoSSLVPN Il modello di certificato è stato modificato dall'opzione TestPC$ conto del computer.

Creazione di una trappola honeypot con un modello di certificato esca: Esempio 2

Il WebServer Il modello di certificato è comunemente usato per emettere certificati SSL/TLS per Windows Server Update Services (WSUS), Active Directory Federation Services (ADFS), server web Internet Information Services (IIS) e bilanciatori di carico. Garantisce una comunicazione crittografata su HTTP. Per impostazione predefinita, è configurato con Supply in Requestma poiché l'uso esteso della chiave (EKU) è impostato su Server Authentication, ESC1 non può essere sfruttato (Figura 8).

Figura 8. In questo caso, PowerShell visualizza gli attributi del file WebServer modello di certificato, dimostrando che Supply in Request (CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT) è abilitato, ma l'EKU è impostato su Server Authentication.

Per preparare la nostra trappola, si può iniziare duplicando il file WebServer e dargli un nome realistico per farlo sembrare legittimo. Quindi, modificate la DACL per farla apparire come una configurazione legittima, consentendo un account di computer falso, come ad esempio WSUS-2016per iscriversi.

Allo stesso tempo, si configura intenzionalmente in modo errato il modello concedendo le autorizzazioni di scrittura agli utenti autenticati(Figura 9), creando così un'opportunità di sfruttamento.

Figura 9. L'output di PowerShell mostra il modello di certificato WebServer modificato, in cui un account computer falso (WSUS-2016$) ha i permessi Enroll e gli Utenti autenticati sono stati configurati in modo errato con i permessi di scrittura, rendendo il modello vulnerabile allo sfruttamento.

Figura 10 mostra l'aspetto della ricognizione per un attaccante che identifica i modelli di CA sfruttabili, dove gli utenti autenticati hanno i permessi di scrittura sull'esca. WSUSSSLCert modello.

Figura 10. Questo output di PowerShell mostra il WSUSSSLCert modello di certificato, dove gli Utenti Autenticati hanno WriteProperty che consente loro di modificare attributi come EKU.

Ora, il nostro attaccante esamina i valori correnti degli attributi AD di questo modello di CA, concentrandosi in particolare sull'attributo msPKI-Certificate-Application-Policy che definisce l'uso consentito del certificato (Figura 11).

Figura 11. Output di PowerShell che visualizza gli attributi del file WSUSSSLCert modello di certificato, evidenziando il msPKI-Certificate-Application-Policy valore. L'identificatore dell'oggetto 1.3.6.1.5.5.7.3.1 corrisponde ad Autenticazione del server.

Ora, modificano questo modello di CA per renderlo sfruttabile ESC1, quindi controllano come la msPKI-Certificate-Application-Policy cambia il valore (Figura 12).

Figura 12. PowerShell mostra la modifica del file WSUSSSLCert modello di certificato, dove l'elemento msPKI-Certificate-Application-Policy è stato cambiato in 1.3.6.1.5.5.7.3.2abilitando l'autenticazione del client. Questa modifica rende il modello vulnerabile all'ESC1.

Come Figura 13 mostra, il msPKI-Certificate-Application-Policy è stato aggiornato con un diverso Object Identifier, che ora corrisponde all'Autenticazione del client.

Figura 13. PowerShell mostra la versione aggiornata WSUSSSLCert modello di certificato, dove l'elemento msPKI-Certificate-Application-Policy è stato modificato in 1.3.6.1.5.5.7.3.2abilitando l'autenticazione del client. Ora, il modello non è solo vulnerabile, ma è anche sfruttabile per l'ESC1.

Il passo finale del nostro aggressore è quello di concedere i permessi di iscrizione al modello di CA, consentendogli di sfruttarlo(Figura 14).

Figura 14. Questo snippet mostra come l'attaccante abbia concesso agli Utenti autenticati i permessi di registrazione sul file WSUSSSLCert utilizzando PowerView.

Dal lato della difesa AD: in DSP, ora c'è una voce nel registro delle modifiche AD che indica che qualcuno ha modificato questo specifico attributo AD sul modello CA(Figura 15).

Figura 15. Il nostro registro DSP mostra una modifica al WSUSSSLCert modello di certificato, dove l'elemento msPKI-Certificate-Application-Policy è stato cambiato da Autenticazione server ad Autenticazione client.

Nel DSP verrà registrata un'altra voce che indica che l'attributo Security Descriptor è stato modificato nel modello di CA esca (Figura 16).

Figura 16. Il registro di DSPrivela la modifica del descrittore di sicurezza sul server di DSP. WSUSSSLCert Modello CA.

La chiave delle esche nella difesa AD: Creare una regola di notifica in DSP

In DSP è possibile creare una regola di notifica per i modelli di certificati decoy(Figura 17), in modo che qualsiasi modifica apportata a tali modelli faccia scattare un avviso.

Figura 17. Questa regola di notifica DSP , impostata per il WSUSSSLCert è configurato per attivare un avviso ogni volta che viene apportata una modifica al modello di certificato. msPKI-Certificate-Application-Policy attributo.

Quando qualcuno modifica questo attributo AD sul modello di CA esca, DSP invia una notifica via e-mail che include i dettagli su chi ha effettuato la modifica, su quale controller di dominio è avvenuta e altre informazioni rilevanti(Figura 18).

Figura 18. Una notifica via e-mail da parte di DSP avvisa l'utente delle modifiche apportate al modello di CA esca.

Istantanea Semperis

Per le organizzazioni che utilizzano l'ADCS, la creazione di trappole honeypot può essere un modo prezioso per rilevare gli aggressori prima che possano scalare i privilegi. Le errate configurazioni dell'ADCS sono sempre più sfruttate negli attacchi del mondo reale, come evidenziato dal rapporto di Mandiant4 sulle tattiche di post-exploitation di Ivanti. Distribuendo modelli di certificati esca che appaiono vulnerabili ma sono strettamente monitorati, i difensori dell'AD possono attirare gli aggressori a rivelarsi nel momento in cui tentano lo sfruttamento.

Ulteriori informazioni sulla difesa proattiva di Active Directory

Riferimenti

  1. https://specterops.io/wp-content/uploads/sites/3/2022/06/Certified_Pre-Owned.pdf
  2. https://attack.mitre.org/techniques/T1649/
  3. https://github.com/GhostPack/Certify
  4. https://cloud.google.com/blog/topics/threat-intelligence/ivanti-post-exploitation-lateral-movement