Malware is moving from embedding its malicious logic to generating it at runtime with a language model.
For decades, malware has operated on a logic that is easy for defenders to understand. The attacker writes the malicious code, packages it with a set of exploits chosen in advance, and distributes it. Defense, broadly speaking, consists of recognizing that known code and blocking the attack paths it already carries built in. Under that model, patching the specific vulnerability a threat exploits is enough to stop it.
That assumption is starting to crack. Two findings, one observed in practice and the other demonstrated in the lab, point in the same direction: malware is moving away from embedding its malicious logic in a predefined way and toward generating it at runtime with the help of a language model. This is not just about AI helping to write malware ahead of an attack, something we already knew about. It is about code that queries an AI while it runs in order to produce, on the spot, exactly what it needs against each victim.
Analyzed separately, each case is an isolated data point. Seen together, they trace a clear trajectory with direct consequences for how we design our defenses.
In its November 2025 report, Google's Threat Intelligence Group (GTIG) documented a technique it called “just-in-time modification” [1]. The central idea is that the malware no longer carries its evasion code predefined; instead, it requests it from a language model during execution itself.
The most illustrative example is PROMPTFLUX, an experimental dropper written in VBScript identified by GTIG in early June 2025. Its most novel component is a module dubbed “Thinking Robot,” designed to periodically query the Gemini API and obtain new code with which to evade antivirus software. Some variants went as far as instructing the model to rewrite the script every hour, asking it to act as an expert VBScript obfuscator. It is worth being precise about its actual status: according to Google, the sample was in a development or testing phase, with incomplete functions commented out in the code, and it did not demonstrate the ability to compromise a network or a device. Google, for its part, disabled the Gemini accounts and access keys tied to this activity, cutting off the channel the malware used to query the model.
Alongside it, GTIG described PROMPTSTEAL, also known as LAMEHUG, attributed to the group APT28. Unlike PROMPTFLUX, this one was indeed observed in real-world operations. It is a data collector that queries a language model, specifically Qwen2.5-Coder via Hugging Face, to generate at runtime the commands for gathering files and system information. According to the analysis, it directly executes the commands the model returns and likely relies on stolen API tokens.
What matters about this first phase is a limitation that works in the defender's favor. All of this malware depends on a model hosted outside the compromised machine. To work, it needs to make network calls to an external API, it drags along credentials or tokens that in many cases are stolen, and it generates usage patterns that can look anomalous. Each of those signals is an opportunity for detection.
This is where the second finding comes in, one that is much more recent. A preprint published on arXiv on June 2, 2026, produced by researchers from the University of Toronto, the University of Cambridge, and other institutions, presents what it describes as a new kind of threat: a worm that generates attack strategies tailored to each target it encounters [2].
The fundamental difference from traditional malware is that this one does not embed a predetermined set of exploits at compile time. Instead, it uses an open-weights language model running on a single GPU to generate the attack logic at runtime, adjusted to what it discovers on each machine. To do this, it appropriates the compute capacity of the compromised host itself and devotes it to its reasoning.
The results of the experiment, carried out on an isolated and deliberately vulnerable network, help put the problem in perspective [2]. Across 15 independent runs on a network of 33 hosts that reproduced common corporate vulnerabilities, such as reused passwords, the worm identified on average around 31 vulnerabilities, gained elevated access on about 23 hosts, roughly three quarters of those it actively attacked, and replicated autonomously to about 20 hosts, around 62 percent of the network, over the course of seven days. All of this without prior knowledge of the network topology and without human intervention.
It is important to keep this case in proportion. It is a preprint still undergoing peer review and a proof of concept run in an isolated, controlled environment, not a threat observed in real operations. Its value lies not in any damage caused but in what it shows can be built today with publicly available, low-cost models.
The thread connecting the two findings is not simply that “malware uses AI.” It is something more specific and with more uncomfortable implications for defense. AI-assisted malware is evolving from depending on the cloud toward being self-sufficient, and that shift disables two layers of defense at once.
The first layer is signature-based detection. It works by recognizing known code. It loses effectiveness against malware whose code is generated or rewritten on every execution, because there are never two identical runs to recognize.
The second layer is network-traffic-based detection. In the phase represented by PROMPTFLUX and PROMPTSTEAL, the malware still has to call an external API, which makes it possible to detect connections to language-model endpoints, anomalous use of API keys, or stolen tokens in circulation. The Toronto worm eliminates precisely that opportunity by integrating the model into the malware itself. If inference happens locally, on the machine's own GPU, there is no external call to intercept.
Put another way, one case shows what is already happening and the other points to where the trend is heading. Each one on its own is interesting. Together they mark a trend, and it is that trend which is worth keeping in mind when planning.
Several practical consequences follow from this trajectory, and they are worth laying out in order.
Patching driven by a single CVE rests on an assumption that no longer always holds. It assumes we know in advance which exploit needs to be neutralized. When malware can inspect exposed services, read freshly published security advisories, and build a new attack path at runtime, closing a specific vulnerability stops being sufficient. The reasonable response runs through defense in depth and aggressively reducing the attack surface.
Basic hygiene gains weight rather than losing it. It is telling that the Toronto worm leaned on weaknesses as common as reused passwords. AI does not need extraordinary capabilities to make progress when it finds poorly protected systems. It simply exploits, quickly, what was already misconfigured.
Detection needs to shift toward behavior. Against code that mutates on every run, monitoring for runtime anomalies proves more robust than comparison against static signatures. This includes watching for unexpected use of local resources, such as GPU or inference activity that is hard to justify on a given machine.
And monitoring traffic toward language models remains useful, though with an implicit expiration date. Detecting and controlling outbound connections to AI APIs, as well as protecting and rotating credentials, mitigates the current phase of the problem. It is worth maintaining, but without forgetting that the self-contained variant is designed precisely not to emit that signal.
Neither of these two cases justifies alarmism. PROMPTFLUX was a test sample with no demonstrated ability to compromise networks, and the Toronto worm is an academic proof of concept in an isolated environment. What they do justify, taken together, is revisiting some assumptions we have taken for granted for a long time.
The conclusion is not that current defenses have stopped being useful. It is that the mental model on which they were built, that of a static, recognizable malicious artifact, is beginning to fall short against an attack that is generated in the moment and, increasingly, without depending on anything external. Anticipating that shift today, while it is still nascent, is far cheaper than reacting once it has become widespread.
At Kaptor Security we constantly track new trends in cybersecurity and artificial intelligence in order to stay ahead of threats like the ones described in this article and turn that knowledge into concrete defenses. If you would like to assess the security of your artificial intelligence integrations or review your defenses against this kind of threat, we can help.