Il 30 ottobre 2026 Microsoft ha descritto due intrusioni aziendali iniziate con falsi contatti di assistenza su Teams e proseguite con l’abuso di Active Directory Certificate Services (AD CS). Gli aggressori hanno seguito due percorsi distinti, ESC1 e PetitPotam/ESC8: Teams è stato il canale di ingegneria sociale, mentre l’escalation è passata da configurazioni permissive dei servizi di certificazione. Microsoft ha pubblicato il rapporto il 30 ottobre; non ha descritto una vulnerabilità software di Teams.
Dalla falsa assistenza all’accesso remoto
In entrambi i casi, gli aggressori si sono presentati su Teams come addetti IT o del supporto tecnico e hanno convinto gli utenti a concedere l’accesso remoto, principalmente tramite Quick Assist. I contatti arrivavano da tenant esterni e potevano usare nomi che richiamavano l’organizzazione o l’assistenza.
Dopo aver ottenuto accesso interattivo, gli aggressori hanno collocato archivi nelle cartelle utente, li hanno estratti in directory appena create e scrivibili dall’utente e hanno avviato script con runtime portatili di Python, Bun o Java. Da lì hanno esplorato i sistemi e l’infrastruttura di certificazione. La sequenza conta più del nome di un file: Microsoft avverte che un runtime o un nome sospetto, preso da solo, non prova una compromissione.
Due percorsi diversi attraverso AD CS
Nel primo caso, una configurazione vulnerabile di un modello di certificato consentiva a chi faceva la richiesta di specificare l’identità e di ottenere certificati per account privilegiati. È il percorso ESC1. Nel secondo, PetitPotam ha indotto un controller di dominio a eseguire l’autenticazione NTLM; l’aggressore ha inoltrato quell’autenticazione a AD CS Web Enrollment, sfruttando ESC8, e ha ottenuto un certificato per l’identità del controller.
Nel caso ESC1, la prima ondata ha coinvolto tre utenti e una workstation; l’aggressore ha ottenuto certificati per tre account altamente privilegiati. Circa 90 minuti dopo, una seconda ondata ha preso di mira 16 utenti e un’altra workstation, portando a otto ulteriori certificati privilegiati. Microsoft Defender ha bloccato più di 1.000 successivi tentativi di accesso ai file SMB e di logon.
Nel frattempo, però, un account privilegiato escluso dal contenimento automatico è rimasto utilizzabile. L’aggressore lo ha impiegato per raggiungere un file server e trasferire dati verso una destinazione SFTP esterna. Inoltre, un’operazione DCSync, che replica dati di directory, è iniziata pochi secondi dopo l’emissione di un certificato privilegiato; il contenimento ha limitato la replica successiva.
Nel secondo caso, il certificato del controller di dominio è stato usato per l’autenticazione Kerberos basata su certificati, chiamata PKINIT, e per richiedere un ticket TGT. Microsoft Defender ha generato avvisi relativi a ESC8; il cliente ha quindi isolato la workstation associata e Microsoft non ha osservato ulteriori progressi dell’attacco dopo l’isolamento.
I segnali da correlare durante l’indagine
Microsoft ha pubblicato quattro categorie di query di advanced hunting, da adattare all’ambiente e usare come piste d’indagine, non come verdetti:
- contatti esterni sospetti e segnali di impersonificazione su Teams;
- esecuzione di Bun o Java da percorsi di staging con prefisso KB nelle cartelle AppData;
- attività di rete avviata da quei runtime verso le porte 80, 445, 636 o 88;
- avvisi relativi a relay NTLM, Certificate Services, PKINIT o richieste di ticket Kerberos.
Per ricostruire una catena, i team di sicurezza possono collegare la conversazione o la chiamata su Teams e la sessione remota ai processi avviati sulla workstation, alle richieste e alle emissioni di certificati, agli avvisi d’identità e all’attività Kerberos. Un risultato delle query va verificato insieme agli altri segnali: un nome di runtime, una connessione o un avviso isolato non basta a dimostrare una compromissione.
Le misure di risposta indicate da Microsoft
Microsoft raccomanda di verificare le richieste di assistenza inattese attraverso canali interni già noti, riesaminare gli accessi esterni a Teams in base alle necessità operative e limitare il supporto remoto a strumenti e procedure approvati.
Per AD CS, le indicazioni comprendono la revisione dei modelli abilitati all’autenticazione, delle informazioni sull’identità inseribili nelle richieste, dei permessi di registrazione e dei controlli di emissione. Microsoft indica inoltre di rimuovere gli endpoint Web Enrollment non necessari, richiedere HTTPS e Extended Protection for Authentication (EPA) e disabilitare NTLM sui servizi di registrazione dove sia possibile sul piano operativo. La guida Microsoft alla mitigazione dei relay NTLM su AD CS approfondisce EPA e le protezioni degli endpoint; la valutazione Microsoft delle configurazioni dei certificati descrive i rischi legati ai modelli e agli endpoint di registrazione.
Se viene emesso un certificato non autorizzato, Microsoft raccomanda di individuarlo e revocarlo, aggiornare le informazioni di revoca e controllare separatamente i ticket Kerberos già attivi. Cambiare una password o ricreare la workstation iniziale non revoca un certificato già emesso e non annulla i ticket già rilasciati. Per ogni identità o dispositivo escluso dal contenimento automatico, serve un intervento manuale compensativo e la verifica che sia stato completato.
