Individua i percorsi di attacco Active Directory prima di un avversario
EtcSec esegue 340 rilevazioni nominate in 14 categorie Active Directory. La copertura è costruita attorno ai failure di controllo che ricorrono nelle reali catene di compromissione: abuso di Kerberos, deriva del Tier 0, percorsi di takeover via ACL, impostazioni GPO insicure, esposizione dei trust ed escalation tramite certificati ADCS.
La raccolta resta in sola lettura. ETC Collector interroga LDAP o LDAPS, legge SYSVOL via SMB per l’analisi GPO e può aggiungere sonde di rete opt-in per superfici sensibili come spooler o stack TLS deboli. Nessun agente viene installato sui domain controller e nessun oggetto AD viene modificato.
L’audit nomina i finding concreti dietro il rischio: PASSWORD_NOT_REQUIRED, REVERSIBLE_ENCRYPTION, PASSWORD_NEVER_EXPIRES, ADMIN_ASREP_ROASTABLE, KERBEROASTING_RISK, GOLDEN_TICKET_RISK, WEAK_ENCRYPTION_DES, oltre ai finding di delega su utenti e computer.
Invece di un unico bucket di privileged accounts, la piattaforma distingue admin obsoleti, flag adminCount orfani, account di servizio in gruppi sensibili, foreign security principals e gap nei Protected Users.
ACL_GENERICALL, ACL_WRITEDACL, ACL_WRITEOWNER, ACL_SELF_MEMBERSHIP, WRITESPN_ABUSE e i pattern ACE correlati emergono come finding individuali per mostrare quale oggetto, quale trustee e perché quel permesso conta.
Il livello Pro aggiunge controlli ESC1 fino a ESC11, tre detector basati su grafo di attacco e mapping CIS, NIST SP 800-53, ANSSI e DISA STIG. Così l’audit può spiegare percorsi di escalation e non solo problemi di hygiene.
Le 14 categorie corrispondono direttamente ai modi reali con cui AD viene compromesso
Il catalogo è ampio ma non casuale. Ogni categoria chiude un punto cieco specifico nella catena di attacco, dalle password deboli e Kerberos fino all’infrastruttura certificati ADCS e ai gap di monitoraggio.
Account privilegiati e Tier 0
33 rilevazioni su admin obsoleti, account di servizio in gruppi privilegiati, abuso di SID history, shadow credentials, gap nei Protected Users e foreign security principals.
Kerberos e delega
14 rilevazioni su AS-REP roasting, Kerberoasting, delega constrained e unconstrained, età del krbtgt, condizioni di downgrade RC4/DES e target di delega sconosciuti.
Password e autenticazione
10 rilevazioni su storage in chiaro, cifratura reversibile, età delle password e account in cui gli utenti non possono ruotare da soli la password.
GPO e hardening di Windows
33 rilevazioni che coprono password in SYSVOL, WDigest, Zerologon, PrintNightmare, UNC hardening, protezione LSA, firewall e abuso di privilegi.
Escalation tramite certificati ADCS
11 rilevazioni che coprono la tassonomia ESC1-ESC11: template vulnerabili, ACL della CA, SAN permissivo, mapping deboli e superfici HTTP o RPC esposte a relay.
Permessi, trust, monitoraggio, rete e conformità
Analisi ACL, confini di trust, qualità della audit policy, firma LDAP o SMB, sicurezza DNS e mapping di conformità nello stesso workflow.
Perché i team di sicurezza usano EtcSec per review AD ricorrenti
Molti tool AD restano ottimizzati per un report HTML una tantum. EtcSec è progettato per esecuzioni ripetute, liste di remediation concrete e un modello di raccolta difendibile dal punto di vista operativo.
Raccolta in sola lettura
ETC Collector si autentica con un account di directory in sola lettura e accesso SMB in lettura a SYSVOL. Non modifica utenti, gruppi, GPO o oggetti PKI.
Veloce abbastanza per il ritmo operativo
Il dominio pubblicato con 546 utenti, 100 computer e 154 gruppi termina in 6,58 secondi con le network probe abilitate. Gli ambienti piccoli e medi possono essere rivalutati dopo cambi di ruolo o finestre di manutenzione.
Finding nominati invece di un numero opaco
Gli operatori ricevono finding concreti con severità e contesto oggetto. Questo rende più semplice assegnare il lavoro successivo a IAM, Windows, PKI o team applicativi.
Un solo workflow per standalone e SaaS
Lo stesso collector può girare localmente in modalità standalone server oppure essere arruolato come daemon per alimentare EtcSec con storico e orchestrazione multi-site.
Cosa deve spiegare agli operatori un audit Active Directory completo
Una landing page sulla sicurezza AD è utile solo se spiega come vengono raccolti i dati, quali categorie contano davvero e come i finding si collegano a remediation e governance. Le sezioni seguenti seguono come fonte il catalogo pubblicato e la documentazione del collector.
Modello di raccolta, fonti di evidenza e aspettative di runtime
L’audit Active Directory inizia con raccolta LDAP parallela di utenti, gruppi, computer, OU, impostazioni di dominio, relazioni di trust e security descriptor. L’analisi GPO legge SYSVOL via SMB per interpretare registry.pol, GptTmpl.inf e gli script referenziati. Se sono configurati dati Azure o Entra, restano in un flusso separato e non modificano il percorso di raccolta AD.
Il punto operativo chiave è che non occorre installare nulla su un domain controller. Il workflow è raccolta, parsing, analisi, costruzione del grafo e risposta. Questo rende la catena di evidenza spiegabile durante review interne: si può indicare quale protocollo è stato usato, quale classe di oggetto è stata interrogata e perché è stato emesso un finding.
Le 14 categorie e ciò che ciascuna dimostra
| Categoria | Controlli | Cosa dimostra all’operatore |
|---|---|---|
| Password | 10 | Se la configurazione degli account espone già password in chiaro, reversibili, vecchie o mal gestite. |
| Kerberos | 14 | Se ticketing, pre-auth, delega o cifratura aprono percorsi di roasting, downgrade o impersonation. |
| Accounts | 33 | Se account privilegiati e di servizio sono derivati verso stati che aumentano persistenza o takeover. |
| Groups | 15 | Se membership in gruppi sensibili concentrano o nascondono privilegio. |
| Computers | 31 | Se workstation e server lasciano aperte superfici di movimento laterale o delega sfruttabile. |
| Advanced | 50 | Se firma LDAP o SMB, diritti DCSync, quote o AdminSDHolder abilitano attacchi più profondi. |
| Permissions | 21 | Se le ACL danno controllo sufficiente per resettare password, modificare SPN o riscrivere DACL. |
| ADCS | 11 | Se l’infrastruttura certificati consente abuso stile ESC ed escalation basata su certificati. |
| GPO | 33 | Se la distribuzione di policy di dominio perde password o disabilita protezioni critiche di Windows. |
| Trusts | 7 | Se i confini di trust mancano di SID filtering, selective auth o protezioni Kerberos moderne. |
| Attack Paths | 3 | Se l’analisi a grafo può mostrare rotte esplicite di escalation verso Domain Admin. |
| Monitoring | 9 | Se la audit policy è sufficiente per detection e incident response. |
| Compliance | 23 | Se gli stessi finding possono essere riutilizzati come evidenza per CIS, NIST, ANSSI o DISA. |
| Network | 15 | Se LDAP, SMB, DNS e configurazioni di rete non espongono ancora relay o trasporti deboli. |
Le famiglie di detection che guidano davvero la remediation
Esposizione di credenziali e gestione debole delle password
La categoria Password nomina i problemi che helpdesk e team IAM devono davvero ripulire: PASSWORD_NOT_REQUIRED, REVERSIBLE_ENCRYPTION, PASSWORD_CLEARTEXT_STORAGE, UNIX_USER_PASSWORD, PASSWORD_IN_DESCRIPTION e PASSWORD_VERY_OLD.
- Separa configurazione dell’account da debolezza di policy.
- Rileva descrizioni rischiose e attributi Unix, non solo flag UAC.
- Fornisce liste di oggetti azionabili, non solo uno score.
Abuso di Kerberos
ADMIN_ASREP_ROASTABLE, ASREP_ROASTING_RISK, GOLDEN_TICKET_RISK, UNCONSTRAINED_DELEGATION, KERBEROASTING_RISK, KERBEROS_AES_DISABLED e DELEGATION_UNKNOWN_TARGET spiegano perché l’ambiente è sfruttabile, non solo che Kerberos è “debole”.
- Isola i casi AS-REP privilegiati dal resto del parco.
- Copre sia downgrade di cifratura sia errori di delega.
- Rende visibile l’igiene del krbtgt come rischio di persistenza.
Deriva di Tier 0 e account di servizio
L’esposizione privilegiata si distribuisce fra SERVICE_ACCOUNT_PRIVILEGED, SERVICE_ACCOUNT_INTERACTIVE, ADMIN_COUNT_ORPHANED, PRIVILEGED_ACCOUNT_STALE, NOT_IN_PROTECTED_USERS e FOREIGN_SECURITY_PRINCIPALS.
- Utile quando l’ownership è divisa tra IAM, messaging e team applicativi.
- Aiuta a pulire privilegi residui e non solo a rilevarli.
- Rende visibili gruppi operatori e built-in spesso dimenticati.
Takeover via ACL e condizioni DCSync
I finding di Permissions mostrano GenericAll, WriteDACL, WriteOwner, self-membership, ForceChangePassword e diritti di replica fuori dai normali account DC, con oggetto e trustee responsabili.
- L’output serve alla remediation, non solo al grafo di attacco.
- Le identità DCSync-capable sono visibili direttamente.
- WriteSPN e reset password sono separati perché il loro abuso è diverso.
GPO e hardening di Windows
GPO_PASSWORD_IN_SYSVOL, HARDENED_UNC_PATHS_WEAK, WDIGEST_ENABLED, LSA_PROTECTION_DISABLED, ZEROLOGON_PATCH_ENFORCEMENT, PRINTNIGHTMARE_VULNERABLE e abuso di privilegi legano sicurezza dell’identità e hardening di Windows.
- Importante quando il rischio AD vive nella policy e non solo negli oggetti identità.
- Copre sia esfiltrazione di credenziali sia superfici di esecuzione su larga scala.
- Si assegna bene a owner di endpoint o server.
Escalation tramite certificati e analisi a grafo
I finding ADCS come ESC1_VULNERABLE_TEMPLATE, ESC4_VULNERABLE_TEMPLATE_ACL, ESC8_HTTP_ENROLLMENT e ESC10_WEAK_CERTIFICATE_MAPPING completano i tre finding di attack path che modellano l’escalation via grafo.
- Utile in ambienti dove la PKI è già critica.
- Mostra dove l’infrastruttura certificati crea privilegio.
- Associa finding grezzi e spiegazione del percorso.
La distribuzione per severità conta perché la remediation è multi-team
Il catalogo pondera i finding critici a 10, gli alti a 3, i medi a 1 e i bassi a 0,2. Questo è utile per lo scoring, ma il vero risultato operativo è la distribuzione: pochi temi critici richiedono spesso contenimento immediato, mentre la fascia High e Medium definisce il backlog di hardening.
In pratica, la remediation non ricade quasi mai su un solo team. IAM gestisce gruppi privilegiati e policy password, Windows engineering possiede hardening GPO ed endpoint, PKI gestisce il backlog ADCS e governance si concentra sui mapping di conformità. L’audit deve quindi separare i finding in modo assegnabile.
- Usa i Critical per definire contenimento immediato o hardening urgente.
- Raggruppa gli High per owner: IAM, Windows, PKI o infrastruttura.
- Usa i Medium per backlog ricorrente e review trimestrale.
- Mantieni visibili i Low senza lasciare che nascondano i veri percorsi di privilegio.
Dove finisce il collector open-source e dove EtcSec aggiunge di più
Il collector è l’evidence engine. Gestisce raccolta, parsing, detection, analisi a grafo opzionale e output JSON. In modalità standalone server tutto può restare nella tua infrastruttura con GUI locale e API REST sulla porta 8443. In modalità daemon, lo stesso binario viene arruolato nella piattaforma SaaS e fa polling dei comandi ogni 30 secondi mantenendo locale la raccolta AD.
EtcSec aggiunge a questo layer di raccolta dashboard, trending storico, orchestrazione multi-site e workflow di remediation. I team possono così mantenere la stessa raccolta locale e aggiungere un layer operativo centrale quando serve.
Domande frequenti
Cosa copre esattamente l’audit di Active Directory?
Il catalogo pubblicato elenca 340 rilevazioni in 14 categorie: Password (11), Kerberos (14), Accounts (34), Groups (17), Computers (33), Advanced (50), Permissions (21), ADCS (11), GPO (34), Trusts (7), Attack Paths (3), Monitoring (9), Compliance (81) e Network (15).
Questa composizione è importante perché copre sia oggetti di identità sia controlli Windows attorno all’identità.
L’audit richiede privilegi elevati o un agente sui DC?
No. Il modello documentato si basa su LDAP o LDAPS in sola lettura e lettura SMB di SYSVOL. Nessun agente viene installato sui domain controller e il collector non modifica la directory.
Quanto tempo serve per ottenere un report utilizzabile?
Il benchmark pubblicato su un dominio con 546 utenti, 100 computer e 154 gruppi termina in 6,58 secondi con le sonde di rete attive. Questo consente review ricorrenti dopo cambi importanti e non solo audit annuali.
Come si confronta EtcSec con PingCastle per le review AD?
La documentazione comparativa mostra ETC Collector con 59 regole PingCastle su 61 e 876 punti di rischio su 896, aggiungendo analisi ADCS ESC, grafi di attacco, copertura Entra ID e mapping di conformità che PingCastle non offre.
Pagine correlate alla sicurezza dell’identità
Scopri come lo stesso collector audita Conditional Access, MFA, PIM, permessi applicativi e governance guest in Entra ID.
Ispeziona le rilevazioni nominate e le categorie che alimentano le pagine AD ed Entra.
Comprendi la modalità standalone, il daemon, la GUI locale, la REST API e l’impronta open-source.
Confronta il collector open-source con il layer SaaS per dashboard, scheduling e follow-up.
Avvia il tuo audit Active Directory
Distribuisci il collector, esegui l’audit con credenziali read-only e ottieni un set di finding che team IAM, Windows, PKI e governance possono davvero trattare.