Shadow Credentials e abuso di msDS-KeyCredentialLink

Che cosa sono le Shadow Credentials?

Shadow Credentials è il nome usato dalla comunità Active Directory per indicare un percorso di attacco che abusa di materiale di autenticazione basato su chiave su un account, di solito tramite l’attributo msDS-KeyCredentialLink. Il punto importante non è il nome. Il punto importante è che a un principal può essere dato un ulteriore percorso di autenticazione con chiave pubblica, separato dalla password.

In un deployment legittimo, msDS-KeyCredentialLink viene usato da Windows Hello for Business e da scenari correlati di Key Trust. Microsoft documenta che, in alcune implementazioni ibride di Windows Hello for Business, la chiave pubblica dell’utente può essere sincronizzata da Microsoft Entra ID verso Active Directory e scritta nell’attributo msDS-KeyCredentialLink dell’oggetto utente. Microsoft documenta anche il comportamento Key Trust per Kerberos PKINIT: un KDC che usa Active Directory come database degli account deve confermare che l’account abbia la stessa chiave pubblica in msDS-KeyCredentialLink.

Un caso di abuso Shadow Credentials esiste quando un attaccante o un amministratore non autorizzato può aggiungere o mantenere una key credential inattesa su un oggetto utente o computer, quindi usare la chiave privata corrispondente per autenticarsi come quell’account tramite un flusso basato su chiave. Non è password spraying, Kerberoasting, DCSync o Golden Ticket. È più vicino a un percorso di persistenza e impersonificazione basato su ACL: l’oggetto directory dell’account è stato modificato in modo che una chiave diversa possa soddisfare i controlli di autenticazione.

Questo articolo usa il termine Shadow Credentials perché è ampiamente riconosciuto da difensori e assessor Active Directory. La documentazione Microsoft di solito descrive i meccanismi sottostanti come Windows Hello for Business, Key Trust, PKINIT e msDS-KeyCredentialLink. Questa distinzione conta: l’attributo in sé non è malevolo. Un valore non nullo in msDS-KeyCredentialLink può essere normale in ambienti che usano Windows Hello for Business, flussi collegati a FIDO o funzionalità di fiducia basata su chiave. L’obiettivo difensivo è identificare key credentials non autorizzate, orfane, inattese o presenti su account privilegiati, non cancellare alla cieca ogni valore.

Per un contesto più ampio sui percorsi di attacco all’identità, consulta Percorsi di Attacco AD: Catene di Configurazioni Errate e Abuso ACL e DCSync: Percorsi verso Domain Admin. Le Shadow Credentials appartengono alla stessa famiglia di problemi, perché la causa radice è spesso una capacità di scrittura eccessiva su un oggetto identità.

Come funziona msDS-KeyCredentialLink

Archiviazione legittima delle key credentials

msDS-KeyCredentialLink archivia dati di key credential su un oggetto Active Directory. Le Microsoft Open Specifications descrivono KEYCREDENTIALLINK_BLOB come la struttura memorizzata nella porzione binaria dell’attributo DN-Binary msDS-KeyCredentialLink. Microsoft documenta anche vincoli per l’aggiunta di valori su oggetti computer, inclusi il fatto che la porzione binaria debba essere un KEYCREDENTIALLINK_BLOB ben formato, che l’uso sia KEY_USAGE_NGC e che l’origine sia KEY_SOURCE_AD per quella specifica operazione documentata sugli account computer.

Quella specifica sugli oggetti computer non deve essere generalizzata a ogni scenario sugli oggetti utente. Per gli oggetti utente, la fonte operativa più chiara è la documentazione Windows Hello for Business: dopo che un utente esegue il provisioning di una credenziale Windows Hello for Business in determinati ambienti ibridi, la chiave pubblica dell’utente può essere sincronizzata verso AD e scritta in msDS-KeyCredentialLink. La guida di supporto Microsoft fornisce anche uno script per enumerare oggetti utente con valori msDS-KeyCredentialLink non nulli ed estrarre campi come Source, Usage, DeviceID e KeyID.

