Si parla di:

Toggle

Per mesi, dentro la chat privata di uno dei gruppi più prolifici nella compromissione delle supply chain open source, si è nascosto un analista di #Google #Mandiant sotto falsa identità. Non un semplice osservatore passivo: qualcuno che ha costruito pazientemente una copertura credibile, ha guadagnato la fiducia di un membro chiave del gruppo #TeamPCP (tracciato anche come UNC6780) ed è entrato nel canale ristretto “CanisterWorm”, dove una dozzina di persone pianificava attacchi contro #npm, #PyPI e Docker Hub. Il 20 settembre Google ha reso pubblica l’operazione, rivelando non solo i dettagli tecnici della campagna ma anche come sia riuscita a smontarla dall’interno, fino agli arresti in Australia dei presunti vertici del gruppo.

Chi è TeamPCP e perché faceva pauraTeamPCP non è un nome nuovo per chi segue le vicende del supply chain #hacking nell’ecosistema open source. Dall’inizio del 2026 il gruppo è stato collegato a una lunga sequenza di compromissioni che hanno colpito, tra gli altri, #Trivy, #LiteLLM, Checkmarx (con l’immagine Docker ufficiale di KICS trojanizzata), TanStack e persino i pacchetti npm enterprise di SAP e Mistral AI. Il filo conduttore di queste campagne è un worm auto-propagante ribattezzato Mini Shai-Hulud — un omaggio non troppo velato ai vermi delle sabbie di Dune — capace di incatenare compromissioni successive lungo l’intera catena di dipendenze: dal furto di token di autenticazione su macchine di sviluppo e pipeline CI/CD, alla propagazione laterale verso bersagli a valle, fino all’automazione completa del ciclo. Un’altra operazione collegata, soprannominata Megalodon, ha portato alla compromissione di oltre 5.500 repository GitHub in appena sei ore tramite workflow CI/CD malevoli. Secondo Google, il bilancio complessivo supera le 1.000 organizzazioni colpite, tra cui nomi come GitHub, OpenAI, la Commissione Europea e la società di recruiting Mercor.

La talpa dentro CanisterWormCiò che distingue questa vicenda da un classico report di threat intelligence è il metodo con cui Google ha ottenuto le informazioni. Secondo quanto ricostruito dal team di Austin Larsen del Google Threat Intelligence Group, un analista Mandiant ha investito diversi mesi nella costruzione di una persona online credibile, coltivando un rapporto di fiducia con un futuro membro del gruppo ancora prima che questi entrasse formalmente in TeamPCP. A marzo 2026 questo lavoro ha dato accesso al canale interno “CanisterWorm”, frequentato da circa una dozzina di persone. Da lì, l’analista ha osservato le operazioni per settimane, mantenendo il minimo indispensabile di interazione necessario a non destare sospetti e senza mai partecipare attivamente agli attacchi. “Scrivere report può essere utile solo fino a un certo punto”, ha dichiarato Google, sintetizzando un cambio di paradigma che porta i team di threat intelligence da un ruolo puramente osservativo a uno di disruption attiva.

L’accesso privilegiato ha permesso a Google di raggiungere il server su cui TeamPCP archiviava le credenziali rubate: oltre 500.000 credenziali tra token e chiavi di accesso a repository, registry e servizi cloud. Invece di procedere a notifiche singole — un processo lento e con un’ampia finestra di esposizione — Google ha scelto la revoca massiva, coordinandosi direttamente con AWS e Microsoft per invalidare le chiavi compromesse, ed è ha inviato centinaia di alert alle organizzazioni coinvolte, riuscendo in diversi casi a bloccare attacchi già pianificati prima che venissero lanciati.

L’arma segreta: exploit generati con l’IAUno degli aspetti più significativi emersi dall’infiltrazione riguarda il livello di sofisticazione tecnica raggiunto dal nucleo storico di TeamPCP. Google ha confermato che alcuni membri hanno utilizzato strumenti di intelligenza artificiale per sviluppare exploit zero-day, incluso un bypass dell’autenticazione a due fattori funzionante contro un prodotto di login ampiamente diffuso. Non un esperimento accademico: Google ha verificato che l’exploit funzionava esattamente come progettato. È un dato che si inserisce in un trend più ampio già osservato da diversi threat intelligence team nel 2026, dove gruppi criminali con competenze tecniche limitate riescono a colmare il gap sfruttando modelli linguistici per la ricerca di vulnerabilità e la scrittura di codice offensivo.

