Che cosa è stato annunciato e cosa risulta dalla pagina giudiziaria
Il 22 settembre 2026 Microsoft ha pubblicato una pagina intitolata «EvilTokens» nella sezione dedicata alle notifiche di documenti giudiziari. Il materiale verificato per questo articolo conferma il titolo, la posizione della pagina e la data di pubblicazione, ma non è sufficiente a stabilire i dettagli delle parti, le misure richieste o lo stato del procedimento. Non è quindi corretto presentare specifiche accuse o una decisione giudiziaria come fatti accertati sulla base di quella pagina. La distinzione è importante: la presenza di una notifica non costituisce, da sola, un resoconto completo della vicenda.
La copertura di CSO Online inserisce il caso nel contesto più ampio della criminalità informatica legata all’intelligenza artificiale. Questa impostazione giornalistica non dimostra, di per sé, quale ruolo abbia eventualmente avuto l’IA in incidenti specifici. Le fonti disponibili qui non forniscono una verifica indipendente del suo impiego, della sua portata o dei suoi effetti nelle campagne attribuite a EvilTokens. La stessa cautela vale per le cifre sull’impatto e per l’estensione di qualsiasi azione contro la piattaforma. I documenti verificati non offrono un conteggio indipendente degli account coinvolti né descrivono quali risorse tecniche siano state rimosse. La pagina Microsoft conferma che esiste una pubblicazione su EvilTokens in una sezione giudiziaria, ma non permette di ricostruire tutti i dettagli del caso. Separare ciò che è documentato da ciò che non è stato possibile verificare evita di trasformare un annuncio o un riferimento giornalistico in un bilancio confermato.
Il flusso legittimo che può diventare un’esca
L’autenticazione con codice dispositivo è un flusso di autorizzazione OAuth legittimo, utile per apparecchi con interfacce limitate, come televisori, stampanti o dispositivi IoT. Il dispositivo richiede un codice e la persona completa l’autenticazione nel browser di un altro dispositivo. La documentazione Microsoft spiega che il client attende la risposta del servizio di autorizzazione mentre l’utente completa la procedura; il codice utente ha una validità limitata. In pratica, il flusso separa il dispositivo che deve autenticarsi da quello che la persona usa per inserire le credenziali e approvare la richiesta. Il codice collega le due parti per un intervallo limitato, mentre le interrogazioni del client consentono al dispositivo originale di sapere se l’autorizzazione è stata completata, senza bisogno di una propria interfaccia di accesso.
Questa comodità è utile quando un dispositivo non dispone di una tastiera o di un browser adeguati, ma rende importante che l’utente capisca quale richiesta sta approvando. La documentazione permette di descrivere il meccanismo generale, ma le fonti verificate per questo articolo non bastano a confermare che EvilTokens lo abbia usato in una campagna specifica né a ricostruirne i passaggi tecnici. Come rischio generale di questo tipo di flusso, una persona potrebbe essere indotta a inserire un codice e approvare una richiesta che non ha avviato o non riconosce. Un portale legittimo non garantisce che la richiesta approvata sia legittima. Questa spiegazione del rischio non va confusa con una descrizione verificata delle tattiche di EvilTokens.
Che cosa si può dire sull’IA
Il titolo della copertura di CSO Online collega l’interruzione di EvilTokens al contesto più ampio della criminalità informatica basata sull’IA. Tuttavia, le fonti verificate disponibili non includono un’indagine indipendente che confermi l’uso di capacità di IA in incidenti specifici. Non è quindi possibile presentare l’IA come una spiegazione dimostrata del successo di una campagna collegata a EvilTokens. Occorre distinguere l’inquadramento di un articolo giornalistico dalle prove relative a un episodio concreto: il primo non accerta ciò che è avvenuto nel secondo.
Il rischio generale del flusso è comprensibile senza attribuirlo a una tecnologia specifica: una persona può essere indotta ad approvare una richiesta di autenticazione che non riconosce. Se quell’approvazione consente di creare una sessione valida, i controlli incentrati soltanto sulla password non descrivono, da soli, l’intero rischio. Contano sia il meccanismo di autorizzazione sia la decisione di approvare la richiesta, ma queste considerazioni generali non dimostrano come funzionasse un servizio specifico. L’IA merita attenzione, ma per spiegare la precauzione pratica non è necessario attribuirle un ruolo in questo caso. Il materiale disponibile non permette di determinare se vi sia stata automazione, quali attività avrebbe svolto o quanto avrebbe contribuito. Allo stesso modo, senza una fonte verificabile sul numero di account coinvolti, non è responsabile riproporre un conteggio come se fosse confermato. La copertura sul contesto dell’IA va tenuta distinta dalle conclusioni effettivamente ricavabili dalla documentazione.
Che cosa significa — e che cosa non significa — un’interruzione
La pagina Microsoft conferma una pubblicazione intitolata «EvilTokens», ma le informazioni disponibili nelle fonti verificate non consentono di precisare il numero o il tipo di risorse tecniche che potrebbero essere state rimosse. Non permettono neppure di affermare che sia scomparsa tutta l’infrastruttura collegata. La presenza di una pagina in una sezione di notifiche giudiziarie non basta ad attribuire a un’operazione un risultato tecnico specifico. Anche quando viene annunciata un’interruzione, i suoi effetti concreti e duraturi devono essere dimostrati da elementi ulteriori rispetto all’annuncio.
In generale, interrompere una piattaforma può rendere più difficile la prosecuzione delle attività che le vengono attribuite, ma non dimostra che tutte le sue istanze, i suoi operatori o le sue copie siano stati individuati o rimossi. Non prova neppure che altri soggetti non possano ricorrere a infrastrutture diverse o riprodurre una tecnica simile. Si tratta di limiti generali nell’interpretare un’operazione di smantellamento, non di affermazioni verificate sull’estensione di una specifica azione contro EvilTokens. Sulla base di quanto è stato possibile verificare, non è corretto affermare che siano stati rimossi tutti i domini o i servizi collegati, né precisare quali misure siano state adottate contro ciascun componente. Interrompere un’operazione identificata può ridurne la portata; non elimina, da solo, una tecnica di phishing né impedisce ad altri di riprodurla. Distinguere lo stato di una piattaforma dalla possibile prosecuzione di metodi simili aiuta a evitare conclusioni più ampie di quanto consentano le prove disponibili.
Misure difensive: valutare prima di bloccare
Per le organizzazioni che non hanno bisogno del flusso con codice dispositivo, Microsoft documenta la possibilità di bloccarlo mediante una policy di Accesso condizionale. Prima di applicarla, è opportuno verificare se l’organizzazione utilizza il flusso e quali accessi potrebbero essere interessati. La documentazione Microsoft sui flussi di autenticazione spiega come usare quel tipo di flusso come condizione di una policy; non significa che tutte le organizzazioni debbano adottare un blocco identico. La verifica preliminare è importante perché un blocco indiscriminato potrebbe interrompere dispositivi o processi che dipendono legittimamente da questo metodo. Se servono eccezioni, è prudente limitarle a esigenze identificate e riesaminarle quando cambiano i sistemi o i loro utilizzi.
La raccomandazione pratica è ridurre i flussi non necessari senza presumere che il codice dispositivo non abbia usi legittimi, e provare la configurazione prima di applicarla su larga scala. È un’indicazione operativa basata sul controllo documentato, non l’affermazione che una singola policy sia adatta a ogni ambiente. Per gli utenti, un segnale d’allarme utile è una richiesta inattesa di copiare un codice o approvare un accesso. Se non si è avviata personalmente l’autenticazione e non si capisce quale dispositivo o applicazione la richieda, è meglio non completare la procedura e verificare la richiesta tramite un canale conosciuto. L’aspetto del portale, da solo, non permette di sapere chi abbia avviato la richiesta associata al codice; conta anche il contesto. I team di sicurezza possono cogliere l’occasione per rivedere i flussi abilitati e gli accessi insoliti. La raccomandazione non è abbandonare l’autenticazione a più fattori, ma affiancarla a policy adeguate alle esigenze e a un’attenta valutazione del contesto di ogni approvazione.