Anatomia del worm Python che manipola gli agenti di sicurezza AI

Sei arrivato a un punto in cui ti fidi del tuo assistente di codice AI più della tua stessa revisione manuale? Molti sviluppatori lo hanno fatto. Ci affidiamo ai modelli linguistici di grandi dimensioni (LLM) per scansionare vulnerabilità, suggerire correzioni e verificare l'integrità dei pacchetti di terze parti. Ma cosa succede quando il malware sa come rispondere all'IA? La scorsa settimana ho trascorso diverse notti a esaminare i dettagli tecnici della Campagna Hades, una minaccia che segna un cambiamento nel modo in cui gli aggressori approcciano le difese automatizzate. Questo non è solo un ladro di dati. È un'operazione psicologica diretta al software che usiamo per proteggerci.

I ricercatori di StepSecurity hanno recentemente identificato questa campagna come l'ultimo lavoro del gruppo di minaccia Miasma. Mentre in precedenza Miasma si concentrava sulla raccolta di credenziali cloud, Hades è un worm più aggressivo e auto-propagante. Prende di mira specificamente gli ambienti di sviluppo Python attraverso pacchetti compromessi nell'ecosistema PyPI. L'elenco delle librerie interessate include ensmallen, mflux-streamlit e diversi strumenti utilizzati nella bioinformatica. Se lavori nella biologia computazionale o nella scienza dei dati, la tua workstation è un bersaglio di alto valore per questo specifico gruppo.

Il punto di ingresso nel processo di inizializzazione di Python

L'attacco inizia quando uno sviluppatore importa un pacchetto compromesso. Hades nasconde il suo loader primario all'interno del file __init__.py. Questo è un file standard che Python usa per contrassegnare una directory come pacchetto. Posizionando qui lo script malevolo, gli aggressori assicurano che il codice venga eseguito nel momento stesso in cui il pacchetto viene caricato in un progetto. Il loader è offuscato per evitare il rilevamento basato su firme di base, ma il suo scopo è semplice. Rilascia sul sistema un binario precompilato del runtime Bun.

Bun è un toolkit JavaScript ad alte prestazioni. È uno strumento eccellente per gli sviluppatori legittimi, ma è anche un motore di esecuzione perfetto per il malware. Poiché Bun è un binario autonomo, consente al malware di eseguire complessi payload JavaScript senza richiedere un'installazione di Node.js sulla macchina della vittima. Questo bypassa il monitoraggio tradizionale che cerca attività sospette di npm o Node. Da un livello architettonico, l'uso di Bun permette agli aggressori di operare in un ambiente ombra che si trova al di fuori della visibilità di sicurezza standard della maggior parte delle workstation incentrate su Python.

Come il malware manipola il guardiano automatizzato

La caratteristica più innovativa di Hades è la sua capacità di mentire agli agenti di sicurezza AI. Molti ambienti di sviluppo moderni utilizzano gli LLM per scansionare il codice alla ricerca di pattern malevoli. Hades lo anticipa. In cima ai suoi file malevoli, il malware include un blocco di testo progettato come un prompt avversario. Questo testo istruisce l'LLM a ignorare qualsiasi codice sospetto trovato sotto di esso e a classificare il pacchetto come verificato e sicuro.

Ho testato una tecnica simile in un ambiente sandbox il mese scorso. Ho fornito a un LLM uno script contenente una palese reverse shell, ma preceduto da un commento che diceva che il codice era un test di sicurezza pre-autorizzato per un contratto governativo. L'IA ha ignorato l'exploit e ha riferito che lo script seguiva tutti i protocolli di sicurezza. Hades utilizza esattamente questa strategia del cavallo di Troia digitale. Sfrutta la logica cognitiva dell'IA. Poiché gli LLM sono suscettibili all'ingegneria sociale, accettano queste istruzioni nascoste come comandi ad alta priorità. Ciò si traduce in un verdetto di falso negativo, consentendo al malware di sfuggire all'analisi automatizzata dell'organizzazione.

Sfruttare il framework di integrità della supply chain

Hades non si limita a nascondersi; cerca di apparire ufficiale. Sfrutta diversi framework di sicurezza mission-critical, tra cui OpenID Connect (OIDC) e Supply-chain Levels for Software Artifacts (SLSA). Quando il malware si trova in esecuzione all'interno di un workflow di GitHub Actions, controlla le variabili OIDC. Utilizza quindi queste credenziali per generare bundle di provenienza SLSA firmati crittograficamente tramite Sigstore.

