C'è una beffa dentro questa campagna che vale la pena mettere subito in chiaro. Le passkey sono, tecnicamente, la migliore difesa contro il phishing che abbiamo oggi: la chiave privata resta sul dispositivo, la firma è legata al dominio, un sito clone non può riutilizzarla. Gli attaccanti non hanno provato a romperle. Hanno usato la parola «passkey» come esca, perché è nuova, perché suona urgente e perché quasi nessun dipendente sa ancora come dovrebbe funzionare un'iscrizione legittima.

Il 9 e il 10 settembre 2026 Microsoft ha pubblicato due analisi che descrivono due campagne distinte ma coerenti tra loro. Li teniamo insieme perché puntano allo stesso reparto e allo stesso riflesso: fare in fretta una cosa che sembra amministrativa.

I fatti: la catena a tema passkey

L'attività è osservata da maggio 2026 e comincia quasi sempre fuori dai sistemi aziendali. L'attaccante chiama o scrive al numero di cellulare personale del dipendente, si presenta come help desk IT interno e chiede di aggiornare subito la passkey, la configurazione MFA o l'SSO, pena l'interruzione dell'accesso. Il messaggio successivo, via SMS sul dispositivo personale, contiene il link a un portale che riproduce la pagina di accesso Microsoft.

Da lì la vittima viene guidata lungo uno di due percorsi: un flusso adversary-in-the-middle, che intercetta credenziali e cookie di sessione, oppure un flusso di autenticazione device code, che è più insidioso perché non richiede affatto di rubare la password. Nel device code phishing l'attaccante genera un codice sul proprio dispositivo e convince l'utente a inserirlo nel portale legittimo di Microsoft: è la vittima ad autorizzare, in buona fede, un dispositivo che non è il suo. L'MFA viene soddisfatto correttamente e non c'è nessuna credenziale da intercettare.

I domini registrati raccontano bene la strategia. Microsoft ne elenca diversi — passkeyhelpdesk[.]com, secure-passkey[.]com, setupmypasskey[.]com, add-passkey[.]com, integratedsso[.]com, oktasession[.]com, syncmykey[.]com, portalsetuphub[.]com — usati con uno schema preciso: il nome dell'azienda bersaglio come sottodominio, nella forma nomeazienda.dominiomalevolo[.]com. Un utente che guarda l'inizio dell'URL vede il nome della propria società. È lo stesso trucco cognitivo dei link accorciati, applicato al DNS.

La ricognizione preventiva è pesante: profili professionali, organigrammi, social. In un numero minore di casi gli attaccanti partono da un account già compromesso e inviano gli stessi messaggi a tema passkey via Microsoft Teams, dove il mittente è un collega reale.

Il passaggio che conta: la persistenza si chiama MFA

Qui la campagna smette di essere «l'ennesimo phishing» e diventa istruttiva. Microsoft è esplicita sull'obiettivo immediato dell'attaccante dopo l'accesso iniziale: trasformare una compromissione temporanea in un punto d'appoggio stabile. E il modo scelto non è una backdoor, non è un malware, non è un token rubato. È registrare un proprio metodo MFA sull'account della vittima: un nuovo numero di telefono, un'app authenticator, un token OTP software.

Vale la pena fermarsi su cosa significa. Da quel momento l'attaccante può autenticarsi sull'account aziendale senza alcuna partecipazione della vittima, superando il secondo fattore con il proprio dispositivo. Il reset della password, che è la prima cosa che un help desk fa quando sospetta una compromissione, non basta più: se il fattore ostile resta registrato, l'accesso si ricostruisce al volo. È una forma di persistenza che vive interamente nel piano dell'identità, non lascia artefatti sugli endpoint e non viene toccata da nessun EDR.

Cosa succede dopo: l'abuso di Graph

