#cyberwar

Alle 2:20 del mattino di martedì 28 luglio, poche ore prima che le azioni di Unitel iniziassero a essere scambiate sulla borsa di Luanda nella più grande IPO della storia angolana, i sistemi core del principale operatore di telecomunicazioni del paese sono andati in tilt. Voce, dati mobili e connettività internet si sono fermati per oltre 21 milioni di persone, quasi metà della popolazione dell’Angola. La tempistica, quasi chirurgica, ha subito sollevato una domanda che l’azienda stessa non ha escluso: è stato un sabotaggio pensato per far deragliare la quotazione?

Un blackout nazionale nelle 24 ore che contavano di piùUnitel, ex monopolista statale passato sotto controllo pubblico nel 2022 dopo il sequestro delle quote un tempo detenute da Isabel dos Santos, figlia dell’ex presidente José Eduardo dos Santos, ha dichiarato di aver rilevato l’incidente attorno alle 2:20 locali del 28 luglio e di aver attivato “immediatamente” i protocolli di risposta e contenimento. Il ripristino graduale dei servizi mobili è iniziato solo alle 11:45 del giorno successivo, provincia per provincia, con gli SMS rimasti fuori uso più a lungo di voce e dati. Le infrastrutture fisse su fibra e wireless, che servono istituzioni pubbliche e aziende, sono invece rimaste operative per tutta la durata dell’incidente, un dettaglio che suggerisce un impatto concentrato sui sistemi core mobili piuttosto che su un evento di disponibilità generalizzato.

Il dato più interessante arriva dalla telemetria di rete, non dai comunicati aziendali. Recorded Future News ha verificato che i prefissi IP di Unitel sono rimasti annunciati su internet per tutta la durata dell’incidente: i router che connettono l’operatore al resto della rete globale non sono mai andati offline, come invece accadrebbe in un classico taglio di connettività a monte o in un attacco DDoS volumetrico. Il traffico misurato da Cloudflare Radar mostra invece un crollo netto proprio nella finestra dell’attacco, confinato esclusivamente a Unitel mentre gli altri operatori angolani non hanno mostrato alcun degrado. La lettura più plausibile è quella di un incidente che ha disabilitato sistemi interni critici — probabilmente elementi core della rete mobile o piattaforme di autenticazione/billing — piuttosto che un attacco alla connettività esterna.

Il contesto: una IPO da record e un sospetto legittimoL’attacco è arrivato meno di 24 ore prima del debutto di Unitel alla BODIVA, la borsa angolana, nell’ambito del programma di privatizzazioni del presidente João Lourenço volto a ridurre il peso dello stato nell’economia post-marxista del paese. L’offerta, gestita dall’istituto statale di gestione patrimoniale IGAPE per una quota del 15%, è stata sottoscritta oltre il 120%, con più di 11.000 investitori coinvolti: un test di appetito del mercato per gli asset statali angolani, considerato un possibile precursore per la futura quotazione della compagnia petrolifera nazionale Sonangol. Nonostante il blackout in corso, la negoziazione è comunque partita mercoledì, valutando la società 2,14 miliardi di dollari e raccogliendo circa 321 milioni per le casse pubbliche.

Unitel stessa ha dichiarato di non poter escludere che l’attacco fosse “deliberato e mirato”, proprio a causa della coincidenza con l’avvio delle negoziazioni azionarie. Nessun gruppo ha rivendicato la responsabilità, e non ci sono conferme pubbliche su esfiltrazione di dati o impiego di ransomware. Un elemento di contesto rilevante: settimane prima dell’incidente, il collettivo “CyberTeam” — coinvolto in un attacco contro l’Assemblea Nazionale angolana — aveva lasciato intendere che Unitel potesse essere il bersaglio successivo, sebbene al momento non vi sia alcuna prova che leghi quel gruppo all’incidente di luglio. L’interruzione ha avuto ricadute anche sull’economia reale: i terminali POS collegati alla rete Unitel hanno smesso di funzionare, colpendo pagamenti digitali e comunicazioni aziendali in un paese dove la penetrazione mobile è lo scheletro portante dei servizi finanziari.

Perché conta per chi guarda alla sicurezza delle telcoAl di là del singolo episodio, l’incidente Unitel è un caso di scuola su tre fronti che meritano attenzione da parte di chi si occupa di protezione delle infrastrutture critiche. Primo: la tempistica di un attacco può essere un’arma quanto il payload stesso. Colpire un operatore telco nelle ore immediatamente precedenti un evento finanziario ad alta visibilità massimizza il danno reputazionale e la pressione su chi deve decidere se procedere comunque con l’IPO, indipendentemente dalla natura tecnica dell’attacco. Secondo: la persistenza dei prefissi BGP durante l’intero blackout conferma ancora una volta che gli attacchi più dannosi contro le telco moderne non colpiscono più solo la disponibilità della rete di trasporto, ma i sistemi applicativi core — HLR/HSS, piattaforme di autenticazione, sistemi di billing — la cui compromissione può paralizzare i servizi senza mai far sparire l’infrastruttura di routing dai radar esterni. Terzo: la sequenza di ripristino, provincia per provincia e canale per canale (voce e dati prima, SMS dopo), suggerisce un lavoro di remediation selettivo su sistemi distinti piuttosto che un semplice riavvio, coerente con un incidente di sicurezza più che con un guasto tecnico diffuso.

