(in)sicurezza digitale

2026-05-23 17:51:48

Whatsapp compromesso su iPhone, la ricerca di Forenser sullo 0-click

Una premessa prima di iniziare: se hai un iPhone con iOS inferiore a 16.7.12, aggiorna, è già tardi e un miracolo che non sia ancora successo niente di brutto.

Detto questo, per anni l’ecosistema Apple è stato raccontato come una fortezza quasi inespugnabile. “Se hai un iPhone sei al sicuro” è diventato uno dei mantra più ripetuti anche fuori dalla bolla tech. Poi arrivano casi come quello documentato da Forenser e improvvisamente quella narrativa inizia a incrinarsi. Non perché iPhone sia diventato improvvisamente insicuro, ma perché il punto debole — come spesso accade — non è il dispositivo in sé. È la catena completa: notifiche, sessioni, social engineering, bug, sincronizzazioni cloud e fiducia implicita dell’utente.

La ricerca pubblicata da Forenser fotografa infatti una serie di compromissioni WhatsApp osservate su dispositivi Apple rimasti fermi a iOS 16 (specificatamente sotto il famoso aggiornamento alla 16.7.12). Non si parla di semplici tentativi di phishing “artigianali”, ma di account effettivamente presi in controllo, con accessi alle chat e utilizzo dell’identità digitale delle vittime per colpire ulteriori contatti.

Le vittime, infatti, non riportano comportamenti compatibili con il classico phishing. Nessun link cliccato volontariamente, nessuna installazione di applicazioni sospette, nessun QR code scansionato deliberatamente, nessuna richiesta di OTP condivisi. Eppure gli account risultano violati.

È questo il dettaglio che ha acceso l’interesse della comunità forense.

Secondo quanto riportato nell’analisi di Forenser, gli utenti colpiti avrebbero ricevuto messaggi specifici poco prima della compromissione. Messaggi che, in alcuni casi, sembrano avere un comportamento anomalo lato client. La ricostruzione tecnica suggerisce che il vettore d’attacco possa sfruttare una vulnerabilità legata alla gestione dei contenuti ricevuti da WhatsApp su iOS 16, permettendo l’esecuzione di operazioni malevole senza necessità di interazione diretta dell’utente.

In altre parole: il semplice ricevere il messaggio potrebbe essere sufficiente ad attivare la catena di compromissione.

È questo il vero significato di 0-click. Nessun tap. Nessun consenso. Nessun comportamento “sbagliato” da parte della vittima.

Nel mondo mobile moderno, questo tipo di attacco rappresenta uno degli scenari più pericolosi in assoluto, perché elimina completamente il principale livello difensivo su cui si basa gran parte della sicurezza consumer: l’utente stesso. Le campagne di phishing tradizionali funzionano solo se qualcuno sbaglia. Gli exploit 0-click invece trasformano il dispositivo in un bersaglio passivo.

La ricerca di Forenser suggerisce inoltre un elemento fondamentale: il problema sembrerebbe concentrarsi su device ancora fermi a certe release superate di iOS 16. Questo potrebbe indicare la presenza di vulnerabilità già corrette nelle versioni successive di iOS, ma ancora sfruttabili sui terminali non aggiornati. Ed è qui che emerge uno dei problemi più sottovalutati dell’ecosistema Apple: l’idea che “se hai un iPhone allora sei automaticamente al sicuro”.

In realtà il modello di sicurezza Apple funziona in maniera estremamente efficace proprio grazie agli aggiornamenti continui. Restare bloccati su una major release precedente significa esporsi progressivamente a vulnerabilità già note, studiate e potenzialmente weaponizzate.

Dal punto di vista operativo, un attacco del genere è devastante perché estremamente difficile da rilevare. Non lascia i classici indicatori di compromissione associati al malware tradizionale. Non rallenta necessariamente il dispositivo. Non mostra finestre sospette. Non installa applicazioni visibili. Tutto avviene all’interno di una superficie software considerata “trusted”: l’app di messaggistica stessa.

E WhatsApp rappresenta un bersaglio ideale.

Dentro quell’applicazione oggi transitano conversazioni personali, documenti, codici OTP, messaggi vocali, relazioni professionali e spesso persino elementi di autenticazione indiretta per servizi bancari o aziendali. Compromettere WhatsApp non significa più soltanto leggere chat private: significa ottenere accesso a una porzione enorme dell’identità digitale della vittima.

L’aspetto forse più interessante dell’indagine di Forenser è che porta l’attenzione su una categoria di minacce spesso percepite come lontane dal mondo reale. Quando si parla di exploit 0-click si pensa immediatamente ad attori statali, intelligence offensive e spyware da milioni di euro. Ma la linea che separa il cyberespionage dal cybercrime si sta assottigliando sempre di più. Tecniche un tempo esclusive delle operazioni governative iniziano lentamente a comparire anche in scenari meno sofisticati.

Ed è esattamente questo a rendere il caso così importante.

Perché al netto dei dettagli tecnici ancora da chiarire completamente, la ricerca di Forenser mostra un cambiamento preciso nel panorama delle minacce mobile: gli smartphone non vengono più attaccati soltanto inducendo l’utente a commettere errori. Sempre più spesso, basta semplicemente raggiungerli.

Account WhatsApp compromessi su iPhone con iOS 16: l’attacco 0click che bypassa i dispositivi collegati - Forenser Srl

Un weekend tranquillo, di fine maggio: il tempo passa senza problemi fino a quando non iniziano ad arrivare messaggi ambigui sull’applicazione di WhatsApp

^{forenser (Forenser Srl)}

(in)sicurezza digitale

2026-05-23 06:55:44

Showboat e JFMBackdoor: il gruppo cinese Calypso spia le telecomunicazioni del Medio Oriente con malware Linux e Windows

I ricercatori di Lumen Technologies Black Lotus Labs hanno pubblicato il 21 maggio 2026 un’analisi dettagliata di due nuovi strumenti malevoli — Showboat (Linux) e JFMBackdoor (Windows) — impiegati in campagne di cyberspionaggio attribuite con moderata confidenza al gruppo cinese Calypso, noto anche come Red Lamassu. I bersagli: operatori di telecomunicazioni nel Medio Oriente, nell’Asia Pacifica e, più recentemente, entità negli Stati Uniti e in Ucraina.

Chi è Calypso / Red Lamassu

Calypso è un gruppo APT di matrice cinese attivo almeno dal 2018, storicamente orientato allo spionaggio su governi, settore energetico e telecomunicazioni in Asia Centrale e Medio Oriente. Il gruppo condivide infrastrutture e tooling con altri cluster affiliati alla Cina, in linea con il modello del cosiddetto digital quartermaster: una struttura centralizzata che rifornisce più gruppi APT di strumenti comuni come PlugX, ShadowPad e, ora, Showboat. Questa logica di condivisione complica l’attribuzione e amplifica la portata operativa.

Showboat: un framework post-exploitation modulare per Linux

Il punto di partenza dell’indagine è stato un binario ELF caricato su VirusTotal nel maggio 2025, inizialmente classificato come backdoor Linux sofisticato con capacità rootkit (Kaspersky lo traccia come EvaRAT). Showboat è progettato per sistemi Linux con un insieme di capacità modulari orientate alla persistenza silenziosa e al movimento laterale: shell remota per l’esecuzione di comandi arbitrari, trasferimento file bidirezionale, proxy SOCKS5 per il tunneling verso sistemi interni non esposti su internet, raccolta di informazioni di sistema, nascondimento dei processi dalla lista dei processi attivi, e recupero di payload da Pastebin (paste creato l’11 gennaio 2022) — tecnica che frammenta la kill chain su piattaforme legittime per eludere il rilevamento.

Il malware comunica con il server C2 trasmettendo informazioni di sistema in un campo PNG come stringa cifrata in Base64. La funzione proxy SOCKS5 è particolarmente significativa: consente agli attaccanti di interagire con macchine raggiungibili solo via LAN, espandendo silenziosamente il perimetro di compromissione verso asset interni critici.

JFMBackdoor: un impianto Windows a pieno spettro

A fianco di Showboat, i ricercatori hanno identificato JFMBackdoor, un impianto Windows distribuito tramite DLL side-loading. Si tratta di un RAT completo con accesso shell remoto, operazioni su file (upload, download, eliminazione), network proxying, cattura di screenshot e auto-rimozione (self-removal) per cancellare le tracce post-operazione. Il vettore DLL side-loading è un classico dei toolkit cinesi: consente di agganciare un processo legittimo per l’esecuzione del codice malevolo, riducendo la visibilità per le soluzioni EDR.

Vittime identificate e infrastruttura C2

L’analisi infrastrutturale ha rilevato le seguenti compromissioni: un provider di telecomunicazioni nel Medio Oriente (vittima principale, bersagliata almeno dal 2022), un ISP in Afghanistan, un’entità in Azerbaigian, due possibili compromissioni negli Stati Uniti e una in Ucraina, identificate tramite un cluster C2 secondario che condivide certificati X.509 con quello primario.

I nodi C2 mostrano correlazioni geografiche con indirizzi IP geolocalizzati a Chengdu, capoluogo della provincia del Sichuan — area già associata ad operazioni APT cinesi come quelle di APT41. La presenza di infrastruttura condivisa con altri cluster cinesi, tramite certificati e pattern C2 analoghi, rinforza l’ipotesi del digital quartermaster. Il gruppo ha registrato domini tematici che impersonano operatori telecom per rendere il traffico C2 meno sospetto.

Perché le telco sono obiettivi privilegiati dello spionaggio cinese

Le infrastrutture di telecomunicazione rappresentano un obiettivo di primaria importanza per le operazioni di intelligence offensiva. Il controllo, anche parziale, di un operatore telecom offre accesso a metadati di traffico, possibilità di intercettazioni mirate, informazioni su clienti governativi e aziendali, e capacità di prepararsi per operazioni disruptive in scenari di escalation geopolitica. Non è un caso che Showboat sia progettato specificatamente per Linux: i sistemi basati su questo OS costituiscono il backbone infrastrutturale della maggior parte delle telco mondiali. La funzione SOCKS5 rispecchia un obiettivo preciso: muoversi lateralmente e silenziosamente all’interno di reti segmentate, raggiungendo asset normalmente inaccessibili dall’esterno.

Indicatori di compromissione (IoC)

