Percorsi script di accesso AD: verificare scriptPath prima delle ACL

Cosa significano i percorsi script di accesso AD

I percorsi script di accesso AD richiedono un inventario e una verifica delle responsabilità prima di modificare i permessi. Un attributo utente valorizzato indica dove è configurato uno script di accesso; non indica se la destinazione esiste, se qualcuno la utilizza ancora o chi può modificarne il contenuto. Considerate il percorso come il punto di partenza per raccogliere le evidenze.

La documentazione dello schema Script-Path di Microsoft identifica scriptPath come il percorso dello script di accesso dell'utente e ammette una stringa nulla. Il parametro ScriptPath di New-ADUser accetta un percorso locale assoluto o un percorso UNC (Universal Naming Convention). Un valore UNC è quindi un'opzione di configurazione documentata. La sua sola presenza non dimostra un controllo degli accessi debole.

Le domande utili sono concrete: quale utente punta a quale destinazione, chi è responsabile della funzione aziendale, quali client la utilizzano e quali entità di sicurezza possono modificarla? Il responsabile dell'account, chi mantiene lo script e l'amministratore del file server possono essere persone diverse. Registrate ogni responsabilità invece di presumere che il proprietario nel file system approvi anche l'utilizzo aziendale.

Come funziona: distinguere assegnazione, contenuto e utilizzo

La verifica comprende tre livelli. L'attributo della directory assegna un percorso. Il file referenziato e le sue dipendenze contengono le istruzioni. Il comportamento effettivo del client all'accesso determina se tali istruzioni vengono utilizzate. Le evidenze di un livello non possono sostituire quelle degli altri.

La tecnica Network Logon Script di MITRE ATT&CK descrive l'abuso di script assegnati tramite Active Directory o Criteri di gruppo e raccomanda di limitarne la scrittura agli amministratori designati. Descrive l'esecuzione con i privilegi dell'utente a cui sono assegnati. Non deducete un'esecuzione come SYSTEM da un rilievo su un percorso di rete. Per indagare un possibile abuso, accertate una capacità non autorizzata di alterare lo script o reindirizzarne l'assegnazione, poi accertate che un client pertinente utilizzi il contenuto modificato. Questo articolo non afferma che si sia verificato uno di questi eventi.

Tenete il scriptPath dell'utente distinto dagli script configurati all'interno di una GPO. Se è coinvolta la distribuzione dei criteri, utilizzate la verifica separata di Read, Apply e dell'ambito delle GPO. Le sue domande su Read per il computer e Apply mirato riguardano il recupero e l'applicazione dei criteri; non stabiliscono chi può riscrivere il file referenziato dall'attributo di un utente.

Esaminate anche il contenuto per individuare dipendenze e credenziali esposte attraverso il processo di verifica appropriato. La verifica esistente delle credenziali nei file SYSVOL, inclusi gli script tratta questo problema. Un inventario dei percorsi non può stabilire se uno script contiene un segreto, e questo flusso di lavoro non ripete l'indagine separata su cPassword.

Rilevamento: inventariare gli utenti, risolvere le destinazioni e ispezionare entrambe le ACL

1. Inventariare i percorsi configurati senza escludere gli utenti disabilitati

Eseguite gli esempi seguenti da un ambiente amministrativo Windows autorizzato con i moduli pertinenti. Sono esempi basati sulla documentazione, non comandi eseguiti su un dominio di un cliente. Sostituite il server, la base di ricerca, le identità e i percorsi di esempio con valori approvati.

La documentazione di Get-ADUser descrive -LDAPFilter, -SearchBase, -Server e il recupero di attributi aggiuntivi con -Properties. Questa query inventaria gli utenti con scriptPath presente, inclusi gli account disabilitati:

Get-ADUser -LDAPFilter '(scriptPath=*)' -SearchBase 'DC=example,DC=com' -Server 'dc01.example.com' -Properties scriptPath | Format-List -Property DistinguishedName,SamAccountName,Enabled,scriptPath

Un'alternativa che utilizza la sintassi di filtro del modulo è:

Get-ADUser -Filter 'scriptPath -like "*"' -SearchBase 'DC=example,DC=com' -Server 'dc01.example.com' -Properties scriptPath | Format-List -Property DistinguishedName,SamAccountName,Enabled,scriptPath

