Si parla di:

Toggle

Per anni l’autenticazione a più fattori è stata venduta come il rimedio quasi definitivo al furto di credenziali. BigBear 2.0, una piattaforma di phishing-as-a-service (#PhaaS) tracciata dal team TRIAD di CloudSEK, dimostra quanto quella promessa sia oggi fragile: costruita su un fork pesantemente personalizzato di #Evilginx2, la piattaforma ha compromesso 258 organizzazioni bypassando l’MFA in modo completo, sottraendo oltre 5.100 credenziali — comprese 474 sessioni con secondo fattore già superato — da un bacino di 461 aziende prese di mira in oltre 40 paesi. Non parliamo di un proof-of-concept accademico: è un servizio criminale in abbonamento, con un’infrastruttura da 42 VPS, cinque affiliati attivi e un pannello di amministrazione ancora operativo al momento della scoperta.

Adversary-in-the-Middle: la tecnica che rende inutile il secondo fattoreBigBear non ruba solo la #password: intercetta l’intero flusso di autenticazione #OAuth 2.0 verso #Azure AD/Entra ID grazie a un phishlet Evilginx2 personalizzato, ribattezzato internamente “offy”. Il meccanismo è quello classico dell’adversary-in-the-middle (#AiTM): la vittima crede di trovarsi sulla pagina di login Microsoft 365, ma in realtà sta dialogando con un reverse proxy controllato dagli attaccanti, che inoltra le richieste al server reale e restituisce le risposte legittime — comprese quelle di verifica MFA. Password, codice del secondo fattore e, soprattutto, il cookie di sessione autenticato finale vengono catturati in tempo reale e possono essere “rigiocati” via #API per dirottare la sessione della vittima, aggirando completamente la necessità di ripetere l’autenticazione.

La versione 2.0 aggiunge un tassello che la distingue dai kit AiTM più comuni: un #JavaScript custom che interferisce attivamente con FIDO2/WebAuthn, disabilitando nel browser la funzionalità che gestisce le chiavi di sicurezza hardware, così da spingere la vittima verso metodi di autenticazione più deboli e aggirabili. A questo si affianca l’iniezione automatica del parametro “keep me signed in” (KMSI), che allunga la vita utile del cookie rubato, e il blocco della telemetria Microsoft lato client per ridurre il rischio che Defender for Identity o i sistemi di risk-based Conditional Access rilevino l’anomalia in tempo reale.

Un’infrastruttura pensata per l’affiliazione, non per l’attacco singoloCloudSEK ha identificato 42 nodi VPS ospitati presso The Constant Company LLC (Vultr), tutti dedicati esclusivamente a Microsoft 365 — nessun altro provider di identità risulta tra i bersagli. Per aggirare i controlli anti-frode basati su geolocalizzazione, BigBear instrada il traffico attraverso proxy residenziali geo-matchati che coprono 69 paesi, così che l’IP “visto” dai sistemi antifrode di Microsoft corrisponda plausibilmente alla presunta posizione della vittima. Un controllo aggiuntivo tramite il servizio ipapi.is filtra a monte le connessioni provenienti da datacenter o VPN, riducendo il rischio che ricercatori o honeypot automatizzati vengano serviti con la pagina di phishing.

Il modello di business è quello del PhaaS puro: dietro l’alias “General Boss” opera un rivenditore che fornisce l’infrastruttura come servizio a un piccolo network di affiliati, ciascuno con il proprio bot Telegram per ricevere in tempo reale le credenziali rubate e un proprio set di domini di phishing. CloudSEK ha mappato cinque operatori attivi — @Sunagashison, @app_ham, @donplayer00, @workin_161 e @Mazal100 — ciascuno collegato a bot Telegram dedicati (rispettivamente @PackingitonG_bot, @botterxyz_bot, @donplayer_bot, @bolywan_bot, @rdsxtdytguyg75d_bot) e a domini distinti come konceptenterprises[.]com, dnsforward[.]com e cifutura[.]com. Un bot centrale, @comeandget_bot, fungeva da canale primario di raccolta prima di essere revocato durante l’indagine.

Chi viene colpito, e perché conta per gli MSPLa distribuzione settoriale delle vittime racconta molto dell’obiettivo strategico della campagna: 151 delle organizzazioni compromesse operano nel settore IT services/MSP, seguite da SaaS/tecnologia (38), oil & gas (22), farmaceutico (20) e consulenza (16). Colpire un provider di servizi gestiti significa, potenzialmente, ereditare l’accesso a decine di clienti a valle attraverso strumenti RMM e privilegi delegati — lo stesso principio dietro molti attacchi ransomware su larga scala degli ultimi anni. Geograficamente, l’India guida la lista delle vittime con 658 record (12,8%), seguita da Francia (463, 9%), Arabia Saudita (circa 353, 6%), con presenze significative anche in Nuova Zelanda e Germania, per un totale di 3.331 IP univoci in oltre 40 paesi.

CloudSEK ha individuato la campagna a giugno 2026 e ne segue l’evoluzione da allora; dalla fine di luglio l’attore ha iniziato a ripulire le proprie tracce, dismettendo 26 dei 42 nodi VPS osservati inizialmente — un comportamento tipico di chi sa di essere sotto osservazione ma non ha alcuna intenzione di fermare l’operazione, semplicemente la sposta. Al momento della pubblicazione della ricerca, il pannello di amministrazione di BigBear risultava ancora raggiungibile.

Perché l’MFA “classica” non basta piùIl caso BigBear 2.0 conferma una tendenza che i team di threat intelligence osservano ormai da un paio d’anni: i kit AiTM basati su Evilginx2, Modlishka ed Evilnginx hanno reso il phishing “classico” con MFA a tempo (OTP, push notification, codice via app) sostanzialmente equivalente, in termini di sicurezza reale, all’autenticazione con la sola password. Il cookie di sessione, non la password, è oggi il vero bene da proteggere. Le organizzazioni che vogliono davvero alzare l’asticella devono muoversi su tre fronti: imporre chiavi di sicurezza hardware FIDO2/WebAuthn phishing-resistant come unico secondo fattore ammesso per gli account privilegiati (BigBear dimostra che il downgrade software verso metodi più deboli è già una funzionalità del kit, non un’ipotesi teorica); attivare Conditional Access che richieda dispositivi gestiti e conformi, rendendo inutile un cookie di sessione rubato da un dispositivo non registrato; e monitorare pattern di rete distintivi come header HTTP custom (x-evg-*), naming di sessione riconducibile a Evilginx (evginx_session, bigbear_session) e chiamate anomale verso l’API Telegram (sendMessage, sendDocument) che spesso tradiscono l’exfiltration automatizzata dei kit PhaaS.

Per chi sospetta una compromissione, la prima azione non è il reset della password ma la revoca esplicita di tutte le sessioni attive e dei refresh token — un cambio password da solo lascia intatti i cookie già rubati, che in molti tenant restano validi per giorni.

Indicatori di compromissione# Domini di phishing attivi (fonte: CloudSEK TRIAD, settembre 2026)
konceptenterprises[.]com
ccpipharma[.]com
annastudios-paros[.]com
dnsforward[.]com
dataclust[.]com
cifutura[.]com
offtic[.]com

Domini storici associati

daengrentacar[.]com
arrmmy[.]com
captelind[.]com

Infrastruttura

Hosting: The Constant Company LLC (Vultr)
Nodi VPS osservati: 42 (26 dismessi da fine luglio 2026)
Proxy residenziali geo-matchati: 69 paesi
Anti-bot check: ipapi.is (blocco datacenter/VPN)

Telegram - affiliati e bot di exfiltration

@Sunagashison -> @PackingitonG_bot (soil-management[.]com, kgsscans[.]com)
@app_ham -> @botterxyz_bot (dnsforward[.]com, dataclust[.]com)
@donplayer00 -> @donplayer_bot (konceptenterprises[.]com)
@workin_161 -> @bolywan_bot (annastudios-paros[.]com)
@Mazal100 -> @rdsxtdytguyg75d_bot (cifutura[.]com)
Bot C2 primario (revocato): @comeandget_bot

Pattern di rilevamento

Cookie/sessione: evginx_session, bigbear_session
Header HTTP custom: x-evg-*
Endpoint exfiltration: api.telegram.org/bot*/sendMessage, sendDocument

Fonte primaria

CloudSEK TRIAD - "Tracking BigBear 2.0 Evilginx2 Phishing Campaign"
Scoperta: giugno 2026 - Pubblicazione: settembre 2026

Con l’adozione di #Copilot che accelera dentro Microsoft 365, molti team IT si stanno scontrando con un problema che precede di anni l’AI generativa ma che l’AI generativa rende improvvisamente urgente: la sovraesposizione dei dati. File condivisi “a chiunque abbia il link” dimenticati su #SharePoint anni fa, permessi ereditati mai ripuliti, cartelle OneDrive con dati finanziari accessibili a interi reparti. Finché a leggere quei file era un motore di ricerca aziendale poco usato, il rischio restava contenuto. Con un assistente AI che risponde a qualunque domanda pescando da tutto ciò a cui l’utente ha accesso, ogni permesso mal configurato diventa una potenziale fuga di informazioni istantanea. Microsoft #Purview Data Security Posture Management (DSPM) nasce per rispondere proprio a questo scenario, e vale la pena capire cosa fa concretamente, prima di attivare Copilot su larga scala.

Cos’è DSPM e perché non è “un altro tool di compliance”DSPM è il componente di Microsoft Purview dedicato a rispondere a quattro domande fondamentali sulla postura di sicurezza dei dati di un’organizzazione:

Che dati abbiamo? — discovery e classificazione automatica

Dove sono conservati? — mappatura di location e storage

Chi può accedervi? — #analisi dei pattern di accesso e permessi

Come sono protetti? — valutazione delle policy di protezione applicate

A differenza di un tool di #compliance tradizionale che verifica la conformità a una #normativa in un dato momento, DSPM è pensato per essere continuo: monitora costantemente lo stato dei dati sensibili in Microsoft 365, #Azure e alcune piattaforme di terze parti, e traccia se l’esposizione migliora o peggiora nel tempo attraverso un grafico di trend a 30 giorni sulla dashboard principale.

Il flusso operativo: discovery, assessment, remediationDSPM lavora attraverso cinque fasi concettuali:

Discovery: individua informazioni sensibili — dati di payroll, codici fiscali, contratti, proprietà intellettuale, codice sorgente — usando classificatori integrati e sensitive information type basati su pattern matching (numeri di carte di credito, patenti, SSN, oltre a classificazioni personalizzate per record finanziari o contratti specifici dell’organizzazione)

Assessment: valuta lo stato di crittografia, l’applicazione di etichette di sensibilità e i rischi di condivisione eccessiva

Prioritizzazione: ordina i problemi rilevati per severità, in modo da affrontare prima gli elementi a rischio più alto

Remediation: applica azioni correttive — etichette di sensibilità, riduzione dei permessi, creazione di policy DLP

Monitoraggio continuo: verifica se l’esposizione dei dati migliora o peggiora nel tempo

Un punto tecnico che vale la pena chiarire subito, perché genera spesso confusione: DSPM individua l’esposizione, DLP la applica. DSPM è lo strumento di ricerca e scoperta — risponde a “dove abbiamo un problema” — mentre Data Loss Prevention è il livello che impone effettivamente restrizioni comportamentali una volta identificato il rischio. Non sono strumenti alternativi ma complementari, e DSPM può generare direttamente raccomandazioni per creare o affinare policy DLP.

Le funzionalità chiaveData risk assessmentDSPM offre assessment predefiniti e personalizzabili che identificano contenuti sovraesposti, protezione inadeguata, etichette di sensibilità mancanti e permessi ad alto rischio. Quando questi problemi vengono confermati, DSPM può automatizzare passaggi di remediation come la rimozione di link di condivisione pubblici, l’applicazione di policy DLP, la revoca di permessi o l’applicazione di etichette di sensibilità — prima che l’incidente si verifichi, non dopo.

Rilevamento dei percorsi di esfiltrazioneUno degli use case più concreti è la mappatura dei cosiddetti “exfiltration path”: dati sensibili condivisi esternamente, o informazioni business-critical protette da controlli di accesso deboli. DSPM consolida in questo ambito gli insight provenienti da quattro soluzioni Purview distinte: Data Loss Prevention, Insider Risk Management, Information Protection (etichette di sensibilità) e Data Security Investigations — offrendo così una vista unificata invece di quattro dashboard scollegate.

DSPM for AI: la componente più rilevante per chi sta adottando CopilotCon l’estensione DSPM for AI, Microsoft ha aggiunto un livello di osservabilità specifico per gli agenti e le app AI, incluso Microsoft Agent 365. L’AI Observability Dashboard fornisce:

Un inventario delle app e degli agenti AI in uso nell’organizzazione

Attività registrata negli ultimi 30 giorni

Il conteggio degli agenti considerati ad alto rischio

Il numero totale di agenti che interagiscono con dati sensibili

Una vista dettagliata per singolo agente e per policy di governance applicata

In pratica, prima di dare a Copilot (o a qualunque altro agente AI collegato al tenant) accesso ai dati aziendali, DSPM for AI permette di vedere quali repository quell’agente toccherebbe e con quale livello di rischio, invece di scoprirlo a posteriori tramite un incidente.

Attivazione: i setup task principaliLa configurazione iniziale avviene dal Microsoft Purview portal, sotto DSPM > Actions > Setup tasks, dove ogni attività include istruzioni passo-passo, stato di completamento, tempo stimato e impatto previsto sugli utenti. I task principali sono:

Setup taskCosa faNoteAttivazione Microsoft Purview AuditVerifica che l’audit sia abilitatoAttivo di default sui tenant nuovi, va abilitato manualmente sui tenant esistentiOnboarding dei dispositiviDeploy su endpoint WindowsNecessario per la visibilità su siti AI di terze parti e per endpoint DLPEstensione browser PurviewDeploy su Chrome/EdgeRichiesta per le policy DLP a livello di browserEtichette di sensibilitàCrea etichette e policy predefiniteSolo se non già configurate nel tenantConfigurazione billingAttiva il pay-as-you-goRichiesta per alcune configurazioni avanzateIntegrazione con SentinelCollega il content hubFunzionalità in previewUn aspetto da verificare con attenzione prima del rollout è quello dei permessi: la documentazione ufficiale non elenca in modo esplicito i ruoli richiesti (Global Admin, Security Admin, Compliance Admin), quindi è opportuno validare con un tenant di test quali ruoli minimi servono per ciascun setup task, prima di assegnare permessi troppo ampi al team che gestirà DSPM in produzione.

Licensing: cosa aspettarsiDSPM (in versione “classica”) è incluso nelle licenze Microsoft 365 E5 / E5 Compliance, mentre alcune funzionalità più avanzate — in particolare componenti di DSPM for AI e alcune configurazioni di billing pay-as-you-go — possono richiedere add-on o un modello di consumo separato. Prima di pianificare il rollout, vale la pena verificare la Microsoft Purview Licensing Guidance aggiornata, perché il pacchetto di funzionalità incluse per fascia di licenza è soggetto a modifiche frequenti.

DSPM non sostituisce la compliance tradizionaleUn’ultima precisazione utile per chi deve giustificare il progetto internamente: DSPM offre visibilità sul trattamento dei dati sensibili ed è un complemento prezioso agli strumenti di compliance tradizionali, ma non li sostituisce. Framework normativi (GDPR, ISO 27001, settoriali) richiedono comunque processi, documentazione e controlli dedicati. DSPM riduce il rischio operativo e dà visibilità continua, ma resta uno strumento di data security posture, non un motore di conformità normativa.

Quando ha senso adottarloDSPM è particolarmente utile per organizzazioni che:

Stanno pianificando o hanno già distribuito Copilot su larga scala

Gestiscono ambienti SharePoint/OneDrive di grandi dimensioni con anni di condivisioni stratificate

Trattano dati regolamentati (finanziari, sanitari, PII in generale)

Faticano a mantenere visibilità sulla governance dei dati a scala aziendale

Organizzazioni piccole, con esigenze di compliance minime e un perimetro dati contenuto, potrebbero non trarne un beneficio proporzionato al costo di licenza e all’impegno di configurazione iniziale.

ConclusioneIl messaggio di fondo di DSPM è semplice ma spesso trascurato: attivare Copilot senza prima aver mappato chi può accedere a cosa significa dare a un assistente AI estremamente efficiente nel trovare informazioni lo stesso identico perimetro di accesso — sbagliato — che esisteva già, solo molto più velocemente interrogabile. Per i team che gestiscono tenant Microsoft 365 di dimensioni medio-grandi, un ciclo di discovery e remediation con DSPM prima del rollout di Copilot non è un passaggio opzionale di “nice to have”, ma la differenza tra un’adozione AI controllata e un incidente di esposizione dati che si scopre solo dopo che è già successo.

Fonte originale: Microsoft Purview Data Security Posture Management Explained: How It Reduces Data Exposure Before Copilot – Petri IT Knowledgebase (Brien Posey). Approfondimenti tecnici da Microsoft Learn.

Un malware che usa il calendario di Outlook come dead-dropA metà luglio 2026 il team di Threat Intelligence di Group-IB ha pubblicato un’analisi tecnica su HOLLOWGRAPH, un impianto malevolo che ribalta un’assunzione su cui molte architetture di sicurezza si basano ancora: se il traffico esce verso graph.microsoft.com con un token valido, allora è “legittimo”. HOLLOWGRAPH dimostra che non è più così, e lo fa in un modo che vale la pena capire in dettaglio anche per chi non si occupa di threat intelligence, perché le tecniche di evasione che usa (abuso di API cloud fidate, DNS tunneling, cifratura ibrida) sono ormai pattern ricorrenti e replicabili.

Il malware è attribuito con alta confidenza al framework di backdoor modulare Cavern, già collegato ad attività di cyberspionaggio riconducibili all’area di influenza iraniana (con sovrapposizioni tecniche, seppur a bassa confidenza, con il gruppo Lyceum). La campagna osservata ha colpito in modo mirato organizzazioni israeliane: 12 sistemi compromessi identificati, di cui solo 3 attivamente in comunicazione con l’attaccante al momento dell’analisi — un profilo operativo selettivo, non opportunistico.

Il calendario come canale C2 bidirezionaleL’idea centrale di HOLLOWGRAPH è semplice da spiegare e proprio per questo efficace: invece di contattare un server C2 sotto il controllo dell’attaccante, il malware autentica una mailbox Microsoft 365 compromessa tramite Microsoft Graph API e usa il calendario di quella mailbox come dead-drop bidirezionale.

Il malware supporta solo due comandi:

get — cerca eventi del calendario con oggetto Event ID: <taskID>, programmati per il 13 maggio 2050 (una data lontana nel futuro, scelta per non comparire mai nella vista “prossimi eventi” del proprietario della mailbox), scarica gli allegati e li decifra con la chiave privata RSA incorporata nel binario.

send — cifra i dati da esfiltrare, crea un nuovo evento con la stessa data fittizia, carica i dati come allegati File{n}.txt e rinomina l’oggetto dell’evento con un tag riconoscibile dall’operatore (schema Boss{..}ID{..}).

Le chiamate Graph coinvolte sono quelle che qualunque applicazione legittima con permessi calendario userebbe normalmente:

GET /users/{mailbox}/calendarView
?startDateTime=2050-05-13T22:00:00
&endDateTime=2050-05-13T23:00:00
&$filter=contains(subject,'Event ID: ')

POST /users/{mailbox}/calendar/events
POST /users/{mailbox}/events/{event-id}/attachments
PATCH /users/{mailbox}/events/{event-id}Non c’è nulla in queste richieste che le distingua sintatticamente da un utente che crea un invito a una riunione. È questo il punto: il traffico malevolo non anomalizza il protocollo, sfrutta la fiducia implicita che i controlli di rete perimetrali attribuiscono al dominio graph.microsoft.com.

Cifratura ibrida e rinnovo credenziali via DNS tunnelingOgni payload scambiato tramite il calendario è protetto con uno schema ibrido RSA-OAEP + AES-256-GCM, con due coppie di chiavi RSA distinte per le due direzioni (tasking in ingresso ed esfiltrazione in uscita), così che comandi e dati rubati restino crittograficamente indipendenti l’uno dall’altro anche in caso di compromissione parziale.

Il secondo canale, separato, serve a rinnovare le credenziali Microsoft Entra ID (tenant ID, client ID, client secret, indirizzo della mailbox) necessarie per autenticarsi a Graph. Qui HOLLOWGRAPH usa DNS tunneling su record AAAA verso un dominio controllato dall’attaccante (cloudlanecdn[.]com):

LENGTH query: {random}.{taskID}.{fieldIndex}.p.cloudlanecdn.com
DATA query: {random}.{taskID}.{fieldIndex}.{offset}.q.cloudlanecdn.comOgni risposta IPv6 restituita (16 byte) trasporta 14 byte di payload utile; il client ricompone i frammenti, li decodifica come UTF-8 e aggiorna un file di configurazione locale (logAzure.txt) mascherato da comune file di log. L’uso di IPv6/AAAA anziché dei più monitorati record TXT o A è una scelta non casuale: molte pipeline di DNS analytics sono ancora tarate prevalentemente su IPv4.

Perché elude i controlli tradizionaliTre fattori rendono HOLLOWGRAPH difficile da individuare con gli strumenti perimetrali classici:

Il traffico C2 viaggia interamente su infrastruttura Microsoft fidata (Graph API), quindi non compare in nessuna blocklist di reputazione IP o dominio.

Non c’è mai una connessione diretta a un server dell’attaccante per il tasking o l’esfiltrazione: solo il canale di rinnovo credenziali tocca un dominio esterno, e lo fa via DNS, spesso meno ispezionato del traffico HTTPS.

Gli eventi di calendario datati 2050 sono progettati per restare invisibili all’utente reale della mailbox, che normalmente non scorre trent’anni avanti nel proprio calendario.

Cosa può fare concretamente un team di sicurezzaLe raccomandazioni di Group-IB si traducono in azioni piuttosto precise per chi gestisce ambienti Microsoft 365 / Entra ID:

Caccia agli indicatori noti. Bloccare o mettere in allerta su richieste verso cloudlanecdn[.]com e cercare sugli endpoint il file logAzure.txt.

Monitoraggio Graph API e audit di calendario. Con Microsoft Sentinel o Defender Advanced Hunting è possibile costruire una query che cerchi eventi di calendario creati da un’applicazione (non da un utente interattivo) con oggetto sospetto o data anomala:

CloudAppEvents
| where Application == "Microsoft Exchange Online"
| where ActionType in ("New item created.", "New-CalendarItem")
| extend AppId = tostring(RawEventData.ClientAppId)
| where isnotempty(AppId)
| extend Subject = tostring(RawEventData.ItemSubject)
| where Subject matches regex @"Event ID: |Boss{.}ID{.}"
| project Timestamp, AccountDisplayName, AppId, Subject, RawEventDataRilevamento di DNS tunneling. Una query di partenza per individuare volumi anomali di query AAAA verso lo stesso dominio, con sottodomini ad alta entropia:

DnsEvents
| where QueryType == "AAAA"
| extend RootDomain = strcat(split(Name, ".")[-2], ".", split(Name, ".")[-1])
| summarize QueryCount = count(), DistinctSubdomains = dcount(Name) by Computer, RootDomain
| where QueryCount > 200 and DistinctSubdomains > 100
| order by QueryCount descIrrigidire l’identità cloud. Applicare Conditional Access con restrizioni sulle app registrate che usano client-credentials flow, generare alert sulla creazione di nuovi client secret e ruotare periodicamente le credenziali applicative — HOLLOWGRAPH dipende interamente da un set di credenziali Entra ID statiche incorporate nel binario: se quelle credenziali vengono revocate o ruotate, il canale Graph smette di funzionare finché l’attaccante non le rinnova via DNS tunneling, un’operazione che a sua volta genera telemetria rilevabile.

ConclusioneHOLLOWGRAPH non introduce tecniche crittografiche nuove né exploit in Microsoft Graph: il suo valore per l’attaccante sta tutto nel mimetismo. Per i team che gestiscono tenant Microsoft 365, il takeaway pratico non è “bloccare Graph API” — impossibile in qualunque organizzazione moderna — ma spostare parte della detection dal perimetro di rete alla telemetria applicativa: audit log di Exchange Online, anomalie nei permessi delle app registrate, e DNS analytics capace di guardare oltre i soliti record A/TXT. È un promemoria che vale la pena avere in mente ogni volta che si progetta un controllo di sicurezza basato solo sulla reputazione del dominio di destinazione.

Fonte: Group-IB Threat Intelligence, “HOLLOWGRAPH: Turning Microsoft 365 Calendars into Covert Command-and-Control Channels” e Petri IT Knowledgebase.

Un impianto di spionaggio finora sconosciuto ha trasformato uno degli strumenti più banali della vita d’ufficio, il calendario di Microsoft 365, in un canale di comando e controllo. Si chiama HollowGraph, non sfrutta alcuna vulnerabilità software e per questo è quasi impossibile da rilevare con i controlli di rete tradizionali: il traffico che porta gli ordini dell’attaccante e i file rubati è, a tutti gli effetti, traffico legittimo verso le API di Microsoft Graph.

A scoprirlo è stata Group-IB, che ha pubblicato l’analisi tecnica il 20 luglio 2026 dopo aver individuato l’impianto su almeno 12 macchine compromesse, di cui solo tre attivamente in comunicazione con l’attaccante durante la finestra di osservazione. Il traffico della vittima analizzata copre il periodo dal 3 giugno al 9 luglio 2026, e la casella di posta usata per l’esfiltrazione appartiene a un’organizzazione israeliana. Un’impronta piccola e selettiva, che i ricercatori leggono come spionaggio mirato piuttosto che criminalità opportunistica, anche se la tecnica potrebbe essere riutilizzata su scala molto più ampia.

Il calendario come dead dropHollowGraph è una DLL .NET che supporta solo due comandi, get e send, e non contatta mai direttamente un server dell’attaccante per ricevere istruzioni. Al loro posto usa il calendario della casella compromessa come dead drop bidirezionale: per ricevere i comandi, interroga un evento specifico piazzato dall’operatore e datato 2050-05-13, una data così lontana nel futuro che nessun utente lo scoprirebbe mai scorrendo la propria agenda, e ne legge le istruzioni da un file allegato.

Per l’esfiltrazione il processo si inverte: il malware cifra il file rubato, crea un proprio evento altrettanto lontano nel tempo e carica i dati come uno o più allegati. L’intero scambio è protetto da uno schema ibrido RSA più AES-256, con coppie di chiavi separate per il canale di comando in entrata e per quello di esfiltrazione in uscita. Chi osservasse solo i log di rete vedrebbe esclusivamente chiamate alle API Microsoft Graph, indistinguibili dal traffico generato da un client Outlook qualsiasi.

Il secondo canale: DNS tunneling per restare viviPerché l’accesso a Graph resti valido nel tempo, HollowGraph mantiene un secondo canale, più grezzo ma altrettanto insidioso. Via DNS, il malware aggiorna periodicamente le credenziali dell’applicazione registrata su Entra ID (Azure AD): tenant ID, client ID, client secret e la casella di posta bersaglio. Questi valori vengono decodificati da record AAAA IPv6 restituiti da un dominio controllato dall’attaccante, cloudlanecdn[.]com, e scritti in un file camuffato da log di routine, logAzure.txt. A differenza del traffico sul calendario, qui le credenziali applicative viaggiano in chiaro, il che rende questo canale un punto di osservazione prezioso per i difensori.

Chi c’è dietro: Cavern e l’ombra di TeheranGroup-IB collega HollowGraph al framework backdoor modulare Cavern con alta confidenza, sulla base della sintassi di comando condivisa e di corrispondenze nella logica di tasking interna. Cavern era stato documentato all’inizio di luglio da Check Point, che lo ha attribuito a un cluster legato al Ministero dell’Intelligence e della Sicurezza iraniano (MOIS) soprannominato Cavern Manticore, con sovrapposizioni note verso i gruppi iraniani MuddyWater e Lyceum.

Il legame però riguarda il codice, non necessariamente l’operatore di questa specifica campagna: Group-IB è stata esplicita nel dire di non poter attribuire con sicurezza questa attività a un attore già noto, segnalando solo una sovrapposizione a bassa confidenza con Lyceum, sottogruppo dell’iraniano OilRig. La geografia della vittima, un’organizzazione israeliana, viene trattata dai ricercatori come dato sul bersaglio e non come prova di attribuzione.

Va detto che nascondere il comando e controllo dentro servizi Microsoft fidati non è una novità assoluta: caselle Outlook, cartelle bozze e OneDrive sono già stati abusati in passato con logiche simili. Ciò che rende HollowGraph interessante è aver scelto l’angolo cieco più remoto possibile, un evento di calendario piantato 24 anni nel futuro, in un momento in cui la difesa si concentra sempre di più sul monitoraggio delle identità cloud e delle applicazioni OAuth piuttosto che sui contenuti stessi delle caselle di posta.

Perché conta per i difensoriNon c’è una vulnerabilità Microsoft da patchare: HollowGraph vive su un account compromesso e sulle normali funzionalità dell’API Graph, il che è esattamente ciò che lo rende difficile da individuare. Il lavoro va fatto sul piano dell’identità e dei permessi applicativi, non su quello delle patch. Group-IB raccomanda di restringere e verificare le applicazioni OAuth con credenziali client che possono raggiungere Graph, allertare sulla creazione di nuovi client secret e applicare la consueta igiene su Entra ID: Conditional Access, rotazione delle credenziali e rilevamento di token anomali.

Cercare eventi di calendario con data remota 2050-05-13

Verificare oggetti che siano un GUID nudo o seguano schemi tipo Event ID: o Boss{..}ID{..}

Individuare allegati con nome File{n}.txt

Auditare le modifiche al calendario generate da un’applicazione anziché da una persona (eventi creati, allegati caricati, oggetti rinominati via app)

Monitorare query DNS AAAA insolitamente frequenti verso un singolo dominio, con sottodomini lunghi e ad alta entropia

Cercare il dominio cloudlanecdn[.]com e il file di configurazione logAzure.txt

L’operatore dietro questa campagna resta senza nome, e il traffico della vittima risultava ancora attivo il 9 luglio. Vale la pena controllare fin da ora quegli eventi datati nel remoto futuro: è esattamente lì che nessun analista avrebbe mai pensato di guardare.

Indicatori di compromissioneDominio C2 (DNS tunneling): cloudlanecdn[.]com
File di configurazione: logAzure.txt
Evento calendario esca: data 2050-05-13
Pattern oggetto evento: GUID nudo / "Event ID:" / "Boss{..}ID{..}"
Allegati di comando: File{n}.txt
Framework correlato: Cavern (Cavern Manticore / MOIS-linked, overlap MuddyWater e Lyceum)
Finestra di attività osservata: 3 giugno - 9 luglio 2026
Set completo di IoC e hash: report tecnico Group-IB, "HOLLOWGRAPH: Turning Microsoft 365 Calendars into Covert Command-and-Control Channels"