(in)sicurezza digitale

2026-07-02 12:54:21

Da un runner Jenkins ad Amazon Redshift: come il worm Shai-Hulud trasforma una CI/CD in una breach cloud

Si parla di:
Toggle

Un worm nato per infettare pacchetti npm, pensato per propagarsi da un progetto all’altro sottraendo token di pubblicazione, si è trasformato in un vettore capace di arrivare fino a un data warehouse Amazon Redshift in produzione. È la traiettoria che i ricercatori di FortiGuard Labs hanno ricostruito analizzando una compromissione partita da un semplice runner Jenkins esposto: nel giro di poche ore, l’attaccante è passato da un job di build a pieni poteri amministrativi sull’intero account AWS.

Shai-Hulud: la storia del worm che ha terrorizzato npm

Battezzato con il nome dei vermi delle sabbie di Dune, Shai-Hulud è emerso per la prima volta alla fine del 2025 come campagna di supply chain attack contro l’ecosistema npm, e da allora è stato attribuito al cluster tracciato come TeamPCP. Il meccanismo è quello del worm classico: un pacchetto compromesso esegue codice malevolo durante l’installazione o all’interno di una pipeline CI, ruba i token e le credenziali di build presenti sulla macchina, e li usa per pubblicare versioni trojanizzate di altri pacchetti di cui il maintainer ha accesso — propagandosi così, in autonomia, lungo l’intero grafo delle dipendenze.

La variante più recente, Shai-Hulud 2.0, ha alzato ulteriormente l’asticella: all’infezione di un pacchetto legittimo vengono iniettati due file, setup_bun.js e bun_environment.js, attivati tramite uno script di preinstall (anziché postinstall come nella prima ondata) — una modifica che amplia sensibilmente la superficie di impatto perché il codice malevolo scatta prima ancora che l’installazione del pacchetto sia completa. Il payload offuscato raccoglie credenziali da oltre 100 percorsi di file diversi, spaziando da provider cloud a wallet di criptovalute, tool AI e app di messaggistica, e installa hook di persistenza dentro Claude Code, VS Code e servizi a livello di sistema operativo, capaci di sopravvivere al riavvio della macchina. Secondo le stime della community, la campagna 2.0 ha compromesso almeno 796 pacchetti npm unici (1.092 versioni), toccando oltre 25.000 repository riconducibili a circa 350 maintainer.

Dal runner Jenkins a Redshift: la ricostruzione di FortiGuard Labs

Il caso analizzato da FortiCNAPP nasce a metà maggio 2026, quando gli analisti individuano su un ambiente cliente l’accesso persistente a un Jenkins runner con un pattern di credential-harvesting coerente con Shai-Hulud. Il runner, raggiungibile da internet, viene usato dall’attaccante come testa di ponte: sfruttando il ruolo IAM associato al job Jenkins, l’operatore compie un’escalation di privilegi fino a ottenere pieno accesso amministrativo sull’account cloud, dopodiché modifica i controlli di rete del database e avvia l’estrazione di dati da Amazon Redshift.

La sequenza operativa ricostruita da FortiGuard Labs è particolarmente istruttiva perché mostra quanto velocemente un accesso CI/CD apparentemente marginale possa tradursi in un data breach cloud su vasta scala:

• Creazione di un utente IAM con nome cloudops-monitor, pensato per confondersi con account di monitoraggio legittimi.
• Attribuzione della policy AdministratorAccess al nuovo utente ed emissione di access key.
• Modifica dei security group per allargare l’accesso di rete verso i database.
• Tentativi di modifica della configurazione di accesso a RDS e Redshift.
• Enumerazione sistematica di AWS Secrets Manager, con recupero dei secret collegati al data warehouse.
• Uso ripetuto della Redshift Data API (chiamate ExecuteStatement, DescribeStatement e successivo recupero dei risultati) per interrogare ed esfiltrare dati senza bisogno di una connessione diretta al cluster.
• Creazione di policy IAM con nomi espliciti dal chiaro intento di esfiltrazione, assunzione di ruoli con session name come exfil, e uso di SSM SendCommand insieme alla verifica di identità su Amazon SES — probabilmente in preparazione di un canale di invio dati o notifiche verso l’esterno.

Questa catena mostra un salto qualitativo rispetto alle prime campagne Shai-Hulud, centrate quasi esclusivamente sul furto di token npm e credenziali di sviluppatori: qui l’obiettivo finale è chiaramente il dato strutturato in un data warehouse aziendale, raggiunto attraverso l’abuso sistematico dei permessi IAM disponibili nella pipeline compromessa.

