account condivisi AD: qualificare le prove di accesso

Che cosa deve stabilire l’attribuzione degli account condivisi AD

L’attribuzione degli account condivisi AD parte da una distinzione: un account di directory è un principal di sicurezza, mentre un operatore è la persona che lo utilizza. Un account chiamato shared-support può richiedere una verifica, ma il nome non dimostra che più persone ne conoscano le credenziali. Un accesso con quell’account può stabilire l’utilizzo dell’account senza identificare la persona che lo ha effettuato.

Trattate un rilievo basato sul nome come una coda di indagini. Per ogni account selezionato, stabilite il responsabile, lo scopo effettivo, gli utenti autorizzati, i sistemi dipendenti e le prove di accesso disponibili. Mantenete l’osservazione della directory, le prove di autenticazione e l’attribuzione a una persona come conclusioni separate. Una dipendenza legittima di un servizio e una sessione umana non attribuibile richiedono risposte diverse, anche quando utilizzano lo stesso nome di account.

La nostra verifica di classificazione, responsabilità e scadenza degli account spiega come chiarire i nomi generici e lo scopo degli account. Questa guida aggiunge i requisiti probatori per attribuire un’attività: quale identità descrive ciascun evento Windows, dove correlarla e che cosa resta sconosciuto prima di dismettere l’account.

Come funziona il processo di qualificazione

1. Creare un fascicolo per ogni account

Registrate il dominio dell’account, il nome SAM, il SID, lo stato attuale di abilitazione, il momento della raccolta, il responsabile e l’uso previsto. Elencate i servizi, le attività pianificate, le applicazioni, le procedure amministrative e i requisiti di ripristino noti. Il responsabile deve risolvere il caso; questa responsabilità, da sola, non stabilisce chi abbia effettuato un determinato accesso.

Chiedete al responsabile quali persone possano ottenere o utilizzare le credenziali e attraverso quali percorsi di accesso. Separate l’autorizzazione documentata dall’uso osservato. Se il responsabile afferma che una sola persona utilizza l’account, conservate la dichiarazione come un’affermazione da confrontare con le prove. Se nessuno riesce a identificare il responsabile, mantenete il caso aperto assegnando nominativamente la responsabilità del passo successivo dell’indagine.

Esaminate anche gli account disabilitati. Il rilevatore include gli utenti disabilitati il cui nome corrisponde ai criteri, quindi il suo conteggio non rappresenta il numero di sessioni condivise attive. Conservate le prove storiche disponibili e verificate le dipendenze prima di decidere se sia possibile dismettere un oggetto disabilitato. Lo stato attuale della directory non stabilisce che cosa sia accaduto durante un precedente intervallo di indagine.

2. Definire il perimetro delle prove prima della ricerca

Identificate le workstation o gli host di gestione che avviano l’attività, i server di destinazione e l’intervallo di tempo pertinente. Verificate quali di questi sistemi generano e inoltrano gli eventi Security necessari. Entrambe le pagine di riferimento collocano gli eventi sotto Audit Logon. La raccolta dai soli controller di dominio non dimostra la copertura di tutte le sessioni di destinazione o di tutti i processi che avviano l’attività.

Per l’inventario più ampio dei criteri di audit e degli eventi, consultate la nostra guida agli eventi e alla raccolta per il monitoraggio di Active Directory. In questo caso, la domanda operativa è più circoscritta: il team può recuperare le prove per questo account, su questi host, durante questo intervallo, mantenendo i campi di identità?

Documentate la conservazione locale, le lacune nell’inoltro, il comportamento del parser, i limiti di accesso e l’allineamento degli orologi prima di trarre una conclusione negativa. Conservate l’XML originale dell’evento o un record equivalente senza perdita di informazioni insieme ai campi normalizzati. Una colonna SIEM chiamata Account può nascondere se il parser abbia selezionato Subject o Target; validate questa mappatura confrontandola con l’evento stesso.

Rilevamento: separare le identità di 4624 e 4648

3. Leggere la sessione riuscita sulla destinazione

Il riferimento Microsoft per l’evento 4624 lo definisce come la creazione di una sessione di accesso sul computer a cui si accede. Subject descrive l’account che segnala o invoca l’accesso; New Logon descrive l’account per cui è stata creata la sessione. Non attribuite la sessione a una persona leggendo soltanto Subject.

Mantenete separati questi campi dell’evento nel fascicolo:

Per esempio, Logon Type 3 descrive un accesso di rete, 4 un accesso batch, 5 un accesso di servizio e 10 un accesso interattivo remoto. Queste descrizioni aiutano a verificare se l’uso osservato corrisponda allo scopo dichiarato dal responsabile. Non sono verdetti di attribuzione a una persona: una sessione di rete può essere avviata da un’automazione e una sessione di servizio non identifica la persona che l’ha configurata.