La fase post-accesso è quasi interamente API. Microsoft descrive una progressione ricorrente:

  • ricognizione estesa tramite Microsoft Graph, con inventario di utenti, gruppi, permessi, risorse e contenuti raggiungibili dall'identità compromessa;
  • ispezione dei ruoli e degli account ad alto valore, comprese le identità di servizio, per cercare vie di elevazione;
  • enumerazione di messaggi, cartelle e metadati degli allegati nelle caselle;
  • download ad alto volume da SharePoint Online e OneDrive for Business, in alcuni casi anche da Exchange Online;
  • esfiltrazione che prosegue da diverse ore a più giorni, in funzione del volume;
  • rotazione deliberata dell'infrastruttura, con indirizzi IP diversi per autenticazione, ricognizione ed esfiltrazione, in modo da spezzare gli indicatori di rete.

Il commento di Microsoft su questo punto è il più utile di tutto il report: l'abuso di Graph raramente sembra sospetto se si guarda una singola chiamata API. Ogni richiesta, isolata, è legittima. Il segnale esiste solo nella progressione comportamentale e nella correlazione tra eventi diversi. Chi ha un SIEM che allerta su singole soglie, qui non vede nulla.

L'accesso iniziale è attribuito a più attori, in particolare Storm-3121 (che porta a estorsioni marchiate ShinyHunters e Falcon) e Storm-3032, designazione Microsoft per UNC6671 — lo stesso ambiente che avevamo descritto parlando della telefonata dell'help desk che svuota gli account e del finto supporto su Teams. Le sovrapposizioni con le sigle Cordial Spider, O-UNC-045 e PREY-0058 non indicano necessariamente un unico gruppo: più probabilmente affiliati che si sono separati e continuano a usare gli stessi pannelli di phishing commerciali, gli stessi call center e la stessa infrastruttura.

La seconda campagna: la fattura che il CEO ha «già approvato»

La ricerca pubblicata il giorno dopo riguarda un'attività diversa ma parallela. Tra il 3 e il 5 agosto 2026 sono state inviate oltre un milione di email fraudolente sfruttando infrastrutture di consegna email di terze parti — cioè servizi legittimi e ben reputati, che superano i controlli di reputazione del mittente.

Il contenuto è frode del CEO, ma costruita con più cura del solito. Gli attaccanti registrano domini simili a quelli dei fornitori (service-nowinc[.]com, domainlify[.]net), inseriscono nelle firme nomi e indirizzi reali di CEO, CFO e presidenti dell'azienda bersaglio, allegano una fattura fabbricata per un presunto rinnovo annuale ServiceNow e — questo è il dettaglio nuovo — includono un finto scambio di email precedente in cui il dirigente avrebbe già approvato il pagamento. La richiesta finale è un bonifico ACH all'ufficio contabilità.

Microsoft indica che i template e la personalizzazione dei testi sono stati prodotti con AI generativa. Il punto non è che l'AI scriva email migliori in astratto: è che elimina il costo marginale della personalizzazione, e quindi rende economico fare a un milione di destinatari ciò che prima si faceva a venti. La campagna ha colpito soprattutto realtà statunitensi nei servizi IT, beni di consumo, immobiliare e manifattura discreta.

Cosa significa per le aziende italiane

Il primo problema è che il canale d'attacco è fuori dal perimetro per costruzione. La chiamata arriva sul cellulare personale, l'SMS pure, il link si apre sul telefono privato. Non c'è un gateway di posta da configurare, non c'è un proxy che filtri, non c'è un EDR sul dispositivo. Ogni controllo tecnico su cui l'azienda ha investito sta guardando altrove. L'unico punto in cui la difesa può intervenire è il momento dell'autenticazione e ciò che succede subito dopo.

Il secondo problema riguarda il modo in cui in Italia si stanno adottando le passkey proprio adesso. Molte organizzazioni, banche e PA comprese, hanno campagne di migrazione in corso, e i dipendenti hanno davvero ricevuto comunicazioni interne che chiedono di iscrivere una passkey entro una certa data. L'attaccante non sta creando un pretesto artificiale: sta cavalcando un'iniziativa reale e annunciata. In queste settimane, chiunque abbia una migrazione MFA in corso dovrebbe assumere che il proprio progetto di sicurezza sia anche un'esca a disposizione degli attaccanti, e comunicarlo agli utenti di conseguenza — dicendo in anticipo, e in modo inequivocabile, da quale canale arriverà l'istruzione vera e che nessuno telefonerà mai per chiederla.