Perché la CI/CD è il bersaglio ideale

I runner Jenkins, GitHub Actions e sistemi CI/CD analoghi sono per costruzione dei nodi ad alto privilegio: hanno bisogno di credenziali per pubblicare pacchetti, effettuare il deploy su infrastruttura cloud e interagire con registry e repository. Quando queste credenziali sono sovradimensionate rispetto al reale bisogno — un ruolo IAM che consente escalation invece di essere ristretto al minimo indispensabile — un singolo pacchetto npm compromesso durante una build automatica può bastare per compiere il salto da “sviluppatore infettato” a “amministratore dell’intero account cloud”. È esattamente lo scenario che rende Shai-Hulud diverso da un comune infostealer: non si limita a rubare, usa quello che ruba per muoversi lateralmente e scalare privilegi in autonomia.

Raccomandazioni per i difensori

• Applicare il principio del minimo privilegio ai ruoli IAM usati dai runner CI/CD: nessun job di build dovrebbe poter assumere ruoli con permessi di amministrazione dell’account.
• Isolare i runner Jenkins/CI da internet o proteggerli dietro autenticazione forte e reti segmentate.
• Monitorare la creazione di utenti/ruoli IAM anomali, in particolare l’attribuzione di AdministratorAccess a identità nuove o non previste nell’infrastructure-as-code.
• Alert su chiamate massive alla Redshift Data API o pattern insoliti di query su data warehouse da identità di servizio.
• Verificare l’eventuale presenza degli script setup_bun.js e bun_environment.js in node_modules, e controllare gli script di preinstall dei pacchetti recentemente aggiornati.
• Applicare lockfile e pinning delle versioni, con verifica delle firme dei pacchetti dove disponibile, per limitare l’impatto di aggiornamenti automatici malevoli.
• Ruotare immediatamente tutte le credenziali (token npm, chiavi AWS, secret in Secrets Manager) se si sospetta una compromissione, anche parziale, della toolchain di sviluppo.

Il caso ricostruito da FortiGuard Labs è un promemoria scomodo: la supply chain del software open source non è più solo un problema di sviluppatori, ma un vettore diretto verso i dati più sensibili dell’azienda, quando la fiducia implicita accordata alle pipeline di build non è accompagnata da controlli granulari sui permessi cloud.

Indicatori di compromissione

Malware: Shai-Hulud / Shai-Hulud 2.0 (worm supply chain, ecosistema npm/PyPI)
Attore: TeamPCP (cluster tracciato)

File iniettati nei pacchetti compromessi:
  setup_bun.js
  bun_environment.js
Trigger: script "preinstall" (2.0) invece di "postinstall" (1.0)

Scala campagna 2.0 (stime community):
  796+ pacchetti npm unici compromessi
  1.092 versioni di pacchetto interessate
  25.000+ repository coinvolti
  ~350 maintainer impattati

Catena post-compromissione osservata da FortiGuard Labs (caso Jenkins -> Redshift):
  - Nuovo utente IAM: cloudops-monitor
  - Policy attribuita: AdministratorAccess
  - Modifica security group per esporre database
  - Enumerazione AWS Secrets Manager
  - Uso Redshift Data API: ExecuteStatement / DescribeStatement
  - Ruoli assunti con session name: "exfil"
  - Attività su SSM SendCommand e verifica identità Amazon SES

Persistenza osservata su endpoint sviluppatore:
  Hook in Claude Code, VS Code, servizi OS-level (sopravvivono al reboot)

Riferimento tecnico: FortiGuard Labs,
"From CI/CD to Cloud Data: How Shai Hulud Persistence Leads to Redshift Breach"

(in)sicurezza digitale

2026-07-02 12:55:36

ShinyHunters e lo zero-day PeopleSoft: il regolatore assicurativo USA tra le 100+ vittime di UNC6240

Si parla di:
Toggle

Per due settimane, prima ancora che Oracle pubblicasse una patch, un gruppo di cybercriminali ha avuto le chiavi di oltre cento infrastrutture PeopleSoft in tutto il mondo. Tra le vittime finite nella rete c’è la National Association of Insurance Commissioners (NAIC), l’organizzazione che coordina la vigilanza assicurativa dei 50 stati USA: 3,1 terabyte di dati pubblicati online, agenzie di rating che hanno sospeso i feed verso il regolatore, e la firma inconfondibile di ShinyHunters, oggi meglio nota agli analisti come UNC6240.