Il riferimento di 4624 spiega inoltre che la disponibilità di indirizzo, porta e workstation dipende dal contesto e dal protocollo di autenticazione. Un campo di origine vuoto deve restare vuoto nel registro delle prove; non compilatelo a partire da un altro evento solo perché il nome dell’account coincide. Il SID dell’account condiviso identifica quel principal, non quale dei suoi possibili utenti abbia agito.

4. Leggere le credenziali esplicite senza scambiare le identità

Il riferimento Microsoft per l’evento 4648 descrive un processo che tenta un accesso con credenziali fornite esplicitamente. Questo avviene anche durante attività ordinarie, comprese le attività pianificate e RUNAS. Subject è l’account richiedente; Account Whose Credentials Were Used è l’identità delle credenziali. Possono essere account diversi.

Un record 4648 con un Subject nominativo e un Target condiviso è una prova utile del fatto che quel contesto di sicurezza nominativo richiede l’uso delle credenziali condivise. Non stabilisce autonomamente chi controlli il contesto. Descrive inoltre un tentativo; non trasformatelo in un accesso riuscito sulla destinazione senza prove a sostegno. L’XML dell’evento elenca nome, dominio e GUID della destinazione; non presumete che fornisca un SID della destinazione solo perché uno schema normalizzato prevede una colonna dedicata.

5. Correlare nell’host e nella sessione corretti

Partite dall’host, dal timestamp e dalla sezione di identità pertinenti. Le indicazioni Microsoft sulla correlazione di Logon ID limitano l’unicità a un computer tra due riavvii. Mantenete le join su Logon ID entro quell’host e quell’intervallo tra riavvii, senza estenderle al dominio. Per un 4648 che avvia l’attività, cercate la sessione 4624 locale corrispondente utilizzando il contesto di accesso Subject di 4648 e il contesto New Logon di 4624. Unire indiscriminatamente Subject a Subject risponde a una domanda diversa.

Conservate entrambi i GUID di 4648. I riferimenti Microsoft descrivono la correlazione 4624/4648 sullo stesso computer quando il GUID pertinente è disponibile. Non si deve selezionare automaticamente né un GUID di Subject né un GUID delle credenziali solo perché un parser li ha rinominati entrambi come un unico campo generico. Stabilite quale sessione rappresenti la corrispondenza proposta e conservate il fondamento della decisione.

Un GUID composto solo da zeri è una prova non disponibile, non una sessione comune a tutti i record contenenti zeri. Tra gli host che avviano l’attività e quelli di destinazione, costruite una cronologia con account e dominio, host di destinazione, contesto di origine disponibile e timestamp. Indicate che l’associazione è contestuale quando non esiste un collegamento affidabile tra sessioni. Non equiparate mai Logon ID esadecimali identici su due macchine.

6. Registrare la confidenza e le spiegazioni contrastanti

Utilizzate categorie esplicite di confidenza come convenzione di verifica, non come sistema di punteggio Microsoft. L’uso dell’account può essere confermato mentre l’attribuzione a una persona resta irrisolta. Mantenete colonne separate per queste conclusioni invece di assegnare un unico punteggio rassicurante all’intero caso.

Una prova indipendente potrebbe essere un record di un gateway di accesso con autenticazione individuale o di prelievo delle credenziali, se l’organizzazione ne dispone e se i timestamp e le identità sono verificabili. Un elenco di persone, un indirizzo IP o il solo ricordo del responsabile sono prove più deboli. Registrate alternative come un’automazione pianificata o un’altra persona che controlla la sessione iniziale; documentate perché la spiegazione mantenuta sia meglio supportata.

Si tratta di una procedura di indagine, non di una query presentata come eseguita. Non è stato effettuato alcun test su host o SIEM per questa guida. Validate le mappature dei campi e le correlazioni con attività controllate e autorizzate prima di farvi affidamento nell’operatività.

Ripristinare la responsabilità prima della dismissione (Remediation)

7. Sostituire l’accesso umano condiviso con accesso nominativo

Per le procedure umane, pianificate l’accesso attraverso identità individuali degli operatori e verificate che i record conservino l’identità individuale fino all’azione privilegiata. Cambiare shared-support in un nome dall’aspetto personale non rende attribuibili le responsabilità. Confermate chi possa ottenere le credenziali, come venga approvato l’accesso e come possa essere revocato quando cambia il ruolo di una persona.

Per l’automazione, documentate il carico di lavoro e il relativo responsabile separatamente dagli operatori umani. Esaminate le opzioni di migrazione con il team applicativo invece di imporre a un servizio un modello di identità interattiva. L’obiettivo è eliminare la condivisione non necessaria delle credenziali, preservando le dipendenze legittime e una traccia di accesso verificabile.