Dalla chat agli arresti in AustraliaL’operazione di infiltrazione si è conclusa il 27 agosto 2026. Circa un mese dopo, la Polizia Federale Australiana ha arrestato due sospetti, entrambi poco più che ventenni: Ruben Ian Thomson e Louis Michael Gaebler. La deanonimizzazione è passata attraverso un mix di OSINT e collaborazione internazionale: un leak di dati su BreachForums ha collegato uno pseudonimo utilizzato dal gruppo a un indirizzo Gmail; archivi di forum risalenti al 2019 hanno associato lo stesso handle a un account PayPal legato a un dominio familiare; infine, un backup su Google Drive collegato all’account Gmail compromesso ha fornito le prove decisive. Un mandato dell’FBI, eseguito in coordinamento con le forze dell’ordine australiane, ha portato alla cattura dei due sospetti.

Cosa cambia per chi difende la supply chainAl di là della componente spionistica, la vicenda TeamPCP resta prima di tutto un caso di studio su come proteggere le pipeline di sviluppo moderne. Google raccomanda ai team che gestiscono pacchetti open source e infrastrutture CI/CD di adottare contromisure ormai da considerarsi indispensabili:

Migrare a credenziali di pubblicazione a breve durata basate su OIDC, evitando token statici e di lunga durata

Pinnare le dipendenze tramite hash crittografico invece che per intervallo di versione

Disabilitare gli script di installazione lifecycle (preinstall/postinstall) negli ambienti CI

Limitare (scope) i token dei registry a singoli pacchetti anziché ad account interi

Imporre chiavi hardware FIDO2 per gli account con privilegi di pubblicazione

La scala dell’operazione — oltre 500.000 credenziali sottratte e più di mille organizzazioni coinvolte in appena pochi mesi — conferma quanto l’ecosistema open source resti un bersaglio ad altissimo rendimento per attori con competenze anche solo moderate ma capacità di automazione avanzate. Il fatto che a fermare la campagna sia stata un’infiltrazione umana, più che un sistema di detection automatizzato, dice molto sui limiti attuali della difesa puramente tecnologica contro gruppi organizzati e disciplinati nell’operational security.

Indicatori e riferimenti operativiNomi campagna/gruppo: TeamPCP (UNC6780), CanisterWorm (canale interno)
Toolchain: Mini Shai-Hulud (worm auto-propagante), Megalodon (compromissione workflow CI/CD)
Ecosistemi colpiti: npm, PyPI, Docker Hub, GitHub Actions
Target noti: Trivy, LiteLLM, Checkmarx/KICS, TanStack, Mistral AI, SAP (pacchetti npm), Mercor
Credenziali sottratte: >500.000 (token, chiavi API, credenziali cloud)
Organizzazioni impattate: >1.000
Sospetti arrestati: Ruben Ian Thomson, Louis Michael Gaebler (Australia)
Mitigazioni consigliate: OIDC short-lived, dependency pinning by hash, disabilitazione lifecycle script, token scoping, FIDO2

Si parla di:

Toggle

Quattordici pacchetti #npm, camuffati da innocue utility per calendari e “streak” di produttività, sono in realtà il vettore di una delle campagne più sofisticate degli ultimi mesi contro la supply chain open source. Il payload si chiama RedC2 4.0 ed è la nuova generazione di un framework di comando e controllo commerciale che, per la prima volta, integra un vero e proprio agente AI capace di tradurre istruzioni in linguaggio naturale in comandi operativi post-exploitation. Il caso, documentato il 21 agosto 2026 dal team TrendAI (la divisione enterprise di Trend Micro) grazie al lavoro del ricercatore Aliakbar Zahravi, segna un salto di qualità nella criminalità informatica “as-a-service”: non serve più essere un operatore esperto per condurre un’intrusione complessa, basta saper scrivere un prompt.

Come funziona l’infezione: un import vale una backdoorI quattordici pacchetti — tra cui streak-metrics-math, kit-map-vim, streak-map-cache, streak-map-kit, map-streak-kit, streak-cache-map, streak-calc-metrics, streak-calc-math, streak-math-abz, streak-metricsaz, streak-math-metrics, streak-metricazbd, streak-metricsazb e streak-kit-map — mantengono la funzionalità dichiarata (calcolo di statistiche e “streak” di calendario) per non destare sospetti in fase di code review. Il payload malevolo è però innescato senza bisogno di alcun hook di installazione: secondo l’analisi di TrendAI, “quando il modulo si carica, localizza il binario incluso, lo rende eseguibile e lo avvia come processo detached in background”. Basta quindi un semplice import del pacchetto perché l’impianto #Linux si attivi automaticamente, senza passare per postinstall scripts più facilmente intercettabili dai controlli di #sicurezza automatizzati.

I binari, con nomi che variano da pacchetto a pacchetto (math-core.bin, math-calc.bin, calc-math.dat, calc-cache.bin, calc.bin, calc-mapping.bin), sono collocati nelle directory dist/ o dist/internal/ del pacchetto, un’ubicazione volutamente innocua che si mimetizza nella normale struttura di un modulo Node.js.