Per i team di difesa delle telco, specialmente in mercati emergenti dove eventi di mercato ad alta visibilità (IPO, fusioni, aste di spettro) sono sempre più frequenti, il caso Unitel rafforza la necessità di considerare tali finestre temporali come periodi a rischio elevato, con controlli rafforzati su change management, accessi privilegiati ai sistemi core e monitoraggio della telemetria BGP/traffico in tempo reale per distinguere rapidamente un attacco interno da un problema di connettività esterna. Vale la pena notare che nessuna autorità di regolamentazione, né la BODIVA né l’authority dei mercati di capitale angolana, ha rilasciato dichiarazioni pubbliche sull’accaduto: un silenzio istituzionale che lascia molte domande aperte su attribuzione, impatto reale sui dati dei clienti ed eventuali richieste estorsive dietro le quinte.

Cosa manca ancora al quadroA oggi restano senza risposta le domande più rilevanti per una piena classificazione dell’incidente: quale vettore di accesso iniziale è stato usato, se ci sia stata esfiltrazione di dati dei 21 milioni di abbonati, e se dietro l’attacco ci sia un gruppo con motivazioni finanziarie, un attore hacktivista legato a tensioni politiche interne, oppure un operatore state-sponsored interessato a colpire la privatizzazione degli asset angolani. La vicenda merita un monitoraggio attento nelle prossime settimane, sia per eventuali rivendicazioni su forum underground sia per comunicazioni obbligatorie che Unitel, in quanto società ora quotata, dovrà rendere al mercato.

28 luglio, ore 2:20 locali: rilevamento dell’incidente sui sistemi core Unitel

28-29 luglio: interruzione totale di voce, dati mobili e SMS a livello nazionale; rete fissa non impattata

29 luglio, ore 11:45: avvio del ripristino graduale provincia per provincia

29 luglio: debutto di Unitel alla BODIVA nonostante l’incidente in corso, raccolta di circa 321 milioni di dollari

Nessuna rivendicazione pubblica, nessuna conferma di esfiltrazione dati al momento della pubblicazione

Non ha un sito web, non ha un catalogo prodotti pubblico, non ha nemmeno un’insegna. Eppure Guangdong Chanming Technology, una società con sede nel Guangdong praticamente invisibile su internet, avrebbe costruito e gestito per anni una delle infrastrutture di offuscamento più utilizzate dagli APT cinesi legati all’Esercito Popolare di Liberazione: la rete RedRelay, nota nella letteratura di threat intelligence occidentale anche come ORBWEAVER. A smascherarla è stato il collettivo di ricercatori indipendenti Intrusion Truth, che da oltre otto anni applica tecniche di OSINT per identificare le persone e le società dietro le operazioni di cyberspionaggio di Pechino.

Cos’è una ORB network e perché fa paura ai difensoriLe “Operational Relay Box” network, o ORB network, sono infrastrutture di proxy multi-hop costruite aggregando router domestici compromessi, VPS commerciali e dispositivi IoT, con l’obiettivo di far rimbalzare il traffico degli attaccanti attraverso molteplici salti prima di raggiungere il bersaglio finale. Google Mandiant e Microsoft le descrivono da anni come uno degli sviluppi più insidiosi nel tradecraft delle APT cinesi: a differenza di una singola VPN o di un bulletproof hosting, un ORB network cambia continuamente topologia, mescola traffico legittimo e malevolo sugli stessi nodi e rende quasi inutile il blocco per indirizzo IP, perché l’infrastruttura di oggi non è quella di domani. Gruppi come Volt Typhoon hanno già dimostrato quanto queste reti complichino l’attribuzione e la difesa perimetrale nelle infrastrutture critiche occidentali.

Da Free Connect a RedRelay: la genesi del progettoSecondo la ricostruzione di Intrusion Truth, RedRelay nasce come evoluzione di Free Connect (FCN), un tool VPN sviluppato in origine come progetto personale da Wang Huiping, oggi co-fondatore di Guangdong Chanming. Il codice, un tempo ospitato su GitHub sotto lo pseudonimo “boywhp”, è stato progressivamente trasformato in un prodotto commerciale a duplice uso: da un lato uno strumento di anonimizzazione generico, dall’altro un’infrastruttura su misura per operazioni offensive. I ricercatori sono risaliti a Wang incrociando un numero di telefono registrato su documenti societari con un indirizzo email legato al progetto FCN, un classico errore operativo che il collettivo sfrutta sistematicamente per deanonimizzare gli sviluppatori di tool “dual use” cinesi.

Sul piano tecnico, campioni VirusTotal riconducibili al dominio associato a FCN includono file identificati come stn.exe, mentre le versioni Linux del tool utilizzano un comando distintivo che ha condotto gli analisti a “bulbature”, un artefatto già associato in passato alla famiglia di malware WHIPWEAVE, anch’essa collegata all’ecosistema RedRelay/ORBWEAVER.