Chi c’è dietro l’attacco: da ShinyHunters a Scattered LAPSUS$ Hunters

ShinyHunters non è un nome nuovo per chi segue il cybercrime dei data breach: attivo almeno dal 2019 e comparso pubblicamente nel maggio 2020 con la vendita di dati sottratti a oltre una dozzina di aziende, il gruppo ha costruito la propria reputazione sul modello “pay or leak” — contatto privato con la vittima, richiesta di riscatto, pubblicazione dei dati in caso di rifiuto. Dal 2025 ShinyHunters opera in una struttura più ampia e fluida, la cosiddetta Scattered LAPSUS$ Hunters (SLH), un’alleanza informale che unisce le competenze di Scattered Spider (accesso iniziale tramite social engineering e SIM swap), LAPSUS$ (estorsione ad alta visibilità mediatica) e ShinyHunters stesso, specializzato in exfiltration su larga scala e gestione dei data leak site. È la stessa federazione già dietro le violazioni a catena di Salesforce e Snowflake nel 2025.

Mandiant e il Google Threat Intelligence Group tracciano il cluster responsabile della campagna PeopleSoft con la sigla UNC6240, confermando la sovrapposizione operativa con ShinyHunters.

CVE-2026-35273: RCE non autenticata nel cuore di PeopleSoft

Il vettore d’ingresso è una vulnerabilità critica (CVSS 9.8) in Oracle PeopleSoft Enterprise PeopleTools, versioni 8.61 e 8.62, localizzata nel componente Environment Management Hub, noto anche come PSEMHUB. Tecnicamente si tratta di una Server-Side Request Forgery che, incatenata correttamente, consente l’esecuzione di codice remoto senza alcuna autenticazione né interazione dell’utente: basta accesso di rete via HTTP agli endpoint /PSEMHUB/hub e /PSIGW/HttpListeningConnector per prendere il controllo del server.

Il dettaglio più inquietante è la tempistica. Secondo Mandiant, lo sfruttamento attivo in the wild è iniziato il 27 maggio 2026, ben prima che Oracle rilasciasse un advisory di sicurezza: un vero zero-day, sfruttato per circa due settimane a insaputa dei difensori. Solo il 10 giugno 2026 Oracle ha pubblicato una patch fuori banda (Patch Availability Document CPU187), poi confluita nel Critical Patch Update di giugno. Nel frattempo, CISA ha aggiunto la falla al proprio catalogo Known Exploited Vulnerabilities.

Una campagna su scala industriale

Tra il 27 maggio e il 9 giugno gli attaccanti hanno colpito circa 300 istanze PeopleSoft appartenenti a oltre 100 organizzazioni, con il 68% delle vittime concentrato nel settore dell’istruzione superiore, in gran parte negli Stati Uniti. Il gruppo ha pubblicato i dati sottratti sul proprio data leak site già il 9 giugno, un giorno prima ancora della patch ufficiale.

Sul piano operativo, gli attaccanti hanno predisposto ambienti di staging che ospitavano agenti MeshCentral camuffati da servizi Microsoft Azure legittimi (file come meshagent64-azure-ops.exe), utilizzati per eseguire query amministrative ed effettuare movimento laterale. Un elemento tecnico rilevante è lo script di defacement e lateral movement che automatizza il credential spraying via SSH: analizza il file /etc/hosts locale per identificare host interni secondo pattern di naming specifici, poi tenta l’autenticazione con una lista predefinita di credenziali amministrative e applicative comuni.

Il caso NAIC: cosa è stato sottratto

NAIC ha rilevato l’accesso non autorizzato al proprio ambiente PeopleSoft l’11 giugno 2026. ShinyHunters ha rivendicato il furto di 3,1 terabyte di dati, oltre 105.000 file: più di 264.000 PDF di filing regolatori assicurativi (rami property, casualty, health e life) relativi al periodo 2017-2024, circa 45.000 file provenienti da importanti agenzie di rating creditizio (tra cui Moody’s, Fitch, S&P, Kroll, DBRS, AM Best), log e file di configurazione di infrastruttura AWS di produzione, oltre a script SQL contenenti credenziali per ambienti produttivi.

