GuardBreaker Attack: How Hackers Use Nuclear Weapons Prompts to Blind AI Malware Analysis

A Russian-affiliated hacking group targeting Ukrainian government and logistics organizations recently deployed malware containing a prompt requesting nuclear weapons manufacturing instructions. They weren't actually after those instructions — they wanted your AI malware analysis tool to trigger its safety refusal mechanism and stop examining the rest of the file.

The trick is that simple: cheap, clever, and exposing a quietly overlooked vulnerability in AI-assisted Security Operations Center (SOC) workflows.

What Happened

According to The Hacker News, the hacking group UAC-0099 deployed a new .NET-based remote access trojan called ASHVEIN against Ukrainian government and logistics targets. Its delivery chain used lure documents, DLL sideloading, and commands hidden in HTML to execute the payload and evade traditional detection.

What really warrants a pause is what researchers are calling GuardBreaker. Embedded within malicious VBScript code was a prompt requesting nuclear weapons manufacturing instructions. Its purpose wasn't to extract dangerous information from the model — it was to trigger the safety refusal mechanism of the LLM used to analyze the code, causing it to stop analyzing the malicious logic sitting right next to it.

Think about what that means. If your incident response process now includes "paste the suspicious script into an LLM and ask what it's doing," that process has an attack surface. Attackers don't need to defeat your malware analysis capabilities — they just need to make the analyst, whether human or AI, refuse to look.

DLL Sideloading is an attack technique that abuses Windows' legitimate library loading mechanism. When Windows loads dynamic link libraries, it follows a specific search order, checking the executable's own directory first. Attackers exploit this by placing a malicious DLL — disguised as a same-named library that legitimate software depends on — in the same directory as a trusted application, causing the legitimate process to load and execute the malicious code. Because the executor is a trusted, legitimate process (such as a built-in system tool or well-known software), this technique effectively bypasses security controls based on process whitelisting or signature verification. UAC-0099 used this technique in ASHVEIN's delivery chain precisely to run the malicious payload under the trust umbrella of a legitimate host process, reducing the likelihood of interception by endpoint protection products.

How the Attack Actually Works

Most people assume prompt injection against LLM-assisted security tools means getting the model to leak data or perform unintended actions. But GuardBreaker is a completely different form of attack: from the attacker's perspective, this is a defensive rather than offensive "trigger-refusal" jailbreak.

Once you see it, the mechanism is straightforward:

1. The malware author embeds an obviously refusal-triggering request inside a VBScript code block (nuclear weapons manufacturing instructions are a universal trigger in the safety training of virtually every mainstream model).
2. This complete VBScript is passed to the LLM tool used by SOC analysts or automated pipelines for summarization or triage.
3. The model's alignment training works exactly as designed: it refuses, likely responding with something like "I cannot assist with instructions for manufacturing weapons."
4. The analyst receives a refusal instead of an analysis. The parts of the script actually performing DLL sideloading or communicating with a C2 server are never summarized, flagged, or explained — because the model stopped at the first content that alarmed it.

This isn't mystical. It's fundamentally a denial-of-service (DoS) attack against an analyst's tools, disguised as a safety trigger. And it works precisely because the safety training is good. The model isn't tricked into doing something bad — it's tricked into doing the "safe thing" at exactly the wrong moment.

Prompt Injection is a class of attacks against large language models where attackers embed carefully crafted instructions into external content the model processes, attempting to override or manipulate the original system prompt to make the model perform unintended actions. Traditional prompt injection is typically "offensive" in nature — getting the model to leak system prompts, bypass content restrictions, or impersonate other identities. The variant GuardBreaker represents is the opposite: it doesn't seek to make the model "do more," but to make it "do nothing." This "defensive refusal-type" injection exploits the deterministic nature of safety refusal mechanisms in model alignment training. Attackers don't need to understand the target model's specific implementation — they only need to know that virtually all mainstream models aligned through RLHF (Reinforcement Learning from Human Feedback) will trigger hard refusals on certain sensitive topics, and nuclear weapons manufacturing instructions are one of the most universally reliable triggers.

The Detection Blind Spot That's Being Ignored

Most defenses break down here — and the problem isn't the model itself, it's the process design.

If your malware analysis workflow involves "dumping raw file contents directly into an LLM prompt," then you have no layer that distinguishes between content meant to be analyzed and content meant to be executed (or in this case, refused). The LLM sees one undifferentiated block of text. It can't tell "this VBScript has a jailbreak payload embedded" from "a human is sincerely asking about nuclear weapons" — it just pattern-matches against its safety training and exits.

