Un malware che usa il calendario di Outlook come dead-drop

A 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 bidirezionale

L’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 tunneling

Ogni 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.com

Ogni 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 tradizionali

Tre 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 sicurezza

Le 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, RawEventData

Rilevamento 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 desc

Irrigidire 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.

Conclusione

HOLLOWGRAPH 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.