Non attribuito. Il CSIRT descrive due kit venduti come servizio, senza indicare un gruppo o un paesehigh
Il kit che legge la posta e cambia l'IBAN: TokenLover e YaksaLover secondo il CSIRT
Il 31 luglio 2026 il CSIRT Italia ha pubblicato un bollettino su due kit di phishing venduti come servizio, TokenLover e YaksaLover, che automatizzano la frode sulle comunicazioni aziendali negli ambienti Microsoft 365. Il CSIRT è esplicito su un punto: i toolkit «non risultano associati allo sfruttamento di nuove vulnerabilità zero-day». Sfruttano invece il flusso di autenticazione con codice dispositivo, dove l'autenticazione a più fattori non protegge perché è la vittima stessa ad approvare la sessione. Una volta dentro, una pipeline basata su modelli linguistici legge la casella di posta e ne estrae le fatture in attesa, i fornitori ricorrenti e le coordinate bancarie. Criticità assegnata: medio, 61.97.
Niente di nuovo, e proprio per questo va letto
La prima cosa che colpisce del bollettino BL01/260731/CSIRT-ITA è una frase che sembra rassicurante e non lo è: i toolkit «non risultano associati allo sfruttamento di nuove vulnerabilità zero-day».
Non c'è una falla da correggere. Non c'è una patch da installare. Quello che il CSIRT descrive è un prodotto: due kit venduti come servizio — phishing as a service — che prendono tecniche note, le mettono in fila, e le rendono utilizzabili da chi non saprebbe eseguirle. TokenLover, «precedentemente noto come TokenVault», e YaksaLover, «noto anche come Yakhub o Yaksha».
La criticità assegnata dal CSIRT è medio (61.97). Gli argomenti indicati sono BEC, Business Email Compromise, PhishingAsAService.
L'ingresso: un codice che vi chiedono di approvare
Il vettore d'accesso iniziale è l'OAuth Device Code Flow, il meccanismo pensato per far autenticare i dispositivi che non hanno una tastiera comoda — una smart TV, un apparato di sala riunioni. Funziona così: il dispositivo mostra un codice, l'utente lo inserisce su una pagina Microsoft dal proprio computer o telefono, e autorizza la sessione.
L'attacco consiste nel far arrivare all'utente quel codice con una scusa credibile e convincerlo a inserirlo. La frase del CSIRT è la più importante di tutto il bollettino: «La presenza dell'autenticazione a più fattori non impedisce l'attacco qualora sia la stessa vittima ad autorizzare la sessione associata al codice dispositivo».
Non c'è nulla da bucare. L'MFA funziona perfettamente: chiede una conferma, e la riceve. La conferma è autentica, è la richiesta a essere falsa.
- 01Il codicel'attaccante avvia un flusso device code e ne consegna il codice alla vittima
- 02L'approvazionela vittima lo inserisce su una pagina Microsoft legittima e conferma con l'MFA
- 03Il tokenl'attaccante riceve una sessione valida: non ha mai visto la password
Dopo l'ingresso: restare, e capire
Ottenuta la sessione, i kit fanno due cose che il bollettino descrive con precisione.
La prima è allargarsi e restare. Il CSIRT indica il pivoting tramite token FOCI (Family of Client IDs) e la rotazione e il rinnovo dei cookie di autenticazione ESTS, con accesso a Exchange Online, Microsoft Graph e SharePoint. Per la persistenza viene registrata sull'account della vittima una chiave riconducibile a Windows Hello for Business — le cosiddette chiavi NGC. La conseguenza, scritta dal CSIRT: «il solo cambio della password potrebbe non essere sufficiente a interrompere l'accesso abusivo».
Che questo sia un obiettivo commerciale e non un effetto collaterale lo dimostra un dettaglio: le dashboard dei kit espongono una metrica dedicata, il «password change survival rate». Il tasso di sopravvivenza al cambio password è una funzione del prodotto, misurata e mostrata al cliente.
La seconda cosa è capire dove sono i soldi. TokenLover, scrive il CSIRT, dispone di «una pipeline per l'analisi automatizzata delle caselle di posta elettronica, basata su modelli linguistici (LLM)». Cosa cerca, secondo l'elenco del bollettino: fatture in attesa di pagamento, fornitori e clienti ricorrenti, coordinate bancarie, scadenze e importi, utenti che approvano le transazioni, e le consuetudini delle comunicazioni aziendali.
Il salto rispetto al phishing tradizionale sta qui. Storicamente la parte lenta di una truffa sulle comunicazioni aziendali era umana: qualcuno doveva leggere mesi di corrispondenza, capire chi paga chi, imparare come si scrivono le email in quell'azienda, individuare il momento giusto. Era il collo di bottiglia che teneva basso il numero di vittime. Quel lavoro adesso lo fa un modello linguistico, in serie, su ogni casella compromessa.
La frode finale, e perché i controlli tecnici non la vedono
Il passaggio conclusivo è la sostituzione dell'IBAN in fatture e comunicazioni, inviate dalla casella Microsoft 365 legittima della vittima.
Da qui l'avvertimento del CSIRT sui controlli di autenticità della posta: «i controlli basati esclusivamente su SPF e DKIM potrebbero non essere sufficienti». È corretto e vale la pena spiegare perché. SPF e DKIM verificano che un messaggio provenga davvero dal dominio che dichiara e non sia stato alterato in transito. In questo caso entrambe le verifiche passano, perché l'email parte davvero da quel dominio, da quella casella, con quelle chiavi. Ciò che è cambiato non è il mittente: è chi lo sta usando.
Un dettaglio quasi ironico chiude il quadro tecnico. Il CSIRT rileva nei kit indizi di vibe coding: uso di Vite, React e Supabase, e «pattern di codice ricorrenti e commenti riconducibili a strumenti automatici di assistenza alla programmazione». Gli stessi strumenti che abbassano la barriera d'ingresso allo sviluppo la abbassano anche qui.
Le mitigazioni indicate dal CSIRT
Il bollettino elenca misure concrete, e sono tutte configurazioni, non acquisti:
- disabilitare il Device Code Flow dove non serve — nella maggior parte delle organizzazioni non serve;
- se serve, limitarlo con l'Accesso Condizionale a dispositivi, reti o gruppi di utenti specifici;
- monitorare la registrazione di nuove chiavi Windows Hello o FIDO sugli account: è il segnale di persistenza descritto sopra, e comparirà nei log come un'operazione legittima;
- verifica fuori banda per ogni variazione di coordinate bancarie. È la misura che ferma la frode anche quando tutto il resto è andato storto: una telefonata a un numero già noto — non a quello scritto nell'email — prima di modificare un IBAN in anagrafica.
Quest'ultima non è una misura informatica ed è la ragione per cui funziona. Chi controlla la posta della vittima controlla tutto ciò che passa dalla posta. Non controlla il numero di telefono che avevate già in rubrica.
Cosa non sappiamo
Il bollettino non pubblica indicatori di compromissione, non quantifica quante organizzazioni italiane siano state colpite, non attribuisce i kit a un attore o a un paese e non riporta prezzi o modalità di abbonamento. Il legame con l'Italia è dato dalla diffusione di Microsoft 365 nel tessuto produttivo nazionale, non da un numero di vittime dichiarato. Le fonti tecniche citate dal CSIRT stesso sono una ricerca di Eye Security e una scheda su mallory.ai: chi vuole i dettagli tecnici trova lì il materiale d'origine.
