In early November 2025, Google’s Threat Intelligence Group published a warning about a new trend: malware calling large language models while it runs, so that it can rewrite and obfuscate its code. One experimental family tracked as PROMPTFLUX uses LLM API calls to generate new Visual Basic scripts that overwrite earlier copies on disk. This “just-in-time” rewriting helps the malware avoid signature checks and makes static detection far less effective.
Other AI-enabled malware families named in GTIG’s report include PROMPTSTEAL, FRUITSHELL, and PROMPTLOCK, with attackers not limiting the use of AI to merely planning and phishing but embedding model calls into malware workflows to produce polymorphic payloads, design evasion techniques, and even draft social-engineering lures on demand. While many samples appear experimental, the shift signals a new operational phase in cybercrime.
Here’s how such an LLM-aided attack looks in real life. A small script, usually VBScript for current samples, is executed on the victim machine. It contains a method or key to invoke an LLM endpoint. The script will send a machine-readable prompt to the model, requesting it to return code that is obfuscated and performs persistence, keylogging, or data theft. The resulted code is written to startup folders or scheduled tasks so that the malware survives reboots. In time, the malware asks for alternate obfuscations or new features, effectively morphing to evade detection.
The danger is partly technical and partly social. On the technical side, runtime self-modification defeats defenses based on known file hashes, static byte patterns, or fixed IOCs. On the social side, powerful LLMs lower the skill barrier: less experienced actors can create stealthy, working code by simply crafting a good prompt. The combination means more attackers can build adaptive threats quicker.
Defenders must, therefore, move away from static detection to behavior and telemetry-based approaches. Some practical measures would include logging and alerting on unexpected process behavior, rapid file writes to persistence locations, and unusual outbound traffic to model provider endpoints. Egress filtering and network segmentation can stop an infected host from calling LLM APIs, while least-privilege policies prevent simple scripts from writing into startup folders or modifying task schedules. These steps make self-modifying code persistence more difficult.
Industry reaction has been swift: security vendors are updating their detection engines to flag “just-in-time” code generation patterns and model runtime behavior rather than static signatures. Cloud providers and LLM vendors are hardening API controls, introducing rate limits, and enhancing anomaly detection so that abusive calls can be blocked or tracked. Google has already disabled the malicious assets it has identified and published guidance for defenders.
Worth noting are the current limits of this threat: many observed samples remain proofs-of-concept; LLM-generated code can be buggy or show consistent stylistic fingerprints which analysts can spot. Operational scale is nontrivial: to turn experiments into large campaigns, reliable API access, stealthy infrastructure, and careful attacker discipline are needed. Yet model quality and cost are improving, so the window to widespread abuse is shrinking.
Beyond the immediate technical defenses, this development raises policy questions.
- Should LLM providers require more thorough identity checks, monitoring, or usage vetting for code generation endpoints?
- Can models be hardened to refuse requests aiming at persistence, obfuscation, or exploitation?
- How should law enforcement and cloud providers collaborate to track and disrupt malicious API use?
Each of these shifts the responsibility between vendors, regulators, and enterprises.
Specific steps organizations can take today include: updating incident-response plans to include LLM abuse, logging outbound calls from endpoints, adding behavioral rules to EDR/XDR tools, implementing strict egress controls, and training SOC teams to investigate anomalies that look like runtime code generation. For users, basic hygiene, patching, avoiding unknown scripts, and using reputable security solutions that look at behavior, remains the best immediate defense.
Watch to know more about AI attacks
The report of Google’s GTIG is a clear wake-up call: AI is moving from a productivity tool for attackers into a core part of their operational toolkit. Though today’s samples are early and imperfect, the path to robust, AI-driven malware is short unless defenders adapt. The next phase in cybersecurity will be a race: adaptive attackers vs. behavior-focused defenses. Whichever side innovates more quickly will set the balance.
