// 2 ZERO-DAY · 5 CVE · 2 EXPLOIT · 1 ADVISORY NELLE ULTIME 24H→
Un AI agent autonomo ha correlato in pochi minuti tre piattaforme per ricostruire una campagna di data exfiltration cross-platform partita da un token GitHub compromesso.

Il 29 settembre 2026, Wiz ha pubblicato un caso di studio in cui il suo investigatore SOC autonomo Blue Agent ha ricostruito una campagna di data exfiltration cross-platform partendo da un singolo alert su un service account CI/CD compromesso. La catena di attacco ha attraversato 18 repository privati su GitHub, due account AWS distinti e un domain controller di produzione, con l'investigazione completata in minuti anziché nelle ore stimae per un analista umano. Il caso solleva questioni concrete sulla velocità degli AI agent autonomi e sui limiti della verifica incrociata quando l'intera evidenza proviene da un unico vendor.

Punti chiave
  • Un token GitHub compromesso ha permesso la clonazione di 18 repository privati contenenti credenziali AWS hardcoded, che hanno aperto il pivot verso il cloud.
  • L'attore ha operato da IP Zenlayer Inc (ExpressVPN) con user agent Kali Linux, anomalo rispetto alla baseline storica di 30 giorni del service account svc_automation.
  • Il Blue Agent ha correlato automaticamente management plane AWS (CloudTrail), data plane (S3) e audit log GitHub per ricostruire la catena completa.
  • L'investigazione ha identificato remote code execution su un domain controller di produzione tramite SSM SendCommand e tre script Python custom per esfiltrazione SQL, PostgreSQL e billing.

Come è partita l'investigazione: tre alert simultanei su un service account CI/CD

L'indagine è iniziata quando tre detection rules sono scattate contemporaneamente contro un singolo attore in un account AWS. Il Blue Agent, l'investigatore SOC autonomo di Wiz lanciato in GA per i clienti Wiz Defend, ha analizzato i segnali in parallelo. L'attore era svc_automation, un IAM service account creato nel 2018 per pipeline CI/CD, non un utente umano. Lo user agent conteneva "kali-amd64", indicante Kali Linux. L'IP sorgente apparteneva a Zenlayer Inc, hosting provider associato a VPN exit nodes, geolocalizzato a Taiwan con ASO Zenlayer Inc (ExpressVPN).

La baseline di 30 giorni mostrava svc_automation operante esclusivamente da tre IP di proprietà Amazon con user agent TeamCity Server e aws-sdk-go, eseguendo operazioni routine CI/CD. Nella detection window, l'attore usava aws-cli su Kali Linux da IP Zenlayer, con operazioni anomale: AssumeRole con privilegi amministrativi e SSM SendCommand. "Any one of these signals could have a legitimate explanation. Together, they warranted deeper investigation", riporta il blog di Wiz.

Il pivot cross-account: stesso attore, stesso pattern, secondo access key

Il Blue Agent ha esteso la query ASO Zenlayer a tutto il tenant. Ha trovato solo due attori con questo profilo: entrambi erano svc_automation, in due account AWS diversi. Nel secondo account, l'attaccante ha usato una differente access key permanente ma stesso user agent Kali Linux e stesso range IP Zenlayer. La timeline nel secondo account mostra: alle 09:55 UTC, AssumeRole alla stessa CI role da un diverso IP Zenlayer; alle 10:06 UTC, SSM SendCommand targeting un'istanza EC2 con naming convention PROD-*******-DC1, indicante un domain controller di produzione.

L'attaccante ha ottenuto remote code execution sul domain controller. Parallelamente, il data plane ha rivelato tre script Python caricati in un bucket S3 da IP Zenlayer: mssql_table_export.py, pg_table_export.py, billing_export2.py. I nomi indicavano tool customizzati per estrarre dati da Microsoft SQL Server, PostgreSQL e sistemi di billing. Gli script sono stati caricati da Kali Linux, poi le istanze EC2 compromesse li hanno recuperati ed eseguiti via curl da IP Amazon-owned.