# Showboat - ELF binary (VirusTotal, maggio 2025)
SHA256: d6a4fad5448838dbc8cc6b33f1dbfbdc7a2fad36de58ff6a66dce96f729f7011
# Kaspersky classification: EvaRAT
# C2 infrastructure: IP geolocati a Chengdu (Sichuan, CN)
# Certificati X.509 condivisi tra cluster C2 primario e secondario
# Domini: pattern telecom-themed (impersonazione operatori target)
# Pastebin paste ID: creato 2022-01-11 (autoconcealment snippet)

Due righe per i difensori

Per le organizzazioni del settore telecomunicazioni e infrastrutture critiche, i ricercatori di Black Lotus Labs raccomandano: monitorare il traffico in uscita verso Pastebin e piattaforme di condivisione testo per rilevare scaricamenti di payload; analizzare le connessioni SOCKS5 anomale verso host interni non esposti; verificare l’integrità dei processi su sistemi Linux alla ricerca di tecniche di process hiding; implementare threat hunting specifico per DLL side-loading su endpoint Windows; correlare i certificati X.509 dei server C2 con quelli osservati da Black Lotus Labs. Come ha sottolineato il ricercatore Danny Adamitis: “La presenza di tali minacce dovrebbe essere interpretata come un segnale d’allarme precoce, indicativo di problemi di sicurezza potenzialmente più gravi e diffusi all’interno delle reti compromesse.”

(in)sicurezza digitale

2026-05-22 20:24:33

L’uscita di Tulsi Gabbard dall’intelligence USA e gli scenari di sicurezza nazionale

Le dimissioni di Tulsi Gabbard dalla guida dell’intelligence americana non sono più soltanto indiscrezioni filtrate da ambienti politici di Washington. Dopo ore di speculazioni, la conferma è arrivata direttamente tramite Fox News e successive dichiarazioni ufficiali della Casa Bianca: Gabbard lascerà il ruolo di Director of National Intelligence il 30 giugno 2026.

Nella lettera inviata al presidente Donald Trump, Gabbard ha motivato la decisione con il peggioramento delle condizioni di salute del marito, Abraham Williams, recentemente diagnosticato con una rara forma di tumore osseo. La direttrice dell’intelligence ha scritto di non poter “in coscienza” lasciarlo affrontare da solo la malattia mentre continua a ricoprire un incarico tanto invasivo e operativo.

Formalmente, quindi, la narrativa ufficiale parla di una scelta personale e familiare. Ma le fonti interne all’amministrazione raccontano uno scenario molto più complesso. Diversi insider citati dalla stampa americana sostengono infatti che Gabbard fosse ormai considerata politicamente isolata all’interno dell’apparato Trump e che la Casa Bianca stesse già valutando da tempo una sua sostituzione.

Secondo le ricostruzioni emerse nelle ultime settimane, il rapporto con Trump si sarebbe deteriorato progressivamente dopo una serie di contrasti su Iran, operazioni di sicurezza nazionale e gestione delle valutazioni intelligence. Uno degli episodi più delicati riguarda proprio le analisi sull’Iran: Gabbard aveva dichiarato davanti al Senato che non esistevano prove concrete di una ripresa del programma nucleare iraniano, entrando indirettamente in collisione con la linea più aggressiva sostenuta dall’amministrazione.

Da quel momento, il suo peso operativo sarebbe diminuito rapidamente. Secondo varie fonti, Gabbard sarebbe stata esclusa da alcuni briefing strategici sensibili e marginalizzata nelle decisioni relative alle operazioni internazionali. Parallelamente, all’interno della Casa Bianca cresceva la convinzione che il DNI non fosse più pienamente allineato alla postura politica dell’amministrazione Trump.

La dinamica con cui la notizia è emersa è particolarmente significativa. Prima ancora dell’annuncio ufficiale, numerosi leak avevano iniziato a circolare verso media statunitensi vicini agli ambienti governativi, descrivendo Gabbard come una figura in uscita già da settimane. In ambienti intelligence questo tipo di comunicazione viene spesso interpretato come una pressione politica indiretta: rendere pubblica una possibile sostituzione serve a indebolire ulteriormente il funzionario interessato e preparare il terreno alla transizione.

Trump ha pubblicamente elogiato il lavoro di Gabbard, definendola una figura che ha svolto “un grande lavoro” alla guida dell’intelligence americana, ma contemporaneamente ha annunciato immediatamente il nome del sostituto ad interim: Aaron Lukas.

Ed è proprio questo passaggio a essere particolarmente rilevante per chi osserva il settore intelligence e cybersecurity. Aaron Lukas non arriva dall’esterno ma dall’apparato interno dell’ODNI, dove ricopriva il ruolo di Principal Deputy Director of National Intelligence dal 2025. La scelta di una figura già integrata nella struttura suggerisce la volontà della Casa Bianca di evitare ulteriori scossoni in una fase estremamente delicata sul piano geopolitico e cyber.

La successione avviene infatti mentre gli Stati Uniti stanno affrontando una delle fasi più aggressive degli ultimi anni sul fronte cyber-intelligence: campagne APT attribuite a Cina, operazioni ibride riconducibili a Iran, tensioni crescenti con Russia e un ecosistema ransomware sempre più vicino a logiche di destabilizzazione geopolitica.

In questo contesto, il problema non è soltanto il cambio di leadership. Il vero nodo riguarda ciò che emerge dietro le dimissioni: una frattura sempre più evidente tra vertice politico e comunità intelligence americana. E quando questo accade negli Stati Uniti, le conseguenze raramente restano interne a Washington.

(in)sicurezza digitale

2026-05-22 09:52:16

“Patchato” non significa protetto: attaccanti bypassano l’MFA sui VPN SonicWall Gen6 e raggiungono i file server in 30 minuti

Si parla di:
Toggle

C’è una categoria di vulnerabilità particolarmente insidiosa: quella delle patch che non funzionano perché nessuno ha seguito tutte le istruzioni. È esattamente quello che sta accadendo con i dispositivi SonicWall Gen6 SSL-VPN e CVE-2024-12802, con intrusioni ransomware già documentate in ambienti multipli tra febbraio e maggio 2026.

Il problema: patch firmware vs. rimedio reale

CVE-2024-12802 è una vulnerabilità di authentication bypass nelle appliance SonicWall SSL-VPN. La radice del problema sta in come SonicWall gestisce due diversi formati di login Active Directory: UPN (User Principal Name, il formato simile a un indirizzo email) e SAM (Security Account Manager, il formato legacy). L’enforcement dell’MFA è applicato indipendentemente a ciascun formato di login, non all’identità utente sottostante.

Un attaccante che conosce credenziali valide può autenticarsi usando il percorso UPN anche quando l’MFA è configurata, perché l’enforcement specifico per quel percorso è assente. L’aggiornamento firmware corregge la gestione delle sessioni, ma non rimuove la configurazione LDAP preesistente che consente il bypass. Come spiega ReliaQuest nel loro report: “Patching the firmware doesn’t remove the existing LDAP configuration that allows the bypass; the vulnerable configuration remains in place.”

La rimediazione completa richiede sei passaggi manuali aggiuntivi documentati nel security advisory SNWLID-2025-0001 di SonicWall: cancellare completamente la configurazione LDAP esistente e ricrearla senza il formato userPrincipalName su cui fa leva l’exploit. I workflow standard di patch management non sono progettati per verificare passi di riconfigurazione manuale — la versione firmware viene aggiornata, il controllo versione passa, il dispositivo sembra protetto. Non lo è.

L’exploitation osservata: dalla VPN al file server in 30 minuti

Tra febbraio e marzo 2026, i ricercatori di ReliaQuest hanno documentato quella che valutano come la prima exploitation in-the-wild di CVE-2024-12802 in ambienti multipli. Il pattern di intrusione osservato è stato consistente tra gli incidenti: gli attaccanti eseguono brute force delle credenziali VPN, bypassano l’MFA usando il percorso UPN vulnerabile, e si muovono rapidamente all’interno delle reti.

In alcuni casi, bastano 13 tentativi di brute force per ottenere credenziali valide. In un incidente specifico documentato da ReliaQuest, l’attaccante è passato dall’accesso VPN iniziale a un file server domain-joined, stabilendo una connessione RDP con una password locale condivisa di amministratore, in meno di trenta minuti.

Il comportamento post-compromissione è rivelatorio: dopo aver stabilito il foothold iniziale, l’attaccante ha tentato di distribuire un Cobalt Strike beacon per command-and-control e ha cercato di caricare un driver vulnerabile — probabilmente tramite la tecnica Bring Your Own Vulnerable Driver (BYOVD) per neutralizzare la protezione endpoint. L’EDR presente ha bloccato entrambi i tentativi. Ma l’attaccante si è disconnesso deliberatamente, è tornato giorni dopo usando account diversi, e ha ripetuto il pattern — comportamento più coerente con un initial access broker che valuta il valore della vittima che con un gruppo ransomware in fase di esecuzione immediata.

Il problema dei log: l’MFA sembra funzionare quando non funziona

Una delle caratteristiche più pericolose di questo attacco è il modo in cui appare nei log. Come riportano i ricercatori di ReliaQuest: “The rogue login attempts observed in the investigated incidents still appeared as a normal MFA flow in logs, leading defenders to believe that MFA worked even when it failed.”

Il segnale chiave da cercare nei log di autenticazione VPN è il valore sess="CLI", che indica autenticazione VPN scriptata o automatizzata. La maggior parte delle organizzazioni non monitora attivamente questo campo. I numeri di evento 238 e 1080 sono ulteriori indicatori da inserire nelle regole di alerting.

Dispositivi affetti e stato di fine vita

La vulnerabilità è specifica all’hardware Gen6, che include i modelli NSa 2700, NSa 3700, NSa 4700, NSa 5700 e NSa 6700 con firmware SonicOS 7.0 attraverso 7.1.1. Questo rappresenta un ulteriore problema: i dispositivi Gen6 hanno raggiunto il fine vita il 16 aprile 2026 e non ricevono più aggiornamenti di sicurezza.

Per i dispositivi Gen7 e Gen8, la situazione è diversa: gli aggiornamenti firmware alle versioni 7.2.0-7015 e 8.0.1-8017 incorporano già i passi di rimediazione descritti nell’advisory, e dopo l’upgrade è nuovamente supportato l’uso di userPrincipalName nelle configurazioni LDAP. Il problema è esclusivo al parco installato Gen6.

