(in)sicurezza digitale

2026-04-11 08:02:26

Operazione Olalampo: MuddyWater sfrutta Rust e Telegram per spiare il Medio Oriente

Dal gennaio 2026, il gruppo iraniano MuddyWater conduce una campagna di spionaggio sofisticata contro organizzazioni governative, energetiche e infrastrutturali del Medio Oriente e Nord Africa. L’Operazione Olalampo segna un salto qualitativo nelle capacità offensive del gruppo: malware scritto in Rust, sviluppo assistito da intelligenza artificiale e un canale di comando-e-controllo nascosto nei bot di Telegram.

Chi è MuddyWater e perché è pericoloso

MuddyWater — conosciuto anche come Seedworm, TA450, Mango Sandstorm ed Earth Vetala — è un gruppo APT ritenuto collegato al Ministero dell’Intelligence e Sicurezza iraniano (MOIS). Attivo da almeno il 2017, il gruppo ha nel tempo ampliato il proprio arsenale tecnico passando da strumenti commerciali come AnyDesk e SimpleHelp a malware completamente custom. L’Operazione Olalampo rappresenta la più recente e sofisticata evoluzione di questa traiettoria.

La catena d’attacco: da una macro Excel al controllo totale

L’infezione inizia con una campagna di spear-phishing mirata: le vittime ricevono email con allegati Microsoft Office (principalmente Excel) contenenti macro VBA malevole. Una volta attivata la macro, il codice decodifica ed esegue il payload iniziale in memoria, avviando una catena a più stadi progettata per massimizzare la furtività.

• Stadio 1 — GhostFetch: downloader di prima fase con funzioni di profilazione del sistema, controlli anti-debug e anti-VM, ed esecuzione in memoria del payload successivo.
• Stadio 2 — GhostBackDoor: backdoor completa con supporto per remote shell, operazioni sui file, esecuzione di comandi arbitrari e meccanismi di persistenza.
• HTTP_VIP: downloader alternativo che effettua ricognizione del sistema, si autentica al C2 e può distribuire AnyDesk per l’accesso remoto diretto, oltre a monitorare gli appunti di sistema.
• CHAR: backdoor scritta interamente in Rust, capace di esecuzione di comandi, accesso a PowerShell, operazioni di reverse proxy e deploy di proxy SOCKS5.

Il cuore dell’operazione: Telegram come infrastruttura C2

L’elemento più interessante di questa campagna è l’uso di un bot Telegram come canale di comando-e-controllo per la backdoor CHAR. Il bot — con display name “Olalampo” e username stager_51_bot — consente agli operatori di inviare comandi ai sistemi compromessi attraverso l’infrastruttura legittima di Telegram, rendendo il traffico indistinguibile da quello normale. Questo approccio offre tre vantaggi tattici significativi: il traffico viene cifrato end-to-end, si mimetizza nel traffico legittimo di messaggistica aziendale, e Telegram è molto difficile da bloccare completamente nei contesti aziendali.

Il monitoraggio del bot C2 ha permesso ai ricercatori di Group-IB di osservare direttamente le attività post-exploitation: comandi eseguiti, strumenti distribuiti e tecniche di raccolta dati utilizzate dagli operatori.

Sviluppo assistito da IA: una nuova frontiera per gli APT

Un dettaglio rivelatore nell’analisi del malware è la presenza di stringhe di debug contenenti emoji — un pattern tipico del codice generato o rifinito con l’assistenza di grandi modelli linguistici (LLM). Questo suggerisce che MuddyWater stia integrando strumenti di intelligenza artificiale nel proprio ciclo di sviluppo malware, potenzialmente accelerando la creazione di nuove varianti e riducendo gli errori. La scelta di Rust per CHAR va nella stessa direzione: Rust è un linguaggio relativamente giovane, ma molto popolare nei progetti LLM, cross-platform per definizione e che produce binari difficili da analizzare con i tradizionali strumenti di reverse engineering.

Infrastruttura e indicatori di compromissione

L’analisi DNS condotta da ricercatori indipendenti ha portato all’identificazione di quattro domini malevoli, tutti registrati tramite Namecheap con indirizzi di registrazione in Islanda — una tecnica di anonimizzazione comune tra gli attori state-sponsored. I domini risultano relativamente recenti, creati tra ottobre 2025 e febbraio 2026, confermando un’attiva preparazione dell’infrastruttura nelle settimane precedenti la campagna.

