differx

2026-04-09 21:14:12

quando dagli #USA farciti di fucili arriva la periodica notizia dello squilibrato che entra in un asilo o una scuola elementare e spara all'impazzata, tutti i giornalisti piangono come vitelli e si inasta il lutto mondiale.
quando uno stato genocida ammazza decine di migliaia di bambini palestinesi e inizia a falciarne anche in #Libano e #Iran , i giornali fischiettano e la bandiera che sventola riverita e felice pure in occidente è quella con la stella degli assassini.

#israhell
#genocidio

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