Article · AI malware

Is Russia weaponising malware and AI as a WMD?

26 August 2026 · incident record and method in the companion technical paper; sources below

For thirty years, catching malware meant recognising it. Every virus carried its weapon inside itself, and if you had seen the weapon before, you knew the virus. In 2025 the malware put the weapon down and picked up a phone. It calls a language model, asks it what to do next, and does whatever it is told. There is nothing left to recognise.

This is not a forecast. It is the incident record of the last eighteen months, and it reads like something out of a paranoid draft nobody was meant to ship.

Start with the clearest case. In July 2025, Ukraine’s national cyber-defence team caught a piece of malware they called LameHug, and tied it to APT28 — a unit of Russian military intelligence. Pull it apart and you find almost nothing: no routine to search the disk, no list of what to steal. What it has instead is a written request to a hosted AI model, telling the model to behave like a system administrator and produce the commands to explore the machine and gather what matters. The malware runs whatever comes back. Google’s threat team, who track this for a living, called it the first time they had ever watched malware call out to a language model in a live attack.

Attribution: Ukraine’s CERT tied LameHug to APT28 with moderate confidence; Google’s Threat Intelligence Group, tracking the same malware as PROMPTSTEAL, independently attributes it to APT28. APT28’s identity as Russian military intelligence is established from the 2018 US indictments.

Read that again. The attack code did not exist until the moment of the attack.

You cannot keep a photograph of a face that is drawn fresh each time. That is the whole point of it, and it is why thirty years of “have we seen this before” walks straight past it.

A month later, in August 2025, the security firm ESET found the same idea pointed at ransomware — software that locks up your files and demands payment. They named it PromptLock. It carries a small model on the machine itself and asks it, on the spot, to write the little scripts that hunt through your files, copy them out, and encrypt them. I want to be exact, because being exact is the whole job here: ESET judged PromptLock a proof of concept, not something that had robbed anyone yet. So this one is a warning shot, not a wound. But you do not get to un-know that it works.

The weapon is no longer in the malware. The malware is just the phone call.

And then the part that is genuinely hard to sit with. In November 2025, the AI company Anthropic disclosed that a state-linked group had used one of its own coding assistants to run — not help with, run — the bulk of an espionage campaign against around thirty organisations. The AI did the reconnaissance, found the way in, stole the credentials, moved through the networks. Humans stepped in at perhaps a handful of moments to say yes or no. The rest was the machine. It is now written up as a formal case in the industry’s shared catalogue of attacks, the same way any other named campaign is.

The thing that changed is not that attackers got cleverer. It is that a single attacker used to be able to run one break-in at a time, because break-ins take a skilled person’s hours. Hand the hours to a machine and that limit is gone. The expensive, rationed thing — a competent operator’s attention — stops being rationed. That is the whole shift, and it is why this stopped being a research curiosity and started being a Tuesday.

So can you catch it?

Partly — and the honest word is partly, because the alternative is to sell you a photograph of a face that is never the same twice.

Here is the crack in the disguise. This malware can throw away its attack code, but it cannot throw away two things, or it stops working. It has to reach a model — somewhere in it there is a call out to an AI service. And it has to run the answer — somewhere it takes what the model said and executes it. Reach out; run the reply. That pairing is not a habit you can drop. It is the engine. And unlike the attack code, the engine sits there in the source, where a scanner reading the code before it ships can see it: a call to a model, feeding into a command that runs. Find those two things wired together and you have found the shape of this entire class of malware — not by recognising the weapon, but by recognising the phone and the hand that acts on the call.

The plain limits, said out loud, because a defence you trust too much is worse than none: a determined attacker can disguise the phone number — build the model’s address in pieces so no clean version appears in the code — and reach the “run it” step by a crooked path a simple scan misses. This catches the careless and the honest-looking. It does not catch a professional who has decided to hide. What it does do is raise the cost and close the easy door, which is most of the doors.

Now the harder ghost: the one already inside

Everything above is an attacker on the outside, reaching in. Turn it around. What about someone you already trust, who builds the trap themselves?

In March 2024 the world got the textbook case, and it is worth telling straight because nothing about it is reassuring. A piece of software called xz sits, quietly, inside nearly every computer running Linux — which is to say inside a large share of the servers running the internet. For about two years, a person using the name “Jia Tan” contributed to it, helpfully, patiently, until the exhausted volunteer who ran the project handed them the keys. Then they planted a backdoor: a secret way in, for anyone holding the matching key, straight past the locks on a vast number of machines.

Here is the part that should keep you up. The trap was not in the code anyone read. It was hidden inside binary test files — blobs that are supposed to be meaningless test material — and stitched together quietly by the build machinery as the software was packaged. You could have read every line of the visible source for a week and seen nothing. It was the most-reviewed kind of software there is, and review did not catch it.

Do you know what caught it? A man who noticed his logins were half a second slow.

One engineer, running a database benchmark, felt a lag that annoyed him — half a second where there should have been none — and had the particular stubbornness to chase it, down and down, until it opened out into the backdoor. Not a scanner. Not a review board. Not a rule. Curiosity, and a man who could not let half a second go.

So let me not pretend. No tool reliably catches a patient, skilled insider from reading their code, because their whole craft is to write code that reads as innocent — or, as in xz, to keep the poison out of the code you read entirely. If someone tells you their scanner would have stopped xz, hold onto your wallet.

But the xz change was loud — in a way nobody was listening for

Here is what turns the story from despair into a plan. The backdoor code was invisible. The backdoor change was not. Look at xz not as text to read but as a change against everything that project had ever done before, and it shouts.

Binary blobs appearing in a folder that had only ever held plain text. A person whose entire history was compression algorithms suddenly editing the build machinery. A shipped package that did not quite match the public code it claimed to come from. None of those is a line of malicious code. Every one of them is a thing that had never happened before in that project’s life — and all three happened at once.

The trap was written to read as innocent. It was not written to look normal against the project’s own past.

This is a different way of watching. It does not ask “is this code evil?” — the question the insider has spent two years making sure fails. It asks “is this change unlike everything that came before it?” And that question does not care how innocent the code looks, because it never reads the code. It reads the shape: who touches what, which files hold which kinds of thing, what the build does, whether the package matches its source. Measured against a project’s own history and an author’s own habits, the xz commits were anomalies with flashing lights — if anyone had been measuring the shape instead of reading the text.

That is not a claim to catch backdoors. Nobody honest makes that claim. It is a claim to do the one thing that actually worked in the only case we have: to point scarce human attention at the handful of changes that are strange, so a person — the real defence, every single time — spends their stubbornness where it is most likely to matter. xz was caught by one person’s attention arriving, by luck, in the right place. The job of the tooling is to stop leaving that to luck.

What all of this actually says

Two threats now walk in through code: an outsider whose malware writes itself by asking a machine, and an insider who hides a trap in plain sight. The first you can catch the shape of, and honestly, so long as you are honest about the disguises it can still wear. The second you cannot catch by reading — but you can catch by noticing that a change does not resemble the ten thousand changes before it.

Neither of these is a tool that hands you a verdict. Anyone selling you a verdict in this territory is selling you the photograph of the face that is never the same twice. What both are is a way of aiming a person — the engineer who chases the half-second, the reviewer with an afternoon and a bad feeling. In every real case in this piece, that person was the whole defence. The machine’s only job, and its only honest promise, is to tell them where to look.