Falso supporto IT su Teams, poi certificati di dominio: Microsoft descrive due intrusioni tramite AD CS

Microsoft ha indagato su due intrusioni iniziate con falsi tecnici su Teams e proseguite con l’abuso di Active Directory Certificate Services. In un caso, i certificati di account privilegiati hanno portato al furto di dati da un file server. Nessuna vulnerabilità di Teams è stata sfruttata: sono bastati un dipendente convinto e una configurazione AD CS insicura.

Cosa è successo

In un rapporto del 30 ottobre 2026, Microsoft Threat Intelligence descrive due intrusioni condotte da operatori umani in organizzazioni di cui non fa il nome. Entrambe sono iniziate allo stesso modo: messaggi e chiamate su Teams da account che si spacciavano per l’help desk, per convincere i dipendenti ad aprire una sessione di Assistenza rapida (Quick Assist) o simile. Microsoft precisa che non è stata sfruttata alcuna vulnerabilità di Teams e non attribuisce l’attività a un attore specifico.

Come sono entrati gli attaccanti

Primo caso (ESC1). Una prima ondata ha preso di mira tre utenti e compromesso una postazione. Un modello di certificato mal configurato ha poi fornito all’attaccante certificati per tre account con privilegi elevati. Circa 90 minuti dopo l’interruzione della prima sessione, una seconda ondata ha colpito 16 utenti e ha fruttato certificati per altri otto account privilegiati. Pochi secondi dopo averne ottenuto uno, l’attaccante si è autenticato su un controller di dominio e ha avviato un DCSync. Un account privilegiato era stato escluso dalla risposta automatica: da lì ha raggiunto un file server, dove una copia rinominata di Rclone ha inviato dati a una destinazione SFTP esterna.

Secondo caso (ESC8). PetitPotam ha costretto un controller di dominio ad autenticarsi presso un sistema controllato dall’attaccante. Quell’autenticazione è stata inoltrata alla registrazione web di AD CS, ottenendo un certificato e poi un ticket Kerberos per l’account del controller. Il cliente ha isolato la postazione dopo gli avvisi e Microsoft non ha osservato ulteriori progressi.

Cosa fare ora

  1. Controllate Teams e l’assistenza remota: limitate i domini esterni, consentite solo gli strumenti di supporto approvati e fate confermare ogni richiesta di supporto non sollecitata tramite un canale interno noto.
  2. Verificate i modelli di certificato: eseguite certutil -v -template e cercate CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT nei modelli che consentono l’autenticazione. Disattivate l’opzione Specificare nella richiesta, limitate i diritti di registrazione o richiedete l’approvazione di un responsabile.
  3. Proteggete la registrazione web: censite gli endpoint Web Enrollment e Certificate Enrollment Web Service e rimuovete quelli inutili. Per gli altri imponete HTTPS e impostate la protezione estesa per l’autenticazione (EPA) su “Obbligatorio”, come indicato nel KB5005413, poi eseguite iisreset /restart.
  4. Attivate l’audit dell’autorità di certificazione per richieste ed emissioni. Revocate i certificati illegittimi e controllate anche i ticket Kerberos: la revoca non invalida quelli già emessi.
  5. Rivedete le esclusioni dal contenimento: ogni account escluso dalla risposta automatica richiede un responsabile designato e un’azione manuale.

Il nostro parere

Il phishing spiega l’ingresso, ma sono le impostazioni dei certificati a spiegare la velocità: una sola postazione è bastata per raggiungere account a livello di dominio. AD CS viene spesso installato una volta e poi dimenticato, anche se merita la stessa protezione di un controller di dominio.

Fonti

Come scegliamo, verifichiamo e scriviamo le nostre analisi →

Le credenziali rubate iniziano spesso con un messaggio di phishing. Hai ricevuto un messaggio sospetto (SMS, WhatsApp, social) o un'e-mail? Verificalo prima di cliccare:

Verifica un messaggio Verificare un’e-mail

Temi che i tuoi server siano esposti? Il nostro team verifica, aggiorna e monitora infrastrutture Linux e cloud 24/7.

Parla con un esperto I nostri servizi di gestione server →