I settori più colpiti nei casi documentati includono servizi finanziari, sanità e manifatturiero, suggerendo un threat actor con conoscenza specifica del settore e obiettivi di alto valore economico.

Indicatori di compromissione e detection

# LOG INDICATORS (SonicWall SSL-VPN authentication logs)
sess="CLI"          # Autenticazione VPN automatizzata/scriptata - indicatore chiave
Event ID 238        # Evento da monitorare in correlazione con sess=CLI
Event ID 1080       # Evento da monitorare in correlazione con sess=CLI

# BEHAVIORAL INDICATORS
- Accessi VPN da IP appartenenti a VPS o infrastruttura VPN
- Autenticazioni UPN riuscite per account con MFA configurata
- Brute force con numero basso di tentativi (anche solo 13)
- RDP da sistemi interni verso file server entro 30 minuti dall'accesso VPN
- Installazione di Cobalt Strike beacon post-compromissione
- Tentativi di caricamento driver vulnerabili (BYOVD)

# CVE
CVE-2024-12802 - SonicWall SSL-VPN Authentication Bypass (MFA bypass via UPN path)
Advisory: SNWLID-2025-0001

Due righe per i difensori

• Verifica rimediazione completa: Non basta che il firmware sia aggiornato. Seguire tutti e sei i passaggi manuali dell’advisory SNWLID-2025-0001 di SonicWall — questo include cancellare e ricreare la configurazione LDAP senza userPrincipalName.
• Caccia retroattiva nei log: Cercare sess="CLI" nei log di autenticazione VPN degli ultimi mesi. Se presente insieme ad autenticazioni “riuscite” per account con MFA attiva, la protezione potrebbe essere stata bypassata in precedenza.
• Migrazione Gen6: Considerare la migrazione urgente da Gen6 a Gen7/Gen8, dato il fine vita raggiunto ad aprile 2026. Non ci saranno patch per vulnerabilità future su questo hardware.
• Monitoraggio accessi VPN da range anomali: Alerting su login VPN originati da IP di VPS provider o range VPN, specialmente per account con MFA configurata.
• Correlazione eventi 238 e 1080: Aggiungere questi event ID alle regole SIEM in correlazione con il campo sess=”CLI”.
• Revisione LDAP: Verificare che la configurazione LDAP attiva non contenga userPrincipalName come formato di lookup.

Il takeaway più importante di questa vicenda non è tecnico, ma procedurale: i workflow di patch management standard non sono progettati per verificare passi di riconfigurazione manuale. Una patch applicata non è necessariamente una vulnerabilità chiusa. In contesti di sicurezza perimetrale, questo principio va internalizzato nei processi di verifica post-patch.

(in)sicurezza digitale

2026-05-22 10:18:34

Una riunione urgente su Teams e il conto svuotato: la nuova truffa che sfrutta il panico da videocall

C’è un dettaglio interessante nelle nuove campagne cyber che stanno circolando nelle ultime ore: non cercano più di sembrare sofisticate. Cercano di sembrare normali.

Una notifica su Microsoft Teams.

Un collega che chiede supporto.

Una call urgente prima di una riunione.

E pochi minuti dopo, credenziali rubate, malware installato o conti aziendali compromessi.

Tra le notizie emerse nelle ultime ore nel panorama cybersecurity internazionale, una delle più interessanti riguarda proprio una nuova ondata di attacchi che sfruttano Microsoft Teams come leva di social engineering. Il punto centrale non è tanto la tecnica utilizzata dai criminali, quanto il modo in cui stanno cambiando le abitudini delle vittime.

Per anni il phishing è stato associato a email sospette, allegati strani e messaggi scritti male. Oggi invece gli attaccanti stanno puntando sempre di più sugli strumenti di lavoro quotidiani: Teams, Zoom, Slack, Google Meet.

Perché funzionano.

E soprattutto perché in molte aziende le persone vivono ormai in uno stato costante di urgenza digitale.

La dinamica osservata nelle campagne più recenti è piuttosto semplice. La vittima riceve un messaggio Teams apparentemente legittimo, spesso collegato a un meeting imminente o a un problema tecnico. In alcuni casi viene chiesto di aprire un file condiviso, installare un aggiornamento, autenticarsi nuovamente oppure partecipare rapidamente a una videocall.

Tutto appare plausibile.

È proprio questo il punto.

I criminali non stanno cercando di violare firewall o bypassare vulnerabilità sofisticate. Stanno sfruttando la pressione psicologica tipica dell’ambiente lavorativo moderno.

Una notifica improvvisa durante una giornata piena di call.

Una richiesta urgente del reparto IT.

Un manager che scrive “mi serve subito”.

Nel contesto giusto, il cervello smette di analizzare e inizia semplicemente a reagire.

È questa la vera evoluzione del social engineering nel 2026: attacchi costruiti attorno ai comportamenti umani più che attorno alle vulnerabilità tecniche.

Le piattaforme collaborative sono diventate perfette per questo tipo di operazioni. A differenza delle email tradizionali, gli strumenti di messaggistica aziendale trasmettono automaticamente un senso di fiducia maggiore. Se un messaggio arriva su Teams, molti utenti tendono inconsciamente a considerarlo “interno”, quindi sicuro.

Ed è qui che i criminali stanno trovando spazio.

In diversi scenari osservati negli ultimi mesi, gli attaccanti utilizzano account compromessi reali per avviare conversazioni credibili con dipendenti dell’azienda. In altri casi sfruttano tenant esterni, nickname aziendali o identità molto simili a quelle originali.

L’obiettivo può cambiare.

A volte si tratta di furto credenziali.

Altre volte di installare malware.

In alcuni casi ancora più critici, gli attacchi servono come porta iniziale per intrusioni ransomware.

Ed è qui che il problema smette di essere “solo IT”.

Perché queste campagne funzionano esattamente come funzionano le truffe telefoniche contro gli anziani o le frodi sentimentali online: sfruttano fiducia, fretta e manipolazione emotiva.

La tecnologia cambia.

La psicologia umana molto meno.

Negli ambienti enterprise moderni esiste ormai una pressione costante alla reperibilità immediata. Rispondere velocemente è diventato quasi un obbligo culturale. Ed è proprio questa dinamica che rende strumenti come Teams particolarmente pericolosi dal punto di vista del social engineering.

Un’email può essere ignorata.

Una notifica Teams durante l’orario lavorativo no.

Anche perché spesso compare direttamente sul desktop, interrompe altre attività e arriva mentre l’utente sta già gestendo decine di conversazioni contemporaneamente.

In pratica il cybercrime sta imparando a inserirsi perfettamente nei micro-momenti di distrazione.

Ed è probabilmente questa la parte più inquietante.

Non serve più creare una finta pagina perfetta o un malware invisibile. Basta convincere una persona stanca, stressata o distratta a cliccare nel momento giusto.

Per questo motivo le aziende stanno iniziando a rivedere anche la formazione interna. Le classiche campagne anti-phishing basate solo sulle email non bastano più. Oggi il social engineering passa attraverso chat aziendali, videochiamate, sistemi di collaborazione e perfino notifiche push.

La vera sfida della cybersecurity moderna non è soltanto proteggere le infrastrutture.

È proteggere l’attenzione umana.

E in un mondo dove lavoriamo continuamente dentro piattaforme collaborative, distinguere una richiesta autentica da una manipolazione sta diventando sempre più difficile.

Fake Microsoft Teams Campaign Delivers ValleyRAT via NSIS Installer and DLL Sideloading

We came across fake Microsoft Teams distribution sites, shared on X platform back in mid April. The websites closely mimic […]

^{Srinivasan E (K7 Labs)}

(in)sicurezza digitale

2026-05-21 17:14:57

TeamPCP viola GitHub dall’interno: 3.800 repository sottratti in 18 minuti tramite un’estensione VS Code malevola

18 minuti. È il tempo in cui una versione trojanizzata dell’estensione VS Code Nx Console (nrwl.angular-console) è rimasta disponibile sul Visual Studio Marketplace il 18 maggio 2026. Un lasso di tempo apparentemente irrisorio, ma sufficiente perché il gruppo criminale TeamPCP compromettesse il device di almeno un dipendente GitHub e sottraesse circa 3.800 repository interni — uno degli incidenti di supply chain più gravi dell’anno sul piano dell’impatto sistemico.

Il contesto: TeamPCP e la catena TanStack

Per capire la violazione di GitHub è necessario risalire di dieci giorni. L’11 maggio 2026, TeamPCP aveva già pubblicato 84 artifact npm malevoli distribuiti su 42 pacchetti nel namespace TanStack — uno degli ecosistemi più adottati per il web development con React. Quell’operazione, che il sito ha seguito nelle settimane precedenti nella campagna Mini Shai-Hulud, aveva come obiettivo la compromissione a cascata di developer tramite dipendenze malevole che esfiltravano credenziali e token durante l’installazione.

TeamPCP ha guadagnato notorietà rapidamente come attore specializzato negli attacchi alla developer trust surface: non attacca i sistemi delle vittime direttamente, ma compromette la catena di strumenti e dipendenze su cui i developer si fidano implicitamente ogni giorno. L’attacco TanStack era già sufficientemente grave da soli — ma era anche il setup per qualcosa di più ambizioso.

Il vettore: Nx Console 18.95.0

Nx Console (nrwl.angular-console) è un’estensione VS Code con 2,2 milioni di installazioni e lo status di verified publisher — la certificazione più alta che Microsoft assegna agli editori sul marketplace. Questa combinazione di popolarità e fiducia istituzionale ne fa un bersaglio di enorme valore per un attore supply chain.

Il team di Nx ha successivamente ricostruito la catena causale: uno dei propri developer era stato precedentemente compromesso nel contesto dell’attacco a TanStack. Le sue credenziali GitHub erano trapelate, permettendo a TeamPCP di accedere al repository dell’estensione, modificare il codice, e pubblicare la versione 18.95.0 — quella avvelenata. Il meccanismo era semplice ma letale: non appena un developer apriva qualsiasi workspace in VS Code con l’estensione installata, il malware iniziava a raccogliere silenziosamente le credenziali memorizzate nel sistema.

La timeline dell’attacco

