Account Obsoleti e Sovraprivilegiati: Il Rischio Nascosto in Active Directory

Gli account obsoleti e sovraprivilegiati non sono solo rumore di igiene della directory. In Active Directory, un account dormiente che appartiene ancora a un gruppo privilegiato, che ha ancora una password vecchia, o che possiede ancora una dipendenza di servizio, può diventare un percorso poco visibile di rientro nel dominio.

Cosa sono gli account obsoleti e sovraprivilegiati?

Gli account obsoleti e sovraprivilegiati sono identità vecchie o poco visibili che si risolvono ancora in un accesso amministrativo significativo in Active Directory. Un account diventa obsoleto quando nessuno lo controlla più; diventa sovraprivilegiato quando conserva più accesso di quanto richieda il suo ruolo attuale. I due problemi spesso si sovrappongono.

Gli ambienti Active Directory accumulano account nel tempo. I dipendenti se ne vanno, i collaboratori terminano gli incarichi, gli account di servizio sopravvivono ai progetti e le identità di amministrazione di emergenza restano abilitate molto dopo che la ragione originale è scomparsa.

Dal punto di vista di un attaccante, queste due condizioni si rafforzano a vicenda. Il bersaglio migliore non è solo un account vecchio. È un account vecchio che si trova ancora su un percorso privilegiato, è monitorato debolmente e non ha un proprietario chiaro che noterebbe un'attività insolita.

Come funziona

Gli account AD restano attivi finché qualcuno non li disabilita o elimina. Se l'offboarding, la revisione degli account di servizio o la revisione dei privilegi vengono saltati, l'ambiente si riempie di account che:

• non si sono autenticati da mesi o anni
• appartengono ancora a gruppi privilegiati
• hanno password impostate molto tempo fa e mai riviste
• restano fuori da qualsiasi revisione disciplinata del ciclo di vita

Un account privilegiato obsoleto è interessante perché unisce alto valore a basso controllo. L'account potrebbe non comparire nel lavoro amministrativo quotidiano, ma si risolve comunque negli stessi permessi quando viene presentata la password.

Le linee guida Microsoft sulla remediation degli account obsoleti indicano esplicitamente gli account inattivi come un rischio di sicurezza e raccomandano controlli regolari. Le stesse linee guida avvertono anche che gli account di servizio potrebbero non accedere per periodi prolungati, quindi la pulizia richiede salvaguardie invece di una cancellazione alla cieca.

Account obsoleti e sovraprivilegiati: i limiti del perimetro quando li cerchi

Una revisione degli account obsoleti deve essere precisa su cosa significano realmente i timestamp.

LastLogonDate e i dati di accesso replicati sottostanti sono utili per trovare candidati alla pulizia, ma non equivalgono all'ultimo uso forense esatto su ogni controller di dominio. Sono sufficientemente buoni per identificare account che necessitano di revisione umana. Non devono essere l'unico segnale prima di rimuovere un'identità di servizio sensibile.

Per questo le revisioni mature separano almeno tre casi:

• account utente che chiaramente avrebbero dovuto essere disabilitati dopo l'offboarding
• identità di servizio o di attività pianificate che potrebbero essere ancora usate in modo non interattivo
• identità privilegiate di emergenza o condivise che sono sopravvissute perché nessuno ha voluto testare le dipendenze

L'obiettivo non è mantenere ogni account vecchio perché un'applicazione potrebbe rompersi. L'obiettivo è smettere di trattare una proprietà poco chiara come una ragione per preservare per sempre un privilegio dormiente.

Una distinzione operativa utile è quella tra inattività e irrilevanza. Un account può essere silenzioso perché è abbandonato, oppure silenzioso perché viene attivato solo mensilmente da un backup, un'attività pianificata o un processo di ripristino usato raramente. La revisione deve separare esplicitamente questi casi.

Le limitazioni dei timestamp che contano

Per il triage degli account obsoleti, usa più segnali. Microsoft nota che PasswordLastSet è replicato e che lastLogonTimeStamp esiste per aiutare a identificare gli account potenzialmente obsoleti. Questo rende quegli attributi utili per una pulizia a livello di dominio. Non significa che dimostrino che un account non ha dipendenze.

Una revisione sicura combina:

• dati di inattività replicati, come l'anzianità della password o lastLogonTimeStamp
• dati degli eventi del controller di dominio per l'autenticazione recente
• analisi dell'appartenenza ai gruppi e dei diritti delegati
• controlli delle dipendenze di servizi, attività pianificate e applicazioni
• attestazione del proprietario per gli account che devono restare abilitati

Più alto è il privilegio, meno accettabile è affidarsi a un singolo timestamp. Un membro dormiente di Domain Admins e un utente dormiente a basso privilegio non rappresentano lo stesso rischio.

