GuardBreaker: How a Simple Code Comment Can Disrupt AI-Assisted Malware Analysis

ESET Researchers Identify GuardBreaker

Artificial intelligence is increasingly being used in cybersecurity workflows, including code triage and malware analysis.

That creates another potential target for attackers: the AI systems being used to examine malicious files.

ESET researchers identified an example of this emerging technique in a VBScript used by the Russia-aligned group UAC-0099 during the early stages of an attack against a target in Ukraine.

ESET calls the technique GuardBreaker.

The approach places a deliberately provocative request inside a comment within the script. The request asks for guidance on building a nuclear weapon, which is the type of content an LLM's safety mechanisms are designed to refuse.

According to ESET, the purpose was not to execute the comment or change the script's runtime behavior. Instead, the comment was intended to trigger the safety guardrails of an LLM-powered code scanner and cause it to stop inspecting the file before reaching the malicious code.

The underlying VBScript was designed to download and install MATCHBOIL, a loader that ESET says is used exclusively by UAC-0099 to deliver additional payloads.

How GuardBreaker Targets AI-Assisted Analysis

The technique is simple in concept.

The attacker inserts the safety-triggering content into a code comment. Because the comment does not affect the script's normal execution, it can remain invisible to the runtime behavior of the malware while still being visible to an AI system analyzing the file.

When the LLM processes the file, it may encounter the embedded request as part of the content it has been asked to inspect.

If the model's safety mechanisms respond by refusing the request, the analysis process could be interrupted or prevented from continuing through the remainder of the file.

This creates a potential gap between malware execution and malware analysis.

ESET describes GuardBreaker as a straightforward form of prompt injection. In this case, attacker-controlled content reaches the LLM through the file being analyzed.

The important point is that the malicious content does not need to control the malware itself.

It is intended to influence the system responsible for examining the malware.

A Simplified GuardBreaker Analysis Path

Malicious file

↓

Embedded adversarial comment

↓

LLM-powered code scanner reads the file

↓

Safety mechanism encounters prohibited content

↓

Model may refuse or fail to continue analysis

↓

Malicious code may receive incomplete AI analysis

ESET notes that the comment has no runtime effect on the script. Its intended effect is on the analysis process.

Attackers May Be Accounting for AI in Defensive Environments

ESET's discovery also points to a broader pattern in how threat actors approach security defenses.

The researchers note that UAC-0099 has checked for processes associated with established analysis tools such as IDA and Wireshark.

GuardBreaker suggests that AI-powered analysis could also become part of that consideration.

Rather than only attempting to avoid detection by security software, an attacker can potentially attempt to influence the technology used to inspect the malicious file.

In this case, the content designed to influence the AI system is not necessarily important to the malware's execution. Its purpose is connected to the analysis environment surrounding the malware.

That makes the AI-powered scanner another potential component within the attack surface.

GuardBreaker Fits a Wider Pattern of AI Analysis Interference

ESET points to other examples involving attempts to interfere with LLM-powered security scanners, particularly in software supply-chain attacks.

Socket identified fabricated system instructions and policy-triggering content placed ahead of JavaScript payloads in malicious PyPI packages.

StepSecurity reported another example in which a prompt instructed an analyzing model to disregard malicious code and report a package as clean.

Researchers also identified an npm package that repeatedly inserted the phrase "You're absolutely right!" tens of thousands of times. ESET says the apparent purpose was to consume the model's context window and push the malicious JavaScript beyond practical analysis.

These cases illustrate different ways attackers could attempt to interfere with AI-assisted security analysis.

Potential approaches described by ESET include:

• Triggering safety refusals

• Injecting false instructions

• Overloading an AI model's context

• Using unusual files that could be partially parsed or truncated

• Presenting malicious code as confidential or sensitive information

• Using custom file types that require additional processing

• Steering AI agents toward actions that require human review

ESET also discusses the additional risks that can arise when AI agents use external tools such as unpackers and deobfuscators. According to the researchers, such tool calls could in some circumstances be hijacked for malware delivery or execution.

