ESET Names GuardBreaker: UAC-0099 Buried a Prompt to Stall AI Malware Analysis

A Russia-aligned threat actor tried to break the analyst instead of the analysis. ESET researchers say the group known as UAC-0099 planted a booby-trapped comment inside a malicious script so that an AI-assisted analysis tool would refuse to look at the rest of the file. ESET named the technique GuardBreaker, and it is a clean example of a shift defenders have been bracing for: the sample your tooling reads is no longer just code to be scanned, it is input that can talk back to your model.

The disclosure, which ESET shared in a series of public posts and was reported by Help Net Security and The Hacker News on August 31, describes a technique aimed squarely at the automated, large language model (LLM) driven triage that more security teams now run over incoming files. UAC-0099 is a Russia-aligned group that has spent 2025 and 2026 running initial-access operations against targets in Ukraine and handing validated footholds to the GRU-linked Sandworm (also tracked as APT44) for follow-on, often destructive, operations.

What ESET Actually Disclosed

Strip GuardBreaker down and it is deceptively simple. Inside a malicious VBS (Visual Basic Script) sample, UAC-0099 embedded a refusal-triggering prompt referencing a restricted, safety-sensitive topic, placed as a script comment that does nothing when the file runs. The comment is not there to execute. It is there to be read by a machine. The goal, per ESET, is to draw an analysis LLM's attention to content its safety training is built to refuse, so the model balks and stops working through the code that matters.

That is the whole trick, and it is worth being precise about what it targets. GuardBreaker does not attack a sandbox, a signature engine, or a specific vulnerability. It attacks the model's safety layer, the same refusal behavior vendors spent years tuning to keep their systems from producing harmful output. The attacker turns that refusal from a feature into a denial-of-service against analysis. ESET's own framing is blunt on the takeaway. "AI and machine learning can be valuable tools in security, but they cannot be trusted blindly," the company's VP of artificial intelligence said, adding that without a multilayered approach behind it, "attackers will look for ways to manipulate or bypass it."

The wrapper matters as much as the trick. The GuardBreaker-tagged VBS script is not a standalone stunt. ESET assesses it as part of UAC-0099's working toolset, and its real job is to download and install MATCHBOIL, a loader used more or less exclusively by this group. In other words, the anti-analysis comment is riding inside live delivery malware, not a proof of concept.

Why This Is Not Just Another Jailbreak

Most adversarial-prompt stories you have read are about getting a model to say something it should not: bypassing guardrails to extract instructions, using a "you have permission" pretext, or splitting a task across sessions. GuardBreaker inverts that. The attacker is not trying to coax the model into helpful compliance. The attacker wants the model to refuse, because a refusal at the right moment stops the machine from reading the malicious payload underneath.

This is prompt injection wearing a threat-intel costume. The manipulative text lives in data (a code comment) that a defender's automated pipeline ingests and feeds to an LLM as part of "please analyze this sample." From the model's point of view, there is no clean line between the code it was asked to examine and the instructions hidden in that code. It is the same structural problem that makes indirect prompt injection so hard to solve in agents and email assistants, now pointed at the malware-analysis bench. And it lands on the exact workflow security teams have been rushing to automate, which is why it belongs in any serious conversation about AI security for defenders, not just AI safety for model builders.

It also fits a trend line. Cisco Talos has documented adversaries claiming false authorization to walk model guardrails, and this desk has covered Talos tying agentic AI to post-compromise operations. The novelty here is the direction of abuse: not making a model help you, but making it quit.

Who Is UAC-0099, and Why the Sandworm Link Matters

UAC-0099 is not a hobbyist. Ukraine's defenders and multiple vendors have tracked the group targeting government, defense, transportation, and energy organizations, typically as the front end of a longer operation. The pattern reported around this cluster is a division of labor: UAC-0099 gets in and confirms the access is real, then hands the foothold to Sandworm, the GRU-linked unit with a long record of wiper attacks against Ukrainian infrastructure. When an initial-access crew starts hardening its loaders against AI triage, the point is not the loader. The point is protecting the pipeline that ends in a destructive payload.

That context changes the risk calculus. GuardBreaker is a small technique, but it sits at the top of a kill chain that has ended in real damage. Buying an extra few minutes of analyst confusion is cheap insurance for an operation whose next stage is Sandworm.

What Defenders Should Do

The fix is not a new detection signature. It is a design assumption: if your triage pipeline runs an LLM over untrusted samples, the sample is now prompt-injection input, and you have to architect for that. The checklist below is the practical version.

Defender checklist for teams running AI-assisted malware analysis. The core principle: content inside a sample can socially engineer the model reading it, so refusal handling and human review are not optional.

A few of these deserve emphasis. The most dangerous failure mode is silent: an automated pipeline that logs a model refusal as "could not analyze" and quietly lets the file pass, or worse, treats "the safety filter tripped" as a sign the sample is harmless. Refusal handling has to fail closed, toward human review, not open. This is also a reminder that the cost of AI in the SOC is not only compute. Running safety monitoring and human oversight around these tools has real overhead, a tension this desk explored when OpenAI added a roughly 20 percent safety-monitoring tax to its own training. Teams adopting AI-assisted analysis should budget for the same kind of oversight rather than assume the tool replaces it.

What Is Not Yet Confirmed

Several things worth wanting to know are not established in the public reporting, and I am flagging them rather than filling the gaps. ESET has not publicly named which specific LLM-based analysis tools GuardBreaker was aimed at, and there is no confirmation in the reporting that the technique actually defeated any particular tool in the wild, as opposed to being a documented attempt. The specific victim organizations in Ukraine tied to this sample are not named in the coverage reviewed here. And there is no public evidence yet that other Russia-nexus clusters, or non-Russian actors, have adopted the same trick. Treat GuardBreaker as a proven technique and a clear direction of travel, not as a measured breach of a named product.

My Read

My read: this is an assessment, not a reported fact, but the strategic lesson is bigger than one VBS file. If your triage pipeline runs an LLM over untrusted samples, the sample is now prompt-injection input, full stop. Every assumption security teams have about "the analyst reads the file" breaks when the analyst is a model that can be addressed by the file. GuardBreaker is a low-effort, high-leverage move for an initial-access crew, which is exactly why I expect copycats. The teams that stay ahead will be the ones who treat their AI analysis tools like any other internet-facing parser: assume the input is hostile, keep a human on the verdict, and never let a refusal masquerade as a clean result.

Primary Documents

• Help Net Security: report on ESET's GuardBreaker disclosure (Aug 31, 2026)
• The Hacker News: Russia-aligned UAC-0099 and the GuardBreaker technique