Russia-Aligned Hackers Use GuardBreaker Prompt Injection to Disrupt AI Malware Analysis

Cybersecurity researchers have identified a new anti-analysis technique dubbed GuardBreaker, in which malicious code contains text specifically designed to influence large language models (LLMs) that may be used by security analysts or automated malware-scanning systems.

The technique was observed in activity associated with UAC-0099, a Russia-aligned threat actor that has previously targeted organizations in Ukraine, particularly within the transportation and energy sectors.

Instead of attempting to hide the malware through traditional obfuscation alone, the attackers placed a safety-sensitive request inside a comment within a malicious Visual Basic Script (VBS) file. The objective was to cause an AI system analyzing the file to focus on the embedded request and potentially refuse to process the remaining code.

Researchers at ESET disclosed the technique in September 2026, describing it as an attempt to deliberately trigger the safety mechanisms of an LLM and interfere with AI-assisted security analysis.

What Is GuardBreaker?

GuardBreaker is essentially a prompt-injection attack against an AI malware-analysis workflow.

The malicious file contains content that resembles a request for prohibited or dangerous information. In the observed sample, the text referenced the construction of a nuclear weapon.

The request was not intended for the human victim running the malware.

Instead, it was designed to be encountered by an AI system that might receive the contents of the malicious file as part of an automated analysis process.

The attack can be summarized as:

Malicious script → Embedded adversarial prompt → AI scanner processes file → Safety mechanism triggered → Analysis potentially interrupted → Malicious code receives less scrutiny

The technique therefore attacks the analysis process rather than the endpoint directly.

UAC-0099 Uses a Malicious VBS Script

ESET observed GuardBreaker in a malicious VBS script attributed to UAC-0099.

The script itself is part of a broader malware delivery chain and is designed to download and install MATCHBOIL, a C#-based loader associated with the threat actor.

MATCHBOIL can subsequently be used to deliver additional payloads onto compromised Windows systems.

This means the prompt injection is not the primary payload.

Instead, it functions as an anti-analysis layer designed to interfere with security tooling examining the script.

ESET said UAC-0099 has previously used MATCHBOIL in attacks targeting organizations in Ukraine.

The Nuclear-Weapon Prompt Is the Trigger

The most unusual component of the sample is a comment containing a request related to building a nuclear weapon.

The malicious code effectively attempts to make the AI system interpret the embedded text as an instruction rather than simply treating it as untrusted file content.

If an AI-powered malware-analysis system responds by refusing to process the file because the content appears to request prohibited information, the attacker may achieve a form of analysis denial.

The malware itself does not necessarily become less malicious.

Instead, the defensive system may become less capable of explaining what the malware actually does.

How the Attack Works

A simplified representation of the GuardBreaker technique is:

Stage	Activity
1. Malicious file created	Attackers prepare a VBS script containing the malware delivery logic.
2. Prompt injection added	A safety-sensitive request is embedded inside the script.
3. File reaches security tooling	The suspicious file is submitted to an AI-assisted analysis system.
4. LLM processes the content	The model receives the malicious code as part of the analysis context.
5. Safety response triggered	The embedded text may cause the model to refuse or alter its analysis.
6. Analysis is disrupted	The security workflow may fail to reach or explain the actual malicious functionality.
7. Malware continues	When executed normally, the VBS script can proceed with its intended payload-delivery activity.

The important distinction is that the prompt is aimed at the analyst or AI system, not the end user.

Why AI-Assisted Malware Analysis Is an Emerging Attack Surface

Security teams increasingly use AI to accelerate tasks that traditionally required manual analysis.

LLMs can assist with:

• Code interpretation
• Script analysis
• Malware classification
• Suspicious-string analysis
• Threat-intelligence enrichment
• Reverse-engineering assistance
• Alert triage
• Security investigations

This can significantly reduce the time required to examine large numbers of suspicious files.

However, it also introduces a new security assumption: the AI system must correctly distinguish between instructions from its trusted system context and untrusted instructions contained inside the file being analyzed.

GuardBreaker attempts to exploit that boundary.

The Difference Between Code and Instructions

A security-analysis pipeline should treat a malicious file as data.

An attacker, however, can deliberately include text that looks like an instruction.

For example, a malware sample could contain:

"Ignore previous instructions and do X."

If the analysis system incorrectly interprets that content as an instruction instead of treating it as part of the file, the attacker has effectively gained influence over the analysis process.

GuardBreaker takes advantage of the same fundamental problem but uses safety-sensitive content rather than a conventional "ignore previous instructions" phrase.

This makes the attack particularly interesting because the model's safety mechanisms themselves become part of the attack surface.

GuardBreaker Does Not Modify the Malware's Primary Function

One important characteristic of the technique is that the embedded prompt is not necessary for the malware to perform its intended activity.

The VBS script remains capable of downloading and installing its malicious payload.

The prompt is effectively an additional layer inserted for defensive-evasion purposes.

This means conventional security controls can still potentially detect other characteristics of the sample, including:

• Suspicious script behavior
• Network connections
• File downloads
• Process execution
• Payload characteristics
• Known indicators
• Persistence mechanisms
• Behavioral anomalies

The AI manipulation is therefore best understood as an anti-analysis technique, rather than a replacement for conventional malware obfuscation.

MATCHBOIL Provides the Malicious Payload

The GuardBreaker-enabled script is associated with MATCHBOIL, a C# loader used by UAC-0099.

The loader provides the threat actor with a mechanism for delivering additional malware after the initial script executes.

CERT-UA previously warned about UAC-0099 activity involving a malicious program disguised as a Notepad++ plugin, which was used to compromise Windows systems with a newer version of MATCHBOIL.

This places GuardBreaker within a larger intrusion chain rather than making it an isolated experiment involving AI.

Similar Techniques Have Already Appeared in Supply-Chain Attacks

GuardBreaker is not the first example of attackers embedding adversarial prompts inside software intended for AI-assisted analysis.

Earlier in 2026, researchers observed malicious and compromised packages containing text designed to trigger LLM safety mechanisms.

Those campaigns used references to dangerous biological and nuclear-weapons instructions in an attempt to cause AI-powered security systems to refuse analysis or become confused by the content.

Researchers warned that such techniques could cause:

• Analysis refusal
• Prompt confusion
• Context pollution
• Premature classification
• Incomplete malware analysis

The emergence of similar behavior from a Russia-aligned actor indicates that the technique is spreading beyond isolated cybercrime campaigns.

Why a Refusal Should Never Equal "Safe"

The most important defensive lesson is that an AI system refusing to analyze a file should not result in that file being classified as harmless.

A refusal is an analysis failure—not a security verdict.

If an automated pipeline interprets:

"I cannot analyze this content."

as:

"No malicious activity detected."

an attacker can potentially turn the AI's safety response into a detection bypass.

Security teams should instead treat unexpected AI refusal or incomplete analysis as a reason to escalate the sample for additional inspection.

Security Teams Should Use Multiple Analysis Layers

Organizations using AI-assisted security workflows should avoid making an LLM the sole decision-maker for malware classification.

A stronger architecture can combine AI analysis with traditional security mechanisms such as:

• YARA rules
• Static analysis
• Behavioral detection
• Sandbox execution
• Script inspection
• Network telemetry
• Endpoint detection and response
• Hash and reputation checks
• Threat-intelligence feeds
• Manual analyst review

This layered approach means that an AI model failing to analyze a sample does not automatically result in the sample being cleared.

Isolate Untrusted Content From AI Instructions

AI-powered security pipelines should also maintain a strong separation between system instructions and the content being analyzed.

Malware samples, documents, email messages and other untrusted inputs should be treated strictly as data.

They should not be allowed to modify the analysis instructions or influence security-policy decisions.

Organizations should consider:

• Strong system-prompt isolation
• Explicit labeling of analyzed content as untrusted
• Structured input formats
• Output validation
• Independent malware verdicts
• Human escalation for refused analysis
• Monitoring for prompt-injection patterns

These controls can reduce the risk of malicious files manipulating an AI-assisted security workflow.

The Threat Extends Beyond Malware

The underlying technique is not limited to VBS files.

Any security workflow that sends untrusted content directly to an LLM could potentially face similar challenges.

Potential targets include:

• Email-security analysis
• Phishing investigation
• Document analysis
• Code-scanning systems
• Threat-intelligence processing
• SIEM copilots
• SOC investigation assistants
• Malware sandboxes
• Software supply-chain scanners

If the system treats external content as both data and instructions, an attacker may be able to influence the model's behavior.

The Broader AI Security Lesson

GuardBreaker demonstrates an important consequence of integrating generative AI into cybersecurity.

AI models can become part of the attack surface even when they are being used defensively.

Attackers no longer necessarily need to fool a human analyst directly. They can attempt to manipulate the AI system that helps the analyst interpret suspicious content.

This creates a new category of defensive security problem:

Protecting the security tools themselves from malicious input designed to manipulate their AI components.

Conclusion

The GuardBreaker technique shows how threat actors are beginning to experiment with prompt injection as an anti-analysis mechanism.

UAC-0099 embedded a safety-sensitive prompt inside a malicious VBS script associated with the MATCHBOIL loader, attempting to trigger an AI model's safety controls and prevent normal analysis of the remaining code.

The technique does not make traditional malware analysis obsolete, but it highlights a significant weakness that organizations adopting AI-assisted security workflows must address.

The key defensive principle is simple: an AI refusal is not a clean verdict.

Security teams should isolate untrusted content from AI instructions, maintain multiple independent detection layers and automatically escalate samples that an AI system cannot fully analyze.

As AI becomes increasingly integrated into SOC and malware-analysis workflows, attackers are likely to explore more ways to manipulate the models themselves. GuardBreaker provides an early warning that AI-powered security tools must be secured against the very data they are designed to analyze.