Reset password in AD: l'attaccante resta dentro dopo il cambio

Il reset password in AD non espelle l'attaccante: ticket Kerberos, cache locali e backdoor ACL mantengono la persistenza anche dopo il cambio credenziali.

Contenuto

Reset password in AD: l'attaccante resta dentro dopo il cambio
Reset password in AD: l'attaccante resta dentro dopo il cambio

Quando un team SOC cambia le credenziali compromesse, chiude il ticket e archivia l'incidente, può accadere che nelle ore successive gli alert segnalino nuovi accessi: ticket Kerberos ancora validi e hash in cache locale riaprono il varco. L'attaccante non è uscito.

Non si tratta di un bug zero-day, ma di comportamenti progettuali noti di Active Directory, descritti in un'analisi tecnica di BleepingComputer dell'11 maggio 2026. Il reset password non interrompe la persistenza: cache, ticket validi e backdoor ACL garantiscono accesso anche dopo il cambio credenziali, generando un falso senso di sicurezza che espone, secondo The Hacker News del 12 novembre 2025, oltre il 90% delle aziende Fortune 1000.

Secondo BleepingComputer sulla base dei dati Verizon DBIR, circa il 44,7% delle violazioni coinvolge credenziali rubate. Spiega perché il reset sia il primo riflesso difensivo, ma anche perché da solo non risolva la persistenza tecnica.

Punti chiave
  • Anche dopo il reset, i sistemi Windows possono conservare in cache l'hash precedente se non hanno riconnesso il dominio, permettendo l'accesso offline e tecniche pass-the-hash.
  • I ticket Kerberos rimangono validi per la loro durata residua indipendentemente dal cambio password, consentendo a un attaccante di mantenere sessioni attive senza reinserire credenziali.
  • Attacchi Golden Ticket e Silver Ticket aggirano completamente il controllo delle password perché l'attaccante forgi autonomamente ticket Kerberos validi per il dominio.
  • Modifiche alle Access Control Lists, incluso l'oggetto AdminSDHolder, creano backdoor di permessi che persistono oltre la rotazione delle credenziali e vengono riapplicate ogni ora.
"Password resets are often the first response to a suspected compromise. It makes sense; resetting credentials is a quick way to cut off an attacker's most obvious path back in. However, that doesn't always completely solve the issue." BleepingComputer, 11 maggio 2026

Perché il cambio password non invalida l'hash ovunque

Quando un amministratore impone un cambio password in Active Directory, la modifica viene scritta sul domain controller, ma la propagazione non è istantanea su tutti i percorsi di autenticazione.

I sistemi Windows memorizzano in cache gli hash delle password per garantire l'accesso offline; se l'endpoint non si è riconnesso al dominio dopo il reset, l'hash precedente può rimanere utilizzabile per l'autenticazione locale.

Negli ambienti ibridi che sincronizzano Active Directory con Entra ID, può inoltre esistere un ritardo di replica prima che la nuova password hash venga propagata all'intera infrastruttura.

In questa finestra temporale, un attaccante può riutilizzare l'hash precedente tramite tecniche di pass-the-hash, continuando a muoversi lateralmente nella rete senza necessità di conoscere la nuova credenziale.

I ticket Kerberos come ponte di persistenza

"Once attackers control AD, they control your entire network." Secondo un'analisi di The Hacker News del 12 novembre 2025, questa è la posta in gioco. In Active Directory, l'autenticazione Kerberos emette ticket che rimangono validi per un periodo definito dalle policy del dominio, indipendentemente da un successivo reset della password.

Se un attaccante ha già ottenuto un ticket valido, può continuare ad accedere alle risorse senza reinserire la password e senza che il domain controller invalidi automaticamente la sessione.

Questo comportamento dipende dalla distinzione architetturale tra il servizio di autenticazione e il ticket granting service: il domain controller emette il ticket, ma non monitora continuamente la revoca in tempo reale dopo un cambio password.

La durata esatta dipende dalle configurazioni dell'organizzazione, ma la finestra temporale è in molti casi sufficiente per consolidare la persistenza ed eseguire movimento laterale verso altri sistemi.

Golden Ticket e Silver Ticket: accesso senza credenziali