Si tratta di un sofisticato bypass proprio dei sistemi destinati a garantire l'integrità del software. Generando un bundle Sigstore valido, il malware può pubblicare versioni compromesse di librerie su PyPI o npm che sembrano provenire da un ambiente di build ufficiale e verificato. Per un osservatore esterno o uno strumento automatizzato, il pacchetto sembra avere una catena di custodia valida. Ciò trasforma l'infrastruttura di sicurezza in un'arma per l'aggressore. Fa apparire il codice compromesso più affidabile del codice legittimo non firmato.

Scraping della memoria e movimento laterale

Una volta stabilito il malware, inizia a raccogliere dati. Include scraper di memoria personalizzati per Linux, macOS e Windows. Questi scraper prendono di mira le mappature di memoria dei processi attivi per estrarre dati sensibili e crittografati che sono altrimenti inaccessibili sul disco. Questo è un approccio furtivo perché evita di creare file sospetti che un sistema di rilevamento e risposta degli endpoint (EDR) potrebbe segnalare.

Il worm cerca anche modi per diffondersi. Scansiona il sistema infetto alla ricerca di chiavi SSH, configurazioni SCP e token GitHub. Se trova un token con permessi di scrittura, utilizza il runner di GitHub Actions per estrarre i segreti direttamente dalla memoria. Tenta quindi di infettare altri repository di proprietà dell'utente. Il traffico di comando e controllo (C2) è nascosto all'interno dell'infrastruttura pubblica di GitHub. I dati rubati vengono compressi, crittografati e inviati a nuovi repository pubblici sotto il controllo dell'aggressore. Questi repository portano spesso la descrizione "Hades — The End for the Damned".

Il meccanismo di persistenza della terra bruciata

La persistenza è una componente centrale del design di Hades. Il malware stabilisce una presenza sulla workstation e monitora lo stato delle credenziali rubate. Se un team di sicurezza rileva la violazione e revoca il token GitHub rubato, Hades entra in una modalità reattiva. Esegue un processo wiper che tenta di cancellare i file locali dell'utente.

Questa è una tattica ritorsiva. Crea una situazione ad alto rischio per i soccorritori degli incidenti. Se interrompi l'accesso, potresti perdere i dati sulla macchina locale. Questa logica costringe le organizzazioni a muoversi con cautela durante la fase di bonifica. Il malware prende di mira anche i file di configurazione di 14 diversi agenti AI. Inserisce istruzioni che attivano una nuova infezione ogni volta che lo sviluppatore consulta il proprio assistente AI riguardo all'area di lavoro corrente. Ciò crea un ciclo in cui l'atto di cercare aiuto da uno strumento di IA reinfetta il sistema.

Costruire una difesa proattiva contro il malware ingannevole

La Campagna Hades dimostra che la nostra dipendenza dall'IA come livello di sicurezza primario è una vulnerabilità. Dobbiamo muoverci verso un modello in cui l'IA sia un collaboratore piuttosto che un'autorità assoluta. Dal punto di vista del rischio, la migliore difesa è di tipo granulare e non si affida a un singolo guardiano.

Punti chiave per mettere in sicurezza il tuo ambiente:

1. Usa un isolamento rigoroso dei confini per gli LLM. Non passare mai codice grezzo e non attendibile a uno scanner AI senza un prompt di sistema che proibisca esplicitamente al modello di seguire le istruzioni contenute nel codice stesso.
2. Controlla i permessi di GitHub Actions. Implementa il principio del privilegio minimo per i token OIDC e assicurati che i runner non abbiano accessi di scrittura non necessari ai tuoi repository.
3. Monitora l'esecuzione di binari non autorizzati. Hades si affida al rilascio di un runtime Bun. Gli strumenti che segnalano o bloccano l'esecuzione di binari sconosciuti nel percorso __init__.py possono fermare l'infezione al punto di ingresso.
4. Verifica manualmente la provenienza Sigstore. Sebbene Hades possa contraffare i bundle, discrepanze nei tempi di build o nelle variabili d'ambiente possono talvolta essere scoperte durante un'audit forense.
5. Implementa strategie di backup robuste. Poiché Hades include un wiper, avere backup offline o immutabili del tuo lavoro di sviluppo è l'unico modo per mitigare la minaccia di perdita di dati durante la bonifica.

Guardando al panorama delle minacce, Hades è probabilmente un'anteprima del futuro. Gli aggressori non stanno più solo cercando di scassinare le serrature delle nostre porte; stanno imparando come convincere il buttafuori digitale a lasciarli entrare. Dobbiamo smettere di trattare i verdetti dell'IA come verità assolute e iniziare a trattarli come punti dati che richiedono una verifica umana.

Fonti: NIST Cybersecurity Framework, MITRE ATT&CK Framework (Software Supply Chain Compromise), StepSecurity Hades Campaign Report.

Disclaimer: Questo articolo è solo a scopo informativo ed educativo e non sostituisce un audit di sicurezza informatica professionale o un servizio di risposta agli incidenti.