GuardBreaker: UAC-0099 inganna gli scanner LLM con un commento VBScript

Il gruppo Russia-allineato UAC-0099 ha impiegato una tecnica denominata GuardBreaker per eludere l'analisi di un VBScript malevolo da parte di scanner basati su modelli di linguaggio. Il metodo, identificato da ESET in un attacco contro un bersaglio in Ucraina, consiste nell'inserire nel codice un commento decoy progettato per innescare i meccanismi di sicurezza dell'LLM e causarne il rifiuto di proseguire l'ispezione.

Il meccanismo: un commento come arma di evasione

La tecnica GuardBreaker rappresenta un'applicazione concreta di prompt injection in ambito malware analysis. Inserendo nel VBScript un commento con una richiesta esplicita di istruzioni per costruire un'arma nucleare, gli operatori di UAC-0099 hanno sfruttato l'architettura degli scanner LLM-powered, in cui il contenuto del file analizzato raggiunge il modello durante l'inferenza senza boundary affidabili tra istruzioni di sistema e input non attendibile.

ESET descrive la dinamica con precisione: il commento decoy ha l'obiettivo di far scattare i meccanismi di rifiuto dell'LLM, interrompendo l'analisi del resto del file. Il risultato è un blind spot: il codice malevolo effettivo, responsabile del download e dell'installazione di MATCHBOIL, rimane non ispezionato. La fonte sottolinea che il commento "non ha effetto sul comportamento dello script a runtime": la sua efficacia è esclusivamente mirata agli strumenti di analisi automatizzata.

Questo approccio si distingue dalle tecniche di evasione convenzionali, come gli EDR-killer basati su driver vulnerabili, perché non modifica il comportamento esecutivo del malware ma colpisce il layer di intelligenza artificiale posto a monte della catena difensiva.

Precursori e pattern consolidati

Il caso GuardBreaker non è isolato. ESET colloca la tecnica all'interno di un pattern più ampio di AI analyst misdirection documentato in altri contesti. StepSecurity ha rilevato una tecnica analoga nella Hades Campaign: un file _index.js in un pacchetto PyPI conteneva un prompt che istruiva esplicitamente qualsiasi modello di analisi a ignorare il codice malevolo e classificare il pacchetto come pulito. Socket, per parte sua, ha identificato istruzioni di sistema fabbricate e contenuti che innescano policy in pacchetti PyPI malevoli.

Questi precedenti, pur riferendosi a campagne distinte e attori diversi, corroborano la classe di tecnica: la manipolazione degli LLM attraverso il contenuto stesso del file analizzato. La differenza sostanziale di GuardBreaker sta nel meccanismo specifico di attivazione, che sfrutta i guardrail di sicurezza anziché istruire direttamente il modello a ignorare il codice.

Il payload MATCHBOIL e le contromisure di UAC-0099

Lo script analizzato da ESET aveva lo scopo di scaricare e installare MATCHBOIL, un loader che la fonte descrive come utilizzato esclusivamente da UAC-0099 per consegnare payload aggiuntivi. Questa esclusività rafforza l'attribuzione del campione al gruppo, che ESET classifica come Russia-allineato.

Oltre a GuardBreaker, il VBScript includeva contromisure multi-livello: la verifica della presenza di processi associati a IDA, il noto disassembler, e a Wireshark, indicando un'attenzione specifica agli ambienti di analisi manuale e alla rilevazione di attività di reverse engineering. Questa duplice strategia — evasione degli strumenti automatizzati tramite LLM e rilevazione degli ambienti di analisi manuale — suggerisce una progettazione mirata a massimizzare la persistenza non rilevata.

"By inserting a decoy request for guidance on building a nuclear weapon into the script's comment, the bad actor aimed to trip the safety guardrails of an LLM-powered code scanner and cause it to stop inspecting the rest of the file" — ESET Research

Cosa fare adesso

