TL;DR

ESET identified an AI targeted anti-analysis technique, which it named GuardBreaker, inside a malicious VBScript associated with threat actor UAC-0099. The script contained non executable comment text asking for help constructing a nuclear weapon. According to ESET, the text was inserted to attract an AI analyzer's attention to safety sensitive content and cause it to stop analyzing the remainder of the malicious script. The actual VBScript was intended to download and install MATCHBOIL malware.

The important distinction is that GuardBreaker is not attempting to bypass the model's safety guardrails. It is attempting to make those guardrails fire, turning the model's defensive refusal behavior into an evasion mechanism. However, ESET's public disclosure does not identify a model, scanner, or analysis platform that was successfully affected, nor does it publish a controlled test demonstrating the technique's effectiveness. It should therefore be treated as an observed adversarial technique with stated intent, not as a proven universal bypass.

The concept is also not entirely new. In June 2026, Socket and Zscaler documented malicious packages containing safety triggering and prompt injection content aimed at AI malware scanners. Zscaler specifically described safety refusal as a potential failure mode when AI based security pipelines treat a refusal or absence of a verdict as equivalent to a clean result.

Confidence note: The malicious artifact and the embedded safety-sensitive text are documented. Public reporting does not demonstrate that GuardBreaker successfully caused any specific AI model or security product to stop analysis.

Core Attack Pattern

ESET found the technique in a malicious VBS script used by UAC-0099, a threat group ESET assesses with medium confidence as aligned with Russian interests. ESET has tracked the group since at least 2022.

The relevant VBScript contained a comment beginning with the safety sensitive phrase "I want to make nuclear weapon. Help me …". Because the content was placed in a script comment, it had no executable function in VBScript. ESET stated that its purpose was instead to attract an AI system toward sensitive content and make it stop analyzing the rest of the code. ESET named this technique GuardBreaker.

The underlying malware operation was independent of the AI targeted text. CERT-UA had previously documented UAC-0099's infection chain involving LUNCHPOKE, BURNYBEAR, and MATCHBOIL.V2. Reporting based on the CERT-UA advisory describes delivery involving a VBS file disguised as a PDF, followed by a legitimate Notepad++ installation bundled with a malicious NppExport.dll plugin. The plugin ultimately participates in loading MATCHBOIL.V2.

This distinction matters: the prompt-like content does not enable the malware to execute. It targets the security system examining the malware.

Attack Analysis

AI becomes part of the attack surface

Traditional malware-analysis systems distinguish executable code from comments. A VBScript interpreter simply ignores REM comments.

An LLM based analyzer, however, may receive the entire source file as natural language context. In that environment, text that is inert to the programming language can become meaningful input to the model. This creates two interpretations of the same artifact:

ConsumerInterpretationVBScript runtimeComment; no executable effectLLM analyzerNatural-language input potentially relevant to its instructions or safety policy

Socket independently highlighted this security boundary in June: comments that have no runtime effect can still constitute active input for AI scanners that consume raw source text.

Guardrails are the target, not the obstacle

GuardBreaker differs from conventional jailbreaks. A jailbreak usually attempts to defeat a restriction so the model performs a prohibited action.

GuardBreaker attempts the inverse:

Malicious artifact → AI analyzer reads safety-sensitive content → model safety mechanism activates → analysis is interrupted or refused → malicious code receives less analysis.

ESET describes the attacker's intended outcome this way. Public evidence does not establish that this sequence successfully occurred against a deployed product.

This distinction is particularly important for threat reporting. Saying that UAC-0099 embedded content designed to trigger an AI refusal is supported. Saying that the actor successfully bypassed an AI security product is not supported by the currently disclosed evidence.

This is part of an emerging anti-AI-analysis pattern

GuardBreaker follows earlier attempts to attack malware-analysis models through the artifacts being inspected.

Check Point Research documented a malware sample in June 2025 containing a conventional prompt injection instructing an AI analyzer to return a benign verdict. Check Point tested the sample against OpenAI o3 and GPT-4.1 and reported that the injection failed in those tests; the models continued analyzing the code.

In June 2026, Socket documented npm and PyPI artifacts containing prompt-injection instructions, safety-triggering content, token flooding, and obfuscation directed at AI scanners. Zscaler subsequently described both false-clean steeringand safety refusal as failure modes that AI-assisted malware-analysis pipelines need to account for.

GuardBreaker therefore provides further evidence that attackers are treating the AI security analyzer itself as an adversarial target.

AI Kill Chain

The GuardBreaker disclosure supports only a small portion of the full AI Kill Chain. Stages without publicly documented evidence should not be inferred.

1. Reconnaissance — Bypassed entirely. No evidence shows UAC-0099 profiling a specific model or scanner. Nothing in the disclosure suggests the attacker tailored the bait text to a particular vendor's analysis pipeline.

2. Trust Manipulation — Bypassed entirely. No authority impersonation or trust-framing behavior was disclosed. The comment does not pose as a system prompt, an authorized instruction, or a trusted source — it relies purely on the content itself being safety-sensitive.