Il modello basato sulla presenza dell'attributo adatta gli esempi di filtri Active Directory di Microsoft. Format-List visualizza le proprietà indicate; conservate anche l'inventario sottostante nel vostro sistema di evidenze approvato. Registrate il controller di dominio interrogato, la base di ricerca, l'ora della raccolta e gli eventuali errori. Una query parziale o non riuscita non è un inventario completo.

Associate ogni utente al percorso e a un responsabile. Mantenete visibili gli account disabilitati come casi del ciclo di vita: chiedete se l'assegnazione è conservata per un rientro previsto, copiata da un modello o obsoleta. Non abilitate un account per provare il suo script. L'assegnazione di un utente disabilitato non dimostra un utilizzo attuale; può comunque identificare una destinazione condivisa con altri utenti.

2. Risolvere la destinazione nel contesto reale del client

Conservate il valore letterale dell'attributo prima di interpretarlo. Per una stringa relativa, identificate la base di risoluzione sul client e nel flusso di accesso pertinenti; non risolvetela rispetto alla directory di lavoro della vostra shell amministrativa. Per un percorso locale assoluto, identificate il client su cui dovrebbe esistere quel file. Per un percorso di rete, identificate il server, la condivisione e il file effettivamente raggiunti dal client di test. Registrate esplicitamente i casi irrisolti.

Chiedete a chi mantiene lo script da quali script, eseguibili, file di configurazione o altre risorse dipende il punto di ingresso. Esaminate anche queste destinazioni. Modificare soltanto l'ACL del punto di ingresso non basta se una dipendenza non verificata fornisce le istruzioni utilizzate dallo script.

Dopo aver risolto un file candidato, questo esempio utilizza i parametri documentati di Test-Path:

Test-Path -LiteralPath '\\files01.example.com\LogonScripts\onboarding.cmd' -PathType Leaf

Leaf verifica un elemento di tipo file; -LiteralPath evita l'interpretazione dei caratteri jolly. Registrate l'identità, il client e gli errori insieme al risultato. Questo test di esistenza non dimostra l'esecuzione riuscita all'accesso, la correttezza dello script o il permesso di modificare il file. Confermate l'utilizzo effettivo tramite un pilota approvato con il responsabile dello script.

3. Ispezionare separatamente i permessi della condivisione e del file system

Sul file server identificato, utilizzate Get-SmbShare per associare il nome della condivisione al suo percorso locale. Poi utilizzate Get-SmbShareAccess per recuperare l'ACL della condivisione. Questi esempi adattano le query -Name documentate:

Get-SmbShare -Name 'LogonScripts' | Format-List -Property Name,ScopeName,Path

Get-SmbShareAccess -Name 'LogonScripts'

Eseguitele sul server che ospita realmente la destinazione. Se è coinvolta una condivisione con ambito specifico, identificate l'ambito e utilizzate il parametro -ScopeName documentato. Una condivisione con un nome simile su un altro server non è un'evidenza per questa destinazione. Conservate ogni entità destinataria, voce Allow o Deny e livello di accesso.

Per NTFS, Get-Acl recupera il descrittore di sicurezza della risorsa in Windows. Dopo aver confermato il percorso locale effettivo, ispezionate il file e la directory che lo contiene:

Get-Acl -LiteralPath 'D:\LogonScripts\onboarding.cmd' | Format-List -Property *

Get-Acl -LiteralPath 'D:\LogonScripts' | Format-List -Property *

Sono esempi, non un'affermazione che questa condivisione corrisponda a D:\LogonScripts. Raccogliete la proprietà, le voci di accesso e l'ereditarietà. Risolvete i gruppi dietro ogni entità destinataria prima di concludere quali utenti possono modificare il contenuto. L'elenco delle ACL è un'evidenza per questa verifica, non una simulazione dell'accesso effettivo per ogni identità.

Il modello di sicurezza dei file di Microsoft valuta i diritti richiesti rispetto al token del chiamante e al descrittore dell'oggetto. Le sue costanti dei diritti di accesso ai file distinguono la scrittura dei dati di un file, la creazione di file in una directory e l'eliminazione degli elementi figli. Esaminate la capacità di alterare o sostituire il contenuto oltre all'amministrazione dei permessi; leggere lo script è una questione diversa. Ispezionate insieme le evidenze della condivisione e di NTFS per il percorso di accesso specifico.

Correzione: verificare prima, poi intervenire in modo mirato (Remediation)

1. Concordare il comportamento previsto e chi può scrivere