NAIC ha dichiarato che nessun dato personale identificabile né informazioni di pagamento risultano compromessi, e che i sistemi regolatori critici — SERFF, OPTins, UCAA, EDP e RDC — non sono stati toccati. Ma l’impatto operativo è stato comunque tangibile: diverse agenzie di rating hanno sospeso temporaneamente i feed di dati verso il regolatore, e NAIC ha interrotto momentaneamente l’assegnazione delle proprie designazioni di investimento, i parametri che determinano quanto capitale gli assicuratori vita statunitensi devono accantonare a fronte dei propri portafogli. Un breach che tocca un ente pubblico, quindi, si traduce in frizioni immediate sull’intero mercato assicurativo americano.

Cosa devono fare i difensori

• Applicare immediatamente la patch CPU187 di Oracle su tutte le istanze PeopleSoft PeopleTools 8.61/8.62.
• Se il patching non è immediato, bloccare l’esposizione internet degli endpoint EMHub/PSEMHUB o disabilitare il servizio nelle configurazioni multi-server; nelle installazioni single-server valutare la rimozione dell’applicazione PSEMHUB.
• Verificare i log di accesso WebLogic per richieste POST esterne verso /PSEMHUB/hub o /PSIGW/HttpListeningConnector.
• Cercare file .jsp non attesi sotto PSEMHUB.war e cartelle anomale (logs, persistantstorage, scratchpad); controllare modifiche recenti ai file XML sotto envmetadata/data/environment, potenziale vettore di persistenza via XMLDecoder al riavvio.
• Monitorare traffico DNS e connessioni verso il dominio C2 noto azurenetfiles.net.
• Ruotare le credenziali potenzialmente esposte in script SQL, configurazioni e log applicativi.

La campagna NAIC conferma un pattern ormai consolidato per l’alleanza Scattered LAPSUS$ Hunters: individuare zero-day in software enterprise ampiamente diffusi (Salesforce, Snowflake, ora Oracle PeopleSoft), colpire in massa prima che la finestra di patching si chiuda, e monetizzare l’estorsione anche quando i dati sottratti sono in gran parte “pubblici” o di scarso valore diretto — sfruttando la pressione reputazionale e regolatoria che un data leak comporta per l’organizzazione colpita.

Indicatori di compromissione

CVE: CVE-2026-35273 (CVSS 9.8, SSRF -> RCE non autenticata)
Componente: Oracle PeopleSoft PeopleTools 8.61 / 8.62 - Environment Management Hub (PSEMHUB)
Endpoint sfruttati:
  /PSEMHUB/hub
  /PSIGW/HttpListeningConnector

C2 domain: wss://azurenetfiles[.]net:443/agent.ashx

Agenti MeshCentral malevoli (masquerading Azure):
  meshagent32-azure-ops.exe
  meshagent64-azure-ops.exe
  meshagent64-v2.exe

IP di staging (Python HTTP server, porta 8888):
  142.11.200.186 - 142.11.200.190