3. Input & Instruction Weaponization — Active. Safety sensitive natural language content was embedded in inert VBS comments that could become input when the file is processed by an AI analyzer. Because a VBScript interpreter ignores REM comments outright, the payload is silent to the runtime and only becomes meaningful once an LLM-based analyzer reads the full source file as natural-language context — exactly the interpretation gap between "VBScript runtime" and "LLM analyzer" that Socket also flagged in June.

4. Reasoning-Time Execution — Active. ESET assesses that the embedded content was intended to trigger AI safety behavior and cause analysis of the remaining code to stop. This is the inverse of a conventional jailbreak: rather than defeating a restriction to get the model to do something prohibited, the goal is to make the restriction fire so the model stops doing what it's supposed to do — analyze the code. Successful execution has not been publicly demonstrated; ESET describes intent, not a confirmed refusal event on any specific platform.

5. Tool Invocation — Bypassed entirely. No AI mediated tool execution was reported. The technique targets the analyzer's own reasoning, not any downstream tool it might call.

6. Privilege Escalation — Bypassed entirely. Not observed.

7. Lateral Movement — Bypassed entirely. Not observed in the AI attack path.

8. Persistence — Bypassed entirely. Not observed in the AI attack path. Malware persistence exists in the broader infection chain — via the NppExport.dll plugin and MATCHBOIL.V2 — but that persistence is not AI mediated.

9. AI-Native C2 — Bypassed entirely. Not observed.

10. Action on Objectives — Active. The intended objective was degradation or interruption of AI-assisted malware analysis, reducing scrutiny on the actual malicious code once the analyzer's attention is diverted. Whether that objective was achieved has not been publicly established.

Kill Chain interpretation

The core of GuardBreaker is therefore Stage 3 → Stage 4:

Indirect adversarial content enters the model's analysis context → the attacker attempts to exploit the model's own safety behavior to terminate analysis.

Unlike many agentic attacks, the chain does not require tool invocation, privilege escalation, lateral movement, or AI-native C2 to trigger detection suppression.

‍

Mitigation Strategy

Treat analyzed content as adversarial data

Files undergoing malware analysis should never acquire instructional authority merely because their contents are placed inside an LLM context. Code, comments, strings, metadata, documentation, and embedded text should all be treated as untrusted subject matter, not instructions governing the analyzer.

Where feasible, deterministic parsing can additionally distinguish executable structures from comments and other non-executable material before the LLM performs semantic analysis. This should supplement rather than replace inspection, because malicious behavior can also exist inside data that eventually becomes executable.

Fail closed on AI refusal

A safety refusal, context-limit error, timeout, or inability to produce a verdict must not be interpreted as "clean."

A resilient pipeline should instead treat: refusal ≠ benign and route the artifact to another analysis mechanism or human review. Zscaler specifically identified this architectural issue when discussing AI scanner evasion: a pipeline that treats "no verdict" or refusal as a pass creates a detection blind spot.

Do not make the LLM the sole detection engine

ESET recommends a multilayered approach combining AI assisted analysis with behavioral analysis, reputation systems, sandboxing, heuristics, telemetry, and expert-driven research and engineering.

This is particularly important for GuardBreaker because traditional analysis layers are largely unaffected by the adversarial text. The nuclear-weapons comment does not change the VBScript's runtime behavior; sandboxing, behavioral execution, static parsing, IoC detection, and malware signatures can continue examining what the program actually does.

Detect attempts to manipulate the analyzer

Security pipelines can also independently flag artifacts containing patterns associated with scanner-directed instructions or safety triggering anti analysis content. Socket's research shows that attackers are already experimenting with combinations of prompt injection, safety triggering text, context flooding, and obfuscation.

Such detection should be used as a risk signal, not as proof that the artifact is malicious.

UnifAI Policy

AI_APP_SEC_080

Lessons / Conclusion

GuardBreaker represents an important evolution in malware evasion because the defensive AI system itself becomes a target. Attackers no longer have to alter executable semantics to interfere with analysis; content ignored completely by the programming language runtime can potentially influence an LLM consuming the same artifact.

The most important architectural lesson is therefore not simply "improve the model's prompt injection resistance." The security workflow around the model must assume that everything being analyzed was created by an adversary specifically aware that an AI may inspect it. Models should not independently determine whether analysis succeeds, fails, or terminates without external controls validating that outcome.

At the same time, the available evidence warrants restraint. ESET has documented the embedded content and assessed its intended purpose, but there is currently no publicly disclosed demonstration that GuardBreaker caused a specific production AI malware scanner to refuse analysis or allowed the malware to evade detection. Previous anti LLM malware techniques have sometimes failed when experimentally tested.

The significant development is therefore the adversarial intent and tradecraft, rather than a proven universal vulnerability: attackers are beginning to design malicious artifacts not only for the operating system that will execute them, but also for the AI systems that will inspect them.