## Domini C2 identificati
jerusalemsolutions[.]com
miniquest[.]org
codefusiontech[.]org

## Indirizzi IP
162[.]0[.]230[.]185
209[.]74[.]87[.]100

## Telegram C2
Bot username: stager_51_bot
Bot display name: Olalampo

## Note infrastruttura
Registrar: Namecheap
Posizione registrazione: Islanda
Periodo creazione domini: 10/2025 – 02/2026
Comunicazioni victim-IoC osservate: 10 IP unici su 3 ASN (01/25–02/25/2026)

Settori e geografie colpite

I target primari dell’Operazione Olalampo includono agenzie governative, operatori di infrastrutture critiche, aziende del settore energetico, operatori di telecomunicazioni e professionisti di alto profilo nelle regioni MENA (Medio Oriente e Nord Africa). La scelta dei target è coerente con gli obiettivi di intelligence strategica del MOIS: raccolta di informazioni su politica estera, accordi energetici e comunicazioni riservate di governi nella sfera di influenza dell’Iran.

Consigli per i difensori

La natura dell’Operazione Olalampo richiede un approccio difensivo su più livelli. Limitare o monitorare il traffico verso i server Telegram (t.me, api.telegram.org) nei perimetri aziendali può bloccare il canale C2 principale, anche se ciò richiede un’analisi del rischio rispetto all’uso legittimo della piattaforma. A livello email, rafforzare i controlli sugli allegati Office con macro e abilitare Protected View/AMSI per documenti provenienti da fonti esterne è un primo scudo efficace. Sul fronte EDR, è fondamentale cercare attività anomale di PowerShell, processi figlio di applicazioni Office, e l’esecuzione di binari Rust non firmati. Infine, la presenza di processi AnyDesk o SimpleHelp avviati da percorsi inusuali dovrebbe costituire un alert ad alta priorità.

(in)sicurezza digitale

2026-04-11 08:03:16

GlassWorm: il worm che infetta tutti gli IDE tramite un’estensione OpenVSX contraffatta

Un’estensione contraffatta nel marketplace OpenVSX installa silenziosamente un dropper compilato in Zig che individua e infetta tutti gli IDE compatibili con VS Code presenti sulla macchina, per poi deployare un RAT con C2 su blockchain Solana e un’estensione Chrome per rubare sessioni e keystroke. La campagna GlassWorm è attiva da oltre un anno e ha appena compiuto il suo salto evolutivo più sofisticato.

Una campagna che cresce da un anno

GlassWorm non è una minaccia nuova: Aikido Security ne traccia l’evoluzione dal marzo 2025, quando fu individuata la prima variante nascosta in pacchetti npm attraverso caratteri Unicode invisibili per offuscare il payload. Da allora, la campagna ha iterato costantemente le proprie tecniche, arrivando oggi a una versione che colpisce non un singolo editor, ma l’intero ecosistema degli ambienti di sviluppo installati su una macchina — con una catena di infezione a più stadi difficile da individuare con le sole difese tradizionali.

Il vettore iniziale: un’estensione che finge di essere WakaTime

Il punto di ingresso è un’estensione pubblicata sul marketplace OpenVSX sotto il nome specstudio/code-wakatime-activity-tracker. L’estensione si spaccia per WakaTime, uno strumento molto diffuso tra gli sviluppatori che tiene traccia del tempo trascorso nel codice. Una volta installata, esegue immediatamente un codice di installazione minimale — dove un modulo punta a binari nativi Node.js compilati per la piattaforma target.

Il dropper Zig: fuori dalla sandbox JavaScript

Il vero cuore della tecnica è l’uso di binari nativi Node.js (file .node) compilati con Zig — un linguaggio di sistema relativamente giovane e poco presidiato dai motori antivirus. Questi addon vengono caricati direttamente nel runtime di Node con accesso completo al sistema operativo, bypassando completamente la sandbox JavaScript di VS Code. Il comportamento è fondamentalmente diverso da quello di un’estensione normale: non è codice JS interpretato con permessi limitati, ma una libreria nativa con diritti equivalenti al processo padre. I binari identificati sono specifici per piattaforma: su Windows viene deployato win.node (PE32+ DLL), mentre su macOS viene utilizzato mac.node (Universal Mach-O). Quest’ultimo conteneva simboli di debug rivelatori, con un percorso che ha permesso ai ricercatori di identificare il developer environment dell’autore.