Gli attacchi Golden Ticket e Silver Ticket rappresentano uno scenario ancora più estremo. Forgiando un Ticket Granting Ticket o un ticket di servizio, l'attaccante non necessita di credenziali valide né della password hash più recente.

Il reset utente non invalida questi documenti crittografici generati autonomamente, perché il dominio li riconosce come tecnicamente legittimi.

Chi controlla il segreto KRBTGT può emettere autorizzazioni valide per l'intera foresta, rendendo il cambio password un'azione del tutto ininfluente sullo stato di compromissione.

Questa tecnica sfrutta il fatto che il dominio si fida dei ticket firmati con la chiave segreta dell'account KRBTGT, un meccanismo che non viene interrotto dal semplice cambio password di un utente compromesso.

Le backdoor nascoste nelle ACL e in AdminSDHolder

Un vettore di persistenza del tutto indipendente dalle credenziali risiede nelle Access Control Lists. Un attaccante con privilegi elevati può modificare i permessi ereditati dagli oggetti protetti, incluso AdminSDHolder, il contenitore che definisce la Security Descriptor Propagator.

Il processo SDProp ripristina automaticamente quei permessi ogni ora sui gruppi privilegiati del dominio. Anche dopo aver resettato tutte le password degli amministratori, la backdoor ACL sopravvive.

Se l'aggressore ha inserito una backdoor ACL, questa viene riapplicata periodicamente, mantenendo l'accesso anche dopo la rotazione di tutte le password degli amministratori.

Questo meccanismo rende la backdoor particolarmente insidiosa, perché non richiede né l'hash della password né un ticket attivo per mantenere i privilegi nel tempo.

Cosa fare adesso

I team di risposta devono trattare il reset delle password come il primo anello di una catena più ampia, non come conclusione dell'incidente. L'evacuazione completa richiede azioni coordinate su più livelli.

  1. Invalidate le sessioni e i ticket Kerberos. La modifica password non revoca automaticamente i ticket già emessi né scollega le sessioni attive. È necessario forzare la disconnessione degli utenti compromessi e, dove possibile, attivare procedure di purge per chiudere la finestra di persistenza.
  2. Ruotate la password dell'account KRBTGT. Questa operazione invalida i Golden Ticket potenzialmente forgiati dagli attaccanti, poiché il trust del dominio si basa sul segreto di quel service account.
  3. Auditate le ACL e AdminSDHolder. Verificare le configurazioni esatte e ripristinare le ACL originarie è l'unico modo per rimuovere accessi indipendenti dalle credenziali, dato che le modifiche a AdminSDHolder vengono riapplicate automaticamente ogni ora da SDProp.
  4. Verificate la cache locale e la sincronizzazione ibrida. Assicuratevi che gli endpoint Windows abbiano ristabilito la comunicazione con il domain controller, e che in ambienti AD/Entra ID non permangano ritardi di replica che mantengano attivo il vecchio hash.

Nota editoriale. Le analisi citate sono editoriali tecnici programmatici, non il resoconto di un singolo breach documentato. BleepingComputer descrive meccanismi noti di Active Directory in un articolo con riferimenti commerciali a Specops; la stessa fonte riporta, in base a claim del vendor, che una soluzione di monitoraggio password ha bloccato più di 4 miliardi di credenziali compromesse. The Hacker News presenta un conflitto di data interno (byline 12 novembre 2025, metadata 11 maggio 2026) e contenuto promozionale in calce. DeafNews ha verificato i fatti tecnici indipendentemente dalla natura sponsorizzata dei materiali.

La lezione è che Active Directory non è un sistema di autenticazione monolitico: la separazione tra identità, autorizzazione e configurazione dei permessi crea falle procedurali che gli attaccanti sanno sfruttare.

Al CISO: il piano di risposta agli incidenti non può terminare con il reset. È necessario invalidare sessioni e ticket, ruotare il segreto KRBTGT e auditar le ACL prima di dichiarare chiuso l'evento. Altrimenti non si sta chiudendo una porta: si sta solo cambiando la serratura, mentre l'intruso è già dall'altra parte con un duplicato delle chiavi. È questa l'illusione che costa più cara.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

Link utili

Apri l'articolo su DeafNews