Spring Ring, il vishing su Microsoft Teams che punta al controllo del dominio Windows
Cloud Security

Immagine illustrativa generata con AI

Spring Ring, il vishing su Microsoft Teams che punta al controllo del dominio Windows

Finto help desk su Teams induce a installare Quick Assist per accesso remoto e relay NTLM al domain controller. Campagna Spring Ring.

Testo generato da intelligenza artificiale, pubblicato senza revisione umana. Trasparenza IA

Un falso tecnico dell’help desk apre una chat su Microsoft Teams, chiama la vittima e la guida nell’installazione di strumenti di accesso remoto. Dietro l’assistenza simulata c’è però un’operazione offensiva che può arrivare fino al domain controller.

La campagna, denominata Spring Ring da Palo Alto Networks ed emersa il 2 settembre 2026, ha preso di mira almeno 150 utenti appartenenti ad almeno 10 organizzazioni. L’attività osservata si è svolta tra gennaio e aprile.

Gli aggressori hanno combinato ingegneria sociale, software legittimo per il supporto remoto, payload PowerShell e tecniche di relay NTLM. Nel vettore più avanzato hanno cercato di costringere un domain controller ad autenticarsi verso un’infrastruttura sotto il loro controllo.

Il falso help desk entra direttamente in Teams

L’attacco comincia all’interno di Microsoft Teams, una piattaforma che molti dipendenti associano automaticamente alle comunicazioni aziendali attendibili. Gli aggressori creano conversazioni usando nomi visualizzati che richiamano l’help desk, l’assistenza informatica o il personale di supporto.

Alla chat segue una chiamata vocale. Il passaggio alla voce permette al falso tecnico di esercitare pressione in tempo reale, rispondere alle esitazioni e accompagnare la vittima attraverso una sequenza precisa di operazioni.

Le telefonate andate a buon fine durano generalmente tra 10 e 15 minuti. Gli operatori mostrano inoltre una certa perseveranza: ripetono i tentativi di contatto e, quando necessario, lasciano messaggi vocali.

L’obiettivo non è convincere l’utente a compiere un singolo clic. La vittima viene indotta a eseguire programmi, installare strumenti di amministrazione remota oppure aprire file preparati appositamente per la sua organizzazione.

È un cambiamento rilevante rispetto al phishing tradizionale. Il dipendente non deve soltanto valutare un messaggio statico, ma prendere decisioni durante una conversazione con qualcuno che si presenta come un collega autorizzato.

Secondo un rapporto di threat hunting di CrowdStrike citato nell’analisi della campagna, gli attacchi di vishing sarebbero raddoppiati nella prima metà del 2026. Il dato non costituisce tuttavia una conferma indipendente di Spring Ring.

Quick Assist e software RMM aprono il primo accesso

Nel primo scenario osservato, il falso tecnico convince l’utente ad avviare Windows Quick Assist oppure un software RMM, cioè uno strumento legittimo per il monitoraggio e la gestione remota dei dispositivi.

Questi programmi vengono normalmente impiegati dagli amministratori per fornire assistenza. Se la sessione è autorizzata dalla vittima, però, l’attaccante può ottenere il controllo del computer senza sfruttare necessariamente una vulnerabilità software.

Dopo l’accesso, gli operatori di Spring Ring eseguono una ricognizione iniziale sull’host e sul dominio Windows. Cercano così di comprendere la configurazione del dispositivo, il contesto aziendale e le possibili opportunità per proseguire l’intrusione.

In una delle attività analizzate è stato tentato il download di un RAT scritto in PowerShell e offuscato. Il payload avrebbe fornito capacità di accesso remoto persistente, ma la protezione endpoint ne ha bloccato l’esecuzione.

Il nome del RAT non è stato reso noto. Non sono disponibili neppure hash dei file, domini, indirizzi IP o altri indicatori tecnici utilizzabili direttamente per una ricerca retrospettiva.

Questa carenza rende più importante il rilevamento comportamentale. Limitarsi a cercare una specifica firma malware rischia di non intercettare la fase iniziale, condotta mediante strumenti autorizzati e azioni confermate dall’utente.

Dal browser nascosto al tentativo di relay NTLM

Il secondo vettore presenta una catena tecnica più articolata. Gli aggressori indirizzano la vittima verso file ospitati su infrastrutture cloud e personalizzati in funzione dell’utente e dell’organizzazione bersaglio.

Gli eseguibili stabiliscono un meccanismo di persistenza e avviano un’istanza nascosta di Microsoft Edge. Successivamente caricano lateralmente un’estensione, svolgono ricognizione sulla rete interna e generano traffico di autenticazione NTLM.

La fase più pericolosa consiste in un tentativo di NTLM relay basato su PetitPotam. La tecnica serve a indurre un sistema Windows, in questo caso il domain controller, ad avviare un’autenticazione verso una destinazione controllata dall’avversario.

