Non puoi annullare un segreto che è già stato letto

Immagina una cassaforte per documenti che contiene preziosa proprietà intellettuale. Una spia assoldata la apre, fotografa i documenti al suo interno, la richiude e se ne va. La mattina dopo, la cassaforte ha lo stesso aspetto della sera prima: stessa porta, stessa combinazione, nulla spostato. Non c'è nulla da rimettere a posto, perché, nei termini che uno strumento di ripristino può comprendere, non è stato portato via nulla. La perdita ha già lasciato l'edificio sotto forma di copia.

Questa è la forma scomoda che assume un'ampia classe di attacchi ad Active Directory, ed è il motivo per cui la narrazione difensiva preferita dal settore ha un vuoto al centro.

Da un decennio, il mercato della sicurezza di Active Directory compete su un unico asse: la velocità con cui si riesce ad annullare una modifica dannosa. Rilevare la scrittura dannosa, generare un avviso, quindi ripristinare uno stato noto e sicuro. Il tracciamento delle modifiche a prova di manomissione e il rollback automatico sono l'intera proposta di valore. Come storia di ripristino è una buona storia, e il ripristino conta davvero. Ma concede il punto che conta davvero. La modifica è già avvenuta, e alcune modifiche, una volta avvenute, non si possono disfare.

Gli attacchi ad Active Directory che si concludono prima che tu possa annullarli

Considera come funzionano davvero gli attacchi AD più veloci. I gruppi ransomware concatenano vulnerabilità come noPac, la coppia di spoofing del sAMAccountName alla base di CVE-2021-42278 e CVE-2021-42287, per passare da un account ordinario al pieno controllo del dominio in pochi minuti. Una volta che l'attaccante raggiunge quella posizione, le tecniche successive non sono atti di vandalismo rumorosi da sistemare in seguito. Sono letture e impersonificazioni che completano il proprio lavoro prima che un rollback abbia qualcosa da recuperare.

DCSync è l'esempio più chiaro e il parallelo diretto con la storia della cassaforte. Abusando del protocollo di replica del directory stesso, l'attaccante chiede a un domain controller gli hash delle password degli account e li riceve come farebbe un altro controller. Non resta alcun oggetto alterato nel directory che uno strumento di ripristino possa notare e annullare. La modifica, per quanto tale, è una copia delle tue credenziali che è già uscita. Puoi reimpostare tutte le password in seguito, e dovresti farlo, ma a quel punto stai ripulendo dopo un furto, non fermandolo.

DCShadow agisce nella direzione opposta. Registra un domain controller illegittimo e fraudolento e inietta nel directory modifiche scelte dall'attaccante attraverso il canale di replica, bypassando il normale percorso di scrittura monitorato dai tuoi controlli. Qui il controllo efficace rifiuta la replica fraudolenta nell'istante in cui viene tentata, così la modifica iniettata non entra mai nel directory e non c'è nulla da annullare.

Prendi ora una modifica dannosa a un oggetto Criteri di gruppo (GPO), del tipo che distribuisce un payload ransomware a ogni macchina che legge il criterio, oppure una discreta aggiunta a un gruppo con privilegi. Ripristina l'oggetto e lo stato del directory viene ristabilito. Eppure il criterio è già stato distribuito e il payload che trasportava è già stato eseguito. Ripristinare l'oggetto non fa nulla contro il raggio d'impatto già generato.

È qui che la narrazione del ripristino finisce lo spazio a disposizione. Per questa intera categoria, rilevamento e rollback arrivano, per loro stessa struttura, troppo tardi, e la prevenzione non è una versione più veloce della stessa idea: è una disciplina diversa. Il rilevamento conferma che qualcosa di pericoloso ha già raggiunto il directory. La prevenzione blocca l'operazione prima che il directory arrivi ad accettarla.

Rilevamento contro prevenzione: un attacco a un GPO, ragionato in entrambi i modi

Supponi che un attaccante modifichi un GPO collegato ai tuoi server per distribuire un payload al successivo aggiornamento dei criteri. Ragionaci prima secondo il modello di ripristino. L'impostazione dannosa viene rilevata e ripristinata, e il GPO torna al suo stato precedente; sulla carta, l'incidente è chiuso. In pratica, ogni macchina che ha scaricato il criterio nella finestra di tempo tra la modifica e il ripristino ha già eseguito il payload, e nessun ripristino dell'oggetto può disfare quell'esecuzione.

Ora ragionaci nell'altro modo. La scrittura su quel GPO viene valutata inline e respinta prima che Active Directory la confermi (commit). Il criterio non cambia mai, quindi non viene mai distribuito, e non resta alcuna esecuzione del payload da analizzare. Stesso attacco, due modelli difensivi, e solo uno dei due non ti lascia nulla da ripulire.

Perché la parola giusta è prevenzione, non rilevamento rapido

Questo secondo esito è disponibile solo a un controllo che si trovi nel percorso di scrittura stesso. Questo è il meccanismo alla base di Netwrix Threat Manager: valuta le operazioni inline (modifiche a oggetti critici e GPO, modifiche ai gruppi con privilegi e richieste di replica) e le blocca alla fonte, prima che il directory confermi la scrittura. Cattura inoltre questi eventi nel loro punto di origine anche quando il logging nativo è stato disabilitato o cancellato, così un attaccante non può accecare il controllo cancellando prima i log. È questo che guadagna la parola prevenzione, invece di un rilevamento rapido travestito da un linguaggio più forte.

Nulla di tutto ciò significa che la prevenzione sostituisca il rilevamento. Alcuni attacchi possono essere individuati e affrontati solo a posteriori, e fingere il contrario non supera la prima domanda diretta che qualsiasi CISO competente porrà. Promettere troppo attira la risposta che merita. La posizione difendibile è più circoscritta e più solida di uno slogan: prevenzione al primo posto per le modifiche che si possono bloccare in modo deterministico, rilevamento e risposta per tutto il resto.

Alla base di tutto questo c'è una visione coerente. Insistere nel bloccare una modifica pericolosa nel momento in cui viene tentata è la controparte, sul fronte della resilienza, dell'insistere nel sapere chi detiene l'accesso nel momento in cui lo utilizza. Entrambe le posizioni insistono nell'agire nell'istante dell'azione, non nella ripulitura che segue.

Il che ci riporta alla cassaforte che sembrava intatta. Il rollback è una promessa che puoi disfare il danno rapidamente. La prevenzione è una garanzia che non c'era alcun danno da disfare. Per gli attacchi ad Active Directory che copiano un segreto, impersonano un controller o esplodono prima che tu possa annullarli, solo una di queste due è una promessa che il meccanismo può davvero mantenere, ed è quella fatta dal controllo che non ha mai lasciato che la modifica venisse confermata (commit).