Percorso di autenticazione Key Trust

Il lato autenticazione si basa sulla crittografia a chiave pubblica. RFC 4556 definisce PKINIT come crittografia a chiave pubblica per lo scambio iniziale di autenticazione Kerberos. La documentazione PKCA di Microsoft descrive come Windows implementa PKINIT e Key Trust. In un caso Key Trust, il KDC può cercare un account tramite chiave pubblica, e le implementazioni che usano Active Directory devono confermare che la stessa chiave pubblica sia presente in msDS-KeyCredentialLink.

In termini difensivi pratici, l’attributo offre ad AD un modo per associare un account a materiale di chiave utilizzabile per l’autenticazione. La chiave privata deve restare protetta sul dispositivo legittimo o nel contenitore credenziale. La chiave pubblica è ciò che AD può usare per validare che il tentativo di autenticazione corrisponda a una chiave attesa. Se una chiave non autorizzata viene aggiunta a un account di alto valore, l’account ottiene un percorso di autenticazione aggiuntivo che i difensori potrebbero non notare durante le normali revisioni delle password.

I reset della password non bastano

Per questo le Shadow Credentials sono diverse da una compromissione basata su password. Un reset della password affronta una password rubata. Non rimuove necessariamente dall’account un valore key credential non autorizzato. Microsoft documenta che accesso e sblocco con Windows Hello for Business usano una chiave o un certificato, e che la modifica della password dell’account utente non influenza quel comportamento di accesso o sblocco. Per la risposta a incidenti, questo significa che la rotazione della password può essere necessaria ma insufficiente se l’oggetto account contiene ancora materiale di chiave non autorizzato.

Perché Key Trust cambia il modello di attacco

L’hardening tradizionale di Active Directory spesso si concentra su password, esposizione NTLM, ticket di servizio Kerberos e appartenenza a gruppi privilegiati. Questi temi restano importanti, ma Key Trust introduce una domanda diversa: chi può modificare l’oggetto account o il materiale di chiave associato all’account?

Se un utente o servizio ha il permesso effettivo di scrivere msDS-KeyCredentialLink, o può cambiare la DACL o il proprietario dell’oggetto per ottenere quella capacità di scrittura, il rischio non è più solo il login all’account. Diventa controllo dell’oggetto identità. Windows Event 4662 evidenzia Write Property, WRITE_DAC e WRITE_OWNER come tipi di accesso importanti da monitorare sugli oggetti AD. Questi diritti non sono automaticamente malevoli, ma su utenti privilegiati, account di servizio, domain controller o OU amministrative meritano molta più attenzione.

Questo è anche il motivo per cui Shadow Credentials è un problema di attack path. Il punto iniziale può essere un gruppo helpdesk delegato, un account di servizio con ampi diritti sugli oggetti, un permesso ereditato su una OU o una delega amministrativa obsoleta. Lo stato finale può essere un percorso persistente di autenticazione contro un account privilegiato. Se il difensore controlla solo l’appartenenza ai gruppi, può perdere il permesso a livello di oggetto che ha reso possibile il percorso. Anche la nidificazione dei gruppi può nascondere chi riceve effettivamente controllo delegato; rivedi Gruppi AD nidificati: Percorsi nascosti verso DA quando sono coinvolti permessi ereditati.

Confronta questo tema con Attacchi Delega Kerberos: Non Vincolata a RBCD. L’abuso di delega dipende da impostazioni di delega e relazioni tra identità di servizio. Shadow Credentials dipende da materiale di chiave e controllo di scrittura sull’oggetto. Entrambi sono vicini a Kerberos, ma non sono lo stesso failure mode e non devono essere fusi in un articolo Kerberos generico.

Prerequisiti per l’abuso

Uno scenario Shadow Credentials richiede in genere tutte queste condizioni:

Condizione	Significato difensivo
Un account target supporta un percorso rilevante di autenticazione basata su chiave	L’ambiente usa o accetta Key Trust, autenticazione supportata da certificati o pattern Windows Hello for Business che dipendono dalla validazione di chiave pubblica.
Un principal non autorizzato può aggiungere o preservare materiale key credential	Il permesso pericoloso può essere scrittura diretta sull’attributo o controllo più ampio dell’oggetto che può portare a quella scrittura.
L’attaccante controlla la chiave privata corrispondente	AD conserva il lato pubblico. L’autenticazione riesce solo se il client può provare il possesso della chiave privata corrispondente.
L’attività non viene rilevata o bonificata	Il valore resta sull’oggetto e può sopravvivere a una pulizia limitata alla password.

Cosa non è una vulnerabilità di per sé

Questi prerequisiti vanno letti con attenzione. La presenza di Windows Hello for Business non significa che l’ambiente sia vulnerabile di per sé. La presenza di msDS-KeyCredentialLink non significa compromissione di per sé. Il rischio appare quando permessi sugli oggetti account, inventario delle key credentials e telemetria di autenticazione mostrano che una key credential inattesa è stata aggiunta o viene usata.

Nota sugli oggetti computer

Gli oggetti computer richiedono una precisazione separata. Microsoft documenta l’autenticazione a chiave pubblica per dispositivi domain-joined e spiega che i dispositivi Windows moderni possono eseguire il provisioning di una chiave pubblica associata al proprio account computer quando supportati da un domain controller Windows Server 2016 o successivo. I difensori devono quindi aspettarsi materiale di chiave legittimo su alcuni account computer. Il controllo non è zero key credentials ovunque. Il controllo è ownership accurata, mappatura attesa dei dispositivi e capacità di scrittura limitata.

Nota sugli account privilegiati

Gli account privilegiati richiedono uno standard più rigido. La guida Microsoft sul dual enrollment di Windows Hello for Business descrive i permessi Key Admins su msDS-KeyCredentialLink e considerazioni AdminSDHolder per utenti e gruppi privilegiati protetti. È un segnale forte per i difensori: qualunque workflow che abilita intenzionalmente il sign-in basato su chiave per credenziali privilegiate deve essere documentato, limitato e monitorato, perché tocca la stessa superficie di controllo che gli attaccanti abuserebbero.

La catena di attacco

Un modello difensivo sicuro della catena di attacco è questo:

Fase	Cosa accade	Cosa devono verificare i difensori
1. Scoperta dei permessi	L’attaccante identifica un account o una OU dove può influenzare attributi o security descriptor dell’oggetto target.	Rivedere i permessi effettivi su utenti di alto valore, account computer, account di servizio e OU amministrative.
2. Aggiunta di key credential	Un valore key credential inatteso viene aggiunto a `msDS-KeyCredentialLink`.	Monitorare Event 5136 per il LDAP display name `msDS-KeyCredentialLink`, soprattutto operazioni `Value Added`.
3. Autenticazione basata su chiave	L’attaccante tenta di autenticarsi con la chiave privata corrispondente alla chiave pubblica aggiunta.	Correlare eventi 4768, pattern di pre-autenticazione PKINIT o simili a smart card, host sorgenti e sensibilità dell’account.
4. Movimento laterale o persistenza	L’account viene usato per accesso, escalation o persistenza mentre la sola rotazione password potrebbe non rimuovere il percorso con chiave.	Rimuovere key credentials non autorizzate, correggere i permessi dell’oggetto e validare che non continui autenticazione basata su chiave inattesa.

L’articolo non fornisce intenzionalmente comandi di exploitation specifici per tool. I difensori non hanno bisogno di un percorso di exploit copiabile per capire il fallimento del controllo. Il punto chiave è che una modifica a un oggetto directory può creare un percorso di autenticazione che la normale igiene delle password non rimuove.

Questa catena spiega anche perché Shadow Credentials si trova spesso accanto ad altri rischi AD. Un account privilegiato obsoleto, una ACL ereditata pericolosa o un modello di delega debole possono creare le condizioni per la scrittura della key credential. Per l’esposizione degli account, consulta Account Obsoleti e Sovraprivilegiati in AD. Per il contesto di persistenza Kerberos, confronta le meccaniche diverse in Golden Ticket: Le Chiavi del Tuo Dominio.

