Impatto Sistemico

Critico (82.05)

Sintesi

È stata rilevata una vulnerabilità in dMSA (delegated Managed Service Account), nuova funzionalità introdotta in Windows Server 2025 all’interno di Active Directory che consente di delegare la creazione e la gestione di account di servizio a utenti non privilegiati. Microsoft ha riconosciuto il problema, ma lo ha classificato come “Moderate Severity” e non ha ancora rilasciato una patch.

Note: un Proof of Concept (PoC) per lo sfruttamento della vulnerabilità risulta disponibile in rete.

Tipologia

• Privilege Escalation

Descrizione e potenziali impatti

È stata rilevata una vulnerabilità in dMSA (delegated Managed Service Account), nuova funzionalità introdotta in Windows Server 2025 all’interno di Active Directory che consente di delegare la creazione e la gestione di account di servizio a utenti non privilegiati. Microsoft ha riconosciuto il problema, ma lo ha classificato come “Moderate Severity” e non ha ancora rilasciato una patch.

Un dMSA viene tipicamente utilizzato per sostituire un account di servizio legacy, per semplificare la gestione delle credenziali, automatizzando la gestione delle password e legando l’autenticazione all’identità del dispositivo. Per facilitare questa transizione, i dMSA possono essere configurati in modo da assumere i permessi o le funzionalità associate all’account legacy, tramite un meccanismo di migrazione.

Questa funzionalità può tuttavia essere abusata per assegnare, in modo improprio, privilegi elevati a un nuovo account controllato da un attaccante.

Dettaglio

Ricercatori di sicurezza hanno rilevato una criticità nel suddetto meccanismo. Gli attaccanti potrebbero simulare la migrazione in questo modo:

1. creando, come utente non privilegiato, ma avente il permesso “CreateChild” su una Organizational Unit (OU), un nuovo oggetto dMSA;
2. modificando due attributi sull’oggetto dMSA:
3. msDS-ManagedAccountPrecededByLink – impostandolo al DistinguishedName dell’utente target;
4. msDS-DelegatedMSAState – impostandolo a “2” (che indica il completamento della migrazione).

Tale configurazione inganna il sistema facendogli credere che sia avvenuta una migrazione legittima.

A questo punto, infatti, il dMSA assume (copia) le autorizzazioni ACL, l’associazione del Service Principal Name (SPN), la configurazione di deleghe Kerberos e anche eventuali SIDHistory. In sintesi, il nuovo dMSA eredita i privilegi dell’account legacy.

In tale scenario, un eventuale attaccante può:

• elevare istantaneamente i propri privilegi per corrispondere a qualsiasi utente scelto, inclusi Domain Admins o account di servizio sensibili;
• effettuare movimenti laterali all’interno dell’ambiente;
• effettuare un attacco di tipo “golden ticket”;
• eludere i meccanismi di isolamento o tiering.

Prodotti e/o versioni affette

• Windows Server 2025

Azioni di mitigazione

Per valutare la propria esposizione, è stato rilasciato da Akamai uno script PowerShell al link: https://raw.githubusercontent.com/akamai/BadSuccessor/refs/heads/main/Get-BadSuccessorOUPermissions.ps1 . Tale script analizza l’ambiente AD al fine di identificare utenti o gruppi che dispongono dei permessi necessari per creare dMSA nelle OU (CreateChild), evidenziando quali OU sono a rischio.

In attesa del rilascio di un aggiornamento ufficiale da parte del vendor, volto a sanare la vulnerabilità, si raccomanda agli utenti e alle organizzazioni di valutare la verifica e l’implementazione delle seguenti azioni preventive:

1. Abilitare auditing e logging dettagliato per la creazione di nuovi oggetti dMSA: monitorare in modo approfondito la creazione, la modifica e l’autenticazione degli account dMSA abilitando gli Event ID di Active Directory, come:
2. 5137 (creazione);
3. 5136 (modifica attributi, in particolare per msDS-ManagedAccountPrecededByLink e msDS-DelegatedMSAState);
4. 2946 (autenticazione);
5. Integrare questi log con sistemi SIEM o strumenti di monitoring per ricevere alert tempestivi su attività sospette.
6. Limitare chi può creare e gestire i dMSA: ridurre al minimo gli utenti o i gruppi con delega alla creazione di dMSA. In particolare, rimuovere i permessi “CreateChild” o equivalenti da account o gruppi non specificamente incaricati dell’amministrazione degli account di servizio.
7. Verificare e rimuovere associazioni SPN non autorizzate: controllare regolarmente gli SPN associati ai nuovi account dMSA e rimuovere quelli che non sono necessari o che sembrano sospetti.