GuardBreaker: UAC-0099 Tricks LLM Scanners with a VBScript…

Russia-aligned group UAC-0099 used the GuardBreaker technique to make an LLM-based scanner refuse analysis of a malicious VBScript. The decoy comment demonstrates how safety guardrails can be weaponized to create blind spots in AI-assisted malware analysis.

Russia-aligned group UAC-0099 employed a technique dubbed GuardBreaker to evade analysis of a malicious VBScript by scanners powered by large language models. The method, identified by ESET in an attack against a target in Ukraine, consists of inserting a decoy comment into the code designed to trigger the LLM's safety mechanisms and cause it to refuse further inspection.

Key Takeaways

ESET identified GuardBreaker in a VBScript used by UAC-0099 in the early stages of an attack in Ukraine.
The decoy comment requested instructions for building a nuclear weapon, aiming to trip the safety guardrails of an LLM scanner.
The actual payload was MATCHBOIL, a loader used exclusively by UAC-0099 to download additional payloads.
The comment does not alter script execution at runtime; its sole function is deceiving the automated analyzer.

The Mechanism: A Comment as an Evasion Weapon

GuardBreaker represents a concrete application of prompt injection in malware analysis. By inserting a comment containing an explicit request for instructions on building a nuclear weapon into the VBScript, UAC-0099 operators exploited the architecture of LLM-powered scanners, where the content of the file under analysis reaches the model during inference without reliable boundaries between system instructions and untrusted input.

ESET describes the dynamic precisely: the decoy comment aims to trigger the LLM's refusal mechanisms, halting analysis of the rest of the file. The result is a blind spot: the actual malicious code, responsible for downloading and installing MATCHBOIL, remains uninspected. The source emphasizes that the comment "has no effect on the script's behavior at runtime": its effectiveness is exclusively targeted at automated analysis tools.

This approach differs from conventional evasion techniques, such as EDR killers based on vulnerable drivers, because it does not modify the malware's execution behavior but instead strikes the artificial intelligence layer positioned upstream in the defensive chain.

Precursors and Established Patterns

The GuardBreaker case is not isolated. ESET places the technique within a broader pattern of AI analyst misdirection documented in other contexts. StepSecurity detected an analogous technique in the Hades Campaign: a _index.js file in a PyPI package contained a prompt that explicitly instructed any analysis model to ignore the malicious code and classify the package as clean. Socket, for its part, identified fabricated system instructions and policy-triggering content in malicious PyPI packages.

These precedents, while referring to distinct campaigns and different actors, corroborate the technique class: manipulation of LLMs through the content of the file being analyzed. The substantial difference with GuardBreaker lies in the specific activation mechanism, which exploits safety guardrails rather than directly instructing the model to ignore the code.

The MATCHBOIL Payload and UAC-0099's Countermeasures

The script analyzed by ESET was designed to download and install MATCHBOIL, a loader the source describes as used exclusively by UAC-0099 to deliver additional payloads. This exclusivity reinforces attribution of the sample to the group, which ESET classifies as Russia-aligned.

Beyond GuardBreaker, the VBScript included multi-layered countermeasures: checking for the presence of processes associated with IDA, the well-known disassembler, and Wireshark, indicating specific attention to manual analysis environments and detection of reverse engineering activity. This dual strategy — evasion of automated tools via LLM and detection of manual analysis environments — suggests a design aimed at maximizing undetected persistence.

"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

What to Do Now

The implications of GuardBreaker for security pipelines are immediate and concrete. ESET offers an assessment the source makes explicit: "no single LLM engine should have the sole authority to decide that a piece of code is safe." This position, expressed in the context of the GuardBreaker analysis, highlights an architectural problem: centralizing security judgment on a single language model exposes it to manipulation techniques that exploit the very design features — safety guardrails — meant to protect.

For organizations employing LLM scanners in the malware analysis chain, three actions derive directly from the documented case. First: implement a second, non-LLM-based analysis engine for every file submitted to automated screening, preventing a single model refusal from halting inspection. Second: explicitly configure scanners to flag — not block — content that triggers safety guardrails, allowing analysis of the rest of the file to continue. Third: treat comments and metadata in script files with the same level of scrutiny reserved for executable code, given that GuardBreaker demonstrates their functionality as a prompt injection vector.

The dossier does not specify which LLM scanner was the target of the attack, nor whether the bypass actually succeeded. The frequency of GuardBreaker use by UAC-0099 or other groups is not quantified, and specific indicators of compromise for the VBScript sample are absent. The exact date of the attack in Ukraine is not indicated beyond the formulation "early stages."

The Legacy: When AI Safety Generates Blindness

GuardBreaker raises a structural contradiction in the adoption of LLMs for cybersecurity. Refusal mechanisms — designed to prevent generative models from producing harmful content — become vulnerable to an inversion: an apparently virtuous refusal, triggered by malicious input, can block analysis of the threat itself. The guardrail, in other words, becomes the vehicle of evasion.

The technique requires no technical sophistication in the comment itself: its efficacy lies in understanding the architectural limits of LLM scanners, where the boundary between content to be analyzed and content that triggers policy is permeable. As ESET observes, "any technology that could affect an attacker's chances of success will end up in their crosshairs." The UAC-0099 case demonstrates that this logic applies to emerging defensive technologies as well.

The dossier does not allow establishing whether GuardBreaker represents an escalation in the group's operational capability or an isolated experiment. Its relevance lies in the demonstrated principle: AI systems integrated into security pipelines require independent verification layers, not due to model deficiency, but because of the manipulable nature of the boundaries that define their behavior.

FAQ

Is GuardBreaker a vulnerability in the LLM itself?

No. ESET explicitly classifies it as a prompt injection technique, not a software vulnerability in the model. The manipulation occurs through the content of the file being analyzed, exploiting the absence of robust boundaries between untrusted input and system instructions.

Does the decoy comment alter malware execution?

No. The source explicitly states that the comment "has no effect on the script's behavior at runtime." Its function is exclusively directed at automated analysis tools based on LLMs.

Are there other examples of this technique?

Yes, in distinct contexts. StepSecurity documented a case of prompt injection in the Hades Campaign on PyPI, while Socket detected fabricated system instructions in malicious PyPI packages. These cases corroborate the technique class, but are not linked to UAC-0099 or the analyzed VBScript sample.

Information is based on the cited source and current as of publication.

Sources

Sources and references

Get DeafLetter