• 11 maggio 2026 — TeamPCP pubblica 84 pacchetti npm malevoli nel namespace TanStack; un developer Nx viene compromesso
• 18 maggio 2026, 12:30 UTC — Nx Console 18.95.0 (versione backdoor) appare sul VS Code Marketplace
• 18 maggio 2026, 12:48 UTC — La versione malevola viene rimossa dal Marketplace (18 minuti di esposizione)
• 18 maggio 2026, ~13:06 UTC — Rimossa da Open VSX (36 minuti totali di esposizione)
• 20 maggio 2026 — GitHub conferma la violazione: circa 3.800 repository interni esfiltrati, avvio rotazione di tutti i secret esposti

L’impatto: 3.800 repository interni di GitHub

GitHub ha confermato la sottrazione di circa 3.800 repository interni a opera di TeamPCP. L’azienda ha proceduto immediatamente alla rotazione di tutti i secret potenzialmente esposti. Non è ancora stato reso noto se i repository contengano codice relativo alla piattaforma github.com stessa, strumenti interni, infrastrutture di supporto o documentazione riservata — ma la sola portata numerica dell’esfiltrazione suggerisce un accesso profondo all’ecosistema di sviluppo interno di Microsoft GitHub. L’incidente ha colpito anche Grafana, compromessa attraverso un percorso diverso ma sempre legato alla catena TanStack.

Perché questo attacco è strutturalmente diverso

A differenza dei classici attacchi alla supply chain che operano a livello di package manager (npm, PyPI), questo incidente colpisce il layer dell’IDE — la superficie più prossima al developer e quella con i privilegi di accesso più ampi. Un’estensione VS Code non è un pacchetto passivo: ha accesso al filesystem locale, alle variabili d’ambiente di sistema, ai token Git memorizzati, alle chiavi SSH, ai file di configurazione cloud e all’intera sessione di sviluppo attiva.

Un’estensione verified con milioni di installazioni diventa, una volta compromessa, un vettore di distribuzione quasi impossibile da bloccare con le tradizionali difese perimetrali. La maggior parte degli endpoint detection agent non monitora il comportamento delle estensioni IDE con la stessa granularità con cui monitora i processi di sistema — un gap che TeamPCP ha sfruttato con precisione chirurgica.

Indicatori di compromissione (IoC)

# TeamPCP - GitHub Breach via Nx Console - IoC (maggio 2026)
# Estensione malevola
EXTENSION: nrwl.angular-console (Nx Console) versione 18.95.0
MARKETPLACE: Visual Studio Code Marketplace
TIMEFRAME: 2026-05-18 12:30–12:48 UTC (VS Code Marketplace)
TIMEFRAME: 2026-05-18 12:30–13:06 UTC (Open VSX)
# Infrastruttura TeamPCP documentata
DOMAIN: t.m-kosche.com (infra C2 TeamPCP)
# Campagne correlate
CAMPAIGN: Mini Shai-Hulud (npm/PyPI, 160+ pacchetti)
CAMPAIGN: TanStack supply chain (84 artifact npm su 42 pacchetti, 2026-05-11)
# Possibili alias
ACTOR: TeamPCP
ACTOR_ALIAS: UNC6780 (attribuzione parziale)
# Azione raccomandata
ACTION: Verificare estensioni VS Code installate nel periodo 2026-05-11/20
ACTION: Ruotare tutti i token GitHub/credential store sui sistemi degli sviluppatori

Due righe per i difensori

L’incidente impone una revisione urgente della postura di sicurezza degli ambienti di sviluppo. I team di sicurezza dovrebbero verificare immediatamente se l’estensione Nx Console 18.95.0 è stata installata su device aziendali nel periodo 11–20 maggio 2026, e in caso affermativo avviare la rotazione di tutte le credenziali presenti sui sistemi coinvolti — token GitHub, chiavi SSH, credenziali cloud, certificati. È fondamentale estendere il monitoraggio EDR alle estensioni IDE, configurando alert per comportamenti anomali come lettura massiva di file di configurazione, accesso ai credential store di sistema o connessioni di rete originate dal processo VS Code verso endpoint inusuali. Sul piano organizzativo, è necessario implementare il principio del minimo privilegio per le credenziali usate negli ambienti di sviluppo: i developer non dovrebbero mai usare token con permessi di scrittura su repository interni critici sui propri device personali. Infine, considerare l’adozione di ambienti di sviluppo isolati — container o VM dedicati — per i progetti a più alto rischio, separando fisicamente l’ambiente di esecuzione del codice dall’ambiente di lavoro quotidiano.

(in)sicurezza digitale

2026-05-20 18:59:45

FamousSparrow spia l’Azerbaigian: il gruppo APT cinese colpisce l’industria petrolifera del corridoio energetico europeo

Bitdefender Labs ha documentato un’operazione di cyberspionaggio cinese di ampio respiro contro l’industria petrolifera e del gas dell’Azerbaigian, attribuita con confidenza medio-alta al gruppo FamousSparrow — noto anche come Earth Estries — un attore APT allineato con Pechino. L’operazione, durata oltre due mesi tra dicembre 2025 e febbraio 2026, assume una rilevanza geopolitica straordinaria: l’Azerbaigian è diventato un corridoio energetico strategico per l’Europa dopo la scadenza del contratto di transito del gas russo attraverso l’Ucraina e le perturbazioni nello Stretto di Hormuz del 2026.

Il contesto geopolitico: perché l’Azerbaigian è nel mirino cinese

Comprendere questa intrusione richiede un passo indietro sul panorama energetico europeo. A fine 2024, è scaduto il contratto di transito del gas naturale russo attraverso l’Ucraina, eliminando uno dei principali canali di approvvigionamento per l’Europa orientale. Nel primo trimestre del 2026, la sospensione delle spedizioni di GNL dal Qatar e le perturbazioni nello Stretto di Hormuz hanno ulteriormente ridotto le alternative disponibili. In questo scenario, l’Azerbaigian ha consolidato il proprio ruolo di partner energetico strategico, espandendo le forniture a 13 paesi europei — incluse nuove consegne a Germania e Austria — con un volume export cresciuto del 56% dal 2021.

Accesso iniziale: lo stesso server Exchange sfruttato tre volte

Il 25 dicembre 2025, il processo w3wp.exe (worker IIS di Microsoft Exchange) ha tentato di scrivere una web shell malevola in una directory pubblica del server. Il vettore era la catena exploit ProxyNotShell (CVE-2022-41040, CVE-2022-41082), documentata già dal 2022. Ulteriori tentativi di deploy di web shell sono stati registrati il 26 e 29 dicembre, con filename quali key.aspx, log.aspx, errorFE_.aspx e signout_.aspx.

Ciò che rende questa intrusione particolarmente significativa è la disciplina operativa: il medesimo server Exchange vulnerabile è stato ri-sfruttato per tre ondate distinte nell’arco di due mesi, nonostante i tentativi di remediation della vittima. Ogni volta che la difesa rimuoveva il malware, il gruppo tornava attraverso lo stesso punto di accesso, cambiando il backdoor ma preservando il canale.

Prima ondata: Deed RAT tramite la triade LogMeIn Hamachi

Dopo aver stabilito un foothold via web shell, gli attaccanti hanno distribuito il backdoor Deed RAT attraverso una catena DLL sideloading a tre componenti che sfrutta il legittimo software LogMeIn Hamachi:

• LMIGuardianSvc.exe — binario legittimo LogMeIn Hamachi (MD5: 0554f3b69d39d175dd110d765c11347a)
• LMIGuardianDll.dll — loader malevolo che patcha una Windows API e prepara il payload
• .hamachi.lng — payload Deed RAT cifrato con AES-128-CBC

Il meccanismo di evasione è raffinato: la DLL distribuisce la logica malevola su due export separati, Init e ComMain. La funzione Init patcha silenziosamente l’API Windows StartServiceCtrlDispatcherW in memoria, poi termina senza rivelare comportamenti sospetti. Il payload si attiva solo quando l’applicazione legittima raggiunge la chiamata patchata nel suo flusso naturale. Il risultato pratico: le sandbox di analisi automatica che eseguono la DLL in isolamento non osservano alcun comportamento malevolo — il malware rimane completamente inerte senza il contesto applicativo completo.

Seconda ondata: tentativo con Terndoor via Mofu Loader

Circa un mese dopo, FamousSparrow è tornato con un secondo backdoor: Terndoor, caricato attraverso il Mofu Loader. La catena sfruttava USOShared.exe (rinominato da deskband_injector64.exe) per sideloadare winmm.dll malevolo. Il tentativo è stato bloccato dalla soluzione di sicurezza, ma le tracce forensi hanno rivelato il tentativo di installare un driver kernel (vmflt.sys) per persistenza a livello rootkit — una tecnica documentata da Cisco Talos nel report UAT-9244.

Terza ondata: Deed RAT con C2 aggiornato

A fine febbraio 2026, gli attaccanti sono tornati per la terza volta con Deed RAT aggiornato. Le modifiche principali: magic DWORD aggiornato da 0xDEED4554 a 0xFF66ABCD, compressione plugin da Snappy a Deflate, nuovi target per l’injection (wininit.exe, dwm.exe), e nuovo C2: sentinelonepro[.]com:443. La scelta di un dominio che imita SentinelOne, un noto vendor di sicurezza, è emblematica della cura con cui FamousSparrow costruisce l’infrastruttura per eludere l’attenzione degli analisti.

Movimento laterale: RDP, Domain Admin e Impacket

Con persistenza stabilita sul primo host, gli attaccanti si sono spostati lateralmente via RDP verso un secondo server, autenticandosi con un account Domain Administrator — a indicare che le credenziali privilegiate erano già state compromesse. Da quel secondo host hanno poi usato utility in stile Impacket (atexec, smbexec) per propagarsi su un terzo sistema. La sequenza — accesso RDP, apertura console PowerShell, download del malware in pochi minuti — è la firma di un attore con un playbook collaudato.

Indicatori di compromissione

