LLM-based code scanners won’t help attackers build a nuclear weapon, but that refusal could work in their favor
10 Sep 2026
•
,
4 min. read
Malware developers have long adapted their code and tactics to the defenses and scrutiny that are likely to stand in their way. Using various evasion and anti-analysis methods, they routinely attempt to hinder code analysis or prevent their malware from revealing its true behavior while under inspection. Other tools – notably, EDR killers, documented extensively by ESET researchers – go straight after security solutions themselves.
As LLM-based tools increasingly assist with various security tasks, including code triage and analysis, it was only a matter of time before threat actors began to look for practical ways to subvert them, too. Alongside conventional evasion techniques, some are taking a different tack: the adversarial input that’s intended to frustrate analysis is left in plain sight.
ESET researchers recently spotted one such attempt in a VBScript that the Russia-aligned group UAC-0099 used in the early stages of an attack against a target in Ukraine. By inserting a decoy request for guidance on building a nuclear weapon into the script’s comment, the bad actor aimed to trip the safety guardrails of an LLM-powered code scanner and cause it to stop inspecting the rest of the file – before ever reaching the malicious code. The script’s purpose was to download and install MATCHBOIL, a loader used exclusively by this group to deliver additional payloads.
This simple technique, which ESET has named GuardBreaker, relies on precisely the kind of ‘request’ that LLM models are known to decline:
Unlike many other tricks in attackers’ evasion playbooks, this decoy comment is there for ‘everyone’ – especially for the models analyzing the code – to see. In addition, it has no effect on the script’s behavior at runtime, of course. Nonetheless, its presence suggests that UAC-0099 was accounting for an AI system in the target’s defenses – just as in other recent attacks the group also checked for processes associated with established analysis tools such as IDA and Wireshark.
Anti-analysis takes aim at another target
GuardBreaker is best understood as a very simple attempt at prompt injection: an attacker’s input reaches the LLM at inference time through a file that’s being analyzed. That way, it aims to exploit an architectural weakness in today’s LLMs, which process untrusted content and trusted instructions without dependable boundaries between the two.
Similar attempts to interfere with LLM-powered scanners have surfaced especially in software supply-chain attacks. For example, Socket found fabricated system instructions and policy-triggering content placed ahead of a JavaScript payload in malicious PyPI packages. Reporting on the same broader campaign, StepSecurity found a prompt that flat-out instructed any analyzing model that parsed the file to disregard the malicious code and report the package as clean. In another incident, researchers spotted an npm package whose main JavaScript file repeated “You’re absolutely right!” tens of thousands of times in the hopes of exhausting the model’s context window and putting the malicious script that followed beyond practical analysis.
Attackers could attempt to blind the analysis pipeline to malware through other trivial tricks, or even their combinations: unusual or awkwardly structured files could end up being truncated or parsed only in part. Some parts of the malicious code could be concealed under the pretense of being confidential information or other sensitive data.
Other attacks could deploy custom file types that would require attackers’ tools to process, whereas others still could steer AI agents towards actions that require human review, thus causing delays exploiting the response times. Agents that invoke external tools, such as unpackers or deobfuscators, widen the attack surface further, as the calls could in some cases be hijacked for malware delivery and execution.
Who’s in charge?
GuardBreaker drives home a lesson that security practitioners know already: any technology that could affect an attacker’s chances of success will end up in their crosshairs. Businesses relying on LLM-powered code reviews and other LLM-assisted workflows need to know what exactly any such tool inspects, where it sits in the decision chain, as well as what happens when it refuses to respond or can’t complete a task.
Crucially, however, no single LLM engine should have the sole authority to decide that a piece of code is safe. AI-assisted output needs to be cross-validated using a multi-layered and multi-model approach that makes the best use of advanced automation and human expertise; meanwhile, a lack of output, too, needs to trigger further checks.
Organizations of all sizes also need a clear path from prevention to detection and response. For those without their own round-the-clock security teams, managed detection and response (MDR) can supply the requisite follow-through where an expert can investigate any suspected incidents, including in the context of other activity across the environment, and determine the next steps. This approach is best built on decades-long use of AI’s foundational technologies, tried-and-tested analysis methods, expert judgment, threat research and global telemetry. That way, any business can ensure that an action by one LLM model doesn’t become a blind spot in the organization’s cyber-defenses.
Click Here For The Original Source.
