EvilTokens e il “phishing fantasma”: quando la pagina malevola nasce nel browser
Come accorgersi degli attacchi, come difendersi e perché l’analisi del rischio aiuta a separare dati oggettivi, luoghi comuni e fake news.
La notizia in breve: non è “solo” un nuovo link di phishing
La campagna descritta da The Hacker News l’8 luglio 2026 attribuisce a EvilTokens una tecnica che può essere riassunta così: il contenuto dannoso non appare subito in forma leggibile, ma viene rivelato nel browser della vittima tramite decrittazione lato client. Questa caratteristica può ingannare controlli statici, scanner di URL e ispezioni superficiali che giudicano il link “vuoto”, “benigno” o non ancora attivo al momento dell’analisi.
Il punto più importante, però, non è l’effetto scenico della pagina che “prende vita”. È il cambio di bersaglio: molte campagne moderne non cercano più soltanto la password. Cercano token OAuth, sessioni, autorizzazioni cloud e flussi di autenticazione legittimi. In pratica, invece di forzare una porta, convincono l’utente ad aprire una porta vera a un dispositivo o a una sessione controllata dall’attaccante.
Le fonti più recenti convergono su un punto: l’attacco alle identità cloud è diventato un problema di governance dell’autenticazione, non soltanto di filtraggio email. FBI/IC3, Microsoft, CISA, NIST, APWG, Verizon e Mandiant indicano che la difesa deve combinare MFA resistente al phishing, controllo dei flussi OAuth/device-code, logging, risposta agli incidenti e formazione realistica.
Come funziona il “phishing fantasma”
Il nome “phishing fantasma” è utile dal punto di vista giornalistico, ma va maneggiato con cautela: non indica una categoria giuridica o uno standard tecnico universale. Nel caso discusso, descrive un insieme di tecniche di evasione in cui la pagina malevola resta nascosta finché il browser non esegue codice, ricostruisce il DOM, decripta porzioni di HTML o attiva richieste successive. Il risultato è che chi analizza il link solo in modo statico può vedere una pagina innocua, incompleta o priva della parte davvero pericolosa.
Device-code phishing: perché è insidioso
Nel device-code phishing l’attaccante avvia un flusso di autenticazione su un proprio dispositivo o script e induce la vittima a inserire un codice in una pagina legittima del provider. La vittima può vedere un dominio autentico, un’esperienza familiare e una MFA apparentemente corretta. Ma sta autorizzando una sessione che non controlla. L’avviso FBI/IC3 del 21 maggio 2026 su Kali365 descrive proprio questa dinamica: email-esca, pagina Microsoft reale, inserimento del codice, cattura di access e refresh token, accesso a Microsoft 365 senza ulteriore password o MFA.
Il fatto che una pagina di login sia “vera” non significa automaticamente che l’operazione sia sicura. La domanda corretta è: chi ha iniziato il flusso di autenticazione e quale dispositivo/sessione sto autorizzando?
Perché l’email security tradizionale può non bastare
I gateway email e i motori anti-phishing restano necessari, ma molti prodotti sono forti quando il contenuto malevolo è già visibile: URL noti, domini appena registrati, pagine di credential harvesting, allegati con pattern sospetti. Il phishing fantasma sposta parte dell’evidenza nel runtime del browser. Servono quindi capacità di analisi dinamica, osservabilità del DOM, telemetria endpoint/browser, correlazione degli eventi di identità e controlli preventivi sui flussi di autenticazione.
- Non sempre ruba password: può ottenere token o autorizzazioni.
- Non sempre usa pagine false: può abusare di pagine legittime del provider.
- Non sempre è visibile subito: il payload può apparire dopo decrittazione o rendering.
- Non sempre è fermato dalla MFA tradizionale: push, OTP e device code possono essere aggirati o abusati.
- Non sempre è “malware”: spesso è social engineering più abuso di funzionalità legittime.
Come accorgersi degli attacchi: segnali per utenti, help desk e SOC
Il primo errore è pensare che il riconoscimento dipenda solo dall’utente. La persona può intercettare segnali di incoerenza, ma un’organizzazione matura deve progettare controlli che non scarichino tutto sull’attenzione individuale. Il principio è semplice: l’utente segnala, il sistema verifica, il SOC correla.
Segnali visibili all’utente
| Segnale | Perché conta | Azione consigliata |
|---|---|---|
| Richiesta di inserire un codice su una pagina Microsoft/Google/altro provider senza aver avviato l’accesso | Possibile device-code phishing | Interrompere, non inserire il codice, segnalare al canale interno |
| Messaggio con urgenza artificiale: “scade tra 10 minuti”, “serve ora”, “account sospeso” | Le campagne di social engineering sfruttano pressione temporale | Verifica tramite canale indipendente |
| Documento condiviso inatteso o richiesta da mittente noto ma tono insolito | Potrebbe essere account compromesso o pretexting AI-assisted | Contattare il mittente su canale già noto, non rispondere al thread sospetto |
| QR code in email o documento | Il quishing sposta il controllo su dispositivo personale, fuori dai filtri aziendali | Non scansionare se non atteso; usare browser aziendale protetto |
| Richiesta di approvare MFA non iniziata dall’utente | Possibile MFA fatigue, relay o session hijacking | Rifiutare, cambiare password solo da portale ufficiale, segnalare |
Segnali per help desk e amministratori
Il supporto interno è un bersaglio: gli attaccanti sanno che molte procedure di recupero account, reset MFA e onboarding dispositivi sono costruite per aiutare rapidamente l’utente. Per questo ogni richiesta insolita di reset, sostituzione telefono, registrazione di un nuovo metodo MFA o “urgenza del dirigente” deve essere trattata come un evento di sicurezza, non come una semplice pratica amministrativa.
- Verificare l’identità con canale indipendente: non usare il numero o l’indirizzo fornito nella richiesta sospetta.
- Limitare reset MFA ad alto rischio: richiedere approvazione o workflow rafforzato per ruoli privilegiati.
- Registrare motivazione e contesto: ogni eccezione deve lasciare traccia auditabile.
- Controllare segnali di compromissione: nuovi dispositivi, refresh token anomali, login da geografie insolite, creazione regole inbox.
- Non fidarsi della sola “conoscenza personale”: il vishing e i deepfake rendono fragile il riconoscimento informale.
Segnali tecnici per SOC e identity team
Un attacco basato su token e device code può lasciare meno tracce nel perimetro tradizionale ma molte tracce nell’identità. La telemetria utile comprende: eventi di device-code flow, richieste OAuth insolite, consenso ad applicazioni non previste, accessi impossibili o improbabili, refresh token usati da indirizzi IP incoerenti, nuove regole di inoltro email, lettura massiva di mailbox, download da OneDrive/SharePoint, registrazione di nuovi dispositivi o metodi MFA.
| Dato da monitorare | Indicatore sospetto | Possibile risposta |
|---|---|---|
| Authentication flows | Uso improvviso di device code da utenti che non lo usavano | Audit, policy di blocco o allowlist stretta |
| OAuth consent | Nuova app con permessi mail/files/offline_access | Revoca consenso, blocco app, revisione tenant |
| Mailbox rules | Regole di inoltro, cancellazione o nascondimento messaggi | Disabilitare regole, preservare evidenze, reset sessioni |
| Sign-in logs | Login da ASN/proxy/residential network inusuali | Step-up, token revoke, Conditional Access |
| Browser/runtime | DOM che cambia dopo decrittazione o script condizionali | Sandbox interattiva, acquisizione HTML/JS/har, IoC contestuali |
Come difendersi: non una misura, ma una catena di controlli
La difesa più solida nasce dalla combinazione di più livelli. Alcuni sono preventivi, altri rilevano, altri riducono il danno quando qualcosa passa. È importante evitare due estremi: pensare che basti “formare meglio gli utenti” oppure che basti “comprare un nuovo filtro”. La realtà è più concreta: bisogna togliere all’attaccante i flussi facili, ridurre la durata dei token, aumentare la visibilità e rendere la segnalazione semplice.
1. Bloccare o limitare il device-code flow
Microsoft Learn, nella pagina aggiornata il 7 aprile 2026, raccomanda di avvicinarsi il più possibile a un blocco unilaterale del device-code flow, dopo un audit degli usi legittimi. Dove il flusso è davvero necessario, va documentato, limitato a gruppi specifici, monitorato e protetto con Conditional Access. Lo stesso documento indica anche policy per bloccare l’authentication transfer, con attenzione alle esclusioni per account di emergenza.
Creare una policy Conditional Access in modalità audit, osservare per un periodo definito chi usa davvero device code, poi passare al blocco per tutti salvo eccezioni motivate, approvate e riesaminate periodicamente.
2. Passare a MFA resistente al phishing
CISA e NIST convergono sulla necessità di autenticazione resistente al phishing. In termini pratici, significa privilegiare FIDO2/WebAuthn, passkey con adeguate garanzie, smart card, certificati o altri metodi basati su crittografia e binding al dominio. OTP, SMS, push “approve/deny” e codici temporanei migliorano la sicurezza rispetto alla sola password, ma non sono equivalenti alla resistenza al phishing.
“Abbiamo la MFA, quindi siamo protetti dal phishing.”
Correzione: la MFA riduce molti rischi, ma alcune forme di MFA possono essere aggirate con relay, social engineering, MFA fatigue o abuso di flussi legittimi. La parola chiave è “phishing-resistant”, non semplicemente “MFA”.
3. Governare OAuth, app consent e token
Le organizzazioni che usano Microsoft 365, Google Workspace, Salesforce, Slack, GitHub o altri ecosistemi SaaS devono trattare OAuth come una superficie critica. Un consenso eccessivo a un’applicazione può dare accesso a posta, file e dati anche senza password. La governance deve prevedere: consent workflow, blocco del consenso utente non autorizzato, revisione periodica delle app enterprise, revoca dei token in risposta a eventi sospetti e alert su permessi ad alto impatto.
4. Migliorare l’analisi dinamica dei link
Se una pagina diventa pericolosa solo nel browser, lo scanner deve comportarsi più come un browser reale. Questo non significa che ogni azienda debba costruire un laboratorio malware: significa pretendere dal proprio stack di sicurezza capacità di analisi dinamica, sandbox interattive, emulazione dei flussi, acquisizione del DOM nel tempo e correlazione tra click, autenticazione e token.
5. Rendere facile la segnalazione
Un pulsante “Segnala phishing” integrato nel client email è più utile di un corso annuale dimenticato. La segnalazione deve aprire un processo: triage automatico, arricchimento con header e URL, risposta all’utente, eventuale rimozione dai mailbox, ricerca di messaggi simili, blocco indicatori e aggiornamento delle regole. La formazione, da sola, è fragile; la formazione collegata a un processo misurabile è difesa.
Scala qualitativa editoriale: il valore indica impatto difensivo atteso nel contesto specifico, non una misura statistica universale.
Una corretta analisi del rischio potrebbe aiutare?
Sì, se non è trattata come un documento da archiviare. L’analisi del rischio aiuta perché trasforma una minaccia generica — “phishing avanzato” — in scenari misurabili: chi può essere colpito, con quale probabilità, con quale impatto, quali controlli esistono, quali lacune restano, quali investimenti riducono davvero il rischio.
Scenario di rischio: compromissione Microsoft 365 tramite device code
| Elemento | Domanda guida | Esempio di evidenza |
|---|---|---|
| Asset | Quali dati sono raggiungibili con l’account compromesso? | Mailbox, Teams, SharePoint, OneDrive, CRM collegati |
| Minaccia | Chi può tentare l’attacco? | PhaaS, gruppi BEC, criminalità opportunistica, attori mirati |
| Vulnerabilità | Quali flussi sono aperti? | Device code consentito a tutti, OAuth consent libero, MFA non resistente |
| Impatto | Cosa succede se l’attacco riesce? | Frode BEC, esfiltrazione documenti, movimento laterale, abuso reputazionale |
| Controlli | Che cosa riduce probabilità o impatto? | Conditional Access, FIDO2, token revocation, DLP, monitoraggio mailbox |
| Rischio residuo | Cosa rimane scoperto? | Eccezioni legacy, help desk, account esterni, dispositivi personali |
Matrice qualitativa
Questa matrice è volutamente qualitativa: serve a guidare priorità e responsabilità, non a produrre una falsa precisione numerica.
Come evitare l’analisi del rischio “di facciata”
Un’analisi utile deve collegarsi a decisioni reali: bloccare un flusso, finanziare FIDO2, cambiare una procedura help desk, rivedere l’onboarding di applicazioni SaaS, aggiornare il piano di risposta agli incidenti. Se non cambia nulla, non è analisi del rischio: è documentazione postuma.
- Percentuale di utenti con MFA resistente al phishing.
- Numero di applicazioni OAuth con permessi ad alto impatto.
- Numero di account che usano device-code flow in 30/60/90 giorni.
- Tempo medio di revoca token dopo una segnalazione.
- Tempo medio di rimozione di email malevole già consegnate.
- Quota di segnalazioni phishing chiuse con feedback all’utente.
- Numero di eccezioni Conditional Access e data dell’ultima revisione.
Dati oggettivi, luoghi comuni e fake news
La cybersicurezza è un terreno fertile per semplificazioni e slogan. Un articolo rigoroso deve distinguere tra fatti documentati, inferenze ragionevoli e affermazioni non provate. Di seguito alcune frasi che ricorrono spesso e che meritano correzione.
“Il phishing fantasma è invisibile a tutti.”
No. Può eludere controlli statici o superficiali, ma non è magicamente invisibile. Analisi dinamica, telemetria browser, log di identità, eventi OAuth e monitoraggio delle sessioni possono produrre evidenze.
“Se il dominio è Microsoft, Google o un altro provider noto, allora è sicuro.”
No. Una pagina legittima può essere usata in un flusso malevolo. Il problema può essere l’autorizzazione concessa, non la falsità del dominio.
“Il training anti-phishing risolve il problema.”
No. La formazione è utile se continua, contestuale e integrata con controlli tecnici e processi. Studi recenti mostrano risultati controversi quando la formazione è isolata e generica.
“L’AI rende ogni attacco perfetto.”
No. L’AI può migliorare grammatica, personalizzazione e velocità, ma non elimina errori operativi degli attaccanti. Va considerata un acceleratore, non una bacchetta magica.
Dove stanno i dati più solidi
Tra le fonti più utili per orientarsi ci sono report con metodologia esplicita e fonti istituzionali. APWG offre dati trimestrali sul volume phishing. Verizon DBIR aggrega incidenti e violazioni con classificazioni consolidate. Mandiant M-Trends porta osservazioni da incident response. Microsoft, CISA, NIST e FBI/IC3 forniscono indicazioni operative e di policy. I vendor privati possono aggiungere dettagli tecnici preziosi, ma è corretto leggere i loro report tenendo conto del possibile interesse commerciale.
Piano operativo: 30 giorni per ridurre il rischio
La risposta non deve essere perfetta per essere utile. In molte organizzazioni, trenta giorni bastano per ridurre sensibilmente il rischio se si interviene sulle configurazioni più esposte.
Alla fine del ciclo l’organizzazione dovrebbe sapere chi usa device code, quali eccezioni esistono, quali app OAuth hanno privilegi sensibili, quanto tempo serve per revocare token e come reagisce l’help desk a una richiesta sospetta.
Conclusione: la vera novità è l’identità come perimetro
EvilTokens e le campagne simili non devono essere raccontate come “l’attacco imbattibile del momento”. Sarebbe impreciso e controproducente. Devono invece essere lette come un segnale chiaro: l’identità cloud è diventata il perimetro operativo dell’azienda. Se un attaccante riesce ad abusare di un flusso legittimo, ottenere token e muoversi tra email, file e applicazioni SaaS, il vecchio modello “email filtrata uguale azienda protetta” non regge più.
La difesa migliore è sobria: ridurre i flussi inutili, adottare autenticazione resistente al phishing, governare OAuth, monitorare i token, rafforzare help desk e SOC, esercitare la risposta. In altre parole, meno spettacolo e più disciplina. È proprio qui che una corretta analisi del rischio può fare la differenza: non perché preveda ogni attacco, ma perché costringe l’organizzazione a decidere prima cosa è accettabile, cosa va bloccato e chi deve agire quando il browser “racconta” una storia diversa dall’email.
Fonti pubbliche e riferimenti
Le fonti sono state selezionate privilegiando fonti istituzionali, documentazione ufficiale, report con metodologia dichiarata e analisi tecniche raggiungibili pubblicamente. I link sono indicati in chiaro per consentire verifica autonoma.
| Fonte | Data fonte / aggiornamento | Rilevanza | URL |
|---|---|---|---|
| The Hacker News | 8 luglio 2026 | Notizia iniziale su EvilTokens, ghost phishing, AES-GCM encrypted HTML e device-code phishing | https://thehackernews.com/2026/07/new-ghost-phishing-wave-is-breaking.html |
| FBI / IC3 | 21 maggio 2026 | Avviso pubblico Kali365 PhaaS: device code, OAuth token, Microsoft 365, mitigazioni | https://www.ic3.gov/PSA/2026/PSA260521 |
| Microsoft Learn | 7 aprile 2026 | Policy Conditional Access per bloccare device-code flow e authentication transfer | https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-block-authentication-flows |
| Microsoft Security Blog | 6 aprile 2026 | Campagna AI-enabled device-code phishing e automazione del flusso | https://www.microsoft.com/en-us/security/blog/2026/04/06/ai-enabled-device-code-phishing-campaign-april-2026/ |
| APWG | Q1 2026 | Statistiche: 971.181 attacchi phishing nel primo trimestre 2026, +13,8% su Q4 2025 | https://apwg.org/trendreports |
| Verizon DBIR | 2026 | Dati su violazioni, elemento umano, social engineering, credenziali e vulnerabilità | https://www.verizon.com/business/resources/reports/dbir/ |
| Google Cloud / Mandiant M-Trends | 23 marzo 2026 | Tendenze incident response, vettori iniziali, persistenza e raccomandazioni | https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2026 |
| NIST SP 800-63B Rev.4 | Finale dal 1 agosto 2025; consultato 8 luglio 2026 | Linee guida identità digitale e autenticazione, inclusi livelli di assurance | https://pages.nist.gov/800-63-4/sp800-63b.html |
| CISA | Fact sheet / guida phishing-resistant MFA | Raccomandazioni per implementare MFA resistente al phishing | https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf |
| ESET / WeLiveSecurity | 15 giugno 2026 | Analisi divulgativa di EvilTokens: attacco senza furto diretto di password | https://www.welivesecurity.com/en/cybercrime/eviltokens-phishing-doesnt-steal-password/ |
| The Register | 1 luglio 2026 | Contesto giornalistico-tecnico su EvilTokens come ambiente BEC/PhaaS | https://www.theregister.com/cyber-crime/2026/07/01/eviltokens-device-code-phishing-kit-totally-more-evil-than-we-all-thought/5265409 |
| ANY.RUN | Giugno 2026 | Analisi tecnica su DOM dinamico, sandbox interattiva e ispezione browser | https://any.run/cybersecurity-blog/eviltokens-ghost-code-analysis/ |
| Push Security | 4 aprile 2026; aggiornamento 15 maggio 2026 | Analisi della crescita del device-code phishing e kit correlati | https://pushsecurity.com/blog/device-code-phishing/ |
| ENISA Threat Landscape | 1 ottobre 2025 | Scenario UE, AI-supported phishing e social engineering | https://www.enisa.europa.eu/topics/cyber-threats/threat-landscape |
| Ricerca accademica: Rozema & Davis | 24 giugno 2025 | Studio su limiti della formazione anti-phishing isolata | https://arxiv.org/abs/2506.19899 |
| Ricerca accademica: Berladskyy & Aßmuth | 22 aprile 2026 | Analisi vettori di attacco contro FIDO2 e valutazione della phishing resistance | https://arxiv.org/abs/2604.20826 |
| Ricerca accademica: Weinz et al. | 17 maggio 2025 | Quishing e email generate con LLM in simulazioni organizzative | https://arxiv.org/abs/2505.12104 |
Questo articolo non attribuisce responsabilità penali o civili a soggetti specifici oltre quanto riportato da fonti pubbliche citate. I nomi di kit, campagne, prodotti e fornitori sono usati a scopo descrittivo e informativo. Le raccomandazioni tecniche devono essere adattate al contesto dell’organizzazione e verificate da personale qualificato. Non sono stati riprodotti contenuti protetti da copyright: le fonti sono riassunte, citate e linkate per approfondimento.