Le implicazioni di GuardBreaker per le pipeline di sicurezza sono immediate e concrete. ESET formula una valutazione che la fonte stessa rende esplicita: "no single LLM engine should have the sole authority to decide that a piece of code is safe". Questa posizione, espressa nel contesto dell'analisi di GuardBreaker, evidenzia un problema architetturale: la centralizzazione del giudizio di sicurezza su un singolo modello di linguaggio espone a tecniche di manipolazione che sfruttano le stesse caratteristiche progettuali — i guardrail di sicurezza — che dovrebbero proteggere.

Per le organizzazioni che impiegano scanner LLM nella catena di analisi malware, tre azioni derivano direttamente dal caso documentato. Primo: implementare un secondo motore di analisi non basato su LLM per ogni file sottoposto a screening automatico, evitando che un singolo rifiuto del modello interrompa l'ispezione. Secondo: configurare esplicitamente gli scanner per segnalare — non bloccare — i contenuti che innescano i guardrail di sicurezza, permettendo il proseguimento dell'analisi del resto del file. Terzo: trattare i commenti e i metadati nei file script con lo stesso livello di attenzione riservato al codice eseguibile, dato che GuardBreaker dimostra la loro funzionalità come vettore di prompt injection.

Il dossier non specifica quale scanner LLM fosse il target dell'attacco, né se il bypass sia effettivamente riuscito. Non è quantificata la frequenza di utilizzo di GuardBreaker da parte di UAC-0099 o di altri gruppi, e mancano indicatori di compromesso specifici del campione VBScript. La data esatta dell'attacco in Ucraina non è indicata oltre la formulazione "early stages".

L'eredità: quando la sicurezza dell'IA genera cecità

GuardBreaker solleva una contraddizione strutturale nell'adozione degli LLM per la sicurezza informatica. I meccanismi di rifiuto — progettati per impedire che modelli generativi producano contenuti dannosi — diventano vulnerabili a un'inversione: un rifiuto apparentemente virtuoso, innescato da input malevolo, può bloccare l'analisi stessa della minaccia. Il guardrail, in altre parole, diventa il veicolo dell'evasione.

La tecnica non richiede sofisticazione tecnica nel commento stesso: la sua efficacia risiede nella comprensione dei limiti architetturali degli scanner LLM, dove il confine tra contenuto da analizzare e contenuto che innesca policy è permeabile. Come osserva ESET, "any technology that could affect an attacker's chances of success will end up in their crosshairs". Il caso UAC-0099 dimostra che questa logica si applica anche alle tecnologie difensive emergenti.

Il dossier non permette di stabilire se GuardBreaker rappresenti un'escalation nella capacità operativa del gruppo o un'esperimentazione isolata. La sua rilevanza sta nel principio dimostrato: i sistemi di intelligenza artificiale integrati nelle pipeline di sicurezza richiedono layer di verifica indipendenti, non per carenza del modello, ma per la natura manipolabile dei confini che ne definiscono il comportamento.

FAQ

GuardBreaker è una vulnerabilità nell'LLM stesso?

No. ESET lo classifica esplicitamente come una tecnica di prompt injection, non come una vulnerabilità software nel modello. La manipolazione avviene attraverso il contenuto del file analizzato, sfruttando l'assenza di boundary robusti tra input non attendibile e istruzioni di sistema.

Il commento decoy altera l'esecuzione del malware?

No. La fonte afferma esplicitamente che il commento "non ha effetto sul comportamento dello script a runtime". La sua funzione è esclusivamente diretta agli strumenti di analisi automatizzata basati su LLM.

Esistono altri esempi di questa tecnica?

Sì, in contesti distinti. StepSecurity ha documentato un caso di prompt injection nella Hades Campaign su PyPI, mentre Socket ha rilevato istruzioni di sistema fabbricate in pacchetti PyPI malevoli. Questi casi corroborano la classe di tecnica, ma non sono collegati a UAC-0099 né al campione VBScript analizzato.

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

Fonti

• https://www.welivesecurity.com/en/business-security/guardbreaker-derailing-ai-assisted-malware-analysis-code-comment/
• https://www.welivesecurity.com/en/eset-research/edr-killers-explained-beyond-the-drivers/
• https://www.stepsecurity.io/blog/the-hades-campaign-pypi-packages
• https://www.welivesecurity.com/en/business-security/how-smbs-use-threat-research-mdr-build-defensive-edge/