RedShell: il beacon Linux e le sue capacitàLa variante Linux del framework, battezzata RedShell Beacon, fornisce agli attaccanti una shell interattiva tramite /bin/sh ed espone comandi dedicati alla ricognizione del sistema, alla raccolta di credenziali (comprese le chiavi #SSH e le credenziali salvate nei #browser), alla persistenza e all’esecuzione in-memory di file ELF, riducendo così le tracce lasciate su disco. La variante #Windows del framework va oltre, aggiungendo bypass di UAC, rilevamento e tampering degli #antivirus e strumenti per il movimento laterale in rete.

Sul piano cross-platform, RedC2 4.0 offre capacità che lo rendono paragonabile a framework offensivi di fascia alta come Cobalt Strike o Sliver: tunneling host-to-host e pivoting di rete, trasferimento file e consegna di payload in fasi successive, esecuzione in memoria di Beacon Object File (BOF), assembly .NET e shellcode. Non stupisce che il prezzo di listino sul canale di distribuzione “Red Offsec” sia fissato a 99,99 dollari: un investimento minimo per capacità offensive un tempo riservate ad attori con risorse ben più consistenti.

“Red Agent”: quando l’IA orchestra il post-exploitationL’elemento che distingue davvero questa release è il componente denominato “Red Agent”, un modulo basato su LLM che trasforma intenzioni espresse in linguaggio naturale in comandi beacon del framework. In pratica, l’operatore non deve più conoscere a memoria la sintassi dei comandi RedShell: può limitarsi a formulare richieste come “enumera gli host raggiungibili in rete” o “raccogli le credenziali salvate”, lasciando che sia l’agente AI a tradurle in azioni concrete di ricognizione, movimento laterale e credential dumping. È lo stesso paradigma che negli ultimi mesi ha abbassato la barriera d’ingresso per campagne di phishing e sviluppo malware — applicato però direttamente alla fase più delicata di un attacco, quella successiva alla compromissione iniziale, dove finora serviva esperienza operativa reale per non farsi scoprire.

Timeline di un framework in evoluzioneAgosto 2025 — Rilascio di RedC2 v2.0

Gennaio 2026 — Commercializzazione della v3.0

Giugno 2026 — L’attore “MarlboroMan” pubblicizza la v4.0 su Hack Forums

Agosto 2026 — TrendAI scopre la campagna di distribuzione via npm con i 14 pacchetti trojanizzati

Due righe per i difensoriIl caso RedC2 conferma una tendenza consolidata: gli attaccanti prediligono nomi di pacchetti “typosquattati” su termini generici e popolari (in questo caso legati a calendari e tracking di abitudini) proprio perché generano traffico di installazione costante e passano più facilmente inosservati tra le migliaia di dipendenze di un progetto Node.js. TrendAI non ha reso pubblici hash o indicatori di rete specifici al momento della pubblicazione, ma i nomi dei pacchetti e dei binari incorporati restano il principale segnale di compromissione disponibile.

Per i team di sicurezza, le priorità operative sono chiare: verificare immediatamente la presenza di uno qualsiasi dei pacchetti elencati nelle dipendenze dirette o transitive dei propri progetti (anche tramite npm ls o strumenti SCA), monitorare i processi detached generati subito dopo l’installazione di nuovi moduli npm, applicare policy di allow-listing per i pacchetti approvati nei pipeline CI/CD e verificare la presenza di file binari eseguibili — un pattern estremamente anomalo per una libreria JavaScript pura — all’interno delle directory dist/. La comparsa di agenti AI integrati nei toolkit offensivi commerciali suggerisce inoltre che i prossimi mesi vedranno una proliferazione di varianti sempre più accessibili, e che la difesa dovrà spostarsi sempre più a monte, sulla supply chain, piuttosto che sul solo endpoint.

Indicatori di compromissione# Pacchetti npm trojanizzati (RedC2 4.0 / RedShell)
streak-metrics-math@1.0.0, 1.0.1
kit-map-vim@1.0.0
streak-map-cache@1.0.0
streak-map-kit@1.0.0
map-streak-kit@1.0.0
streak-cache-map@1.0.0
streak-calc-metrics@1.0.0
streak-calc-math@1.0.0
streak-math-abz@1.0.0
streak-metricsaz@1.0.0
streak-math-metrics@1.0.0
streak-metricazbd@1.0.0
streak-metricsazb@1.0.0
streak-kit-map@1.0.0

Nomi dei binari embedded (in dist/ o dist/internal/)

math-core.bin
math-calc.bin
calc-math.dat
calc-cache.bin
calc.bin
calc-mapping.bin

Comportamento indicativo (host Linux)

• Processo detached avviato subito dopo import del modulo
• Shell interattiva via /bin/sh generata da processo Node.js
• Persistenza via cron job o unit systemd non riconducibile a software noto
• Accesso in lettura a ~/.ssh/ e a credential store dei browserFonti: TrendAI / Trend Micro (Aliakbar Zahravi), The Hacker News.