// 1 CRITICAL · 2 ZERO-DAY · 3 CVE · 4 EXPLOIT NELLE ULTIME 24H
Un server con directory listing attivo ha rivelato toolkit completi di phishing M365, due tecniche di aggiramento MFA e l'uso dell'intelligenza artificiale da parte

Un server di phishing con directory listing attivo ha esposto tre operazioni Evilginx distinte contro Microsoft 365, rivelando toolkit completi, identità di operatori criminali e due tecniche meccanicamente diverse di aggiramento dell'autenticazione a più fattori. La scoperta, effettuata da Lexfo a fine aprile 2026, documenta come operazioni di medio livello utilizzino ora l'intelligenza artificiale per accelerare lo sviluppo di infrastrutture di phishing personalizzate.

Punti chiave
  • Un server con python3 -m http.server 8080 e directory listing attivo ha esposto .bash_history leggibile, rivelando tre operazioni Evilginx indipendenti
  • Due tecniche di compromissione distinte: AiTM proxy live e abuso del OAuth device code flow legittimo di Microsoft, quest'ultimo non bloccabile da FIDO2 o passkey
  • L'operatore saroula01 ha catturato 218 account distinti in log Telegram bot tra giugno 2025 e luglio 2026, con circa il 94% di corporate mailboxes
  • Segni di AI-assisted development in tutte e tre le operazioni: commit co-authored by Claude, file instructions.txt da sessione AI, credito a CyberNeurova API

Come una directory listing ha smascherato un intero ecosistema

Il server, con indirizzo IP 185.163.204[.]7 a Budapest, è stato catalogato durante uno scan internet di routine condotto da Lexfo a fine aprile 2026. La configurazione difettosa — un server HTTP Python sulla porta 8080 con directory listing attivo — ha reso leggibile il file .bash_history, tracciando comandi, clonazioni di repository e operazioni di deployment.

Lexfo ha identificato tre operatori distinti, tutti con fork custom di Evilginx clonato da GitHub pubblico. Il primo, 'codemado', è un attore egiziano attivo dal 2018, con piattaforma AiTM su picis[.]net e bulk mailer 'MaDoO Blaster'; la sua campagna è iniziata il 20 aprile 2026. Il secondo, 'mail-argenta', opera dalla Nigeria: il suo fork 'red-queen' modifica attributi HTML per bypassare Subresource Integrity e integra un URL-rewriting engine nel file http_proxy.go. Il terzo, 'saroula01', handle non deanonimizzato, gestisce il fork 'black-queen' e abusa del OAuth device code flow di Microsoft senza alcun proxying intermedio.

"Directory listing on a working attack server is close to a full confession"

AiTM e device code: due tecniche, unico obiettivo

Le prime due operazioni convergono sul medesimo meccanismo: l'AiTM (Adversary-in-The-Middle) proxy. Evilginx intercetta in tempo reale credenziali e sessioni, permettendo all'attaccante di aggirare MFA tradizionale. Questa tecnica è vulnerabile all'origin-bound authentication: FIDO2 e passkey la neutralizzano, poiché legano la firma crittografica al dominio originale.

La terza tecnica, quella di saroula01, è meccanicamente diversa. L'operatore abusa il flusso legittimo OAuth device code di Microsoft: la vittima si autentica su microsoft.com/devicelogin, un endpoint autentico, inserendo un codice fornito dall'attaccante. Il token generato è valido e trasferibile. Nessun proxy è necessario; nessun dominio contraffatto è visitato. Il risultato è che FIDO2 e passkey non offrono protezione, perché la vittima autentica sé stessa su infrastruttura Microsoft legittima autorizzando la sessione dell'attaccante.

Secondo il team CTI di Lexfo: "Calling this 'MFA bypass' misses how it works: nothing gets bypassed". La distinzione non è retorica: cambia radicalmente il perimetro difensivo richiesto. Microsoft ha documentato questa tecnica a febbraio 2025 nella campagna Storm-2372, associata con medium confidence a operatori Russia-aligned.

I numeri dell'operazione saroula01

I log del Telegram bot di saroula01 documentano 218 account distinti catturati tra giugno 2025 e luglio 2026. Circa il 94% risulta corporate mailboxes. Un file nella git history del repository contiene 97 token Microsoft live con autoRefresh abilitato; alcuni token mostrano fino a 25 refresh, indicando persistenza prolungata nell'accesso ai servizi compromessi.