# Deed RAT - Prima ondata
MD5 LMIGuardianSvc.exe:  0554f3b69d39d175dd110d765c11347a
Path installazione:       C:\Program Files (x86)\LogMeIn Hamachi\
Magic header:             0xFF66ABCD (vecchio: 0xDEED4554)
C2 Prima variante:        HTTPS://virusblocker[.]it[.]com:443
C2 Terza variante:        HTTPS://sentinelonepro[.]com:443
# Web shell ProxyNotShell (Exchange)
File:  key.aspx, log.aspx, errorFE_.aspx, signout_.aspx
Path:  directory accessibili via web su Exchange server
# Terndoor - Seconda ondata
Loader:        C:\ProgramData\USOShared\USOShared.exe
DLL malevola:  C:\ProgramData\USOShared\winmm.dll
Driver kernel: C:\ProgramData\USOShared\vmflt.sys
Registry:      HKLM\SYSTEM\ControlSet001\Services\vmflt
# IOC completi: github.com/bitdefender/malware-ioc/
# File: 2026_05_13-famoussparrow-iocs.csv

Due righe per i difensori

• Patch immediata dei server Exchange esposti: ProxyShell e ProxyNotShell sono vulnerabilità note dal 2021-2022. Qualsiasi Exchange non patchato esposto a internet deve essere considerato compromesso
• Monitorare w3wp.exe: il processo IIS worker non dovrebbe mai scrivere file .aspx in directory pubblicamente accessibili nel contesto MSExchangePowerShellAppPool
• Rilevamento API hooking: monitorare modifiche ai primi byte di API Windows critiche (StartServiceCtrlDispatcherW, CreateProcessW) da parte di binari non firmati
• Alert RDP con credenziali DA: sessioni RDP da host interni con account Domain Administrator al di fuori delle finestre di manutenzione devono innescare alert immediati
• Rotazione credenziali post-compromissione: qualsiasi dichiarazione di remediation completata che non includa la rotazione delle credenziali Domain Admin è incompleta per definizione

La capacità di FamousSparrow di tornare sullo stesso accesso per tre ondate consecutive, adattando il toolset ma mantenendo il canale di ingresso, è la lezione operativa centrale di questa campagna: la remediation che rimuova il malware senza affrontare la vulnerabilità sottostante e ruotare le credenziali non è remediation — è una pausa.

(in)sicurezza digitale

2026-05-20 14:41:42

Intelligenza artificiale, responsabilità e cybersicurezza: il punto sul convegno di Cagliari

Si parla di:
Toggle

Nel grande auditorium dell’ARNAS G. Brotzu di Cagliari, si parla di intelligenza artificiale, responsabilità e cybersicurezza nel sistema sanitario nazionale. Sul palco si alternano dirigenti pubblici, giuristi, esperti di compliance, rappresentanti istituzionali e figure di primo piano della sicurezza informatica italiana.

Un convegno importante per far diventare la cybersicurezza un tema per tutti

I temi sono quelli inevitabili del momento: AI generativa, governance del dato, regolamentazione europea, rischio cyber, continuità operativa, resilienza.

Il tono è solenne, spesso tecnico, quasi rassicurante. Si parla di protezione delle infrastrutture critiche, di necessità di regolamentare l’uso dell’intelligenza artificiale, di responsabilità giuridica e organizzativa. Ma mentre scorrono le slide e si susseguono gli interventi, emerge una sensazione difficile da ignorare: manca il protagonista principale di tutta questa discussione. Il dato sanitario reale. Quello che ogni giorno viene esposto, rubato, venduto, pubblicato o utilizzato senza controllo.

Il convegno è stato un momento di grande opportunità per innescare discussioni sul tema a me molto a cuore: la cybersicurezza nazionale. E gli interventi sono stati un momento importante per sentire punti di vista e situazione attuale nel campo della sanità. Ciò che mi piacerebbe introdurre con questo articolo, vista la qualità della discussione introdotta dal convegno, è la necessità come paese Italia di fare un passo indietro rispetto a ciò che attualmente occupa il maggior spazio nelle scrivanie decisionali, di vedere cosa davvero sta succedendo ai dati dei cittadini italiani.

Il mio intento con questo intervento è quello di farci porre delle domande affinché si possano innescare processi per migliorare eventuali situazioni quotidiane.

Il dato sanitario purtroppo è già ovunque

C’è un paradosso evidente. Tutti concordano sul fatto che il dato sanitario sia “speciale”, “sensibile”, “delicato”, “meritevole di protezione rafforzata”. Eppure quasi nessuno affronta davvero cosa accade quando questi dati finiscono fuori controllo. Nessuno racconta il destino concreto delle cartelle cliniche sottratte durante gli attacchi ransomware. Gli unici interventi che si sono avvicinati a centrare questo punto sono stati il brillante discorso introduttivo del Gen CdA Luciano Carta e quello del Gen CdA Leandro Cuzzocrea entrambi con una visione estramente strategica del mondo criminale dei dati. Che poi è esattamente ciò che occorre su questo tema al Paese Italia.

Nessuno spiega dove finiscono referti, analisi, documenti oncologici, dati psicologici, informazioni genetiche o amministrative una volta pubblicati sui leak site dei gruppi criminali. Nessuno sembra voler affrontare il fatto che, in Italia, gli attacchi contro strutture sanitarie non siano scenari ipotetici o eventualità remote, ma eventi ormai sistematici.

Basta osservare quanto monitorato negli ultimi anni da piattaforme indipendenti come quella sviluppata e mantenuta da me Ransomfeed, che da tempo traccia le rivendicazioni ransomware pubblicate dai gruppi criminali a livello globale. Nel database compaiono ASL, aziende ospedaliere universitarie, strutture territoriali, centri diagnostici e realtà sanitarie italiane finite nel mirino di operatori ransomware ovunque nel tempo: c’è Lazio Crea del 2020 ma dopo quello ce ne sono nel 2021, 2022, 2023, 2024, 2025. Non episodi isolati, ma una sequenza costante di compromissioni che racconta un fenomeno strutturale. Alcuni casi sono rimasti confinati ai disservizi temporanei; altri hanno comportato la sottrazione e pubblicazione di grandi quantità di documentazione sanitaria e amministrativa.

È assolutamente prioritario e strategico sapere e far sapere a tutti i cittadini che questi Terabyte di dati persi nell’Internet e nelle mani criminali, sono gli stessi dati alla base di altri attacchi personali ai cittadini. Sono spesso la risposta alla domanda che spesso ci poniamo su Come ha fatto questo numero sconosciuto dall’Africa a inviarmi un SMS/messaggio Whatsapp, con una truffa a tema bancario?

Eppure, durante il convegno, il tema dominante sembra essere soprattutto la resilienza operativa. Il backup. Il ripristino rapido. La continuità del servizio. Elementi certamente fondamentali, ma che spesso finiscono per ridurre il problema cyber a una semplice questione di disponibilità dei sistemi. Come se il vero obiettivo fosse soltanto “riaccendere tutto il prima possibile”. Come se la perdita definitiva del controllo sui dati fosse un danno secondario.

Ma nel settore sanitario il problema non è soltanto il downtime. È la persistenza del danno. Un referto medico pubblicato online non può essere “ripristinato” da un backup. Una diagnosi oncologica esfiltrata non può essere annullata. Una banca dati sanitaria sottratta e venduta può continuare a circolare per anni in forum criminali, marketplace underground, archivi privati o circuiti di estorsione. E questo aspetto sembra quasi assente dal dibattito istituzionale.

Dico quasi perché effettivamente mi sono ritrovato molto nel discorso conclusivo del Prof. UNICAL Mario Caligiuri, che in qualche modo ha tracciato una “strada del pericolo” di quello che realmente sta già accadendo da anni.

Anche l’AI non è nemica, il problema è caricarci dentro dati sensibili

Lo stesso discorso vale per l’intelligenza artificiale. Sul palco si discute di AI Act, governance, responsabilità dell’algoritmo, supervisione umana. Ma raramente emerge una domanda molto più concreta: cosa accade quando personale sanitario, amministrativo o tecnico inizia a utilizzare chatbot di AI generativa caricando documenti clinici, referti o informazioni dei pazienti? Dove finiscono quei dati? Come vengono trattati? Vengono conservati? Utilizzati per training? Processati da terze parti? Quali controlli esistono realmente nelle strutture pubbliche?

È una questione enorme, eppure ancora affrontata in modo marginale. In molte realtà sanitarie italiane manca completamente una cultura operativa capace di gestire questi strumenti. Il rischio non è teorico. È quotidiano.

Basta osservare cosa accade negli ospedali: porte USB liberamente utilizzabili, workstation condivise, installazione incontrollata di software terzi, accessi a servizi cloud esterni, credenziali riutilizzate, navigazione senza restrizioni, segmentazione di rete insufficiente. In alcuni casi persino software obsoleti e dispositivi medicali non aggiornabili continuano a convivere con infrastrutture moderne.

Tutto questo è sicuramente governance, ma non che sia ancora da normare. È tutto perfettamente normato, ma l’attuale infrastruttura non ne permette la precisa attuazione, purtroppo, all’interno della pubblica amministrazione, come invece avviene da decenni nelle grandi aziende private (come giustamente indicato dal responsabile della sicurezza informatica di Poste Italiane, Rocco Mammoliti).

Il contrasto tra il linguaggio istituzionale del convegno e la realtà operativa percepibile sul campo è netto. Da una parte la narrazione strategica, fatta di regolamenti, framework e governance. Dall’altra la quotidianità di strutture spesso prive di risorse adeguate, personale insufficiente, processi fragili e superfici di attacco enormi. E soprattutto una mancanza cronica di trasparenza pubblica su ciò che avviene dopo un incidente.

Anche il post incidente è una questione di sicurezza

Perché il vero nodo è anche questo: in Italia si parla pochissimo delle conseguenze concrete degli attacchi cyber sulla sanità. Quando una struttura viene colpita, il dibattito si concentra sul blocco dei servizi, sulle prenotazioni sospese, sui disagi temporanei. Molto meno sulla sorte dei dati sottratti. Raramente i cittadini vengono informati in modo chiaro su cosa sia stato realmente esfiltrato, dove quei dati possano finire o quali rischi futuri possano derivarne.

Ed è forse proprio qui che emerge il limite più evidente di molti eventi istituzionali sul tema cybersecurity: la distanza tra il racconto teorico della sicurezza e la realtà pratica delle compromissioni. La cybersicurezza sanitaria non può essere ridotta a compliance normativa o disaster recovery. Richiede una presa di coscienza molto più dura: i dati sanitari italiani sono già oggi un bersaglio costante del cybercrime internazionale, e in molti casi sono già stati sottratti.