Percorsi sospetti da monitorare:
  /logs/
  /persistantstorage/
  /scratchpad/
  envmetadata/data/environment/*.xml (persistenza via XMLDecoder)

Attore: UNC6240 (Mandiant) / ShinyHunters / Scattered LAPSUS$ Hunters
Finestra di sfruttamento zero-day: 27 maggio - 9/10 giugno 2026
Patch Oracle: CPU187, rilasciata 10 giugno 2026

Spcnet.it

2026-07-02 09:37:06

WSL Container in Public Preview: container Linux nativi su Windows senza Docker Desktop

Cosa sono i WSL Container?

Microsoft ha annunciato a fine giugno 2026 la public preview di WSL Container, una nuova funzionalità del Windows Subsystem for Linux che porta lo sviluppo di container Linux direttamente in Windows, senza richiedere strumenti di terze parti. L’annuncio è arrivato durante Microsoft Build 2026 e rappresenta un passo significativo verso l’integrazione nativa dei workload containerizzati nell’ecosistema Windows.

I container sono diventati una parte fondamentale dello sviluppo moderno: dalle applicazioni cloud-native ai carichi AI, dai test alle pipeline di deployment. Fino ad ora, gli sviluppatori su Windows dovevano ricorrere a Docker Desktop, Podman Desktop o Rancher Desktop, strumenti di terze parti non sempre ideali in ambienti enterprise per questioni di licensing o di gestione centralizzata. WSL Container punta a risolvere questo problema con una soluzione nativa, enterprise-ready e integrata con le policy di gestione Microsoft.

Le due componenti principali

La CLI: wslc.exe

Il cuore della nuova funzionalità è il binario wslc.exe, disponibile automaticamente nel PATH dopo aver aggiornato WSL alla versione pre-release più recente. La sintassi è volutamente familiare a chiunque abbia già usato Docker:

# Aggiornare WSL alla versione pre-release
wsl --update --pre-release

# Eseguire un desktop Linux completo in un container
wslc run -d --name=webtop \
  -e PUID=1000 \
  -e PGID=1000 \
  -e TZ=Etc/UTC \
  -p 3000:3000 \
  -p 3001:3001 \
  lscr.io/linuxserver/webtop:ubuntu-kde

# Verificare l'accesso GPU con PyTorch
wslc run --rm --gpus all pytorch/pytorch:2.5.1-cuda12.4-cudnn9-runtime \
  python -c "import torch; print(torch.cuda.is_available()); print(torch.cuda.get_device_name(0))"

Esiste anche un alias integrato container.exe che rimanda a wslc.exe, per chi preferisce una sintassi ancora più esplicita. Il fatto di avere uno strumento come exe nel PATH di Windows — non dentro una distro WSL — significa che può essere invocato da qualsiasi terminale Windows, da PowerShell, da script batch o da pipeline CI/CD senza dover prima avviare un ambiente Linux.

La WSL Container API

La seconda componente è un package NuGet che permette alle applicazioni Windows di usare container Linux come parte della propria logica applicativa. L’API supporta C, C++ e C# e consente di gestire programmaticamente pull di immagini, avvio dei container, interazione via stdin/stdout, mount di file, configurazione di rete e accesso GPU.

Un aspetto particolarmente interessante per chi usa MSBuild o CMake è che l’API si integra direttamente nel sistema di build: aggiungendo poche righe ai file di progetto, la build e il deploy del container diventano parte del processo di compilazione dell’applicazione, senza step manuali aggiuntivi.

// Esempio di utilizzo base dell'API WSL Container in C#
// (il package è disponibile su nuget.org)
using Microsoft.WSL.Container;

var client = new WslContainerClient();

// Pull di un'immagine
await client.PullAsync("ubuntu:24.04");

// Avvio del container
var container = await client.RunAsync(new ContainerOptions
{
    Image = "ubuntu:24.04",
    Command = "/bin/bash",
    Interactive = true
});

// Interazione via stdin/stdout
await container.WriteLineAsync("echo 'Hello from Linux container!'");
string output = await container.ReadLineAsync();
Console.WriteLine(output);

Integrazione enterprise

Una delle priorità dichiarate di Microsoft è l’integrazione con gli strumenti di gestione enterprise già in uso nelle organizzazioni.

Microsoft Defender for Endpoint

Il plugin MDE esistente per WSL è stato aggiornato per rilevare anche gli eventi provenienti dai container Linux, offrendo la stessa copertura di sicurezza sia per le distro WSL tradizionali che per i nuovi container. Questa funzionalità è attualmente disponibile in private preview su registrazione.

Gestione con Intune e Group Policy

Tramite un file ADMX già disponibile su GitHub, è possibile configurare policy di gruppo per controllare se gli utenti possono avviare distro WSL o container, e soprattutto specificare una allowlist dei registry di container da cui è consentito fare pull di immagini. Questa è una risposta diretta a una delle richieste più frequenti degli amministratori enterprise: avere controllo sulle immagini Linux autorizzate nell’organizzazione. Il supporto nativo in Intune è previsto nelle settimane successive alla preview.

VS Code Dev Containers

Il supporto a VS Code Dev Containers è stato aggiunto a partire dalla versione 0.462.0-pre-release dell’estensione. La configurazione è semplice: nelle impostazioni dei Dev Containers di VS Code, basta modificare il campo “Docker Path” impostando il valore wslc. In questo modo VS Code utilizzerà wslc.exe invece di Docker per gestire i container di sviluppo.

Miglioramenti a livello di piattaforma

Lo sviluppo di WSL Container ha portato con sé significativi miglioramenti all’infrastruttura di WSL stessa, che beneficeranno anche dei tool di terze parti come Docker Desktop, Podman e Rancher Desktop.

Il filesystem predefinito per WSL Container è ora virtiofs, che raddoppia le prestazioni di accesso ai file Windows rispetto al layer precedente. La modalità di networking predefinita è consomme, una soluzione sperimentale che instrada il traffico di rete Linux attraverso lo stack Windows, garantendo compatibilità con VPN aziendali, proxy e policy di sicurezza di rete già configurate per i client Windows. Infine, sono state introdotte tecniche migliorative per il reclaim della memoria, con rilascio graduale e consistente della RAM non utilizzata dalla VM Linux verso l’host Windows.

Supporto GPU

Una delle funzionalità più rilevanti per chi lavora con carichi di Machine Learning è il supporto nativo alla GPU. Passando il flag --gpus all, i container WSL possono accedere all’hardware grafico dell’host, consentendo a framework come PyTorch di sfruttare l’accelerazione GPU direttamente dall’interno di un container Linux su Windows.

Come iniziare

La funzionalità è disponibile già oggi nella versione pre-release di WSL:

# Installare la versione pre-release di WSL
wsl --update --pre-release

# Oppure scaricare direttamente da GitHub (versione 2.9.3 o superiore)
# https://github.com/microsoft/WSL/releases

# Verificare la versione installata
wsl --version

# Primo test: verificare che wslc sia nel PATH
wslc --version

# Eseguire un container Ubuntu di base
wslc run --rm ubuntu:24.04 echo "WSL Container funziona!"

Per esplorare i sample ufficiali, Microsoft ha pubblicato esempi su GitHub che mostrano l’integrazione con MSBuild e CMake, oltre a casi d’uso per container personalizzati. La documentazione completa è disponibile su aka.ms/wslc.

Considerazioni finali

WSL Container non vuole sostituire Docker, Podman o i tool esistenti — anzi, tutti questi beneficeranno delle migliorie a livello di piattaforma che questa nuova funzionalità porta con sé. L’obiettivo è offrire un’opzione nativa, senza licensing enterprise, con una gestione centralizzata tramite Intune e Group Policy, e con un’integrazione profonda nell’ecosistema di sicurezza Microsoft.

Per i team che già usano WSL intensivamente nel proprio workflow di sviluppo, WSL Container rappresenta un’evoluzione naturale: stessi strumenti, stessa infrastruttura, ma ora con la possibilità di isolare i processi Linux in container veri e propri. La GA è attesa per l’autunno 2026.

Fonte: WSL container is now available for public preview — Windows Command Line Blog (Craig Loewen, 29 giugno 2026)

WSL container is now available for public preview

At Microsoft Build 2026, we introduced WSL containers, bringing Linux container development directly into Windows through the Windows Subsystem for Linux

^{Craig Loewen (Windows Command Line)}

Spcnet.it

2026-07-02 09:37:30

Agent AI e Malware Nascosto: come i Coding Agent vengono Ingannati da Repository GitHub Apparentemente Puliti

I moderni strumenti di coding assistito da AI stanno diventando parte integrante del flusso di lavoro di milioni di sviluppatori. Ma questa automazione introduce una nuova superficie di attacco che i ricercatori di sicurezza hanno appena dimostrato in modo preoccupante: un repository GitHub apparentemente pulito può indurre un agente AI a eseguire malware, senza che nessun codice malevolo sia visibile né agli scanner statici né agli occhi umani.

La ricerca di Mozilla 0DIN

I ricercatori della Mozilla Zero Day Investigative Network (0DIN), la piattaforma di sicurezza AI di Mozilla, hanno pubblicato un proof-of-concept che dimostra come un agente di coding autonomo possa essere indotto a installare una reverse shell sul sistema dello sviluppatore. Il test è stato condotto specificamente con Claude Code, ma la vulnerabilità concettuale riguarda qualsiasi agente AI che abbia accesso al filesystem e al terminale.

La parte più inquietante della ricerca è questa frase dei ricercatori: “No exploit code, no warning, no suspicious command anyone had to approve.” Nessun codice exploit, nessun avvertimento, nessun comando sospetto da approvare.

Come funziona l’attacco: tre componenti innocui

L’attacco si basa su tre elementi che, considerati singolarmente, non destano alcun sospetto:

1. Un repository GitHub pulito — Il repo contiene istruzioni di setup standard: installazione dipendenze (pip3 install -r requirements.txt) e inizializzazione del progetto (python3 -m axiom init). Nessun codice malevolo, nessun flag da scanner.
2. Un pacchetto Python progettato per fallire — Il package è volutamente configurato per rifiutare l’esecuzione finché non viene inizializzato. Genera un errore che istruisce l’utente (o l’agente) a eseguire python3 -m axiom init. L’agente AI, tentando di risolvere autonomamente l’errore di setup, lancia questo comando.
3. Un record DNS TXT controllato dall’attaccante — Il comando di inizializzazione chiama uno script shell che recupera un valore di configurazione da un record DNS TXT controllato dall’attaccante. Quel valore viene eseguito come comando.

Il risultato è una reverse shell con i privilegi del developer. L’agente AI ha eseguito tre livelli di indirection — un messaggio di errore fidato, uno script che ha recuperato un valore, e un record DNS che non ha mai esaminato — senza mai “vedere” il payload malevolo.

Perché è invisibile ai controlli tradizionali

Questa tecnica bypassa tutti i meccanismi di difesa convenzionali:

• Scanner statici: non trovano nulla perché il repository è genuinamente pulito
• Code review umana: anche un revisore attento non vedrebbe codice malevolo
• AI review: l’agente AI valuta solo il codice che vede, non il payload DNS
• Audit log limitati: l’agente potrebbe non registrare l’intera catena di esecuzione, incluse le risorse recuperate dinamicamente a runtime

Ciò che rende l’attacco efficace è il comportamento goal-oriented degli agenti AI: quando incontrano un errore, il loro obiettivo è risolverlo. E lo risolvono eseguendo esattamente ciò che viene suggerito — anche se quel suggerimento porta a recuperare ed eseguire un payload da un record DNS remoto.

Cosa ottiene l’attaccante

Se l’attacco va a segno, l’attaccante ottiene una shell interattiva con i privilegi dello sviluppatore. Questo significa accesso a:

• Variabili d’ambiente (incluse credenziali e API key)
• File di configurazione locali (chiavi SSH, certificati, config di cloud provider)
• Possibilità di stabilire persistenza sul sistema
• Accesso ai repository locali e ai segreti in essi contenuti

I ricercatori 0DIN avvertono che questa tecnica potrebbe essere distribuita facilmente attraverso fake job posting, tutorial, post su blog tecnici o messaggi diretti su piattaforme come Discord o LinkedIn.

Come mitigare il rischio

0DIN ha proposto alcune contromisure concrete per chi sviluppa o utilizza strumenti di coding AI agentico:

1. Execution chain disclosure: gli agenti AI dovrebbero mostrare esplicitamente l’intera catena di esecuzione dei comandi di setup, inclusi script e codice recuperato dinamicamente a runtime, prima di eseguirlo.
2. Sandboxing più rigido: gli agenti autonomi che interagiscono con repository esterni dovrebbero operare in ambienti isolati (container, VM, namespace separati) con privilegi minimi.
3. Permission scoping: limitare le azioni che un agente AI può compiere autonomamente — specialmente l’esecuzione di comandi shell — richiedendo conferma esplicita dell’utente per operazioni ad alto rischio.
4. Monitoraggio DNS in uscita: implementare logging e alerting su query DNS anomale durante le operazioni di build e setup.
5. Analisi comportamentale: non fidarsi solo degli scanner statici, ma adottare strumenti di analisi comportamentale che monitorino le azioni effettive a runtime.

Un segnale di allarme per il settore

Questa ricerca evidenzia un problema strutturale nell’adozione degli agenti AI nel ciclo di sviluppo: l’automazione che ci fa risparmiare tempo è la stessa che può diventare un vettore di attacco. Man mano che strumenti come Claude Code, GitHub Copilot Workspace e altri agenti simili vengono integrati nelle pipeline CI/CD e nei workflow quotidiani, la superficie di attacco si espande in modi che i modelli di minaccia tradizionali non contemplano.

La buona notizia è che, per ora, si tratta di un proof-of-concept. La cattiva è che chiunque abbia letto questa ricerca sa come replicarlo — e il costo per un attaccante è praticamente zero: basta pubblicare un repository GitHub e registrare un dominio per il record DNS TXT.

Per i team di sicurezza, questo è il momento di rivedere le policy di utilizzo degli agenti AI, in particolare per quanto riguarda le operazioni autonome su repository di terze parti.

---

Fonte originale: 4sysops.com — ricerca originale di Mozilla 0DIN via BleepingComputer

AI coding agents vulnerable to stealthy malware execution via GitHub – 4sysops

Security researchers have demonstrated a new attack method that tricks autonomous AI coding agents into executing malicious payloads from seemingly clean GitHub

^{IT News (4sysops)}