Autopropagazione: infettare ogni IDE sulla macchina

Una volta eseguito, il dropper Zig non si limita a compromettere l’IDE corrente: scansiona il filesystem alla ricerca di tutti gli ambienti di sviluppo compatibili con le estensioni VS Code. Su Windows controlla le directory %LOCALAPPDATA%\Programs\ e %ProgramFiles%; su macOS la cartella /Applications/. Gli IDE target includono Microsoft VS Code e VS Code Insiders, ma anche i fork come Cursor (AI-first IDE in rapida adozione), Windsurf, VSCodium e Positron. Ogni editor trovato viene infettato con una seconda estensione malevola, installata silenziosamente tramite CLI usando il parametro –install-extension. Il secondo stadio si maschera da una estensione di auto-import con milioni di installazioni, scaricato da un repository GitHub sotto controllo degli attaccanti.

Il payload finale: Solana come C2, RAT e furto di sessioni Chrome

La seconda estensione malevola implementa le capacità di spionaggio vere e proprie. Il meccanismo di C2 è particolarmente innovativo: invece di puntare a un server fisso, il malware interroga la blockchain Solana per recuperare l’indirizzo del server di comando — una tecnica che rende il blocco dell’infrastruttura C2 praticamente impossibile senza bloccare l’intera blockchain. Tra le funzionalità documentate ci sono: geofencing contro sistemi con impostazioni locali russe (l’esecuzione viene saltata), esfiltrazione di segreti, token di sessione e chiavi API dal workspace dello sviluppatore, installazione di un RAT persistente con comunicazione cifrata, e deploy di un’estensione Chrome malevola per il furto di cookie di sessione e keystroke logging.

Indicatori di compromissione

## Estensioni malevole OpenVSX
specstudio/code-wakatime-activity-tracker  (1° stadio)
floktokbok.autoimport                       (2° stadio)

## Hash SHA-256 dei binari nativi Zig
win.node (Windows PE32+ DLL):
  2819ea44e22b9c47049e86894e544f3fd0de1d8afc7b545314bd3bc718bf2e02

mac.node (macOS Universal Mach-O):
  112d1b33dd9b0244525f51e59e6a79ac5ae452bf6e98c310e7b4fa7902e4db44

## Repository GitHub per distribuzione stage-2
ColossusQuailPray/oiegjqde

## Debug artifact (attributione autore)
/Users/davidioasd/Downloads/vsx_installer_zig

## IDE target confermati
VS Code, VS Code Insiders, Cursor, Windsurf, VSCodium, Positron

Perché questa campagna è un segnale d’allarme per i team di sicurezza

GlassWorm dimostra come il marketplace delle estensioni IDE sia diventato una superficie d’attacco matura e sfruttata attivamente. La compromissione di un singolo sviluppatore può propagarsi a tutta l’organizzazione attraverso repository git, ambienti CI/CD e pipeline di build condivisi — con un impatto potenziale molto superiore a quello di un malware che colpisce un endpoint generico. Il fatto che il dropper salti deliberatamente i sistemi russi suggerisce un attore state-sponsored o comunque con motivazioni geograficamente definite, probabilmente orientato verso organizzazioni di sviluppo software in occidente e in Asia.

Consigli per i difensori

I team di sicurezza dovrebbero esaminare l’elenco delle estensioni installate su tutti gli IDE degli sviluppatori, con particolare attenzione a estensioni non presenti nel Visual Studio Marketplace ufficiale ma solo su OpenVSX. L’introduzione di policy di allowlist per le estensioni VS Code, già supportata dalla funzionalità di Policy Management di VS Code, è oggi una misura consigliata in ambienti corporate. A livello di EDR, alert sulla creazione di file .node in directory di estensioni IDE e sull’esecuzione di processi IDE con parametri –install-extension da processi non interattivi sono indicatori ad alta fedeltà. L’analisi dei log di rete alla ricerca di chiamate RPC verso nodi Solana da processi Node.js può aiutare a rilevare la fase di C2 in modo precoce.