Rilevamento

Il rilevamento di Shadow Credentials deve essere basato su correlazione. Nessun singolo evento Windows prova l’intera tecnica. Un rilevamento utile combina evidenze di modifica directory, contesto dei permessi sull’oggetto, comportamento di autenticazione e inventario legittimo Windows Hello for Business.

Segnale	Fonte	Cosa può provare	Limite
Valore `msDS-KeyCredentialLink` aggiunto o modificato	Event 5136, Directory Service Changes	L’attributo dell’oggetto è cambiato, e l’evento può esporre LDAP display name, tipo di operazione, DN dell’oggetto e correlation ID.	Non prova che il cambiamento sia malevolo. Enrollment WHfB o flussi dispositivo possono essere legittimi.
Accesso in scrittura a oggetti sensibili	Event 4662, SACL su oggetti AD	Un principal ha eseguito o tentato operazioni come `Write Property`, `WRITE_DAC` o `WRITE_OWNER` su oggetti o proprietà monitorati.	Richiede audit e copertura SACL corretti. Senza SACL, le evidenze possono mancare.
Richiesta TGT con pre-autenticazione di tipo chiave pubblica	Event 4768 sui domain controller	È stato richiesto un TGT; l’evento espone il tipo di pre-autenticazione e campi relativi ai certificati in scenari pertinenti.	È telemetria di autenticazione, non prova che sia stata aggiunta una chiave malevola. Correlare con 5136/4662 e contesto account.
Inventario di key credentials non nulle	Query AD o parsing stile supporto Microsoft	Quali utenti hanno valori `msDS-KeyCredentialLink` e cosa mostrano campi come source, usage, DeviceID e KeyID.	L’inventario deve essere confrontato con record noti WHfB/FIDO/device enrollment.
Permessi effettivi inattesi	Revisione ACL AD	Quali utenti, gruppi o servizi possono scrivere l’attributo o cambiare la sicurezza dell’oggetto.	I finding sui permessi indicano esposizione, non evidenza di sfruttamento.

Telemetria delle modifiche directory

Per 5136, Microsoft raccomanda di monitorare il campo LDAP Display Name quando si tracciano modifiche a uno specifico attributo AD. Per questo tema, il display name rilevante è msDS-KeyCredentialLink. Dai priorità agli eventi Value Added, poi correla per DN dell’oggetto, account che ha effettuato la modifica, workstation sorgente quando disponibile e operazioni directory vicine con lo stesso correlation ID.

Per 4662, dai priorità a utenti di alto valore, gruppi privilegiati, OU amministrative, account di servizio e oggetti computer che rappresentano infrastruttura sensibile. Microsoft evidenzia tipi di accesso come Write Property, WRITE_DAC e WRITE_OWNER come importanti da monitorare. Per una hunt Shadow Credentials, sono particolarmente rilevanti quando coinvolgono un oggetto identità privilegiato o una property GUID mappata a msDS-KeyCredentialLink.

Correlazione di autenticazione

Per 4768, tratta l’evento come contesto di autenticazione. Microsoft documenta che 4768 viene generato quando il KDC emette un TGT e che l’evento include un campo Pre-Authentication Type. I tipi associati ad autenticazione smart card o a chiave pubblica possono aiutare a identificare pattern di autenticazione basata su chiave, ma devono essere correlati con cambiamenti directory e comportamento di login atteso. Se un account privilegiato mostra improvvisamente autenticazione basata su chiave dopo una modifica inattesa dell’attributo, la storia combinata è molto più forte di ciascun evento isolato.

Domande di inventario

Una hunt pratica deve rispondere a queste domande:

Quali utenti privilegiati, account di servizio e account computer hanno valori msDS-KeyCredentialLink non nulli?
I valori sono attesi per un deployment documentato Windows Hello for Business, FIDO o autenticazione dispositivo?
Ogni entry mappa a un dispositivo noto, un utente atteso, un KeyID atteso e una source attesa?
Chi può scrivere l’attributo o cambiare la DACL o il proprietario dell’oggetto?
Sono stati aggiunti valori key credential poco prima di autenticazioni Kerberos insolite o attività amministrative?

Per una copertura eventi più ampia, usa Monitoraggio Sicurezza AD: Event ID e SIEM come checklist complementare, ma mantieni specifica la correlazione Shadow Credentials. Il monitoraggio Kerberos generico non basta.

Remediation

La remediation deve essere mirata. Svuotare alla cieca msDS-KeyCredentialLink in tutto il dominio può rompere scenari legittimi Windows Hello for Business o di autenticazione dispositivo. L’approccio più sicuro è validare l’ownership, rimuovere i valori non autorizzati e correggere i permessi che hanno permesso al valore di apparire.

Inventario e triage

Inizia con l’inventario. Enumera utenti e computer con valori msDS-KeyCredentialLink non nulli, poi esegui il parsing dei valori in campi come Source, Usage, DeviceID e KeyID quando possibile. La guida di supporto Microsoft mostra questo tipo di analisi per oggetti utente e spiega che il certificato corrispondente dovrebbe trovarsi nel certificate store personale dell’utente sul computer con l’identificatore dispositivo corrispondente. In un ambiente gestito, l’inventario dovrebbe anche essere confrontato con record dispositivi Microsoft Entra, record di enrollment Windows Hello for Business e il processo di privileged access.

Poi separa l’atteso dall’inatteso. I valori attesi devono mappare a utenti, dispositivi e design di autenticazione noti. I valori inattesi includono entry su account che non dovrebbero usare autenticazione basata su chiave, entry che non mappano a un dispositivo approvato, entry aggiunte da un principal non approvato, entry apparse dopo attività amministrativa sospetta o valori trovati su account privilegiati senza un processo documentato di dual enrollment o workstation privilegiata.

Rimuovere solo valori non autorizzati

Per entry confermate non autorizzate, rimuovi dall’oggetto il valore specifico non autorizzato. Non affidarti solo al reset della password. Il reset può comunque essere necessario se l’account è stato compromesso in altro modo, ma non prova da solo che il materiale di autenticazione basato su chiave sia stato rimosso da AD.

Correggere il percorso dei permessi

Dopo la pulizia dei valori, correggi i permessi. Rivedi diritti diretti ed ereditati che consentono di scrivere msDS-KeyCredentialLink, scrivere ampie proprietà dell’oggetto, cambiare la DACL o cambiare ownership dell’oggetto. Rimuovi deleghe ampie da account privilegiati, OU amministrative, OU di account di servizio e account computer dove non sono richieste. Se un workflow helpdesk o automation deve gestire legittimamente l’enrollment Windows Hello for Business, limitalo strettamente e monitoralo esplicitamente.

Per account privilegiati, rivedi Key Admins e gruppi correlati. La documentazione Microsoft dual enrollment descrive i permessi Key Admins su msDS-KeyCredentialLink e considerazioni AdminSDHolder per account protetti. Se l’enrollment Windows Hello for Business è consentito per account privilegiati, documenta quali dispositivi sono approvati, quali account sono autorizzati e come vengono autorizzati nuovi valori key credential. Se non è consentito, gli account privilegiati non devono accumulare key credentials silenziosamente.

Infine, rafforza il modello operativo. Usa tiered administration o un isolamento amministrativo equivalente, in modo che workstation meno fidate e gruppi delegati ampi non possano modificare oggetti identità di alto valore. Mantieni l’amministrazione delle identità privilegiate separata dagli account di produttività quotidiana. Rivedi periodicamente gli attack path, perché questo problema di solito nasce da una catena di diritti e non da una singola appartenenza evidente a un gruppo.

Validazione dopo la bonifica

La validazione deve provare sia la bonifica sia il recupero del controllo.

