~/docs/ldap_enumeration.check

di

Enumeration

Quando si parla di enumerazione (enumeration) si parla di tutte quelle operazioni eseguite sui sistemi atte a restiture informazioni relative al contesto per il quale si sta interrogando.

Nel caso specifico di oggi parleremo di enumerazione del servizio LDAP.

Event 1644

L’evento in questione registra un log sull’event viewer per ogni ricerca LDAP effettuata da un client nella directory che viola le soglie di ricerca poco costose e/o inefficienti.

Abilitare questo controllo non è solo utile per trovare sulla rete quali client effettuano ricerche LDAP, ma trova utilità anche nell’ambito della sicurezza per identificare – per esempio – tool come BloodHound o ADRecon: tool usati da pentester per scoprire in un dominio Windows – durante la fase di post exploitation – l’ambiente Active Directory ed eventuali punti deboli.

Come abilitarlo

Per ottenere questo evento, da PowerShell, dare i seguenti comandi sui controller di dominio

PS C:\> Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Services\NTDS\Diagnostics' -Name '15 Field Engineering' -Value "5"

Questo comando modifica la chiave di registro indicata andando ad settare la chiave “15 Field Engineering” al valore 5. Il valore 5 indica l’imperativo di loggare tutte le query, includendo tutte le informazioni a livello di debug.

PS C:\> Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Services\NTDS\Parameters' -Name 'Expensive Search Results Threshold' -Value "0"

Una ricerca è considerata “costosa” se deve interrogare un gran numero di oggetti in Active Directory. “Expensive Search Results Threshold” indica tutte le query che restituiscono un alto numero di occorrenze (di default la soglia è a 10.000). Settando il valore a “0” verranno mostrate tutte le query quindi attenzione: si potrebbero, specialmente in ambienti di grandi dimensioni, verificare moltissimi falsi positivi. Settare con cautela!

C:\> Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Services\NTDS\Parameters' -Name 'Inefficient Search Results Threshold' -Value "0"

Una ricerca è considerata inefficiente se restituisce meno del 10% del totale degli oggetti visitati. La soglia predefinita per una query costosa è 10.000. Ciò significa che qualsiasi ricerca che visiti 10.000 o più oggetti sarebbe considerata costosa. Il limite inferiore predefinito per una query inefficiente è 1.000. Se una query visitasse 1.000 oggetti e ne restituisse solo 99 (meno del 10%), sarebbe considerata inefficiente. Se invece restituisse 900, non verrebbe considerato inefficiente. Per riassumere, con 1.000 come soglia inferiore predefinita, nessuna ricerca che visiti meno di 1.000 voci (anche se ne visitasse 999 e restituisse 0) sarebbe considerata inefficiente.

C:\> Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Services\NTDS\Parameters' -Name 'Search Time Threshold (msecs)' -Value "120"

La più semplice: tutte le query che prendono più di 120 ms a rispondere verranno loggate.

Conclusioni

Come è facile intuire abilitare questo controllo è semplice e migliora la visibilità sulle nostre infrastrutture.

È bene però tenere a mente la gestione delle soglie: in un contesto enterprise, probabilmente, non è consigliato settare i valori a 0 (logga tutto) onde evitare di inondare di eventi il SIEM con conseguente generazione di falsi positivi. Procedere per gradi quindi, rimane sempre la soluzione migliore!

EOF

1 commento su “~/docs/ldap_enumeration.check”

  1. Interessante articolo sulla detection di BH e altri tools che interrogano massivamente AD.
    Suggerisco un altro metodo, altrettanto valido.
    Creare degli oggetti “esche” in AD, per rilevare attività di enumerazione del dominio.
    Le esche dovrebbero avere poi dei nomi che dovranno rispecchiare dei veri e propri utenti.

    Requisito è che AD sia configurato correttamente con i criteri di registrazione avanzati abilitati, necessari per eseguire questa operazione.

    L’unico criterio necessario per rilevare questo processo di enumerazione è ” Directory service Access Audit”.
    Nei domain controller è abilitato di default, tuttavia se non lo fosse si può utilizzare il comando
    auditpol /set /subcategory:”Directory Service Access” /Success:Enable

    Per la creazione degli oggetti esca, si può pensare di creare:
    1 o più oggetti di tipo User
    1 o più oggetti di tipo Computer
    1 o più oggetti di tipo Group

    da distribuire/posizionare all’interno della struttura di AD.
    Una volta create le esche si procede nel attivare l’auditing :
    tasto destro sull’oggetto –> Security –> Advanced –> Auditing e aggiungere una nuova entry con ADD poi:
    – come Principal aggiungere EveryOne
    – su Applies selezionare This object only
    – su permession selezionare solo Read all properties, Read permissions.

    Tutte le attività correlate all’enumerazione di AD tramite SharpHound, ADFind, ecc. “toccheranno” anche
    gli account esca, e verrà generato event ID 4662 negli eventi di sicurezza di Windows.

    Successivamente sul Siem di riferimento si può creare una detection rule che includa gli oggetti esca creati precedentemente.
    Nel momento in cui questi oggetti verranno interrogati simulataneamente, potremmo pensare che sia in corso una query LDAP espansiva.

    NOTA: tale approccio potrebbe generare dei falsi positivi. Effettuare del tuning qualora vi siano servizi che eseguono query LDAP di tipo massivo.

    Rispondi

Rispondi