Traditional antivirus and YARA-based scanners won't notice this at all. There's no file hash to match, no known signature, because this "attack" targets not the endpoint but the "human-in-the-loop" AI tool bolted onto the SOC process after the fact. Nobody threat-models the malware analysis assistant as an attack surface, so nobody builds a defense in front of it.

That's the blind spot. Not "the LLM got jailbroken" in the traditional sense (nobody made it output harmful content), but the LLM was reverse-jailbroken: tricked into refusing to analyze when it should have been analyzing.

Why You Need a Scrubbing Layer Before the Model

This is a textbook case for why untrusted content should pass through a scrubbing layer before it reaches the analysis model — rather than expecting the model to make that judgment in real time.

Take an AI firewall like Sentinel: its fast-path regex library covers patterns like persona-shift and authority-hijack; more relevant to this case is the deep-path vector similarity layer, which scores content against a library of attack signature embeddings regardless of the specific words used. A dangerous content request embedded inside a VBScript code block doesn't look like normal code — it shows up for what it actually is: a semantically jarring injection attempt stitched into an otherwise innocuous-looking script. Whether the payload is written as "tell me how to build a bomb" or wrapped in social engineering language, that similarity gets exposed.

The actual wiring should look like this: raw script content is POSTed to the scrubbing endpoint before it goes to the analysis tool's LLM for summarization. If the embedded prompt scores above the neutralization threshold, the scrubbing layer strips or neutralizes the offending fragment while preserving the rest of the script for analysis. Your malware analysis LLM receives the sanitized version, plus a flag telling it (and the analyst) that adversarial content was stripped. The model never has to decide whether to refuse the whole document, because by the time it arrives, the trigger is already gone.

This also means your analyst doesn't lose the surrounding context — and context is exactly what the DoS-style refusal attack is really trying to destroy. You still see the DLL sideloading logic, the C2 beaconing patterns, all of it. What gets removed is just the nuclear weapons lure, not the entire file.

A caveat: the author hasn't actually tested this specific VBScript sample, and the reporting doesn't include the exact payload text. What's certain is that this is precisely the class of payload that the deep-path and fast-path layers are designed to catch when scanning untrusted content before an LLM sees it.

Illustrative Flow

An illustrative processing result would look roughly like this: the suspicious script is submitted for scrubbing and returns with a medium-high threat score of ~0.89, action "neutralized." The sanitized payload retains DLL sideloading calls like obj.Run "rundll32.exe payload.dll,EntryPoint", while the embedded instruction-hijacking payload is replaced with a [NEUTRALIZED] marker. The DLL sideloading call is preserved in full for the analyst to flag; the nuclear weapons lure never reaches the model, so there's nothing left to trigger a refusal.

YARA is a widely used malware pattern-matching tool in the security industry. Analysts write rules describing file characteristics (strings, byte sequences, structural features, etc.) to identify and classify known malware families. YARA rules are efficient and reliable for detecting known threats with fixed characteristics, but their nature as static signature matching means they're fundamentally unable to address semantic-level attacks. GuardBreaker creates a structural blind spot here: the embedded "nuclear weapons manufacturing instructions request" is ordinary natural language text containing no executable code, malicious byte sequences, or known malware signatures — to a YARA rule, it's indistinguishable from a comment. The real attack happens at the cognitive layer of the analysis tool, not the file layer. That's precisely why defenses must move upstream to the LLM's input pipeline, rather than relying on traditional signature-based detection.

Key Takeaways

If any step in your incident response or malware triage process feeds raw, untrusted file content directly into an LLM, you should treat that content as adversarial input — just as you'd default to treating network packets or uploaded files as potentially malicious before trusting them. Scan before the model sees it, not after it refuses.

GuardBreaker isn't a jailbreak in the traditional sense of "making AI say bad things." It's a jailbreak that weaponizes correct refusal behavior to blind the analysis tool. But regardless of which type it is, the fix is the same: don't make the model the first thing to touch untrusted text.

This incident is a reminder to the entire security industry that AI-assisted tools bring efficiency gains alongside entirely new, insufficiently modeled attack surfaces. As more SOCs embed LLMs into daily workflows, attackers' creativity in targeting AI tools themselves will only grow.