AI Malware Reality Check: What’s Actually Happening

Most companies get this wrong: they prepare for “autonomous AI malware” while missing the boring, profitable way attackers are already using AI.

As we close out 2025, the real shift isn’t that malware has become sentient. It’s that attackers can now produce more phishing, more code variations, more recon, and faster iteration with fewer skilled operators. That’s why AI in cybersecurity can’t just mean “buy an AI tool.” It has to mean: instrument AI usage, detect AI-assisted tradecraft, and harden the controls that still stop attacks even when adversaries move quicker.

This post is part of our AI in Cybersecurity series, focused on practical reality: where AI raises risk, where it doesn’t (yet), and how security teams should respond without chasing sci‑fi threats.

AI malware isn’t “new malware”—it’s faster old malware

Answer first: AI malware today is mostly traditional attack chains with AI added to speed up steps like writing lures, generating code, and orchestrating tools—not a brand-new category of unstoppable tactics.

A useful way to think about “AI malware” is whether the malicious software’s development or runtime behavior depends on generative AI or LLMs. That dependency can show up in different ways:

• LLM-translated: attackers translate existing malware or scripts into new languages to evade detections or match a target environment.
• LLM-generated: code is produced by prompts and then compiled/used like normal tooling.
• LLM-deployed: AI assists packaging, staging, or delivery (for example, generating droppers, macros, or scripts).
• LLM-driven: the malware calls an LLM during runtime to decide commands or actions.
• LLM-embedded: the malware carries its own local model (“bring your own AI”) and runs it on the victim host.

Here’s the stance I take: the hype lives in “embedded” and fully autonomous behavior. The operational risk in 2025 lives in “generated” and “driven,” especially when those systems can call legitimate cloud AI services.

What’s changed for defenders

Speed and scale. If an attacker can create 200 tailored phishing messages in the time it used to take to write 20, your controls face more attempts, more variation, and fewer repeated indicators.

Language and localization. AI makes believable lures easier across regions and business contexts. That matters during year-end cycles—invoice fraud, gift-card scams, benefits changes, procurement renewals—because the content can be tailored to exactly what your staff expects in December.

Iteration. Attackers can quickly rewrite scripts to evade simplistic detections. Even when AI output is imperfect, it’s “good enough” when paired with testing loops.

Use a maturity model to separate risk from marketing

Answer first: You’ll defend better if you classify AI-enabled threats by maturity instead of treating every “AI malware” headline as equal.

Recorded Future’s AI Malware Maturity Model (AIM3) is a practical lens because it focuses on what matters operationally: how much autonomy and integration AI has in the attack chain.

AIM3 levels (plain-English interpretation)

• Level 1 — Experimenting: prototypes and proof-of-concepts. Often academic or lab demos.
• Level 2 — Adopting: AI assists familiar tasks (phishing text, recon, code help). Humans still drive everything.
• Level 3 — Optimizing: AI is integrated into the chain and may generate commands or adapt actions with near-real-time feedback, usually via an API.
• Level 4 — Transforming: AI-native offensive frameworks with agent-like planning, often with human-in-the-loop oversight.
• Level 5 — Scaling: end-to-end automated campaigns with no human oversight at scale.

Here’s the key operational takeaway: most confirmed activity sits in Levels 1–3. That means the defender’s job is less about “stop the robot” and more about:

1. Detect LLM abuse and AI-assisted workflows (especially via approved services and developer tooling).
2. Raise the cost of iteration through strong prevention controls and fast containment.
3. Reduce the organization’s “prompt surface area” (where AI systems can be tricked into harmful actions).

What we actually see in the wild (2023–2025)

Answer first: Public reporting shows AI is being used as a force multiplier, with only limited evidence of agentic, orchestrated operations—and no confirmed examples of malware embedding a local model on victim hosts.

AIM3 mapping helps interpret specific incidents without inflating them.

Levels 1–2: prototypes and AI-assisted workflows are common

Several well-publicized “first AI ransomware” or “AI malware” stories turned out to be proof-of-concepts or narrow experiments:

• PromptLock (Level 1) was reported as AI-powered ransomware because it used an LLM to interpret files and generate customized ransom notes, but later analysis tied it to academic PoC work.
• PROMPTFLUX (Level 1) used a cloud model to rewrite its own source and persist. It’s notable for worm-like behavior, but it was labeled experimental.
• FRUITSHELL (Level 2) included prompt instructions intended to bypass LLM-based analysis, reflecting LLM awareness rather than autonomous operation.

This is where defenders often overreact. A Level 1 PoC shouldn’t drive a million-dollar buying decision. But it should trigger one smart question: if attackers can cheaply test ideas with cloud LLMs, how quickly will those ideas graduate into Level 2 and Level 3 usage?

Level 3: AI starts touching runtime decisions

Level 3 (Optimizing) is where AI becomes more than “help me write code.” Examples include:

• Lamehug / PROMPTSTEAL (Level 3) using a public model API to generate reconnaissance commands. It shows a real-world pattern: malware calling an LLM to decide what to do next.
• S1ngularity / QUIETVAULT (Level 3) in a supply chain context, using AI to exploit CI/CD weaknesses and steal credentials.
• Red-team frameworks like HexStrike-AI and Villager (Level 3) combining agents with classic tools such as network scanners and credential theft utilities.