(in)sicurezza digitale

2026-04-10 08:00:55

Il colloquio di lavoro come arma: Lazarus Group e la campagna Graphalgo contro gli sviluppatori crypto

Si parla di:
Toggle

• L’esca: la finta azienda e il finto recruiter
• La catena d’attacco: tre stadi per un RAT
• L’obiettivo reale: i wallet di criptovaluta
• I marcatori di attribuzione a Lazarus Group
• Timeline della campagna
• Indicatori di compromissione (IoC)
• Come proteggersi

Da maggio 2025, un gruppo di minaccia attribuito con alta confidenza a Lazarus Group — il collettivo di hacker sponsorizzato dallo Stato nordcoreano — conduce un’operazione silenziosa e metodica contro sviluppatori JavaScript e Python specializzati in criptovalute e blockchain. La campagna, battezzata Graphalgo dai ricercatori di ReversingLabs, ha prodotto 192 pacchetti malevoli su npm e PyPI e ha preso di mira centinaia di professionisti attraverso uno strumento di social engineering particolarmente subdolo: un colloquio di lavoro tecnico.

L’esca: la finta azienda e il finto recruiter

Tutto inizia con un messaggio su LinkedIn, Facebook o un forum come Reddit. Un recruiter — cortese, professionale, apparentemente legittimo — si presenta come rappresentante di Veltrix Capital, società nel settore blockchain-fintech con un sito web dall’aspetto curato (veltrixcap.org, registrato il 4 aprile 2025). La posizione è appetibile: sviluppatore per una piattaforma di exchange crypto. Il processo di selezione è familiare: un task tecnico, un repository GitHub da clonare, del codice da eseguire.

Il repository appartiene all’organizzazione GitHub della finta azienda e appare legittimo in tutto e per tutto. La dipendenza richiesta si chiama graphnetworkx — un nome studiato per assomigliare alla ben nota libreria networkx. Oppure graphalgo, con varianti che seguono schemi di naming come graph-* o big-* su PyPI. In totale, i ricercatori hanno identificato 106 pacchetti malevoli su npm e 86 su PyPI — 192 in tutto.

La pazienza è un tratto distintivo dell’operazione: alcuni pacchetti sono rimasti benigni per settimane dopo la pubblicazione, accumulando fino a 10.000 download prima di essere attivati con il payload malevolo — una tattica che massimizza la probabilità di infettare sistemi reali prima che i controlli automatici possano rilevare la minaccia.

La catena d’attacco: tre stadi per un RAT

Il meccanismo di infezione è sofisticato quanto discreto e si articola in tre stadi.

Primo stadio: il pacchetto malevolo

Al momento dell’installazione o dell’import, il pacchetto scarica silenziosamente un secondo stadio da GitHub — non da fork anonimi, ma da repository apparentemente innocui come un banale blog_app con un file .env.example contenente payload cifrati. Nelle varianti più recenti, la raffinatezza aumenta ulteriormente: la chiave di decifrazione non è hard-coded nel pacchetto, ma viene costruita dinamicamente dagli argomenti passati al costruttore del grafo. Ad esempio, istanziare new Graph({weighted:true, directed:true}) genera la chiave "weighted-directed-graph". Il payload rimane cifrato e inerte finché il codice legittimo del candidato non lo attiva con i parametri corretti — una tecnica progettata specificamente per eludere l’analisi automatica da parte di sandbox e scanner.

Secondo stadio: il downloader adattivo

Il secondo stadio, ospitato su GitHub, funge da downloader che utilizza l’hash SHA256 del payload stesso, concatenato con l’hostname della macchina vittima, per derivare dinamicamente l’URL del server C2. Questo rende l’infrastruttura di comando e controllo unica per ogni vittima, complicando significativamente il monitoraggio e il blocco a livello di rete.

Terzo stadio: il RAT

