Alla ricerca degli ospiti non invitati in AD: controlliamo i permessi su AdminSDHolder
Se conosci AD saprai anche cosa è il container AdminSDHolder e che che viene spesso usato per garantirsi persistenza in ambienti compromessi. In rete si trova di tutto, ma consiglio di partire da qui o leggere la documentazione di Microsoft qui.
In due parole: questo container ha applicate delle ACL (o, per i più precisi una ACL con diverse ACE dentro). Regolarmente il servizio Security Descriptor Propagation (or SDPROP) legge questa ACL e la usa come template per applicarla agli oggetti contenuti nei Protected Groups di AD.
Questo perché le ACL di questi gruppi protetti/importanti vengono di solito compromesse col fine di garantirsi un accesso poco visibile: ad esempio garantire ad un utente ordinario e non privilegiato di poter aggiungere account al gruppo Domain Admins oppure consentire di operare come Account Operator.
Il problema è che se viene compromessa l'ACL di AdminSDHolder il risultato è l'opposto di quanto vorremmo: un gruppo protetto con le permission buone potrebbe trovarsele modificate con quelle corrotte e non c'è verso di ricambiarle a mano: SDPROP rimetterà sempre quelle del container compromesso.
Quindi l'idea è quella di controllare che i permessi sul container non vengano modificati o, quantomeno, di essere avvisati se avviene un cambiamento. Ho scritto questa libreria Powershell per automatizzare questo lavoro. L'operazione avviene in due fasi:
- Si salva la ACL "sana"
- Si controlla ad intervalli regolari che la ACL sia sempre quella prevista e in caso di anomalie è possibile inviare degli allarmi.
Il modulo comprende diverse funzioni è l'idea è quella di fare dot-sourcing del file e chiamare le funzioni contenute. Questo può essere fatto con 4 righe di Powershell pianificate con lo Scheduler di Windows oppure inserite negli script di monitoraggio di Zabbix, LibreNMS, Cacti, Nagios, SNMP ecc...
Tutte le funzioni possono essere usate con Get-Help per vedere parametri ed esempi d'uso, uno degli scopi che mi ha portato a scrivere questo codice è proprio il recupero di alcune competenze su Powershell e scoprire nuovi modi di scrivere il codice. In breve, due fasi:
- Salvare la configurazione attuale con:
Output-SDH-ACL
Questo commando salva la ACL in un file XML che per default di chiama sdh-original-acl.xml.
Nome e percorso possono essere modificati con il parametro -XmlOutputFile parameter. Questo file va mantenuto in una posizione sicura essendo il riferimento per i controlli successivi. Ad esempio potrebbe stare su una share in read-only per tutti. Il salvataggio della ACL "buona" dovrebbe essere fatto una volta sola, o comunque raramente quando avvengono cambiamenti che modificano legittimamente AdminSDHolder. - Questa funzione invece va chiamata regolarmente (una volta ogni ora, giorno, ...):
Compare-SDH-ACL
Per default legge lo stesso file di output della funzione precedente, ma può essere indicato un file qualsiasi puntandolo con -XmlInputFile
Compare-SDH-ACL ritorna True se tutto va bene, False altrimenti. Lo script di controllo può essere quindi molto semplice, ad esempio:
. .\sdh-check.ps1
if (Compare-SDH-ACL) {
Write-Console "Tutto sembra a posto"
} else {
# Invio una mail di allarme ad esempio con Send-MailMessage
}
Ci sono diverse funzioni usate internamente che possono essere usate, basta leggere codice o documentazione.
Nello specifico ce n'è una ad uso generale che si chiama Compare-SDH-Files e che serve a verificare le ACL in
due file invece del normale controllo file/AD live.Tutti i comandi supportano il parametro -Verbose per avere qualche informazione in più.
Se questo script ti è utile o vuoi mandarmi qualche suggerimento, anche su come scrivere meglio codice Powershell, usa questo link.