Continuare a trattare questi temi come eccezioni anziché come parte di una crisi strutturale rischia di produrre soltanto altra burocrazia, altra documentazione e altri tavoli tecnici. Mentre nel mondo reale, i leak site ransomware continuano ad aggiornarsi. Ogni settimana. Anche con nomi italiani.

Ransomfeed

^Ransomfeed

(in)sicurezza digitale

2026-05-19 13:01:17

QLNX: il nuovo implant Linux silenzioso che saccheggia la supply chain del software

Si parla di:
Toggle

Un nuovo implant Linux mai documentato prima — denominato Quasar Linux RAT (QLNX) — sta prendendo di mira sviluppatori e ambienti DevOps con l’obiettivo di appropriarsi silenziosamente delle credenziali più preziose del ciclo di sviluppo software: token npm, PyPI, AWS, Kubernetes, GitHub e molto altro. La scoperta, opera dei ricercatori Aliakbar Zahravi e Ahmed Mohamed Ibrahim di Trend Micro, descrive uno strumento che non si limita ad essere un semplice trojan di accesso remoto, ma una piattaforma di spionaggio industriale progettata per persistere, nascondersi e colpire l’intera supply chain del software.

Cosa rende QLNX diverso dagli altri RAT Linux

A differenza di molti implant Linux che puntano sulla semplicità, QLNX è costruito come una piattaforma d’attacco coerente e modulare. Il suo punto di forza non sta in una singola tecnica innovativa, ma nell’integrazione armoniosa di più capacità offensive che si concatenano in un flusso d’attacco preciso: arriva, cancella le tracce dal disco, si radica con sei meccanismi ridondanti, si nasconde sia a livello userspace che kernel, e infine raccoglie sistematicamente le credenziali che contano davvero.

Il malware esegue filelessly dalla memoria, mascherandosi da thread del kernel attraverso nomi come kworker o ksoftirqd — nomi che ogni amministratore di sistema Linux incontra quotidianamente nei propri processi. Questo lo rende praticamente invisibile a una normale ispezione manuale. È inoltre in grado di profilare l’host per rilevare ambienti containerizzati, cancellare i log di sistema e stabilire persistenza attraverso non meno di sette metodi diversi, tra cui systemd, crontab e shell injection nel file .bashrc.

Un harvester di credenziali pensato per la supply chain

Il componente di furto credenziali di QLNX è ciò che lo rende particolarmente pericoloso per l’ecosistema open source. Il malware estrae sistematicamente segreti da un elenco preciso di file ad alto valore per uno sviluppatore:

File target di QLNX per il furto credenziali:

.npmrc              → Token di pubblicazione npm
.pypirc             → Credenziali PyPI
.git-credentials    → Credenziali Git
.aws/credentials    → Chiavi di accesso AWS
.kube/config        → Credenziali Kubernetes
.docker/config.json → Autenticazione Docker Registry
.vault-token        → Token HashiCorp Vault
.env                → Variabili d'ambiente con segreti
**/terraform.tfvars → Credenziali Terraform
GitHub CLI tokens   → Token di accesso GitHub

Il rischio non è solo per lo sviluppatore compromesso: un attore che ottiene accesso a uno di questi token può pubblicare pacchetti malevoli su npm o PyPI, accedere all’infrastruttura cloud o muoversi lateralmente attraverso pipeline CI/CD. È esattamente il meccanismo che ha consentito attacchi supply chain devastanti in passato, come l’operazione TeamPCP che ha colpito oltre 160 pacchetti npm e PyPI nelle scorse settimane.

Architettura rootkit a doppio livello: LD_PRELOAD + eBPF

L’aspetto più sofisticato di QLNX è la sua architettura rootkit a due livelli, che combina tecniche di occultamento a livello userspace e kernel.

Il primo strato è un rootkit userland deployato attraverso il meccanismo LD_PRELOAD del dynamic linker di Linux. Questo garantisce che tutti gli artefatti e i processi dell’implant rimangano nascosti agli strumenti di ispezione standard. Il secondo strato è un componente kernel-level basato su eBPF (Extended Berkeley Packet Filter) — il potente sottosistema Linux originariamente pensato per il networking e l’osservabilità dei sistemi. QLNX sfrutta eBPF per nascondere processi, file e porte di rete agli strumenti userland come ps, ls e netstat, su istruzione del server di comando e controllo (C2).

L’uso offensivo di eBPF per il rootkitting è una tendenza già documentata da altri ricercatori, ma la sua integrazione in un RAT con builder pipeline modulare indica una maturazione significativa di queste tecniche al di fuori di ambienti di ricerca accademica.

Backdoor PAM: furto di credenziali SSH in tempo reale

QLNX include anche un backdoor basato su PAM (Pluggable Authentication Module) che intercetta le credenziali in chiaro durante gli eventi di autenticazione SSH. Il componente PAM inline-hook registra i dati delle sessioni SSH in uscita e li trasmette al C2. È inoltre presente un secondo logger PAM che viene caricato automaticamente in ogni processo collegato dinamicamente, per estrarre nome del servizio, username e token di autenticazione.

Questa tecnica è particolarmente insidiosa perché i moduli PAM girano tipicamente con privilegi root e operano a un livello così basso nello stack di autenticazione che la maggior parte dei sistemi di monitoring tradizionali non riesce a intercettarli. Non a caso, negli ultimi mesi sono emersi altri strumenti simili — come PamDOORa, venduto su forum russi di cybercrime per 900 dollari — che sfruttano lo stesso vettore.

58 comandi C2 e un’infrastruttura operativa completa

QLNX supporta ben 58 comandi distinti che conferiscono agli operatori il controllo completo dell’host compromesso. Le capacità operative includono esecuzione di shell commands, gestione file, code injection nei processi, cattura di screenshot, keylogging, SOCKS proxy, TCP tunneling, esecuzione di Beacon Object Files (BOFs) — la stessa tecnica usata da Cobalt Strike — e gestione di una rete P2P mesh tra host compromessi.

La comunicazione con il C2 avviene su tre protocolli — TCP grezzo, HTTPS e HTTP — con un loop persistente che tenta continuamente di mantenere attiva la connessione. La vettore di infezione iniziale rimane ancora sconosciuto, ma una volta stabilito il foothold, QLNX cancella i propri artefatti dal disco e avvia la fase operativa principale.

Indicatori di compromissione e contromisure

QLNX evidenzia una tendenza preoccupante: la supply chain del software sta diventando il bersaglio privilegiato di attori sofisticati, perché compromettere un singolo sviluppatore con accesso ai registri npm o PyPI può avere effetti moltiplicatori su migliaia di utenti downstream. Per i team di sicurezza, alcune contromisure prioritarie:

• Ruotare regolarmente tutti i token di pubblicazione per npm, PyPI, GitHub e altri registri, soprattutto dopo accessi da sistemi non familiari.
• Monitorare processi Linux con nomi simili a thread del kernel — kworker, ksoftirqd ecc. — che non corrispondono agli effettivi thread del kernel: strumenti come pstree con verifica del PPID possono rivelare anomalie.
• Verificare l’integrità dei moduli PAM: controllare regolarmente che i file .so nei percorsi PAM non siano stati modificati rispetto alla versione del package manager.
• Abilitare audit logging di eBPF per rilevare il caricamento di programmi eBPF non autorizzati: auditctl -a always,exit -F arch=b64 -S bpf.
• Isolare i segreti CI/CD dall’ambiente di sviluppo locale, usando secret manager dedicati piuttosto che file in chiaro su disco.

Trend Micro ha pubblicato i dettagli tecnici completi nel proprio blog di ricerca. La natura fileless di QLNX e il suo doppio rootkit rendono il rilevamento basato su signature sostanzialmente inefficace: la difesa deve puntare su behavioral analytics e monitoraggio delle anomalie a livello di syscall, combinati con soluzioni EDR capaci di ispezionare la memoria dei processi.

Quasar Linux (QLNX) – A Silent Foothold in the Supply Chain: Inside a Full-Featured Linux RAT With Rootkit, PAM Backdoor, Credential Harvesting Capabilities

TrendAI™ Research breaks down Quasar Linux (QLNX), a previously undocumented sophisticated Linux RAT with low detection rates.

^{Trend Micro}

(in)sicurezza digitale

2026-05-18 15:45:00

Mini Shai-Hulud: TeamPCP compromette 160+ pacchetti npm e PyPI in un supply chain attack che ha colpito TanStack, Mistral AI e OpenAI

Tra il 11 e il 14 maggio 2026, un attore di minacce tracciato come TeamPCP ha sferrato uno dei supply chain attack più sofisticati mai documentati nell’ecosistema open source: oltre 160 pacchetti npm e 2 pacchetti PyPI compromessi, tra cui componenti del popolare framework TanStack, librerie di Mistral AI e UiPath, e il fondamentale pacchetto node-ipc con 822.000 download settimanali. L’operazione, ribattezzata “Mini Shai-Hulud” dai ricercatori di Wiz, ha colpito le pipeline di sviluppo di migliaia di organizzazioni — inclusi due dipendenti di OpenAI — e ha dimostrato come un singolo punto debole nelle GitHub Actions possa trasformarsi in una bomba a orologeria lungo tutta la catena del software.

L’innesco: tre vulnerabilità GitHub Actions in sequenza

Il vettore iniziale dell’attacco non è stato una vulnerabilità nei pacchetti stessi, ma nell’infrastruttura CI/CD che li gestisce. TeamPCP ha sfruttato una catena di tre vulnerabilità nelle GitHub Actions, secondo quanto ricostruito dai ricercatori di Wiz e Orca Security. L’attaccante ha creato un fork del repository TanStack/router, ha aperto una pull request che ha innescato un workflow pull_request_target — una tipologia di workflow che, a differenza di pull_request, viene eseguita con i permessi completi del repository originale anche per PR da fork esterni — e ha avvelenato la cache pnpm di GitHub Actions con un payload malevolo.

Una volta avvelenata la cache, il malware si è auto-propagato: ogni volta che il workflow legittimo veniva eseguito, invece di scaricare le dipendenze originali recuperava le versioni compromesse dalla cache infetta. Questo meccanismo di auto-propagazione — il “worm” di Mini Shai-Hulud — ha permesso la compromissione a cascata di tutti i namespace associati al progetto.

I 373 pacchetti compromessi: la portata dell’operazione