L’aggressore prova quindi a inoltrare quell’autenticazione verso un altro servizio, sfruttandola per ottenere privilegi che non possiede direttamente. Se l’operazione riesce contro sistemi e configurazioni esposti, il controllo può estendersi dall’endpoint iniziale all’infrastruttura delle identità.

Il bersaglio finale è particolarmente sensibile. Un domain controller gestisce autenticazioni, account, criteri e relazioni di fiducia dell’ambiente Windows; comprometterlo può aprire la strada al controllo dell’intero dominio.

Il servizio di managed detection di Unit 42, divisione di Palo Alto Networks, ha bloccato il tentativo di acquisizione dell’infrastruttura. Non risulta quindi che il domain controller osservato sia stato effettivamente compromesso.

Portata e limiti delle informazioni disponibili

Palo Alto Networks ha contato almeno 150 utenti bersaglio in almeno 10 organizzazioni. Non è stata però comunicata una percentuale complessiva di successo, quindi non è possibile stabilire quante vittime abbiano eseguito i file o concesso l’accesso remoto.

I due tentativi descritti in dettaglio sono stati fermati: il RAT PowerShell dalla protezione endpoint e l’attacco contro il dominio dal servizio Unit 42. Questo non dimostra che ogni episodio associato alla campagna abbia avuto lo stesso esito.

Non sono state indicate le versioni specifiche di Microsoft Teams, Windows, Quick Assist o Edge coinvolte. Spring Ring non viene presentata come lo sfruttamento di una falla in una determinata release, ma come abuso di funzionalità legittime combinato con tecniche di social engineering e autenticazione Windows.

Di conseguenza, non è stata indicata una patch risolutiva né una CVE associata alla campagna. Aggiornare i sistemi resta una misura necessaria, ma non neutralizza una telefonata nella quale l’utente autorizza volontariamente una sessione remota.

I dati disponibili provengono dall’indagine di Palo Alto Networks. Non è stata fornita una corroborazione indipendente dello stesso insieme di incidenti.

Come riconoscere e contenere Spring Ring

La prima contromisura è separare la piattaforma di contatto dalla verifica dell’identità. Una richiesta ricevuta tramite Teams non dovrebbe essere considerata autentica soltanto perché appare in un ambiente aziendale.

Quando un presunto tecnico chiede di avviare Quick Assist, installare un RMM o eseguire un file, il dipendente dovrebbe interrompere la procedura e contattare l’help desk attraverso un numero o un portale già noto. Non deve usare recapiti forniti dall’interlocutore.

Le organizzazioni possono inoltre intervenire su più livelli:

  • limitare Quick Assist e gli strumenti RMM agli utenti, ai dispositivi e ai flussi di assistenza autorizzati;
  • registrare l’avvio di sessioni remote inattese e correlarlo con nuovi contatti ricevuti su Teams;
  • rilevare PowerShell offuscato, download anomali, browser avviati in modalità nascosta e sideload di estensioni;
  • controllare i file eseguibili scaricati da servizi cloud, soprattutto se personalizzati o consegnati durante una chiamata;
  • analizzare autenticazioni NTLM verso destinazioni esterne o sistemi non approvati;
  • cercare comportamenti compatibili con coercizione dell’autenticazione e relay;
  • rafforzare il monitoraggio dei domain controller e delle anomalie legate alle identità;
  • addestrare il personale con simulazioni vocali, non soltanto con esercizi di phishing via email.

In assenza di hash e indirizzi di rete pubblici, gli indicatori più utili sono comportamentali: contatti ripetuti da falsi account di supporto, chiamate inattese, avvio non autorizzato di RMM, esecuzione di PowerShell e traffico NTLM insolito.

I problemi di disponibilità di Teams sono incidenti separati

Il 4 settembre 2026 sono stati segnalati anche problemi operativi di Microsoft Teams, ma non esistono elementi che li colleghino a Spring Ring.

L’incidente TM1466820 può impedire l’apertura del client desktop Windows oppure ritardare fino a due minuti il primo caricamento. Microsoft ha indicato Teams sul web, l’app mobile e gli altri metodi di accesso come soluzioni temporanee.

Un problema distinto, identificato come TM1466659, riguarda alcuni utenti Mac impossibilitati a partecipare a chiamate o riunioni. Microsoft stava analizzando i log e rivalutando la causa dopo una prima ipotesi legata a una modifica del codice.

Si tratta di malfunzionamenti di disponibilità, non di prove di una compromissione. Non è noto che abbiano causato, agevolato o nascosto gli attacchi Spring Ring.

La distinzione è essenziale: la campagna sfrutta la fiducia riposta negli strumenti di collaborazione, non i disservizi segnalati nei client. La difesa deve quindi concentrarsi tanto sui controlli tecnici quanto sulla verifica dei processi di assistenza e delle identità.

Leggi anche

Fonti

Questo articolo è una rielaborazione originale basata sulle fonti seguenti.

Argomenti correlatiSpring Ringvishing Microsoft TeamsQuick AssistNTLM relaydomain controllersicurezza Windowsfalso help desk
Torna alla home