Passo di validazione	Criterio di successo
Rieseguire l’inventario delle key credentials	Rimangono solo valori `msDS-KeyCredentialLink` attesi, e ciascuno mappa a utente, dispositivo, source, usage e KeyID documentati.
Ricontrollare i permessi dell’oggetto	Nessun principal non autorizzato può scrivere l’attributo, scrivere ampie proprietà, cambiare DACL o cambiare owner su account di alto valore.
Rivedere 5136 dopo la bonifica	Non si verificano operazioni `Value Added` inattese per `msDS-KeyCredentialLink` su account privilegiati o computer sensibili.
Rivedere 4662 dopo la bonifica	L’attività Write Property e security descriptor sugli oggetti monitorati corrisponde a workflow admin approvati.
Rivedere 4768 dopo la bonifica	L’autenticazione basata su chiave per account sensibili avviene solo da utenti, dispositivi e scenari attesi.
Testare flussi legittimi WHfB/FIDO	Gli utenti approvati possono ancora accedere dove il business si affida intenzionalmente a Key Trust.

Se un incidente ha coinvolto un account privilegiato, la validazione deve includere anche la revisione dell’attività a valle. Controlla logon amministrativi, cambi di membership di gruppi, modifiche a configurazioni di servizi, modifiche GPO, nuovi certificati e qualsiasi movimento successivo che potrebbe aver usato l’identità recuperata. Shadow Credentials può essere il metodo di accesso, ma non necessariamente l’obiettivo finale.

Come EtcSec rileva l’esposizione correlata

EtcSec non dovrebbe etichettare questo articolo con un tipo di vulnerabilità impreciso se il catalogo non contiene una voce diretta Shadow Credentials o msDS-KeyCredentialLink. L’esposizione correlata si adatta comunque al modello di audit Active Directory di EtcSec: permessi oggetto pericolosi, esposizione di account privilegiati, percorsi ACL ereditati e lacune di monitoring sui cambiamenti degli oggetti AD.

In pratica, una review EtcSec può aiutare a identificare le condizioni che rendono praticabile questo attack path: principal con controllo di scrittura eccessivo su oggetti utente o computer, account privilegiati non isolati, percorsi ACL pericolosi verso identità amministrative e gap di monitoring sulle modifiche directory. Questo è il framing corretto. Shadow Credentials non è una debolezza Kerberos generica; è un percorso di abuso Key Trust creato dal controllo dell’oggetto.

Controlli correlati

I controlli Shadow Credentials devono essere legati all’ownership delle identità, non solo al monitoraggio Kerberos.

Controllo	Perché conta
Inventariare `msDS-KeyCredentialLink` su utenti e computer	Stabilisce quali percorsi di autenticazione basati su chiave esistono prima di un incidente.
Limitare l’accesso in scrittura agli attributi key credential	Impedisce a principal non autorizzati di aggiungere nuovo materiale di autenticazione.
Monitorare 5136 su `msDS-KeyCredentialLink`	Cattura modifiche a livello di attributo quando Directory Service Changes auditing e SACL sono configurati.
Monitorare 4662 su oggetti identità sensibili	Espone operazioni Write Property, DACL e ownership quando le SACL sono presenti.
Correlare 4768 con modifiche directory	Aiuta a collegare il comportamento di autenticazione basata su chiave a modifiche recenti sugli oggetti.
Proteggere account privilegiati con isolamento amministrativo	Riduce la possibilità che una compromissione di livello inferiore possa modificare oggetti identità di alto valore.
Rivedere Key Admins e comportamento AdminSDHolder	Evita che percorsi amministrativi WHfB legittimi diventino percorsi incontrollati di scrittura chiavi privilegiate.

Questi controlli supportano anche un hardening AD più ampio. Se stai costruendo una review strutturata, combina questo articolo con Auditare la sicurezza di Active Directory: checklist pratica, poi priorizza prima oggetti identità privilegiati e OU sensibili.

Shadow Credentials: abuso di msDS-KeyCredentialLink in Active Directory