Mail-argenta è stato identificato attraverso le proprie credenziali presenti in log di infostealer, con password riutilizzata nel pannello Kraken — un errore operativo che ha permesso la deanonimizzazione. Per codemado e saroula01, l'identità reale non è stata pienamente deanonimizzata nel report.

L'intelligenza artificiale come acceleratore del "glue code"

Le tre operazioni mostrano segni convergenti di AI-assisted development. Nel fork di saroula01, commit co-authored by Claude. Nel repository di mail-argenta, un file instructions.txt traccia una sessione AI con prompt e risposte. Nel toolkit di codemado, credito esplicito a CyberNeurova API.

La valutazione del team CTI di Lexfo è tuttavia calibrata: "The Evilginx forks carried only minor changes to the core, and that the clearer signs of AI use sat in the glue code around them". L'intelligenza artificiale non ha generato il framework di phishing — Evilginx resta software open source consolidato — ma ha abbassato la barriera all'entry per personalizzare phishlets, script di automazione e componenti di supporto. Questo è coerente con l'angolo di lettura proposto nel dossier: la democratizzazione dell'AI consente operazioni criminali di medio livello senza competenze tecniche avanzate.

Cosa fare adesso

Le misure difensive dipendono dalla tecnica avversaria:

  • Per l'AiTM proxy: implementare origin-bound authentication tramite FIDO2 o passkey, che neutralizzano l'intercettazione legando la sessione al dominio legittimo
  • Per il device code flow: bloccare il flusso dove possibile attraverso policy di Conditional Access, e abilitare Continuous Access Evaluation per revoca rapida dei token sospetti
  • Monitorare l'utilizzo del flusso device code in ambienti enterprise: l'assenza di proxying lo rende tecnicamente più silenzioso, ma il pattern di autenticazione è tracciabile nei log Azure AD
  • Valutare la visibilità su repository pubblici e infrastructure-as-code: la scoperta di Lexfo è nata da scan internet, non da intelligence confidenziale

Tre operazioni, un ecosistema senza confini

I tre operatori hanno legami indiretti con l'ecosistema 'The Quarry', documentato da SOCRadar a giugno 2026 con circa 200 operatori stimati. La relazione è di fornitura, non di appartenenza: MaDoO Blaster è stato promosso in canali Telegram associati a The Quarry, ma non emerge prova di membership diretta. I domini delle tre operazioni erano già offline prima di qualsiasi azione di Lexfo; il team CTI interpreta questo come rotazione infrastrutturale o ritiro volontario, non come takedown coordinato.

L'esposizione del server non chiarisce se l'errore sia umano o automatizzato, né quanti account totali siano stati compromessi dalle campagne di codemado e mail-argenta. Il conteggio di 218 account riguarda esclusivamente saroula01. Resta inoltre non quantificata l'entità esatta del contributo AI rispetto allo sviluppo umano in ciascuna operazione.

La misconfiguration come "arma a doppio taglio" dell'attaccante: un errore operativo elementare ha trasformato un singolo server in una finestra su un ecosistema di phishing M365 che sfrutta infrastruttura legittima, autenticazione forte e intelligenza artificiale generativa. Le difese tradizionali — MFA, FIDO2, awareness — restano necessarie ma non sufficienti contro il device code flow, che non aggira l'autenticazione ma la suborna attraverso di lei.

Domande frequenti

Perché FIDO2 e passkey non proteggono dal device code flow?

Perché la vittima autentica sé stessa su microsoft.com/devicelogin, endpoint autentico Microsoft. FIDO2 e passkey verificano il dominio, non l'intenzione: se il dominio è legittimo, la firma crittografica viene emessa correttamente autorizzando la sessione dell'attaccante.

Il device code flow è una vulnerabilità di Microsoft?

No. È un flusso OAuth legittimo, documentato e supportato, abusato socialmente attraverso ingegneria psicologica. La distinzione è rilevante per il perimetro difensivo: non esiste patch da applicare, ma policy da configurare.

L'AI ha "creato" i toolkit di phishing?

No. Le modifiche al core Evilginx sono minori secondo Lexfo. I segni di AI-assisted development sono concentrati nel "glue code" — script, phishlets, automazioni — che personalizza e dispiega il framework esistente.

Fonti

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti


Fonti e riferimenti
  1. thehackernews.com
  2. news.cybertechworld.co.in
  3. blog.aimactgrow.com
  4. secnews.gr