La scala dell’attacco è stata eccezionale. In totale, 373 versioni malevole sono state pubblicate su npm, distribuite su 169 nomi di pacchetti distinti. I namespace colpiti includono @tanstack (83 voci: router, start, devtools e adapter packages), @uipath (66 voci), @squawk (87 voci), @mistralai, @tallyui, @beproduct e numerosi pacchetti non con scope. Su PyPI, i pacchetti colpiti sono stati guardrails-ai 0.10.1 e mistralai 2.4.6.

La natura cross-namespace dell’attacco è significativa: le organizzazioni che utilizzavano librerie di vendor diversi (UiPath per l’automazione, Mistral AI per i modelli LLM, TanStack per il routing frontend) erano tutte vulnerabili nello stesso intervallo temporale, senza che esistesse un singolo punto di allerta evidente.

node-ipc: il payload più insidioso

Parallelamente alla compromissione via GitHub Actions, TeamPCP ha eseguito un attacco separato ma correlato contro node-ipc, un pacchetto fondamentale di Node.js per la comunicazione inter-processo con oltre 10 milioni di download settimanali. Tre versioni malevole (9.1.6, 9.2.3 e 12.0.1) sono state pubblicate il 14 maggio 2026 tramite un account maintainer compromesso attraverso una tecnica di account takeover mirata.

L’attaccante aveva re-registrato il dominio atlantis-software.net — scaduto il 10 gennaio 2025 — il 7 maggio 2026 tramite Namecheap, e aveva utilizzato la procedura standard di reset password di npm per ottenere i permessi di pubblicazione senza che il maintainer originale venisse avvisato. Le versioni malevole contenevano un payload da 80 KB, fortemente offuscato, che veniva iniettato come IIFE (Immediately Invoked Function Expression) alla fine del file node-ipc.cjs.

Cosa rubava il malware: 90+ categorie di credenziali

Una volta caricato tramite require('node-ipc'), il payload eseguiva silenziosamente un harvesting massiccio di credenziali: chiavi AWS, Azure e GCP, chiavi SSH private, token Kubernetes, configurazioni GitHub CLI, impostazioni di Claude AI e dell’IDE Kiro, stati Terraform, password di database, cronologia della shell e molto altro — oltre 90 categorie di segreti in totale. I dati venivano compressi in un archivio gzip e esfiltrati verso un server controllato dagli attaccanti che si mascherava da infrastruttura Azure.

Prima di procedere, il payload effettuava un fingerprint SHA-256 dell’ambiente, confrontandolo con un hash hardcoded assemblato da otto frammenti offuscati presenti nel codice — presumibilmente per evitare l’esecuzione in sandbox di analisi. Le versioni malevole sono rimaste attive sul registry per circa due ore prima del rilevamento e della rimozione da parte di npm. Qualsiasi progetto che abbia eseguito npm install o aggiornato automaticamente le dipendenze in quella finestra temporale deve essere considerato potenzialmente compromesso.

OpenAI e Mistral AI tra le vittime: le implicazioni sistemiche

OpenAI ha confermato che due dispositivi di dipendenti nel suo ambiente aziendale sono stati compromessi nell’attacco. L’azienda ha ingaggiato una società di incident response, ha ruotato i certificati di firma del codice per le applicazioni macOS e ha dichiarato di non aver trovato evidenze di accesso a dati utente, sistemi di produzione o proprietà intellettuale. Mistral AI ha visto le sue librerie ufficiali compromise, sollevando preoccupazioni immediate tra gli sviluppatori che le utilizzano per integrare capacità AI nei loro applicativi.

Il fatto che TeamPCP abbia preso di mira specificamente pacchetti di aziende AI leader — Mistral AI, e indirettamente OpenAI attraverso i suoi sviluppatori — non è casuale: i developer che lavorano con questi strumenti hanno tipicamente accesso a chiavi API di alto valore, ambienti cloud critici e codice sorgente sensibile. I repo di Mistral AI rubati sono stati successivamente messi in vendita da TeamPCP, confermando la doppia finalità dell’operazione: furto di credenziali e esfiltrazione di proprietà intellettuale.

Difendersi dalla nuova generazione di supply chain attack

L’attacco di Mini Shai-Hulud rappresenta una nuova classe di minaccia per la quale molte organizzazioni non sono ancora attrezzate. La compromissione non avviene attraverso vulnerabilità nel codice stesso, ma nell’infrastruttura di distribuzione. Alcune misure pratiche per i difensori includono il pinning delle versioni esatte dei pacchetti (evitando range semver come ^1.2.3 o ~1.2.3), l’utilizzo di un lockfile verificato e mantenuto nel controllo versione, l’auditing regolare delle dipendenze con strumenti come npm audit o Snyk, e la verifica dell’integrità dei pacchetti tramite hash SHA-512 dove disponibili.

Sul fronte CI/CD, è fondamentale limitare i permessi dei workflow GitHub Actions, evitare l’uso di pull_request_target con checkout del codice della PR, e implementare cache poisoning prevention attraverso la verifica dell’integrità della cache. Le organizzazioni che hanno eseguito build tra il 11 e il 14 maggio 2026 utilizzando i namespace colpiti dovrebbero effettuare una revisione completa dei secret esposti.

Indicatori di Compromissione (IoC)

# Mini Shai-Hulud / TeamPCP Supply Chain Attack - Maggio 2026
# Fonti: Wiz, Orca Security, Snyk, StepSecurity

# Pacchetti npm malevoli (esempi principali)
node-ipc: 9.1.6, 9.2.3, 12.0.1
@tanstack/router: versioni pubblicate 11-14 maggio 2026
@mistralai/mistralai: 2.4.6 (correlato)

# Pacchetti PyPI malevoli
guardrails-ai==0.10.1
mistralai==2.4.6

# Account maintainer compromesso (node-ipc)
npm user: atiertant (a.tiertant@atlantis-software.net)
Dominio re-registrato: atlantis-software.net (7 maggio 2026)

# Tecniche MITRE ATT&CK
T1195.001 - Supply Chain Compromise: Compromise Software Dependencies
T1059.007 - Command and Scripting Interpreter: JavaScript
T1552.001 - Unsecured Credentials: Credentials in Files
T1041     - Exfiltration Over C2 Channel (verso infrastruttura Azure-like)

# Indicatori comportamentali
- Processi Node.js che effettuano richieste HTTP inattese post-installazione
- Archivi gzip creati in directory temporanee durante npm install
- Chiamate a endpoint Azure non riconosciuti da processi build

# Verifica hash (node-ipc versioni legittime)
SHA-256 v9.1.5 legittima: verificare su https://registry.npmjs.org/node-ipc/9.1.5

Fonti: Wiz Blog, Orca Security, The Hacker News, BleepingComputer, OpenAI Blog

TanStack and 160+ npm/PyPI Packages Compromised in Supply Chain Worm Attack

Over 160 npm/PyPI packages like TanStack were compromised by the Mini Shai-Hulud worm. Orca helps prioritize remediation and immediate action.

^{Roi Nisimi (Orca Security)}

(in)sicurezza digitale

2026-05-18 15:39:00

UAT-8616: il gruppo d’élite sfrutta il sesto zero-day Cisco SD-WAN e prende di mira governi europei e asiatici

Un threat actor di altissimo livello, tracciato da Cisco Talos come UAT-8616, sta sfruttando attivamente una vulnerabilità critica nei controller Cisco Catalyst SD-WAN — la sesta zero-day sfruttata su questa piattaforma nel solo 2026. Con un CVSS di 10.0, la falla consente a un attaccante non autenticato di ottenere privilegi amministrativi completi su dispositivi SD-WAN esposti su internet, prendendo di mira settori governativi, diplomatici e della difesa in Europa e Asia Centrale.

La Sesta Zero-Day in Sei Mesi: CVE-2026-20182

Il 15 maggio 2026, la CISA (Cybersecurity and Infrastructure Security Agency) ha aggiunto CVE-2026-20182 al suo catalogo di vulnerabilità attivamente sfruttate (KEV — Known Exploited Vulnerabilities), imponendo alle agenzie federali civili statunitensi di applicare la patch entro il 17 maggio. La vulnerabilità risiede nel processo di handshake del controllo peering via protocollo DTLS sulla porta 12346 del Cisco Catalyst SD-WAN Controller e Manager.

In termini pratici, un attaccante remoto e non autenticato può autenticarsi come peer interno ad alto privilegio, bypassando completamente l’autenticazione e acquisendo controllo amministrativo sull’appliance bersaglio. Il punteggio massimo CVSS (10.0) riflette la semplicità di sfruttamento combinata alla gravità dell’impatto: nessuna credenziale, nessuna interazione utente richiesta.

Il Profilo di UAT-8616: Un Attore Sofisticato con Radici Profonde

Cisco Talos ha tracciato questa campagna sotto la denominazione UAT-8616, classificandolo con alta confidenza come un “highly sophisticated cyber threat actor”. Sebbene Talos non abbia ancora rilasciato un’attribuzione definitiva a uno stato-nazione specifico, diversi elementi indicativi emergono dall’analisi:

• Longevità operativa: le prime tracce di attività malevola risalgono al 2023, almeno tre anni prima della divulgazione pubblica — segnale che il gruppo operava con una zero-day tenuta segreta per molto tempo.
• Sovrapposizione con ORB network: l’infrastruttura di UAT-8616 si sovrappone a reti di relay operazionali (Operational Relay Boxes) precedentemente associate a operazioni di cyber-spionaggio di attori China-nexus, secondo quanto documentato da Mandiant/Google.
• Target geopoliticamente selettivi: il profilo dei bersagli — governo, diplomazia, difesa in Europa e Asia Centrale — è coerente con operazioni di intelligence offensiva state-sponsored.
• Connessione con endpoint Gamaredon (Aqua Blizzard): la CISA ha segnalato sovrapposizioni con endpoint già compromessi da Gamaredon, il gruppo russo legato all’FSB che storicamente prende di mira organizzazioni ucraine e dell’Europa orientale.

Anatomia dell’Attacco: Dal Bypass all’Esfiltrazione

Le tecniche post-compromissione documentate da Talos rivelano un playbook operativo sofisticato, progettato tanto per la persistenza quanto per l’evasione forense:

• SSH key injection: aggiunta di chiavi SSH nei file authorized_keys per garantire accesso permanente anche dopo il reboot o il cambio di credenziali.
• Escalation a root via CVE-2022-20775: sfruttamento di una tecnica di downgrade della versione software per scalare i privilegi fino a root.
• Manipolazione NETCONF: modifica delle configurazioni di rete tramite il protocollo NETCONF per alterare il traffico o creare tunnel nascosti.
• Creazione di account malevoli: creazione di utenti backdoor per accesso persistente.
• Anti-forensics sistematico: cancellazione di log da syslog, wtmp, lastlog, bash_history e cli-history per coprire le tracce dell’intrusione.

Un Pattern Preoccupante: Sei Zero-Day in Sei Mesi

CVE-2026-20182 non è un caso isolato. Come documenta SecurityWeek, si tratta della sesta vulnerabilità zero-day sfruttata attivamente sulle piattaforme Cisco SD-WAN nel corso del 2026, un dato che solleva interrogativi profondi sulla sicurezza dell’infrastruttura di rete enterprise. Gli SD-WAN sono sistemi critici che gestiscono il traffico di rete tra sedi aziendali distribuite, data center e cloud — la loro compromissione offre all’attaccante una visibilità strategica sull’intera architettura di rete della vittima.

La tendenza è chiara: i dispositivi di rete edge — firewall, VPN concentrator, SD-WAN controller — sono diventati il principale vettore di accesso iniziale per i gruppi APT più sofisticati al mondo. A differenza degli endpoint tradizionali, questi dispositivi raramente eseguono soluzioni EDR e spesso hanno cicli di aggiornamento lenti nelle organizzazioni.

Implicazioni Geopolitiche e per i Difensori

Il targeting di settori governativi e della difesa in Europa e Asia Centrale suggerisce una campagna di cyber-spionaggio strategico. Le sovrapposizioni infrastrutturali con attori Russia-linked come Gamaredon/Aqua Blizzard complicano ulteriormente l’attribuzione, un fenomeno sempre più comune nelle operazioni moderne dove la condivisione di infrastrutture (ORB network) oscura deliberatamente le responsabilità.

Per i team di sicurezza, le priorità immediate sono chiare:

• Patching urgente: applicare immediatamente le patch Cisco per CVE-2026-20182 su tutti i Catalyst SD-WAN Controller e Manager esposti.
• Audit delle authorized_keys: verificare l’integrità dei file SSH authorized_keys su tutti i sistemi SD-WAN.
• Revisione account: identificare e rimuovere eventuali account non autorizzati creati sui sistemi.
• Log integrity check: data la tendenza del gruppo a cancellare i log, implementare forwarding immediato su SIEM centralizzato.
• Network segmentation review: limitare l’accesso amministrativo ai controller SD-WAN tramite reti di gestione dedicate e isolate.

CVE e Riferimenti Tecnici

CVE-2026-20182 — Cisco Catalyst SD-WAN Controller / Manager
CVSS Score: 10.0 (Critico)
Tipo: Authentication Bypass
Vettore: DTLS porta 12346 (handshake peering)
Impatto: Accesso amministrativo non autenticato

CVE correlati campagna UAT-8616:
- CVE-2026-20127 (zero-day precedente, sfruttato da febbraio 2026)
- CVE-2022-20775 (privilege escalation, usato per escalation a root)

Indicatori di Compromissione (comportamentali):
- SSH keys non autorizzate in authorized_keys
- Account di sistema inattesi
- Assenza di voci nei log syslog/wtmp/lastlog (log wiping)
- Configurazioni NETCONF alterate
- Traffico anomalo su porta DTLS 12346

Fonti: Cisco Talos, CISA KEV, SecurityWeek, Help Net Security, Tenable, Dark Reading

(in)sicurezza digitale

2026-05-18 14:10:58

Kazuar si evolve: Secret Blizzard (Turla) trasforma il suo backdoor storico in una botnet P2P modulare invisibile

Si parla di:
Toggle

Il gruppo russo Secret Blizzard, operativo per conto dell’FSB (Federal Security Service) russo e meglio conosciuto come Turla, ha trasformato il proprio storico malware Kazuar in una botnet peer-to-peer modulare, progettata per mantenere accessi persistenti e praticamente invisibili nelle reti governative. La rivelazione arriva da Microsoft Security, che il 14 maggio 2026 ha pubblicato un’analisi approfondita dell’architettura del malware — descrivendo quello che è a tutti gli effetti un salto evolutivo nella sofisticazione operativa di uno dei gruppi APT più longevi al mondo.

Da backdoor tradizionale a ecosistema P2P

Kazuar è attivo almeno dal 2017 ed è stato impiegato in decine di campagne di cyberspionaggio contro governi, ambasciate e organizzazioni della difesa in Europa, Asia Centrale e Ucraina. La versione analizzata da Microsoft nel 2026 rappresenta però un cambio di paradigma: il malware non è più un semplice backdoor controllato centralmente, ma un ecosistema distribuito composto da tre moduli distinti che collaborano per garantire resilienza, persistenza e stealth.

La riorganizzazione è eloquente: non ogni macchina compromessa comunica con il server di comando e controllo (C2). Invece, un unico nodo “leader” — eletto dinamicamente dal modulo Kernel tra i sistemi infetti presenti nella stessa rete o segmento di rete — assume il ruolo di proxy verso l’infrastruttura esterna. Gli altri nodi entrano in modalità “silent”, eliminando quasi completamente il traffico verso l’esterno e riducendo drasticamente la superficie di rilevamento per i team di incident response.

Architettura modulare: Kernel, Bridge e Worker

Microsoft descrive tre componenti fondamentali della nuova architettura Kazuar:

• Modulo Kernel: È il coordinatore centrale. Gestisce i task, controlla gli altri moduli, elegge il nodo leader e orchestra le comunicazioni e il flusso di dati attraverso la botnet.
• Modulo Bridge: Agisce come proxy tra il nodo leader Kernel e il server C2 remoto. Filtra e instrada il traffico, permettendo ulteriore separazione tra i sistemi compromessi e l’infrastruttura degli attaccanti.
• Modulo Worker: È il componente operativo. Registra i tasti premuti (keylogging), aggancia gli eventi Windows, traccia i task, raccoglie informazioni di sistema, listing di file e dettagli MAPI — incluse caselle email di Exchange.

Questa separazione funzionale non è casuale: in caso di rilevamento di un Worker, i nodi Kernel restano inalterati e possono continuare a operare silenziosamente. L’architettura è progettata per sopravvivere a rimozioni parziali.

150 parametri di configurazione: granularità operativa senza precedenti

Uno degli aspetti più rilevanti della nuova versione è il sistema di configurazione esteso: Kazuar supporta ora più di 150 parametri che gli operatori possono personalizzare per ogni campagna o vittima specifica. Questi parametri controllano metodi di esecuzione e persistenza (scheduled task, servizi Windows, chiavi di registro), bypass di AMSI e ETW, timing dell’esfiltrazione e dimensione dei chunk di dati, process injection e tecniche di lateral movement, e protocolli di comunicazione multipli: HTTP, WebSocket ed Exchange Web Services (EWS).

L’uso di EWS per mascherare le comunicazioni C2 nel traffico legittimo di Exchange è particolarmente insidioso: in ambienti enterprise dove Exchange Server è ubiquo, questo canale risulta quasi impossibile da distinguere dal traffico normale senza ispezione profonda dei payload.

Targeting: governi, ambasciate e settore difesa in Europa e Ucraina

Secret Blizzard (alias Turla, Uroburos, Venomous Bear) è noto per campagne di spionaggio ad altissimo valore strategico. Le vittime documentate includono ministeri degli esteri, ambasciate diplomatiche, dipartimenti della difesa e organizzazioni governative in Europa Orientale, Asia Centrale e — con intensità crescente — Ucraina nel contesto del conflitto in corso.

L’evoluzione di Kazuar verso un’architettura P2P suggerisce che il gruppo abbia tratto lezione dalle operazioni di takedown condotte negli ultimi anni contro infrastrutture di malware centralizzate. La distribuzione del controllo rende un’eventuale disruption dell’infrastruttura C2 molto meno efficace: rimuovere il server C2 non smantella la botnet, poiché il leader può essere eletto nuovamente tra i nodi sopravvissuti.

Due righe per i difensori

Microsoft raccomanda di concentrare il rilevamento su indicatori comportamentali piuttosto che su signature statiche. I team di sicurezza dovrebbero monitorare attività IPC insolite tra processi non correlati, rilevare pattern di elezione del leader nella rete interna tramite comunicazioni laterali anomale, identificare esfiltrazione dati staged e frammentata con timing irregolare, e controllare accessi anomali a EWS da processi non di posta elettronica. Dato il targeting storico di Secret Blizzard su entità diplomatiche e governative europee, le organizzazioni in questi settori dovrebbero considerare una revisione urgente dei log di rete e degli endpoint.

Indicatori di Compromissione (IoC)

# Kazuar - Secret Blizzard (Turla) - Maggio 2026
# Fonte: Microsoft Security Blog, 14 maggio 2026

# Tecniche MITRE ATT&CK associate
T1574.001 - DLL Search Order Hijacking
T1055     - Process Injection
T1071.001 - Application Layer Protocol: Web Protocols (HTTP/WebSocket)
T1071.003 - Application Layer Protocol: Mail Protocols (EWS)
T1030     - Data Transfer Size Limits (staged exfiltration)
T1053.005 - Scheduled Task/Job (persistence)
T1562.001 - Impair Defenses: Disable/Modify Tools (AMSI/ETW bypass)

# Comportamenti anomali da monitorare
- Comunicazioni IPC anomale tra processi non correlati
- Accessi Exchange Web Services (EWS) da processi non di posta
- Traffico P2P laterale interno su porte non standard
- Esfiltrazione dati in chunk temporizzati verso IP non categorizzati
- Moduli .NET iniettati in processi di sistema legittimi

# Referenza completa IoC
https://www.microsoft.com/en-us/security/blog/2026/05/14/kazuar-anatomy-of-a-nation-state-botnet/

Fonti: Microsoft Security Blog, BleepingComputer, The Hacker News

Kazuar: Anatomy of a nation-state botnet | Microsoft Security Blog

Kazuar, a sophisticated malware family attributed to the Russian state actor Secret Blizzard, has been under constant development for years and continues to evolve in support of espionage-focused operations.

^{Microsoft Threat Intelligence (Microsoft Security Blog)}