La catena di attacco

Fase 1 - Enumerare gli account obsoleti e ad alto valore

$cutoff = (Get-Date).AddDays(-90)
Get-ADUser -Filter {Enabled -eq $true -and LastLogonDate -lt $cutoff} `
  -Properties LastLogonDate, PasswordLastSet, MemberOf |
  Select-Object SamAccountName, LastLogonDate, PasswordLastSet |
  Sort-Object LastLogonDate

$groups = @('Domain Admins','Enterprise Admins','Schema Admins','Backup Operators','Account Operators')
foreach ($group in $groups) {
  Get-ADGroupMember -Identity $group -Recursive |
    Get-ADUser -Properties LastLogonDate, PasswordLastSet |
    Select-Object @{N='Group';E={$group}}, SamAccountName, LastLogonDate, PasswordLastSet
}

Microsoft documenta anche Search-ADAccount -AccountInactive -UsersOnly come un modo pratico per trovare account utente inattivi. Usalo come strumento di scoperta, poi aggiungi il contesto di privilegio e dipendenza prima di agire.

Fase 2 - Dare priorità agli account con password vecchie e privilegio elevato

Gli account con password molto vecchie, appartenenza stabile a gruppi e nessun proprietario attuale sono i primi che un attaccante proverà a validare, spruzzare (spray) o riutilizzare.

Dai priorità agli account che soddisfano più di una condizione:

• dati di accesso obsoleti
• PasswordLastSet vecchio
• appartenenza a gruppi privilegiati
• appartenenza tramite gruppi annidati
• flag dell'account come "la password non scade mai"
• nessun proprietario aziendale o tecnico nominato

Fase 3 - Trasformare l'accesso dormiente in accesso privilegiato

Un account obsoleto che si risolve ancora in Domain Admins, diritti amministrativi delegati, privilegi di backup o ampio accesso ai server non richiede un exploit inedito. Il privilegio esiste già.

Fase 4 - Persistere tramite identità a bassa visibilità

Gli account dormienti sono spesso assenti dai flussi di lavoro quotidiani, quindi l'attività insolita può passare inosservata più a lungo del dovuto. Questo è particolarmente vero per gli account admin condivisi e le identità di servizio che nessuno ha rivisto di recente.

Rilevamento

Event ID di Windows

Microsoft documenta "Audit Security Group Management" come la sottocategoria di audit che genera eventi per le modifiche di appartenenza ai gruppi di sicurezza, inclusi i gruppi globali, locali e universali. Questa distinzione conta quando il percorso privilegiato usa gruppi annidati o non globali.

Indizi comportamentali

• primo uso riuscito di un account dopo un lungo periodo di inattività
• appartenenza a gruppo privilegiato combinata con un'età della password molto elevata
• account di servizio che accedono in modo interattivo o da host inattesi
• account condivisi usati da più sistemi senza una chiara ragione operativa

Query SIEM (Elastic KQL)

event.code: '4624' AND
winlog.event_data.LogonType: '3' AND
winlog.event_data.TargetUserName: (* AND NOT '*$')

Questa query deve essere arricchita con l'età dell'account, il contesto di privilegio e la proprietà attesa. L'inattività senza contesto è solo un elenco. L'inattività più il privilegio è il vero rilevamento.

L'arricchimento del rilevamento che rende utile l'allerta

Un'allerta su un account obsoleto deve portare abbastanza contesto perché chi risponde decida se disabilitare, investigare o escalare:

• stato attuale abilitato/disabilitato
• data dell'ultima impostazione della password
• contesto dell'ultimo accesso interattivo e di rete conosciuto
• gruppi privilegiati diretti e annidati
• se l'account è contrassegnato come sensibile o protetto
• se l'account possiede servizi, attività pianificate o credenziali applicative
• se l'account ha attività Kerberos o NTLM recente

Senza questo arricchimento, i team di solito creano un foglio di calcolo e rimandano le decisioni difficili.

Rimedio

Azione rapida: disabilita prima gli account utente palesemente obsoleti, poi affronta le identità di servizio e condivise con una revisione basata sul proprietario invece di lasciarle indefinitamente al loro posto.

1. Disabilitare gli account obsoleti

$cutoff = (Get-Date).AddDays(-90)
Get-ADUser -Filter {Enabled -eq $true -and LastLogonDate -lt $cutoff} `
  -SearchBase 'OU=Users,DC=corp,DC=local' `
  -Properties LastLogonDate | ForEach-Object {
    Disable-ADAccount -Identity $_
    Write-Host "Disabled: $($_.SamAccountName) - Last login: $($_.LastLogonDate)"
  }

Per gli account utente che chiaramente non dovrebbero più esistere, disabilitali prima, monitora l'impatto, poi eliminali dopo il periodo di conservazione accettato dai tuoi team operativi. Non eliminare oggetti privilegiati o legati a servizi come prima azione, a meno che l'assenza di dipendenza non sia già dimostrata.

2. Ridurre l'appartenenza ai gruppi privilegiati

$groups = @('Domain Admins','Enterprise Admins','Schema Admins')
$groups | ForEach-Object {
  Get-ADGroupMember -Identity $_ -Recursive |
    Select-Object @{N='Group';E={$_}}, SamAccountName, distinguishedName
} | Export-Csv privileged_members.csv -NoTypeInformation

Rimuovi il privilegio permanente prima di discutere l'eliminazione dell'account. Un account obsoleto senza appartenenza a Domain Admins o diritti delegati equivalenti resta comunque lavoro di pulizia, ma non è più la stessa esposizione Tier-0 immediata.

3. Applicare una policy più rigorosa alle identità privilegiate

New-ADFineGrainedPasswordPolicy -Name 'PrivilegedAccountsPSO' `
  -Precedence 10 `
  -MinPasswordLength 20 `
  -ComplexityEnabled $true `
  -PasswordHistoryCount 24 `
  -MaxPasswordAge (New-TimeSpan -Days 60) `
  -LockoutThreshold 3

Add-ADFineGrainedPasswordPolicySubject -Identity 'PrivilegedAccountsPSO' `
  -Subjects 'Domain Admins'

