L'Active Directory è, ancora oggi, la strada più battuta verso il controllo completo di un dominio. Non perché sia intrinsecamente insicuro, ma perché anni di deleghe, permessi ereditati, template di certificato lasciati aperti e account di servizio dimenticati creano percorsi che portano da un utente qualsiasi fino a Domain Admin, l'account che ha il controllo completo del dominio. Un attaccante che ottiene un punto d'appoggio interno raramente sfrutta una vulnerabilità software: risale l'identità.

Il mercato ha risposto con strumenti dedicati — PingCastle, Purple Knight e simili — che fotografano la postura dell'AD. Sono strumenti validi, ma vivono isolati: girano una volta, producono un report a parte, e non sanno nulla dell'esposizione esterna o della superficie interna che il cliente ha già mappato altrove. Il risultato, per chi eroga sicurezza come servizio, è un silo in più da gestire.

RECON affronta il problema da un'angolazione diversa. L'assessment dell'Active Directory non è un prodotto separato: è una capacità aggiuntiva della stessa piattaforma — e della stessa sonda — che già esegue lo scanning esterno e interno del cliente. Una sonda, una vista correlata, un unico contratto.

La risposta di RECON è pensata proprio per superare quella conversazione. Nessun agente viene installato: né sui domain controller né sugli endpoint. Il collector effettua una singola lettura autenticata della directory, con i soli diritti di un normale utente di dominio, esattamente come farebbe uno strumento di postura — legge, non scrive mai.

La credenziale amministrativa, quando serve, viene usata una volta sola per generare un account collector dedicato in sola lettura, e poi distrutta (crypto-shredded): non finisce mai su disco, in un log o in un campo permanente. In alternativa, l'organizzazione può fornire direttamente un account read-only, senza consegnare alcuna credenziale privilegiata. Tutta l'analisi pericolosa — Tier-0, attack path, abuso dei certificati, calcolo del punteggio — avviene poi lato server, sui dati raccolti, senza toccare di nuovo il dominio vivo. L'invariante è esplicito e non negoziabile: rileva, non sfrutta mai.

Per un partner questo si traduce in un dato commerciale concreto: l'ostacolo tecnico che di solito rallenta la firma — "non voglio software privilegiato sui miei DC" — semplicemente non si presenta.

Il primo livello è un inventario dell'identità: ogni utente, gruppo, computer, unità organizzativa e GPO che la directory espone, raccolto in un elenco filtrabile. Su un'organizzazione di medie dimensioni si tratta facilmente di oltre mille oggetti. Ciò che li rende leggibili sono i marcatori: gli oggetti privilegiati e quelli di Tier-0 vengono evidenziati. Il Tier-0 è l'insieme degli account e dei sistemi più potenti del dominio — i Domain Admins, i domain controller e tutto ciò che può controllarli; chi ottiene il Tier-0 ottiene di fatto l'intero dominio, ed è per questo il primo perimetro da difendere. Accanto agli oggetti compaiono poi i flag di rischio — un adminCount=1 fuori posto (la traccia che un account è, o è stato, privilegiato), un ultimo accesso troppo vecchio, un gruppo sensibile esposto più del dovuto.

E tutto questo si condensa in un unico numero: un voto di postura del dominio, da A a F (da 100 in giù). Il team di sicurezza può aprirlo e vedere i finding pesati dietro al numero; il board lo può leggere senza mediazione tecnica. È la differenza tra consegnare al cliente un muro di finding e consegnargli una frase: ecco quanto è esposto il tuo dominio, ed ecco cosa sistemare per primo.

Un esempio aiuta a capire la forma del risultato. Non è raro che un singolo elemento — un account computer, un account di servizio, un gruppo mal delegato — si riveli il punto di passaggio di una dozzina di percorsi diversi, ciascuno con un punteggio di confidenza e di sforzo stimato. In un caso simile la console non si limita a dire "hai un problema": indica quale singolo nodo presidiare per spegnere il maggior numero di rotte in una mossa sola. E ogni finding porta con sé la propria remediation: per un'ACL pericolosa su un oggetto domain controller, per esempio, l'istruzione precisa è rimuovere i diritti Write/AllExtendedRights/AddKeyCredentialLink detenuti da principal non-Tier-0.

Lo stesso principio vale per i Certificate Services, la PKI interna, tra le vie più abusate verso Domain Admin: RECON legge template e certification authority e classifica le misconfigurazioni note dell'infrastruttura a chiavi pubbliche. «ESC» sta per Escalation: è la sigla con cui la community di sicurezza cataloga le tecniche di abuso di AD CS, una famiglia numerata da ESC1 a ESC16 in cui ogni voce descrive un modo diverso in cui una PKI mal configurata concede a un utente comune privilegi che non dovrebbe avere. ESC1, per esempio, è il caso in cui un template di certificato lascia a chi ne fa richiesta la libertà di indicare da sé l'identità da scrivere nel certificato e ne consente l'uso per l'autenticazione: in pratica un utente qualunque può farsi rilasciare un certificato che lo fa passare per un account molto più potente.

RECON classifica ognuna di queste voci con un'onestà rara — confermato, candidato o detect-only. Un ESC1 confermato significa che un utente non privilegiato può già ottenere quel certificato; un candidato resta marcato come tale finché l'abuso non è provato. Il cliente non legge mai un "critical" gonfiato che nessuno ha dimostrato — e questa onestà, controintuitivamente, è uno degli argomenti di vendita più solidi che si possano portare.

Per il partner non è "un altro strumento da vendere": è una capacità in più su un'infrastruttura già installata, che apre un servizio ricorrente, accorcia la vendita e rende il valore misurabile a ogni scansione.

I passi successivi sono concreti: un walkthrough guidato dell'assessment sul dominio reale del cliente; il deploy della sonda in una sola rete per vedere in un unico passaggio scanning interno, OT/ICS e Active Directory; e la revisione dei percorsi vivi verso Domain Admin, con il chokepoint da rompere indicato per primo.

Per approfondire: [email protected] · orizon.one/services/recon