Perché le credenziali in memoria sono un bersaglio

Dopo l’autenticazione, il processo LSASS (Local Security Authority Subsystem Service) conserva in memoria i secret necessari al single sign-on: hash NTLM, ticket Kerberos (TGT/TGS), talvolta password in chiaro. Un attaccante con privilegi amministrativi locali può estrarli con strumenti tipo Mimikatz e riutilizzarli senza conoscere la password: è l’attacco pass-the-hash (riuso dell’hash NTLM) o pass-the-ticket (riuso del ticket Kerberos). In un dominio, un singolo host compromesso diventa il trampolino per il movimento laterale verso altri server. La difesa si gioca su due fronti: isolare i secret in memoria e ridurre il valore di ciò che viene rubato.

Credential Guard e Virtualization-Based Security

Credential Guard si appoggia alla Virtualization-Based Security (VBS): l’hypervisor Hyper-V crea una regione di memoria isolata (Virtual Secure Mode) in cui gira un processo LSA isolato (LSAIso). Gli hash NTLM e i TGT Kerberos vengono spostati lì, fuori dalla portata del normale LSASS: nemmeno un processo con privilegi SYSTEM nel sistema operativo “normale” può leggerli. Questo neutralizza pass-the-hash e pass-the-ticket alla radice.

Requisiti: firmware UEFI con Secure Boot, estensioni di virtualizzazione della CPU (Intel VT-x/AMD-V), IOMMU, TPM consigliato; in una VM serve la nested virtualization. In Windows Server 2022 non è attivo di default e va abilitato via Group Policy (“Turn On Virtualization Based Security”); su hardware compatibile Windows Server 2025 può presentarlo già attivo.

Attenzione ai limiti: Credential Guard non protegge gli account locali del database SAM, non ferma i keylogger e rompe protocolli legacy — unconstrained delegation Kerberos, DES, NTLMv1, credenziali salvate via CredSSP/Digest. Va testato prima in ambienti che ne dipendono. Complemento importante è la LSA Protection (RunAsPPL), che esegue LSASS come Protected Process Light impedendo ai processi non firmati di aprirne la memoria: misura diversa e cumulabile, non un’alternativa.

Windows LAPS per l’administrator locale

Anche con LSASS blindato, resta il rischio che tutti i server condividano la stessa password di administrator locale: un hash rubato apre l’intero parco macchine. Windows LAPS (Local Administrator Password Solution, ormai integrato in Windows e Windows Server, non più il tool legacy separato) gestisce e ruota automaticamente la password dell’account admin locale, memorizzandola in Active Directory on-premises oppure in Microsoft Entra ID. Ogni macchina ha così una password unica e periodicamente rinnovata: il valore di un hash rubato crolla, perché non è riutilizzabile altrove e scade in fretta. Windows LAPS aggiunge la cifratura della password in AD (con domain functional level adeguato) e la rotazione dopo l’autenticazione (rigenera la password poco dopo l’uso). Si configura via Group Policy o Intune.

Just Enough Administration (JEA)

JEA applica il principio del least privilege all’amministrazione via PowerShell. Invece di rendere admin un operatore, gli si espone un endpoint PowerShell vincolato (session configuration) che consente solo i cmdlet e i parametri necessari al suo ruolo. Le autorizzazioni si descrivono in Role Capability file (.psrc) e Session Configuration file (.pssc); l’endpoint si registra con Register-PSSessionConfiguration. Alla connessione i comandi girano sotto un virtual account temporaneo o un gMSA con i privilegi elevati, mentre l’utente collegato resta non privilegiato. Il risultato: meno account amministrativi permanenti, superficie ridotta e logging centralizzato delle azioni. JEA riduce così la probabilità stessa che credenziali ad alto valore finiscano in memoria su un host esposto.

Trappole tipiche d’esame

  • Bloccare pass-the-hash isolando i secret in memoria → Credential Guard (VBS): l’isolamento hardware-assistito è la risposta; LAPS e JEA riducono l’impatto ma non isolano LSASS.
  • Credenziali admin locali identiche su molti server → Windows LAPS: rotazione e password uniche per host; Credential Guard non tocca la password dell’account locale.
  • Credential Guard “non si attiva” → mancano i requisiti VBS: senza UEFI/Secure Boot, estensioni di virtualizzazione o nested virtualization in VM non parte, a prescindere dalla Group Policy.
  • App legacy con unconstrained delegation o NTLMv1 smette di funzionare → incompatibilità nota di Credential Guard: è un trade-off atteso, non un bug; verificare prima di abilitare.
  • Dare a un operatore solo alcuni comandi senza renderlo admin → JEA: endpoint vincolato con virtual account/gMSA, non l’aggiunta al gruppo Administrators.
  • Rafforzare LSASS dove Credential Guard non è disponibile → LSA Protection (RunAsPPL): complementare, protegge la memoria di LSASS dai processi non firmati.