Il terzo punto è un cambio di priorità nella risposta agli incidenti. Se la persistenza si annida nei metodi di autenticazione, allora la revoca dei metodi MFA sconosciuti e delle sessioni attive diventa il primo passo del contenimento, prima del reset password. Un runbook che prevede «reset credenziali, controllo endpoint, chiusura ticket» lascia l'attaccante dentro. Ed è una lacuna che si può correggere in un pomeriggio.

Sul piano normativo, l'esfiltrazione descritta — mesi di posta, contenuti SharePoint e OneDrive, allegati — configura quasi sempre una violazione di dati personali ai sensi dell'articolo 33 GDPR, con le 72 ore che decorrono da quando il titolare ne viene a conoscenza. Chi è soggetto NIS2 ha in parallelo l'obbligo di pre-notifica al CSIRT Italia entro 24 ore per gli incidenti significativi, e un'esfiltrazione prolungata da tenant aziendale rientra nella casistica. Va anche detto che la ricostruzione dell'ambito della violazione, senza log di Graph API conservati e consultabili, diventa una congettura: e una notifica al Garante che non sa dire quali dati siano usciti è una posizione debole, oltre che un problema di accountability ex articolo 5.

Un'ultima nota sul lato frode. Il modello della finta fattura con il thread di approvazione allegato è direttamente trasferibile al contesto italiano, dove la variante naturale non è l'ACH ma il bonifico SEPA con IBAN modificato, spesso accompagnato da una comunicazione di «cambio coordinate bancarie» del fornitore. La difesa non è tecnologica e si conosce da anni: la verifica dell'IBAN fuori banda, su un numero di telefono già presente in anagrafica e mai su quello scritto nell'email.

Cosa fare subito

  • Rivedere subito l'elenco dei metodi di autenticazione registrati nel tenant Entra ID e cercare numeri di telefono, app authenticator e token OTP aggiunti di recente e non riconducibili all'utente. È la verifica singola con il miglior rapporto tra costo e valore in questa campagna.
  • Allertare sulla registrazione di nuovi metodi MFA, non solo sui login anomali. Un metodo aggiunto poco dopo un accesso da dispositivo o paese insolito è uno dei segnali più affidabili disponibili.
  • Limitare o disabilitare il flusso device code tramite policy di accesso condizionale, se non serve a scenari specifici. È una funzione legittima ma raramente necessaria per la maggior parte degli utenti, ed è il vettore che aggira l'MFA senza rubare nulla.
  • Inserire la revoca dei metodi MFA ostili e delle sessioni attive come primo passo del runbook di compromissione account, prima del reset della password.
  • Monitorare Graph in modo aggregato: volumi anomali di enumerazione utenti, download massivi da SharePoint e OneDrive, attività di un'identità da IP diversi in fasi diverse. La correlazione, non la singola chiamata.
  • Vincolare l'accesso a dispositivi gestiti e conformi per le applicazioni che espongono dati: nel caso documentato l'accesso è avvenuto da dispositivo non gestito, ed è lì che un controllo di conformità avrebbe interrotto la catena.
  • Comunicare agli utenti il canale ufficiale delle migrazioni passkey/MFA e stabilire la regola che l'help desk non chiama mai sul numero personale per chiedere modifiche alle credenziali. Va detto prima, non dopo.
  • Applicare la verifica fuori banda su ogni cambio di IBAN o richiesta di pagamento urgente, usando recapiti già in archivio. Nessuna eccezione per le richieste che sembrano provenire dall'amministratore delegato: sono esattamente quelle per cui la procedura esiste.