Sintesi

Ricercatori di sicurezza hanno recentemente documentato la diffusione di due nuovi toolkit Phishing-as-a-Service (PhaaS), denominati TokenLover , precedentemente noto come TokenVault // 2026 , e YaksaLover , noto anche come Yakhub* o *Yaksha .

Le piattaforme risultano progettate per automatizzare le diverse fasi delle operazioni di Business Email Compromise (BEC) condotte ai danni di organizzazioni che utilizzano servizi Microsoft 365.

I toolkit non risultano associati allo sfruttamento di nuove vulnerabilità zero-day, ma integrano e rendono accessibili, attraverso interfacce centralizzate, tecniche già note per il phishing basato su Device Code, ossia il furto e il riutilizzo di token OAuth, l’accesso abusivo alle caselle di posta elettronica e il mantenimento della persistenza sugli account compromessi.

Descrizione e potenziali impatti

Le piattaforme TokenLover e YaksaLover sono strutturate come servizi SaaS multi-tenant e mettono a disposizione degli operatori dashboard di gestione, funzionalità di monitoraggio delle campagne, metriche relative agli account compromessi e differenti livelli di accesso o abbonamento.

Tale modello operativo riduce significativamente le competenze tecniche necessarie per condurre campagne di compromissione, consentendo a un singolo operatore di gestire contemporaneamente più organizzazioni e account target.

L’analisi del codice, dell’architettura applicativa e delle interfacce utente avrebbe inoltre evidenziato diversi elementi compatibili con l’utilizzo di strumenti di sviluppo assistito da modelli linguistici di grandi dimensioni, secondo pratiche comunemente definite di “vibe coding”.

Tra gli elementi individuati figurano l’impiego di framework quali Vite e React, l’utilizzo di servizi come Supabase, pattern di codice ricorrenti e commenti riconducibili a strumenti automatici di assistenza alla programmazione.

Catena di compromissione

La catena di attacco implementata dai toolkit comprende le fasi di accesso iniziale, acquisizione dei token, mantenimento della persistenza, analisi delle comunicazioni e realizzazione delle successive attività fraudolente.

Per ottenere l’accesso iniziale, gli attaccanti abusano del flusso di autenticazione OAuth denominato Device Code Flow. La vittima viene indotta a inserire un codice controllato dall’attaccante all’interno di una pagina Microsoft legittima e a completare il normale processo di autenticazione, aggirando così l’MFA e senza raccogliere direttamente le credenziali testuali.
A seguito dell’autorizzazione, l’attaccante può ottenere token OAuth validi senza dover necessariamente acquisire la password dell’utente. La presenza dell’autenticazione a più fattori non impedisce l’attacco qualora sia la stessa vittima ad autorizzare la sessione associata al codice dispositivo.
I token acquisiti possono essere successivamente utilizzati per accedere alle risorse dell’ecosistema Microsoft 365, comprese le caselle Exchange Online, Microsoft Graph, SharePoint e gli altri servizi collegati all’identità compromessa.

Le piattaforme supporterebbero inoltre tecniche di pivoting basate sui token FOCI (Family of Client IDs), nonché la generazione, la rotazione o il rinnovo dei cookie di autenticazione ESTS, al fine di estendere l’accesso alle applicazioni Microsoft associate all’account compromesso.

Persistenza sugli account compromessi

Una delle funzionalità di maggiore rilievo riguarda la possibilità di registrare sull’account compromesso chiavi opportunamente predisposte per essere riconducibili a Windows Hello for Business, indicate anche come chiavi NGC .
La registrazione di tali credenziali consente all’attaccante di associare all’identità della vittima un nuovo metodo di autenticazione o un dispositivo sotto il proprio controllo.
In questo scenario, il solo cambio della password potrebbe non essere sufficiente a interrompere l’accesso abusivo. Le sessioni attive, i token precedentemente acquisiti, i dispositivi registrati e le chiavi Windows Hello potrebbero infatti continuare a essere utilizzati anche dopo il reset delle credenziali.
La rilevanza di tale meccanismo è confermata dalla presenza, all’interno delle dashboard analizzate, di metriche dedicate alla capacità degli account compromessi di mantenere l’accesso dopo il cambio della password, indicate come password ” change survival rate “.

Automatizzazione delle frodi BEC

TokenLover risulterebbe dotato di una pipeline per l’analisi automatizzata delle caselle di posta elettronica, basata su modelli linguistici (LLM).
Il sistema sarebbe in grado di analizzare automaticamente i messaggi e gli allegati presenti negli account compromessi, al fine di individuare:

• fatture emesse o in attesa di pagamento;
• fornitori e clienti ricorrenti;
• coordinate bancarie e riferimenti finanziari;
• scadenze e importi dei pagamenti;
• utenti incaricati dell’approvazione delle transazioni;
• modelli e consuetudini delle comunicazioni aziendali.

Le informazioni estratte possono essere utilizzate per ricostruire i flussi finanziari dell’organizzazione e individuare le conversazioni nelle quali inserirsi per modificare le istruzioni di pagamento.
In questo modo un malintenzionato può quindi intercettare una transazione reale e sostituire le coordinate bancarie del beneficiario, ad esempio modificando l’IBAN riportato in una fattura o all’interno di una comunicazione apparentemente legittima.

Le comunicazioni fraudolente possono essere inviate direttamente dalla casella Microsoft 365 compromessa. Poiché il messaggio proviene dall’account e dall’infrastruttura legittima dell’organizzazione, i controlli basati esclusivamente su SPF e DKIM potrebbero non essere sufficienti a identificarlo come malevolo.

L’accesso a una casella interna può inoltre essere utilizzato per distribuire ulteriori messaggi di phishing verso dipendenti, clienti o fornitori, aumentando l’attendibilità delle comunicazioni e favorendo la propagazione della compromissione.

Azioni di mitigazione

Al fine di ridurre il rischio derivante dalle tecniche descritte, si raccomanda alle organizzazioni che utilizzano Microsoft 365 e Microsoft Entra ID di:

• disabilitare il Device Code Flow qualora non necessario per specifiche esigenze operative;
• in alternativa, limitarne l’utilizzo mediante criteri di Accesso Condizionale, consentendolo esclusivamente a utenti, dispositivi o applicazioni preventivamente autorizzati;
• monitorare gli eventi di autenticazione riconducibili al Device Code Flow e individuare accessi provenienti da indirizzi IP, aree geografiche o dispositivi anomali;
• limitare il numero di dispositivi personali registrabili dagli utenti all’interno del tenant Microsoft Entra ID;
• impedire, ove possibile, la registrazione autonoma di dispositivi e metodi di autenticazione da parte degli utenti maggiormente esposti;
• monitorare la registrazione di nuove chiavi Windows Hello for Business, credenziali FIDO e dispositivi associati agli account;
• verificare le attività anomale effettuate tramite Microsoft Graph, Exchange Online e SharePoint;
• monitorare la creazione di regole di inoltro, deleghe, autorizzazioni e configurazioni sospette sulle caselle di posta;
• adottare procedure di verifica fuori banda per le richieste di variazione delle coordinate bancarie o delle modalità di pagamento;
• sensibilizzare gli utenti sui rischi connessi alle richieste di inserimento di codici dispositivo, anche quando presentate attraverso pagine Microsoft legittime.

Le evidenze disponibili mostrano come le moderne piattaforme PhaaS stiano progressivamente evolvendo da semplici strumenti per il furto di credenziali a servizi integrati in grado di automatizzare l’intero ciclo operativo delle frodi BEC, dalla compromissione dell’identità fino all’individuazione e manipolazione dei processi finanziari aziendali.