Il Remote Access Trojan finale esiste in tre varianti — JavaScript, Python e Visual Basic Script — e comunica periodicamente con i server C2 (codepool[.]cloud, aurevian[.]cloud) per ricevere ed eseguire comandi arbitrari. Le comunicazioni sono protette da token di autenticazione, una caratteristica già osservata in precedenti campagne nordcoreane documentate, che impedisce a terze parti di interrogare l’infrastruttura C2 anche conoscendone l’indirizzo.

L’obiettivo reale: i wallet di criptovaluta

Un dettaglio rilevatore emerge dall’analisi del RAT: il malware verifica attivamente la presenza dell’estensione browser MetaMask. Non si tratta di un tentativo generico di accesso remoto: l’obiettivo primario è il furto di asset in criptovaluta, potenzialmente con accesso alle chiavi private dei wallet o alle seed phrase. Questo allinea Graphalgo con la lunga e documentata storia di Lazarus Group nel finanziamento delle operazioni di stato nordcoreane attraverso il furto di valuta digitale — una fonte di entrate stimata in miliardi di dollari negli ultimi anni.

I marcatori di attribuzione a Lazarus Group

L’attribuzione alla cellula nordcoreana non si basa su un singolo indizio, ma su una convergenza di evidenze tecniche e operative:

• Fuso orario: i commit Git mostrano attività nel fuso GMT+9 — il fuso orario standard della Corea del Nord.
• Tecnica d’approccio: le fake recruiter campaign sono una firma operativa consolidata del gruppo, documentata in campagne precedenti come “Contagious Interview” e “DEV-0139”.
• Focus crypto: in linea con decine di operazioni precedenti finalizzate al furto di valuta digitale per finanziare il regime di Pyongyang.
• C2 token-protected: tecnica osservata in precedenti campagne DPRK e mai diventata uno standard nel cybercrime comune.
• Pazienza operativa e sviluppo attivo: la campagna è attiva da maggio 2025, con nuove varianti introdotte regolarmente; l’introduzione del naming big-* a novembre 2025 dimostra sviluppo continuativo.
• RAT multi-linguaggio: la disponibilità di tre versioni del RAT (JS, Python, VBS) indica un’organizzazione con risorse, non un singolo attore.

Timeline della campagna

• 2 maggio 2025: primo pacchetto npm pubblicato (graphalgo@2.2.6)
• 13 giugno 2025: prima variante PyPI
• 17 novembre 2025: introdotta la variante di naming big-* su npm
• 9 dicembre 2025: variante big-* appare su PyPI
• 4 febbraio 2026: identificata variante VBS del RAT (SHA1: dbb4031e9bb8f8821a5758a6c308932b88599f18)
• Aprile 2026: campagna ancora attiva con nuovi package pubblicati settimanalmente

Indicatori di compromissione (IoC)

Domini C2

codepool[.]cloud
aurevian[.]cloud

Organizzazione GitHub malevola

johns92/blog_app (secondo stadio)
raw.githubusercontent.com/johns92/blog_app/refs/heads/main/server/.env.example

File sospetti

graph-settings.min.js
graph-alg.min.js
graph_config.py
load_libraries.py
/Scripts/startup.js  (directory Chrome)

Hash (variante VBS del RAT)

SHA1: dbb4031e9bb8f8821a5758a6c308932b88599f18

Come proteggersi

• Verificare sempre l’identità del recruiter e dell’azienda prima di clonare ed eseguire qualsiasi codice proveniente da task tecnici
• Controllare la presenza nei propri progetti di dipendenze con nomi graph-* o big-* non riconducibili a librerie standard
• Ispezionare i processi in esecuzione per connessioni verso codepool[.]cloud e aurevian[.]cloud
• Verificare l’integrità delle estensioni browser, in particolare MetaMask
• Se si ha un wallet crypto sull’host potenzialmente compromesso: considerarlo esposto e ruotare immediatamente le chiavi/generare un nuovo wallet
• Segnalare offerte di lavoro sospette che richiedono l’esecuzione di codice a npm security (npm.community) e PyPI (security@pypi.org)

Fonti primarie: ReversingLabs – Inside Graphalgo | ReversingLabs – Fake Recruiter Campaign | GBHackers

Fake recruiter campaign targets crypto developers with RAT | ReversingLabs

A new branch of a well-coordinated fake job recruitment campaign is targeting Javascript and Python developers via social channels.