I brevetti che tradiscono lo scopo realeLa parte più interessante dell’indagine riguarda i brevetti e i copyright software depositati da Guangdong Chanming presso gli uffici cinesi competenti. Almeno due brevetti descrivono esplicitamente flussi di traffico anonimizzati e multi-hop coerenti con il comportamento osservato di RedRelay. Ma l’elenco dei prodotti registrati va ben oltre l’anonimizzazione: tra i titoli figurano un “Internet Security Access System”, un “Multi-functional Security Proxy”, un “Anti-traceability Network”, un sistema di “Network Vulnerability Testing”, un “Android Secret Extraction System” e, particolarmente rilevante, un “Telegram Data Collection System”. Si tratta di capacità che, cumulate, disegnano il profilo di un fornitore di strumenti di sorveglianza ed estrazione dati su misura per operazioni statali, non di un’azienda di cybersecurity difensiva come vorrebbe far credere l’assenza quasi totale di presenza pubblica.

Il cliente: non solo intelligence, ma anche poliziaGli elementi più sensibili emersi dall’indagine riguardano i clienti. Documenti di procurement riconducibili a canali dell’Esercito Popolare di Liberazione citano la fornitura da parte di Guangdong Chanming di un “Anonymous Network System” a un’unità di stanza nel distretto di Haidian, a Pechino, area storicamente associata alla PLA Cyberspace Force. Le analisi open source collegano inoltre l’uso di RedRelay a diversi cluster di cyberspionaggio cinese tracciati da anni dall’industria della threat intelligence sotto etichette come APT15, Ke3chang, Vixen Panda, Red Vulture, Playful Dragon e Nylon Typhoon, gruppi storicamente attivi contro ministeri degli esteri, ambasciate e contractor della difesa in Europa e Asia. Secondo Intrusion Truth, a queste attribuzioni si aggiungerebbero designazioni interne cinesi come l’Unità 61046 e l’VIII Ufficio del CSF (Cyberspace Force), sebbene questo livello di attribuzione resti – come sempre in questi casi – basato su indizi convergenti più che su prove dirette e verificabili da terzi.

Non meno significativo è che tra i clienti indicati compaia anche il Ministero della Pubblica Sicurezza, l’apparato che gestisce le forze di polizia cinesi: un dettaglio che conferma quanto il confine tra sorveglianza interna e cyberspionaggio esterno, nel modello cinese dei contractor privati “dual use”, sia ormai strutturalmente sfumato – lo stesso schema documentato in passato per fornitori come i900 e la galassia legata a APT41 e Silk Typhoon.

Due righe per i difensoriPer i team di detection, la lezione principale è che il blocklisting basato su indirizzi IP o su singoli domini è una difesa in costante ritardo contro le ORB network: RedRelay, come le altre infrastrutture simili, ruota continuamente nodi residenziali e commerciali compromessi. È più efficace investire in detection comportamentale (pattern di traffico anomali verso servizi di collaborazione, orari di attività non coerenti con l’utenza reale, fingerprint TLS associati a tool come FCN/stn), condivisione di intelligence tra organizzazioni sullo stesso settore e monitoraggio delle infrastrutture note collegate a WHIPWEAVE. Per le organizzazioni che gestiscono comunicazioni sensibili su Telegram o piattaforme simili, la conferma dell’esistenza di un “Telegram Data Collection System” commerciale cinese è un promemoria che l’app di messaggistica, da sola, non garantisce alcuna protezione dall’intelligence statale se l’endpoint o l’account è nel mirino.

Indicatori e riferimenti notiSocietà identificata: Guangdong Chanming Technology Co., Ltd.
Persona chiave: Wang Huiping (co-fondatore, ex sviluppatore progetto "Free Connect / FCN", GitHub handle "boywhp")
Infrastruttura: RedRelay (alias ORBWEAVER), ORB network multi-hop
Artefatti noti: stn.exe (Windows), comando distintivo Linux collegato a "bulbature"
Famiglia malware collegata: WHIPWEAVE
Prodotti brevettati/registrati: Internet Security Access System, Multi-functional Security Proxy,
Anti-traceability Network, Network Vulnerability Testing System, Android Secret Extraction System,
Telegram Data Collection System, File Transfer Network
Clienti riportati: unità PLA Cyberspace Force (distretto di Haidian, Pechino), Ministero della Pubblica Sicurezza
Gruppi APT collegati: APT15 / Ke3chang / Vixen Panda / Red Vulture / Playful Dragon / Nylon Typhoon
Designazioni interne citate: Unità 61046, VIII Ufficio CSFL’indagine di Intrusion Truth, pubblicata il 27 luglio 2026 e ripresa nei giorni successivi da Risky Business, GBHackers e altre testate di settore, si inserisce in un filone di ricerca ormai consolidato: dal caso i-Soon del 2024 alle rivelazioni su altri fornitori “fantasma” del ministero della Sicurezza di Stato, l’ecosistema dei contractor privati cinesi continua a produrre errori operativi sufficienti a far emergere, poco alla volta, l’architettura reale dietro le campagne di cyberspionaggio più persistenti contro obiettivi occidentali.

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"