Why an AI Refusal Can Become a Security Blind Spot

An AI model refusing a harmful request is normally an intended safety behavior.

But in a malware-analysis workflow, that behavior can have a different consequence if the refusal prevents the system from completing its security task.

This is the central concern highlighted by GuardBreaker.

A security tool may be expected to examine an entire file. If attacker-controlled content causes the AI component to refuse or stop processing, the absence of an analysis result could potentially leave part of the file insufficiently examined.

ESET therefore advises organizations using LLM-powered code reviews and AI-assisted workflows to understand exactly what their tools inspect, where the AI system sits in the decision chain and what happens when it refuses or cannot complete a task.

A failed analysis should not automatically be treated as a clean result.

ESET Recommends Layered Validation

ESET's guidance is that no single LLM should have sole authority to determine whether code is safe.

Instead, AI-assisted output should be cross-validated through multiple layers combining automation and human expertise.

The company also recommends that a lack of AI output should trigger further checks.

This approach reduces the possibility that one model's refusal, failure or incorrect interpretation becomes the final security decision.

A layered process can combine AI-assisted analysis with established analysis methods, independent validation, expert judgment and threat research.

AI Systems Are Becoming Part of the Security Attack Surface

GuardBreaker highlights a broader issue for organizations adopting AI-assisted cybersecurity tools.

Traditional malware analysis focuses on understanding potentially hostile files and identifying malicious behavior.

LLM-assisted analysis adds another layer because the system is also interpreting natural-language content contained within those files.

That creates a distinction between content that is data to be analyzed and content that an AI model could interpret as an instruction.

A comment that has no meaningful effect on a script's execution can still become relevant when an LLM processes the same file.

The announcement highlights a broader industry shift toward recognizing that AI systems used for security can themselves become targets for manipulation.

This does not mean that AI-assisted security analysis is inherently ineffective. Instead, it reinforces the importance of understanding how these systems process untrusted inputs and how the wider security workflow responds when analysis is incomplete.

What Organizations Using AI Security Tools Should Consider

ESET's research suggests several areas organizations need to examine when deploying LLM-assisted security workflows.

Security teams should know:

• What content the AI system actually analyzes

• Where the AI system sits in the overall security decision chain

• What happens when the model refuses to respond

• What happens when the analysis cannot be completed

• Whether AI output is independently validated

• How human analysts become involved when additional investigation is required

For enterprises, this could mean treating AI-assisted analysis as one component of a broader security process rather than as the final authority.

The announcement highlights a broader industry shift toward combining AI automation with established security methods and human expertise.

The Role of Managed Detection and Response

ESET also emphasizes the need for a clear path from prevention to detection and response.

For organizations without round-the-clock security teams, the company points to managed detection and response (MDR) as an option for providing continued investigation and expert follow-through.

ESET recommends an approach that combines established AI technology with tried-and-tested analysis methods, expert judgment, threat research and global telemetry.

The objective is to avoid allowing a single AI action or failure to become a blind spot in the wider security process.

The Bigger Picture

GuardBreaker shows how attackers can target the analysis process rather than simply trying to hide malicious code.

The technique identified by ESET uses attacker-controlled content inside a file to interact with the AI system examining that file.

Its significance lies in the interaction between two different functions: the malware's runtime behavior and the security system's interpretation of the malware.

As LLMs become more involved in code analysis and other cybersecurity workflows, attackers have another component they may attempt to influence.

For security teams, the lesson is not necessarily to remove AI from analysis workflows.

Instead, AI-generated results should be treated as one part of a broader security process, with additional validation available when the model refuses, fails or produces incomplete analysis.

GuardBreaker ultimately reinforces a basic cybersecurity principle: any technology that can affect an attacker's success can become a target.

Organizations using AI-assisted security tools therefore need to understand not only what their models can detect, but also how those models behave when confronted with deliberately crafted content.