Introduction

Publication date: September 10, 2026
– Category: AI Attacks (LLM/LocalAI)

As organizations increasingly adopt Large Language Model (LLM)-based tools to assist with code triage and security analysis, malicious actors are actively developing methods to subvert these algorithmic defenses. ESET researchers recently uncovered one such tactic, dubbed GuardBreaker, deployed by the Russia-aligned threat group UAC-0099 during the early stages of an attack against a target in Ukraine. The technique involves embedding a decoy request for guidance on building a nuclear weapon directly within a VBScript comment. This is engineered to trigger the safety guardrails of an AI-powered code scanner, forcing it to abort inspection of the file before ever reaching the actual malicious code, whose ultimate purpose was to download and deploy the MATCHBOIL loader.

What is GuardBreaker? (General Analysis)

GuardBreaker is conceptually understood as a form of inference-time prompt injection. Rather than exploiting a traditional software vulnerability (such as a memory corruption flaw or remote code execution within the LLM engine itself), it exploits a fundamental architectural limitation in modern AI analysis systems: the inability to cleanly separate trusted control instructions from untrusted data inputs processed within the same execution context.

Although no specific CVE has been assigned to this application-layer behavior (marked as N/A as it represents an algorithmic safeguard bypass rather than a software defect), it can be analytically assessed using standard AI threat taxonomies:

  • Estimated CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L (Estimated Score: 5.1 Medium). Note: Reasoned estimation based on the operational impact on the integrity and availability of the automated analysis pipeline.
  • Estimated CWE Classification: CWE-20 (Improper Input Validation) combined with contextual handling weaknesses in generative models.

The affected component is the automated security workflow relying on LLMs for static code review. By tricking the model into refusing the prompt, attackers successfully blind early-stage detection pipelines.

How Does It Work? (Technical Analysis)

The technical mechanism behind GuardBreaker is straightforward yet highly effective in environments lacking multi-layered analyst oversight:

  • Decoy Input Stream: The threat actor embeds a syntactically valid VBScript comment containing an explicit request for prohibited content, such as instructions for building weapons or other heavily restricted topics regulated by the LLM’s internal safety policies.
  • Inference Interruption (Evasion Mechanism): When the LLM-powered scanner processes the file during static triage, the model interprets the commented text as a policy-violating directive. Triggered by its safety guardrails, the model abruptly halts output generation or aborts the scanning task entirely.
  • Payload Delivery: Because the analysis is aborted prematurely due to the false alarm triggered by the decoy comment, the actual malicious code—designed to download and execute the MATCHBOIL loader—remains uninspected, allowing the initial infection vector to proceed undetected.
text 
[ Malicious VBScript File ]
       │
       ├──> [ Decoy Comment (GuardBreaker) ] ────────> [ Triggers LLM Safety Filters ] ──> [ Analysis Aborted ]
       │
       └──> [ Payload (MATCHBOIL Loader) ] ──────────> [ Hidden From Inspection ] ─────> [ Successful Execution ]

Affected Systems / Environments

The technique does not target a specific software or operating system memory flaw, but rather an entire class of defensive architectures:

  • LLM-powered automated code review systems (including CI/CD integrated tools and local AI-assisted static analysis utilities).
  • Security teams relying solely on generative model automation for rapid script triage (PowerShell, VBScript, JavaScript, etc.).
  • Software supply chain environments where malicious packages in public repositories (PyPI, npm) deploy analogous evasion tactics (fabricated system instructions or context exhaustion via repetitive strings like “You’re absolutely right!”).

Mitigation and Detection

Remediation

  • Multi-Model and Multi-Layer Approach: No single LLM engine should hold sole authority to determine whether a code snippet is safe or malicious. Implement cross-validation combining traditional heuristic analysis, rule-based static engines (YARA/SIGMA), and human supervision.
  • Context Boundary Enforcement: Configure AI-based parsers to strictly treat ingested code strictly as raw data rather than executable control directives, mitigating prompt injection impact.
  • Fail-Safe Policies: Ensure that when an LLM refuses to respond or aborts analysis due to a safety trigger, the system does not default to marking the file as “clean,” but instead automatically routes it to manual review or dynamic sandbox pipelines.

Detection

  • Pipeline Anomaly Monitoring: Log and alert on abrupt interruptions, policy refusal errors, or unexpected truncations within AI-assisted analysis tools.
  • Threat Hunting via IoCs: Audit script repositories and email attachments for unusual comments containing hyperbolic requests, prohibited topics, or repetitive patterns aimed at exhausting context windows.

“No single LLM engine should have the sole authority to decide that a piece of code is safe; automation must always be complemented by human validation and traditional heuristics to prevent blind spots in defense.”

Wrapping Up

The emergence of the GuardBreaker technique by the UAC-0099 threat group highlights how adversaries actively adapt their methodologies to exploit the limitations of artificial intelligence technologies integrated into corporate defense. The deployment of simple decoy comments to disarm LLM-based scanners demonstrates that prompt injection vectors are no longer merely a theoretical risk for web applications, but an operational evasion tool in cyberespionage and malware distribution. Organizations must adopt defense-in-depth architectures where AI acts as a supporting assistant rather than the sole arbiter in critical security decision-making.

References