Se una sostituzione immediata è impossibile, documentate un’eccezione temporanea con responsabile, scopo approvato, utenti autorizzati, host consentiti, prove compensative, scadenza e tappa di migrazione. Un’eccezione senza una traccia di attribuzione utilizzabile deve dichiararlo esplicitamente. Una scadenza futura non rende attribuibile la sessione ambigua di oggi.

8. Disabilitare solo un’identità verificata

Prima della dismissione, ottenete dal responsabile la valutazione delle dipendenze, controllate le disposizioni di ripristino, conservate i record di indagine e concordate le responsabilità di validazione e rollback. Decidete separatamente se le prove giustifichino una risposta a una compromissione. Un rilievo basato solo sul nome non stabilisce una compromissione e non giustifica un’operazione sulle credenziali estesa a tutto l’ambiente.

Per un account ordinario di cui sia stata approvata la dismissione, l’esempio seguente adatta i parametri documentati di Disable-ADAccount. Il DN e il controller di dominio scrivibile sono illustrativi; verificate entrambi prima dell’uso. Questi esempi richiedono il modulo ActiveDirectory e permessi nella directory e non sono stati eseguiti per questo articolo.

Disable-ADAccount -Identity 'CN=shared-support,OU=Users,DC=contoso,DC=com' -Server 'dc01.contoso.com' -WhatIf

-WhatIf mostra un’anteprima dell’operazione; non verifica se un’applicazione smetterà di funzionare. Dopo la verifica delle dipendenze e nella finestra di modifica approvata, l’azione mirata corrispondente è:

Disable-ADAccount -Identity 'CN=shared-support,OU=Users,DC=contoso,DC=com' -Server 'dc01.contoso.com' -Confirm

Non passate ogni corrispondenza del nome a un’operazione di disabilitazione tramite pipeline. Verificate lo stato risultante della directory e le procedure dipendenti dopo la modifica approvata. L’eliminazione richiede una decisione separata su conservazione e ripristino; né un conteggio basso del rilevatore né un intervallo senza eventi forniscono tale autorizzazione.

9. Chiudere con la decisione supportata dalle prove

Rispondete a tre domande per ogni account: quali host e criteri di audit abbiano fornito le prove necessarie; se esista un’identità nominativa indipendente dell’operatore; e quali dipendenze richiedano un’eccezione temporanea prima della rimozione. Se manca una risposta, conservate la domanda irrisolta, il responsabile e la data della verifica successiva.

Chiudete con un esito concreto: accesso umano sostituito, dipendenza del carico di lavoro migrata, identità non necessaria disabilitata o eccezione temporanea mantenuta. Allegate la motivazione della confidenza e le lacune probatorie. Una verifica completata deve spiegare sia la decisione operativa sia i limiti di qualsiasi affermazione di attribuzione storica.

Come EtcSec rileva questo caso

Il controllo SHARED_ACCOUNT di etc-collector è un rilievo di gravità media nella categoria Accounts. Al commit del collector 0423094759d50002457031317098417993e19510, Detect() in public/internal/audit/detectors/ad/accounts/patterns/shared-account.go:45 verifica il SAMAccountName degli utenti raccolti rispetto a quattro prefissi senza distinzione tra maiuscole e minuscole:

(?i)^shared
(?i)^common
(?i)^generic
(?i)^guest-

Si tratta di euristiche del prodotto basate sui nomi. shared-support e CommonDesk corrispondono; my-shared-support non corrisponde a ^shared perché il prefisso è ancorato all’inizio. Il controllo non include i prefissi service/svc, non esamina chi conosca la password e non determina quante persone utilizzino un account.

Ogni utente corrispondente viene aggiunto una volta, poi il ciclo interno sui pattern si interrompe. Count è il numero di utenti raccolti corrispondenti, inclusi gli account disabilitati: non esiste un filtro sullo stato di abilitazione. Quando vengono richiesti i dettagli e sono presenti corrispondenze, il rilievo include le entità utente interessate. La funzione restituisce un rilievo anche quando Count è zero.

Il provider LDAP fornisce utenti e attributi della directory, non la cronologia degli eventi 4624/4648 o un’identità di operatore. Questo Detect non correla le sessioni, non dimostra la condivisione delle credenziali, non valuta i record indipendenti di attribuzione e non verifica una dismissione approvata. Un risultato positivo avvia il processo di qualificazione descritto sopra; un conteggio zero stabilisce soltanto che nessun nome raccolto corrispondeva a queste espressioni, non che ogni uso degli account sia attribuibile.