Oltre il vault: lo zero standing privilege neutralizza più dei soli attacchi alle password

Parte 2 di 3 della nostra serie Rethinking Privileged Access. Inizia dalla Parte 1: La password non è mai stata l'unico problema.

Nella Parte 1 abbiamo tracciato la linea tra il modello vault-and-checkout del PAM legacy e il modello session-and-Activities del PAM moderno con Netwrix Privilege Secure (NPS). Uno protegge la password; l'altro elimina lo standing privilege che sta dietro di essa. Questa impostazione è un buon punto di partenza, ma sottovaluta il problema. In Windows e Active Directory, la password è solo il seme. Tutto ciò che un attaccante usa per muoversi lateralmente deriva da essa o viene emesso a causa sua: un hash NTLM, un ticket Kerberos, un accesso in cache, un certificato, un blob DPAPI. Uno strumento PAM che protegge solo la password protegge un solo anello di una catena molto più lunga.

Qui emerge la vera differenza tra PAM legacy e PAM moderno. Il vault nasconde la password, ma non tocca nulla di ciò che ne deriva. NPS rimuove lo standing privilege ruotando, disabilitando o eliminando gli account nel momento in cui una sessione termina. Questo interrompe diversi di quei percorsi di attacco a valle, perché la maggior parte di essi dipende dall'esistenza di un account privilegiato, in uno stato utilizzabile, per più tempo del necessario. NPS, tuttavia, non previene del tutto minacce AD come il Kerberoasting. Altri prodotti Netwrix, come Netwrix Threat Prevention, possono aiutare rilevando attività di autenticazione sospette.

La superficie delle credenziali che nessuno protegge con un vault

Ecco cosa è attaccabile in un ambiente Windows/AD oltre alla password in chiaro:

• Hash NTLM: utilizzabili direttamente tramite Pass-the-Hash, senza bisogno di craccarli.
• Ticket Kerberos (TGT/TGS): rubabili e riutilizzabili tramite Pass-the-Ticket e falsificabili tramite Golden e Silver Ticket se la chiave krbtgt o quella di un account di servizio viene compromessa.
• Materiale vulnerabile a Kerberoasting/AS-REP roasting: qualsiasi utente di dominio può richiedere un ticket di servizio per un account con SPN, o un AS-REP per un account con preautenticazione disabilitata, e craccarlo offline.
• Credenziali di dominio in cache (MSCACHEv2): presenti nell'hive SECURITY locale di qualsiasi macchina su cui un utente abbia effettuato l'accesso.
• Certificati e voci msDS-KeyCredentialLinkExpand: sfruttabili tramite errori di configurazione dei template AD CS o attacchi Shadow Credential, autenticandosi come un utente senza mai toccarne la password.
• Password gestite da LAPS/gMSA: protette solo dall'ACL sull'attributo che le memorizza.
• Segreti protetti da DPAPI: decifrabili se un attaccante ricava la master key dell'utente o sottrae la chiave di backup DPAPI del dominio.

Nessuno di questi elementi richiede la password in chiaro e tutti concedono qualcosa di molto simile.

Perché lo standing privilege è il filo conduttore

Quasi ogni voce di quell'elenco è potente solo perché l'account che la sostiene detiene privilegi reali in questo momento e continua a detenerli indefinitamente. Una configurazione PAM legacy, con una password custodita in un vault, ruotata e iniettata sopra un'appartenenza permanente a Domain Admins, lascia comunque un hash NTLM che vale la pena rubare, un TGS che vale la pena sottoporre a roasting e un accesso in cache che vale la pena craccare tra un checkout e l'altro.

I modelli di account di NPS (richiedente, gestito ed effimero, descritti per intero nella Parte 1) attaccano direttamente questa causa comune. Gli account gestiti vengono disabilitati e ruotati di nuovo nel momento in cui la sessione termina, gli account effimeri vengono eliminati del tutto e persino gli account richiedenti hanno un'appartenenza elevata ai gruppi solo per la durata della sessione.

Poiché il privilegio ha un inizio e una fine invece di esistere per sempre, la maggior parte degli attacchi sopra elencati perde il proprio bersaglio nell'istante in cui la sessione si chiude. NPS non ha bisogno di rilevare l'attacco perché non resta più nulla che valga la pena attaccare.

Cosa cambia NPS per ciascun attacco

Con NPS, un account compromesso ha privilegi limitati, il che pone un tetto al danno che può causare.

Due funzionalità che ampliano ulteriormente l'effetto

Due delle Activities di NPS non legate agli account, entrambe introdotte nella Parte 1, meritano di essere richiamate di nuovo perché estendono questa stessa logica oltre le credenziali:

• Abilitazione/disabilitazione di RDP. La maggior parte dei server lascia RDP in ascolto in modo permanente. NPS può attivarlo solo per la durata di una sessione e disattivarlo subito dopo. Questo elimina una superficie di attacco ampia e sempre disponibile che non ha nulla a che fare con la credenziale in mano all'attaccante.
• Modalità di protezione. La scansione di risorse Windows e Linux alla ricerca di account locali non approvati intercetta una diversa modalità di errore: un insider (o un attaccante già entrato) che crea di nascosto un account permanente per un uso futuro. Applica la stessa filosofia del «non lasciare che si accumuli privilegio non gestito» agli account che NPS non ha creato in origine.

Cosa non sostituisce

Vale la pena essere precisi sul confine, perché esagerare non fa un favore a nessuno. NPS è efficace contro gli attacchi che dipendono dalla persistenza di un account privilegiato in uno stato utilizzabile, il che copre una parte sorprendentemente ampia del catalogo di attacchi alle credenziali Windows. Non incide sugli attacchi che operano indipendentemente dallo stato in tempo reale di un singolo account: un Golden Ticket falsificato da una chiave krbtgt rubata, l'abuso dei template AD CS, una Shadow Credential scritta in un attributo o il furto della chiave di backup DPAPI a livello di dominio. Tutto questo richiede una propria igiene (disciplina nella rotazione di krbtgt, revisione dei template di certificato, monitoraggio delle scritture sugli attributi, protezione della chiave di backup), indipendentemente da quanto sia rigoroso il modello di sessione e Activities.

In sintesi

Il PAM legacy custodisce una password in un vault e protegge un solo artefatto. Eliminare lo standing privilege riduce il valore di quasi tutto ciò che deriva da quella password: hash, ticket, accessi in cache e attributi degli account gestiti. Quegli artefatti valgono il furto solo se il privilegio che c'è dietro è ancora presente quando l'attaccante prova a usarli. NPS non fermerà ogni attacco alle credenziali in Active Directory, ma chiude molta più superficie di attacco di quanto «proteggere la password» potrebbe mai fare.

Prossimamente in questa serie

Tutto quanto sopra presuppone che gli account funzionino interamente con i modelli di account di NPS. La Parte 3 illustra Bring Your Own Vault (BYOV): come NPS aggiunge questa stessa protezione basata sulle sessioni sopra un vault che già utilizzi (un vault PAM legacy, CyberArk, BeyondTrust, HashiCorp Vault o LAPS), così puoi iniziare a ridurre questa esposizione senza migrare tutto in una volta.