"This was the moment the investigation escalated from compromised credentials in multiple accounts to active data exfiltration operation with custom tooling."

La correlazione con GitHub: da furto di sorgenti a compromissione cloud

L'analisi cross-account IP ha rivelato un terzo attore dalla stessa IP dell'attaccante: un utente GitHub. I log GitHub audit mostravano che poche ore prima dell'attività AWS, un token compromesso è stato usato per clonare 18 repository privati dallo stesso IP Zenlayer. La compromissione GitHub è stata identificata come fase di initial access, non incidente separato. I repository privati contenevano frequentemente credenziali AWS hardcoded, stringhe di connessione database e configurazioni di service account. L'attaccante ha probabilmente estratto la access key AKIA di svc_automation direttamente dai contenuti dei repository clonati.

La catena di attacco completa ricostruita dal Blue Agent comprende cinque fasi: Initial Access (furto sorgente GitHub), AWS Pivot & Authentication, Lateral Movement & Execution (SSM su domain controller), Tool Staging (caricamento script in S3), Data Exfiltration. La correlazione automatica ha attraversato tre piattaforme: AWS CloudTrail per il management plane, S3 data events per il data plane, GitHub audit logs per il SaaS. Il confronto baseline storica è stato multi-dimensionale: IP, user agent, ASO, operazioni e orari.

Velocità e limiti: minuti contro ore, ma con dipendenza da un'unica fonte

L'indagine completa, dall'alert iniziale alla classificazione finale, è stata completata in minuti dal Blue Agent. Secondo il caso di studio di Wiz, un analista umano avrebbe impiegato ore per lo stesso context switching tra CloudTrail, S3 data events e GitHub audit logs, con query manuali e correlazioni sequenziali. Il Blue Agent ha eseguito in parallelo, senza interruzione del flusso investigativo.

Tuttavia, il caso presenta limiti documentati. La fonte non specifica la data esatta dell'incidente oltre agli orari UTC 09:55 e 10:06. Non emerge l'identità dell'attaccante: nation-state, cybercriminali o altri operatori non sono identificabili dalle evidenze pubblicate. Il volume effettivo di dati esfiltrati in GB o record non è quantificato. Non è dichiarato se i dati siano stati successivamente venduti, pubblicati o usati per estorsione. Il vettore di compromissione del token GitHub — phishing, credential stuffing o altro — non è specificato. Non è chiaro se la vittima sia un cliente Wiz reale o un caso di studio composito/anonimizzato. Il caso di studio non documenta se il fix o la remediation siano stati automatizzati dal Blue Agent o abbiano richiesto intervento umano.

Perché è importante

Il caso di studio dimostra che la compromissione di un token GitHub può propagarsi in remote code execution su domain controller AWS in un arco temporale misurato in ore, attraverso credenziali hardcoded in repository privati. Per le aziende cloud-native, questo conferma che il perimetro di sicurezza non è più il network boundary ma il singolo secret in un file di configurazione versionato. Per i team SecOps, mostra il potenziale degli AI agent autonomi a ridurre il MTTR da ore a minuti, ma con un trade-off: la velocità di correlazione cross-platform dipende interamente dalla qualità e dalla copertura dei dati del vendor che fornisce la piattaforma.

La dipendenza da un'unica fonte per tutti i fatti dell'incidente — nessuna conferma incrociata da CERT, altri vendor o ricercatori esterni — costituisce un limite strutturale. Il dossier non specifica misure correttive specifiche. Il caso solleva questioni sul secret scanning preventivo come controllo upstream, ma la fonte non lo documenta come requisito operativo. La lettura è che la velocità dell'AI agent autonomo è reale e misurabile, ma la sua efficacia investigativa resta ancorata alla completezza del dataset che l'organizzazione ha integrato nella piattaforma.

Fonti

Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.

Fonti


Fonti e riferimenti
  1. wiz.io