Per ogni assegnazione, registrate il responsabile aziendale, la popolazione di client prevista, i manutentori approvati e l'accesso in lettura necessario. Classificatela come necessaria, obsoleta o irrisolta. Mantenete visibile l'incertezza invece di considerarla un permesso di eliminare. Una destinazione condivisa può avere più utilizzatori, quindi coordinatene la modifica con ogni responsabile interessato.

2. Conservare uno stato di ripristino e provare la modifica su un pilota

Conservate l'attributo attuale, il contenuto della destinazione, le dipendenze ed entrambi gli insiemi di permessi tramite il processo di backup approvato. Scegliete un utente di test abilitato e un client rappresentativi. Definite il risultato atteso e le condizioni di errore prima del pilota. Per gli account disabilitati, adottate una decisione sul ciclo di vita invece di forzare un test di accesso.

3. Correggere il problema verificato alla fonte

Se la destinazione è necessaria ma un'entità non prevista può modificarla, fate correggere al responsabile del file server la specifica concessione della condivisione o di NTFS tramite la procedura di modifica approvata. Esaminate le concessioni ereditate e le dipendenze prima di scegliere la modifica. La mitigazione di MITRE raccomanda di limitare chi può scrivere gli script; non prescrive un'unica ACL universale per ogni ambiente.

Se l'assegnazione punta a una destinazione errata, modificate l'attributo di quell'utente soltanto dopo aver validato la sostituzione. L'anteprima seguente utilizza i parametri ScriptPath e WhatIf documentati di Set-ADUser:

Set-ADUser -Identity 'CN=PilotUser,OU=Users,DC=example,DC=com' -Server 'dc01.example.com' -ScriptPath '\\files01.example.com\LogonScripts\approved.cmd' -WhatIf

-WhatIf mostra un'anteprima dell'operazione senza applicarla. Questo comando è un'opzione per una correzione approvata dell'assegnazione, non una raccomandazione di migrare tutti gli utenti a percorsi UNC. Se un'assegnazione è obsoleta, ritiratela tramite la procedura concordata di gestione degli account dopo aver verificato le dipendenze condivise. Non eliminate un file referenziato solo perché un utente non ne ha più bisogno.

4. Rileggere la configurazione e verificare il comportamento autorizzato

Interrogate nuovamente l'utente esatto dopo la modifica approvata:

Get-ADUser -Identity 'CN=PilotUser,OU=Users,DC=example,DC=com' -Server 'dc01.example.com' -Properties scriptPath | Format-List -Property DistinguishedName,Enabled,scriptPath

Rileggete entrambe le ACL se i permessi sono cambiati. Ripetete il test client approvato dal responsabile e validate il recupero necessario e il comportamento previsto. Dove opportuno, verificate che un'entità non prevista per la scrittura non disponga di accesso effettivo in modifica, utilizzando la procedura autorizzata dell'organizzazione per i test di accesso. Conservate il contesto del test, i risultati, le eccezioni e la decisione di ripristino insieme all'inventario. La sola rilettura dell'attributo non può validare gli effetti dello script.

Come EtcSec rileva questo caso

Il controllo DANGEROUS_LOGON_SCRIPTS di EtcSec fornisce un elenco da verificare. Nel commit 15fc6399c215eabc415c370b762303cfcd7a353a di etc-collector, dangerous-logon-scripts.go:46 scorre gli utenti forniti e seleziona uno ScriptPath non vuoto quando contiene due barre inverse consecutive in qualsiasi posizione oppure inizia con //. Il ramo delle barre inverse non richiede un prefisso UNC rigoroso. Il rilievo è Medium e Count è il numero di utenti corrispondenti, non di file distinti o condivisioni vulnerabili.

Non esiste un filtro Disabled in questo Detect(). Gli utenti disabilitati possono quindi comparire quando sono forniti nei dati di audit. Un percorso vuoto non corrisponde; i percorsi relativi e le altre stringhe fuori dal predicato possono sfuggire a questo elenco di verifica. Viceversa, una stringa corrispondente non dimostra una destinazione UNC valida e raggiungibile.

Il provider LDAP richiede scriptPath in parser.go:49, lo copia in ScriptPath in parser.go:171 e recupera gli utenti tramite client.go:460. Questo controllo non legge il file di destinazione, l'ACL della condivisione, l'ACL NTFS o l'esecuzione effettiva. Il suo output non può confermare un accesso in scrittura non autorizzato, una persistenza riuscita o un'esecuzione come SYSTEM. Anche l'ambito e la completezza della raccolta limitano ciò che l'elenco rappresenta.