My opinion: Level 3 is the inflection point security leaders should plan for, because it creates faster, more adaptive operations while staying operationally realistic. Attackers don’t need full autonomy to outpace teams that are understaffed and drowning in alerts.

Level 4: agentic operations are real, but not “hands-off”

One widely discussed case was described as AI-orchestrated cyber-espionage using an agentic coding system. It’s meaningful because it points at what Level 4 looks like: multi-step planning and tool use.

It’s also contested because it reportedly still needed human decisions. That matters. It suggests we’re not seeing Level 5 “no humans” campaigns in verified reporting.

Practical read: treat Level 4 as a near-term planning assumption for high-value targets, but don’t rebuild your whole program around Level 5 fantasies.

The big myth: “BYOAI malware” is already everywhere

Answer first: There are no confirmed public examples of malware shipping its own local model and running it on victim hosts at scale.

Most AI-invoking malware calls remote LLM services via APIs (or relies on tooling that does). That has two implications defenders can act on immediately:

1. Network and identity controls matter more than model forensics. If the malware needs outbound access to a model endpoint, that’s a detection and prevention opportunity.
2. Abuse looks like legitimate traffic. If your enterprise already uses popular AI services, adversaries can blend in.

This is why monitoring “AI usage” isn’t a compliance checkbox. It’s now a detection requirement.

Defensive playbook: how to prepare without panic

Answer first: The most effective defense against AI-assisted malware in 2025 is a mix of AI governance, visibility into LLM usage, and hardened fundamentals that still stop attacks when adversaries iterate faster.

1) Build basic AI governance that security can enforce

If your org doesn’t know which AI tools are approved, you can’t reliably detect abuse.

Minimum bar for enterprise AI governance:

• Approved providers list (and approved accounts/tenants)
• Data handling rules (what can/can’t be pasted into prompts)
• Plugin/extension policy (especially for IDEs and browsers)
• Procurement and vendor review requirements for AI features
• Logging retention requirements for AI access events

Governance becomes a leads-and-risk conversation fast, because it forces alignment across security, legal, privacy, engineering, and procurement.

2) Monitor for rogue AI usage like you monitor for rogue SaaS

Attackers don’t need exotic AI infrastructure if employees already have access.

Prioritize visibility into:

• New or unusual AI domains/services contacted from endpoints
• Sudden spikes in API calls to AI providers
• AI usage from service accounts or non-interactive identities
• Developer workstation traffic patterns (where most AI coding usage happens)

A practical detection idea: create a baseline of “normal” AI usage by team and role, then alert on anomalies (volume, time of day, unusual geolocation, new model endpoints).

3) Assume AI will show up in phishing and social engineering

Most AI-enabled attacks still need humans to click, approve, or pay.

Raise resistance where it counts:

• Enforce phishing-resistant MFA for email and admin portals
• Require out-of-band verification for payment changes and vendor banking updates
• Add conditional access for risky sign-ins and new devices
• Tighten OAuth app consent and monitor for new app grants

AI makes phishing more convincing; it doesn’t make identity controls optional.

4) Treat “AI in the attack chain” as an engineering problem

When AI helps attackers iterate, your program needs to iterate too.

Two moves that pay off quickly:

• Shorten containment time: pre-approved isolation actions, EDR playbooks, and credential revocation workflows.
• Reduce variability: standardize endpoint builds, patch cadence, and privileged access paths so anomalies stand out.

If you’ve ever run incident response, you know the hard part isn’t identifying the first alert—it’s coordinating the next 20 steps. Automation (including defensive AI) should be used there.

5) Map threats to maturity levels during triage

Not every “AI malware” story deserves the same escalation.

A simple triage rubric:

1. Is AI used only for content/code creation (Level 2 or below), or at runtime (Level 3+)?
2. Does the operation depend on external AI services? If yes, monitor and restrict egress and identities.
3. Is there evidence of multi-step agent planning and tool use (Level 4)? If yes, expect faster lateral movement and more adaptive recon.

This keeps the team focused on risk, not buzzwords.

Where enterprise AI defense should go next

Answer first: The next 12–18 months will be about AI orchestration on both sides—attackers using agentic tooling more often, defenders using AI for faster detection, investigation, and response.

Attackers are trending toward orchestration because it’s economically rational: you don’t need fully autonomous malware if you can semi-automate recon, payload adaptation, and tool execution. Expect more Level 3 activity and occasional Level 4 operations against high-value targets.

For defenders, the best use of AI in cybersecurity is straightforward: reduce analyst toil. Use AI to summarize alerts, correlate weak signals across logs, and generate investigation steps—but keep strong guardrails and human accountability for actions that change systems.

If you’re building a 2026 plan, start here: inventory AI access, monitor AI abuse, and harden identity + endpoint controls so attackers don’t benefit from faster iteration.

What would you rather explain to your board next quarter: that you bought an “AI malware shield,” or that you can measurably detect and contain AI-assisted attacks faster than last year?