// 6 ZERO-DAY · 9 CVE · 6 EXPLOIT NELLE ULTIME 24H
N0va colpisce organizzazioni in Nord America ed Europa abusando flussi OAuth legittimi per catturare token di accesso e stabilire sessioni SSO persistenti senza malware.

Il 16 settembre 2026, la piattaforma di threat intelligence ANY.RUN ha documentato N0va, un phishkit attivo contro organizzazioni governative, tecnologiche, di consulenza e sanitarie in Nord America ed Europa. L'analisi rivela un salto di qualità rispetto al phishing tradizionale: N0va non ruba password, ma intercetta token di autenticazione già rilasciati da identity provider trusted, convertendoli in sessioni SSO indistinguibili da accessi legittimi. Il rischio operativo non è più il clic sulla mail, ma ciò che accade dopo.

Punti chiave
  • N0va impersona otto piattaforme aziendali trusted — Microsoft Teams, SharePoint, OneDrive, DocuSign, Google Drive, Dropbox, Zoom e Adobe Sign — per indurre le vittime a completare autenticazioni legittime.
  • Il flusso di attacco termina con la cattura di access e refresh token, seguita dall'abuso di meccanismi di token-exchange o device-registration per stabilire accesso SSO persistente.
  • Un pattern URL caratteristico — /api/verification/init?session=*&flow=*prompt_profile= — è stato identificato per il tracciamento delle campagne N0va.
  • La fonte non specifica il numero di vittime confermate, la data di inizio della campagna né l'identità degli operatori dietro il kit.

Come funziona il "post-phishing" di N0va

La catena di compromissione inizia con un lure che replica interfacce familiari: un invito a firmare un documento DocuSign, un alert da Microsoft Teams, un link a un file su Google Drive. La vittima, indotta a autenticarsi, viene instradata attraverso flussi OAuth2/OIDC legittimi. Il punto di rottura non è nel protocollo — che funziona correttamente — ma nel momento successivo.

Dopo l'autenticazione, N0va cattura access e refresh token. La fonte documenta esplicitamente che il kit abusa poi meccanismi di token-exchange o device-registration per convertire queste credenziali temporanee in sessioni SSO stabili. Il risultato: l'attaccante opera con identità legittima, all'interno di flussi di logging standard progettati per tracciare anomalie di malware o exploit, non abuso di token validi.

"Dopo che l'utente completa l'autenticazione, N0va può catturare access e refresh token e abusare di meccanismi di token-exchange o device-registration per stabilire accesso SSO"

Perché i controlli tradizionali non intercettano l'attacco

L'architettura identity moderna si fonda su un presupposto: se il token è valido e rilasciato da un IdP trusted, l'accesso è legittimo. N0va sfonda questo presupposto senza violare il protocollo. Non c'è exploit da patchare, nessuna vulnerabilità zero-day da catalogare, nessun payload eseguito su endpoint.

La conseguenza operativa è diretta. Gli strumenti di rilevamento tradizionali — EDR, filtri URL, sandbox di rete — sono calibrati su anomalie di esecuzione o indicatori di compromissione noti. Un token SSO rilasciato correttamente e poi riutilizzato non genera queste anomalie. La fonte non documenta tecniche di rilevamento alternative, ma il meccanismo descritto implica una lacuna strutturale: il controllo si concentra sulla frontiera, non sulla persistenza del token all'interno.

Pattern, velocità e limiti della fonte

ANY.RUN ha pubblicato un pattern URL specifico associato alle campagne N0va: /api/verification/init?session=*&flow=*prompt_profile=. In un caso con lure a tema Microsoft, la sandbox ha prodotto un verdict malicious in 24 secondi. La fonte riporta anche metriche operative per la propria base utenti — 16.000+ organizzazioni e 700.000+ professionisti — con riduzione del tempo di investigazione Tier 1 del 20%, riduzione delle escalation del 30% e MTTR ridotto di 21 minuti.

Queste cifre sono claim commerciali di ANY.RUN, non verificabili indipendentemente. Il dossier non specifica quando sia iniziata la campagna N0va, quante entità siano state compromesse per nome, né se il kit sia venduto, open source o operato da un gruppo specifico. Nessun vendor di sicurezza indipendente o CERT ha confermato la portata dell'attività.

Cosa fare adesso

Le organizzazioni che operano con infrastrutture SSO devono rivalutare il monitoraggio dei flussi di autenticazione. Il pattern URL /api/verification/init?session=*&flow=*prompt_profile= offre un indicatore concreto per le ricerche nei log e le regole di rilevamento. I team di sicurezza dovrebbero verificare se questo pattern appaia nelle richieste HTTP in entrata o nei redirect di autenticazione.

La struttura dell'attacco — autenticazione legittima seguita da cattura token — richiede un cambio di prospettiva nel monitoring. Le attività da considerare includono: correlare i token rilasciati con l'IP e il device di origine della richiesta iniziale; flaggare riutilizzi di refresh token in contesti geografici o temporali anomali; verificare registrazioni device non iniziate dall'utente finale. Queste azioni sono specifiche al meccanismo documentato da ANY.RUN, non raccomandazioni generiche di hardening.

Per i team che usano sandbox ANY.RUN, il caso Microsoft-themed dimostra che il verdict malicious è emesso in 24 secondi. Questo dato, pur essendo un claim del vendor, suggerisce che l'analisi dinamica può intercettare il lure iniziale prima che l'autenticazione avvenga. La finestra di intervento esiste, ma si colloca a monte del flusso OAuth, non a valle.

Perché è importante

Il caso N0va espone una tensione strutturale nell'enterprise security: la migrazione verso SSO e identity federation ha centralizzato la fiducia, ma ha anche creato un unico punto di fallimento nel token. Quando il token viene rubato attraverso flussi legittimi, l'infrastruttura di logging esistente non distingue l'accesso dell'attaccante da quello dell'utente reale.

Il dossier non specifica se tecniche come il binding del token a dispositivo o il monitoring comportamentale siano state implementate o testate contro N0va. Non documenta né raccomandazioni operative né misure correttive. Ciò che emerge con chiarezza è un problema di modello: la fiducia nel token, senza verifica continua del contesto di rilascio e riutilizzo, lascia aperto uno spazio che kit come N0va sanno sfruttare.

La convergenza con trend più ampi — la personalizzazione automatizzata dei lure tramite AI, documentata in altri contesti — suggerisce che la superficie di attacco per questo tipo di operazioni si espanderà. Il prossimo kit potrebbe non limitarsi a replicare interfacce, ma adattarle in tempo reale al profilo della vittima.

Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.

Fonti


Fonti e riferimenti
  1. thehackernews.com
  2. rapid7.com
  3. helpnetsecurity.com
  4. unit42.paloaltonetworks.com