Microsoft documenta le fine-grained password policy come un modo per applicare impostazioni di password e blocco diverse a insiemi diversi di utenti, incluse impostazioni più rigorose per gli account privilegiati. Questo è utile quando esistono ancora account privilegiati, ma non sostituisce la rimozione dell'appartenenza non necessaria.

4. Correggere il processo del ciclo di vita, non solo gli account

Le cause ricorrenti sono di solito operative:

• offboarding che disabilita l'accesso email ma dimentica i gruppi AD
• account di servizio senza proprietario dopo un cambio di team
• account admin di emergenza mai rimessi sotto revisione
• account condivisi tenuti in vita perché nessuno vuole testare la dipendenza

Una remediation credibile chiude queste lacune di processo mentre la pulizia degli account è in corso.

5. Mettere in quarantena le eccezioni invece di dimenticarle

Se un account a bassa attività deve restare abilitato, documentalo come eccezione con una data di revisione e un proprietario nominato. L'eccezione deve includere:

• perché l'account deve restare abilitato
• quali sistemi ne dipendono
• quali gruppi o diritti delegati possiede
• cosa si romperebbe se venisse disabilitato
• quale monitoraggio dimostra che viene usato solo come previsto

Le eccezioni senza data di scadenza sono il modo in cui gli account obsoleti e sovraprivilegiati ritornano.

Convalida prima di chiudere il rilievo

Una pulizia di account obsoleti non è completa quando il foglio di calcolo sembra più corto. Convalida il risultato reale del controllo.

• riesegui l'esportazione degli account inattivi e conferma che le stesse identità ad alto rischio non sono più abilitate
• conferma che l'appartenenza ai gruppi privilegiati sia stata effettivamente rimossa, e non solo lasciata su un oggetto disabilitato che potrebbe essere riattivato invariato
• rivedi l'attività recente degli eventi 4624 e 4768 per individuare account riutilizzati dopo la decisione di pulizia
• documenta il proprietario, la dipendenza e la prossima data di revisione per qualsiasi account che debba restare abilitato nonostante la bassa attività
• verifica l'ambito della fine-grained password policy per gli account privilegiati rimasti abilitati
• rivedi i percorsi dei gruppi annidati per verificare che il privilegio non sia stato preservato indirettamente

Per gli account di servizio, la verifica finale deve anche confermare che la dipendenza sia reale e ancora attuale. Se nessuno può dimostrare perché l'account esiste, questo è motivo per il ritiro, non per un'altra eccezione.

Come EtcSec rileva questo

EtcSec rende questo rilievo più utile correlando inattività, livello di privilegio, età della password e mancanza di copertura delle policy. Questo conta perché un account dormiente a basso valore e un account dormiente privilegiato non sono lo stesso problema operativo.

Letture correlate

• Sicurezza delle password in Active Directory: gli errori di configurazione che contano
• Kerberoasting: come gli attaccanti craccano le password degli account di servizio
• Monitoraggio di Active Directory: gli Event ID di sicurezza che contano
• Nidificazione pericolosa dei gruppi: percorsi nascosti verso Domain Admin
• Percorsi di attacco Active Directory verso Domain Admin

Riferimenti principali

• Regularly check for and remove inactive user accounts in Active Directory
• Audit Security Group Management
• Configure fine-grained password policies for AD DS
• Configure Windows event auditing (Microsoft Defender for Identity)