^{Karlo Zanki (ReversingLabs)}

(in)sicurezza digitale

2026-04-10 07:11:43

TeamPCP: la gang che ha avvelenato la supply chain del software e violato la Commissione Europea

Si parla di:
Toggle

• La catena del veleno: come funziona una supply chain attack
• Il punto di partenza: Trivy e le credenziali rubate
• L’effetto domino: npm, Checkmarx, LiteLLM, Telnyx
• L’anatomia del payload: sei fasi per compromettere tutto
• Il colpo più clamoroso: la Commissione Europea
• Indicatori di compromissione (IoC)
• Cosa fare se si è stati esposti

Tra marzo e aprile 2026, un gruppo criminale noto come TeamPCP ha orchestrato uno degli attacchi alla supply chain del software più devastanti degli ultimi anni: in meno di dieci giorni ha compromesso strumenti di sicurezza usati da milioni di sviluppatori, rubato credenziali da oltre 500.000 sistemi e — grazie a una chiave AWS sottratta — ha violato le infrastrutture cloud della Commissione Europea, esfiltrando 340 GB di dati da 71 enti dell’Unione.

La catena del veleno: come funziona una supply chain attack

Attaccare uno strumento usato da migliaia di organizzazioni significa colpire migliaia di bersagli con una singola operazione. TeamPCP ha applicato questa filosofia in modo sistematico, con una raffinatezza tecnica che ha sorpreso persino i ricercatori più esperti. Il punto critico sfruttato è quello che in gergo si chiama trusted build pipeline: le pipeline CI/CD che automaticamente scaricano dipendenze, eseguono scanner di sicurezza e pubblicano package su registri pubblici come npm e PyPI. Una volta compromessa questa infrastruttura, il codice malevolo si propaga silenziosamente a tutti gli utilizzatori del pacchetto.

Il punto di partenza: Trivy e le credenziali rubate

Il 19 marzo 2026, TeamPCP ha sfruttato credenziali CI/CD parzialmente ruotate dopo un incidente minore avvenuto a fine febbraio nel repository GitHub di Aqua Security Trivy — uno degli scanner di vulnerabilità open-source più utilizzati al mondo. Con queste credenziali, il gruppo ha pubblicato una versione malevola (v0.69.4) del tool ed eseguito il force-push di 76 dei 77 tag della GitHub Action aquasecurity/trivy-action, sostituendo i tag legittimi con commit malevoli.

In parallelo, il gruppo ha deturpato l’organizzazione GitHub di Aqua Security, rinominando 44 repository con il prefisso “tpcp-docs-” — un messaggio esplicito: “TeamPCP Owns Aqua Security.”

L’effetto domino: npm, Checkmarx, LiteLLM, Telnyx

A partire dal 20 marzo, TeamPCP ha sfruttato le credenziali sottratte per propagarsi orizzontalmente su altri ecosistemi:

• npm (20–22 marzo): Compromessi più di 45 pacchetti, inclusi scope @emilgroup e @opengov, con deployment di un worm auto-replicante focalizzato su payload Kubernetes.
• Checkmarx (23 marzo): Le GitHub Actions KICS e AST sono state backdoorate; compromesse anche due estensioni OpenVSX.
• LiteLLM (24 marzo): Due versioni del popolare AI gateway PyPI (1.82.7 e 1.82.8) pubblicate con payload malevoli. Particolarmente insidiosa la 1.82.8: il malware è stato iniettato in un file .pth denominato litellm_init.pth. L’interprete Python processa automaticamente i file .pth all’avvio, il che significa che il malware si eseguiva ad ogni avvio di qualsiasi processo Python, indipendentemente dal fatto che LiteLLM fosse mai importato.
• Telnyx (27 marzo): Versioni 4.87.1 e 4.87.2 avvelenate con un payload particolarmente creativo: il malware veniva scaricato da un file WAV (ringtone.wav) — un secondo stadio XOR-cifrato nascosto steganograficamente nei frame audio del file.

L’anatomia del payload: sei fasi per compromettere tutto

Il payload di LiteLLM operava in sei fasi distinte:

1. Raccolta credenziali: variabili d’ambiente, chiavi SSH, credenziali cloud (AWS, GCP, Azure), token Kubernetes, configurazioni Docker, cronologia shell, credenziali database, wallet file, segreti CI/CD.
2. Cifratura: chiave di sessione AES-256 con wrapping RSA-4096.
3. Esfiltrazione: dati inviati a models.litellm[.]cloud con header HTTP X-Filename: tpcp.tar.gz.
4. Persistenza: creazione di ~/.config/sysmon/sysmon.py e unità systemd sysmon.service.
5. Payload secondario: polling di https://checkmarx[.]zone/raw per eseguire codice controllato dagli attaccanti.
6. Propagazione Kubernetes: se disponibili token di service account, creazione di pod privilegiati node-setup-* per espandersi nel cluster.

Vale la pena sottolineare un dettaglio agghiacciante sul deploy Kubernetes: sui sistemi ritenuti non iraniani, veniva creato un DaemonSet host-provisioner-std; sui sistemi con caratteristiche riconducibili all’Iran, veniva invece lanciato un container denominato kamikaze che cancellava il filesystem dell’host e forzava il reboot del nodo — un payload distruttivo deliberatamente riservato a un target geopolitico specifico.

Il colpo più clamoroso: la Commissione Europea

Il 19 marzo, il payload Trivy aveva silenziosamente sottratto le chiavi API AWS della piattaforma Europa di hosting web dell’Unione Europea — chiavi che, come si è scoperto, funzionavano come master key sull’intera infrastruttura cloud della Commissione. Passano cinque giorni prima che l’accesso venga rilevato.

La timeline della crisi istituzionale:

• 19 marzo: accesso iniziale, chiavi AWS sottratte tramite Trivy
• 24 marzo: rilevamento dell’accesso anomalo (5 giorni di dwell time)
• 25 marzo: CERT-EU viene notificato
• 28 marzo: le credenziali compaiono sul dark web, pubblicate da ShinyHunters
• 2 aprile: la Commissione Europea divulga ufficialmente l’incidente

Il bilancio: 340 GB esfiltrando (91,7 GB compressi) da 71 enti clienti della piattaforma EU — 42 dipartimenti interni della Commissione più 29 altri enti UE. Inclusi circa 52.000 file email (2,22 GB di comunicazioni in uscita). Almeno 30 entità dell’Unione potenzialmente impattate, rendendo questo uno dei breach più significativi nella storia delle istituzioni europee.

La comparsa dei dati su ShinyHunters apre ulteriori interrogativi: il gruppo criminale opera indipendentemente da TeamPCP, suggerendo che le credenziali siano state cedute o vendute, complicando ulteriormente il quadro di attribuzione.

Indicatori di compromissione (IoC)

Rete

models.litellm[.]cloud
checkmarx[.]zone
83.142.209[.]203 / 83.142.209[.]11
46.151.182[.]203
championships-peoples-point-cassette.trycloudflare.com
investigation-launches-hearings-copying.trycloudflare.com
aquasecurtiy[.]org  (typosquat)

Filesystem

litellm_init.pth
~/.config/sysmon/sysmon.py
~/.config/systemd/user/sysmon.service
/tmp/pglog
/tmp/.pg_state

Kubernetes

Pod names: node-setup-*
DaemonSets: host-provisioner-std, host-provisioner-iran
Container names: kamikaze, provisioner

Cosa fare se si è stati esposti

• Aggiornare immediatamente i package colpiti alle versioni sicure (verificare i changelog ufficiali dei maintainer)
• Ruotare tutte le credenziali presenti sull’host: AWS, GCP, SSH, database, token CI/CD
• Verificare la presenza del file litellm_init.pth e del servizio sysmon.service
• Analizzare i log di rete per traffico verso i domini e IP indicati negli IoC
• Se si opera Kubernetes, ispezionare pod e DaemonSet per anomalie
• Se si trovano tracce di compromissione, considerare l’host come completamente compromesso e procedere a re-imaging

Fonti primarie: Datadog Security Labs | Palo Alto Unit42 | SANS ISC

Weaponizing the Protectors: TeamPCP’s Multi-Stage Supply Chain Attack on Security Infrastructure

TeamPCP continues its string of supply chain attacks, and announces a partnership with Vect ransomware group.

^{Unit 42}