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[.]comLENGTH 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.

Si parla di:ToggleBastava un “npm install” per essere compromessi. L’11 luglio 2026 la versione 8.14.0 del pacchetto jscrambler, tool di offuscamento JavaScript usato in migliaia di pipeline di build e ambienti CI/CD, è stata pubblicata su npm con un hook di preinstallazione malevolo capace di eseguire silenziosamente un infostealer nativo scritto in Rust, con build dedicate per Windows, macOS e Linux. Non serviva importare il pacchetto né lanciare un comando: la sola installazione bastava a far partire il payload.Il caso, documentato da Socket, StepSecurity e SafeDep, si inserisce in una scia di attacchi alla supply chain npm che va avanti da fine 2025 — dal worm Shai-Hulud alla compromissione di chalk e debug, fino al trojan iniettato in Axios a marzo. Ma questa volta il bersaglio non è la massa di utenti finali: è l’ambiente di build stesso, dove risiedono le chiavi cloud, i token di deploy e il codice sorgente che un’infrastruttura CI può raggiungere.Sei minuti per essere scoperti, troppo tardi per moltiSocket ha segnalato la release appena sei minuti dopo la pubblicazione. Chiunque, o qualsiasi sistema di build, avesse scaricato il pacchetto in quella finestra ha già eseguito il payload con tutti i permessi del processo di installazione. L’hook malevolo si attiva prima ancora che il pacchetto venga configurato, e non compare nella release precedente, la 8.13.0: il diff del pacchetto mostra due nuovi file sotto dist/, setup.js — un piccolo loader — e intro.js, che nonostante il nome non è affatto JavaScript ma un container di circa 7,8 MB che impacchetta tre binari nativi compressi in gzip, uno per Linux, uno per Windows e uno per macOS.All’installazione, setup.js seleziona il binario per il sistema operativo host, lo scrive con un nome casuale nella directory temporanea di sistema, lo rende eseguibile e lo lancia in modalità detached nascondendone l’output. I file aggiunti erano presenti nel pacchetto pubblicato ma assenti nel codice sorgente pubblico: sia StepSecurity sia SafeDep, che hanno analizzato indipendentemente la release, riportano l’assenza di qualsiasi commit, tag o pull request corrispondente alla versione 8.14.0 nel repository GitHub, il cui ultimo tag ufficiale resta 8.13.0.La versione compromessa è stata pubblicata direttamente su npm da un account maintainer legittimo, bypassando il normale flusso di rilascio del progetto — un forte indicatore di account npm compromesso o pipeline di build violata. Quale delle due ipotesi sia corretta non è ancora stato stabilito.Cosa fa davvero l’infostealerL’analisi di follow-up di Socket identifica il payload come un infostealer Rust, compilato per tutte e tre le piattaforme, che scandaglia la macchina dello sviluppatore alla ricerca di segreti e li invia a un server di raccolta via TLS. La lista dei bersagli è ampia e mirata esplicitamente agli sviluppatori:Credenziali cloud da AWS, Azure e Google Cloud, inclusi gli endpoint di metadata usati dai runner CI.Wallet di criptovalute e seed phrase da MetaMask, Phantom ed Exodus, oltre al vault del password manager Bitwarden.Password e cookie salvati nel browser, insieme alle sessioni di Discord, Slack, Telegram e Steam.File di configurazione di strumenti di coding AI — Claude Desktop, Cursor, Windsurf, VS Code e Zed — dove risiedono tipicamente chiavi API e credenziali dei server Model Context Protocol (MCP).Il payload va oltre il furto ordinario di credenziali: su Linux, si collega alla libreria BPF del kernel ed è in grado di caricare in memoria un programma eBPF, un punto d’appoggio a livello kernel piuttosto che il semplice accesso userspace ai file su cui si basa il resto dello stealer. Sia StepSecurity sia SafeDep hanno segnalato questa capacità, anche se la funzione esatta del programma eBPF è ancora in fase di analisi. Le build Windows e macOS aggiungono controlli anti-debug, mentre la persistenza è garantita da un task pianificato nascosto su Windows, impostato per rilanciarsi ogni minuto, e da un LaunchAgent su macOS che si ricarica a ogni login.I dettagli di comando e controllo restano cifrati nel binario e non sono emersi dall’analisi statica; il monitoraggio runtime di StepSecurity ha però intercettato il binario mentre contattava due indirizzi IP hardcoded e infrastruttura Tor — i primi indicatori di rete pubblicati per questa campagna.Timeline e portata dell’incidenteNell’arco di circa tre ore, l’attaccante ha pubblicato cinque release malevole — 8.14.0, 8.16.0, 8.17.0, 8.18.0 e 8.20.0 — intervallate da release pulite che i maintainer sembrano aver spinto come tentativo di rimedio. Il pacchetto jscrambler conta circa 15.800 download settimanali: una base d’utenza ben più contenuta rispetto ai grandi incidenti npm dell’ultimo anno, che hanno coinvolto pacchetti con miliardi di download settimanali complessivi. Ma per uno stealer pensato per colpire macchine di build, la portata non era l’obiettivo: lo era l’accesso.Un dettaglio temporale rende il caso ancora più significativo: npm 12, rilasciato l’8 luglio 2026, appena tre giorni prima di questo incidente, ha disattivato di default l’esecuzione automatica degli script di installazione delle dipendenze. Su npm 12, un preinstall hook come questo non gira a meno che qualcuno non lo approvi esplicitamente. I client più datati, però, continuano a eseguirli automaticamente — ed è esattamente lì che l’attacco ha colpito.La versione 8.15.0 ha da allora sostituito la 8.14.0 in cima all’elenco versioni di npm, pubblicata dallo stesso account maintainer e priva di qualsiasi alert di malware: nessuno script di installazione, nessun binario incluso. Ma la versione 8.14.0 non è stata rimossa da npm: resta scaricabile, quindi qualsiasi lockfile o comando ancorato a quella versione continua a installare lo stealer. Solo il pacchetto CLI principale è stato colpito; i plugin jscrambler per webpack, gulp, Metro e grunt sono rimasti sulle release pulite di giugno, senza hook di installazione.Cosa fare adessoAbbandonare immediatamente la versione 8.14.0: passare alla 8.15.0, oppure fissare la 8.13.0 (release precedente all’incidente), ed eliminare jscrambler@8.14.0 da lockfile e cache.Verificare se la versione compromessa è stata installata: controllare lockfile e log dei package manager per jscrambler@8.14.0, e i log CI per qualsiasi esecuzione di dist/setup.js dall’11 luglio in poi. Il loader scrive il payload con un nome casuale nella directory temporanea, quindi non esiste un nome di binario fisso da cercare: bisogna incrociare i timestamp di installazione con i processi figli di Node e l’esecuzione nella directory temp. Su Windows controllare Task Scheduler per task nascosti; su macOS ispezionare ~/Library/LaunchAgents per plist sconosciuti.Se la 8.14.0 è stata eseguita su una macchina, trattare ogni segreto raggiungibile come rubato, non solo come esposto: ruotare chiavi cloud, token npm e GitHub, chiavi API di strumenti AI e MCP; revocare sessioni Discord, Slack, browser e Bitwarden; spostare eventuali fondi in criptovaluta da wallet presenti su quell’host. Bloccare i due IP di comando e controllo elencati di seguito.La pulizia da parte del maintainer è stata rapida, ma uno stealer compie il proprio lavoro nei secondi immediatamente successivi all’installazione. La 8.14.0 resta su npm, e una build ancorata a quella versione, su un client datato che esegue ancora gli script di installazione, continua a eseguire il payload. Nel momento in cui la 8.15.0 ha raggiunto la cima della lista versioni, i segreti su ogni macchina che aveva già eseguito la 8.14.0 erano già compromessi.Indicatori di compromissionePacchetto malevolo: jscrambler@8.14.0 SHA-256 dei file aggiunti e dei payload decompressi: dist/setup.js: a742de963f14a92d24ebcbc7b44ac867e23a20d31d1b0094a13a4f83287f4e60 dist/intro.js: a41a523ef9517aab37ed6eea0ec881821bdcb7aefcb5c5f603adc7907f868c86 Payload Linux: fbbcf4d8f98168f78f5c0c47a9ae56d59ec8ac84a7c9ca6b797fedfb8d62d2bd Payload Windows: b7ca95d1b23c8e67416a25cedf741de0917c2096bbc9d24649eea7853d054903 Payload macOS: c8fd47d36bdf7c825378593ab82ed8c24d1dc52e26b507812393e24e1d5201fd Endpoint di rete osservati a runtime (StepSecurity): C2 IP: 37.27.122[.]124 C2 IP: 57.128.246[.]79 Infrastruttura Tor: check.torproject[.]org, archive.torproject[.]org Artefatti on-host: File nascosto con nome casuale nella directory temp di sistema (.{random}, o .{random}.exe su Windows) Task pianificato nascosto su Windows / LaunchAgent su macOS per la persistenzaFonti: Socket.dev, StepSecurity, SafeDep.