AI-generated ransomware changes the calculus for malware detection

At a glance

What this is: PromptLock is an experimental ransomware sample that uses LLM-generated Lua to vary file discovery, exfiltration, and encryption logic across executions.

Why it matters: It matters because ransomware that changes its runtime path undermines static detections and pushes defenders toward behaviour-based monitoring, especially where automation meets malware development.

Context

AI-generated malware shifts the problem from a fixed sample to a variable execution pattern. In this case, the security concern is not just ransomware, but malware that can ask a model to produce fresh script logic on demand, which complicates signature matching and sandbox assumptions.

That matters for defenders because detection programs are still often built around repeatable artefacts such as hashes, string matches, and stable control flow. When a threat can regenerate its discovery, exfiltration, and encryption steps, the control point moves from static inspection to runtime behaviour, and that affects both malware defence and broader AI governance where autonomous code generation is involved.

Key questions

Q: What breaks when ransomware generates its own code at runtime?

A: Static signatures and single-pass analysis lose coverage because the malware can produce different discovery or encryption logic each time it runs. Defenders need to look for the behaviour sequence, including script generation, file enumeration, exfiltration, and encryption, rather than assuming one sample reveals the full attack path.

Q: Why does AI-enhanced malware make traditional detection less reliable?

A: Because the malware can be generated or modified to look more legitimate, change faster, and blend into normal software patterns. Static signatures, reputation checks, and one-time analysis age quickly in that environment. Detection has to shift toward behaviour, execution context, and response speed rather than expecting the sample to stay stable.

Q: How can security teams spot non-deterministic malware behaviour?

A: Look for repeated execution paths that diverge in implementation but converge on the same malicious actions, such as file discovery followed by exfiltration and encryption. Good indicators include unexpected script spawning, model or API calls from suspicious binaries, and sandbox runs that produce different artefacts from the same sample.

Q: Why does a ransomware proof of concept still matter to security teams?

A: Proof-of-concepts often show which techniques are becoming practical before they appear at scale. Even if a sample is unfinished, it can validate a method that other actors later refine, so defenders should use it to adjust telemetry, detection logic, and AI security boundaries early.

Technical breakdown

How LLM-generated malware changes execution paths

PromptLock is written in Go and uses the gpt-oss:20b model through the Ollama API to generate Lua scripts at runtime. Those scripts handle file discovery, exfiltration, and encryption, which means the malicious logic is partially produced after execution begins rather than being fully fixed at build time. That creates non-determinism: two runs can take different paths, even if the objective stays the same. For defenders, the important shift is that the observable behaviour may be consistent only at the goal level, not at the code-signature level.

Practical implication: Detect the behaviour chain, not just the file hash or payload string.

Why static signatures lose coverage against adaptive malware

Traditional malware detection works best when a sample repeats the same code, file paths, or API calls. LLM-assisted generation breaks that assumption by introducing variation into the logic that performs discovery, staging, and encryption. The proof-of-concept nature of PromptLock also matters: even unfinished malware can demonstrate a technique that other actors later refine. Once generation is integrated into the attack workflow, defenders cannot assume one sample represents one execution pattern.

Practical implication: Shift controls toward behavioural analytics, sandbox telemetry, and anomaly detection for runtime script generation.

What the proof-of-concept status tells defenders

ESET and Anomali note that PromptLock was found on VirusTotal and has not been seen in telemetry, which points to an experimental build rather than an active campaign. That does not reduce the relevance of the technique. Proof-of-concepts often show where malware development is heading, especially when they combine commodity languages, accessible APIs, and automation. The security value is in the method: LLM output can accelerate malware adaptation without requiring the operator to handcraft every step.

Practical implication: Treat experimental AI-assisted malware as an early warning for future operational tradecraft.

NHI Mgmt Group analysis

Runtime code generation is now a malware resilience technique. PromptLock shows that the defensive problem is no longer limited to a static payload that can be identified once and blocked forever. When the execution logic is partly generated at runtime, the adversary gains a practical way to vary discovery and encryption paths without changing the overall objective. The practitioner conclusion is that malware defence must weight runtime behaviour more heavily than file-based detection.

AI-assisted malware compresses attacker development effort. The article’s most important implication is not that this sample is finished, but that the model does more of the work for the operator. That changes the economics of iteration and makes it easier for low-skill actors to produce adaptive tooling. The practitioner conclusion is that security teams should expect faster experimentation cycles and wider malware diversity.

PromptLock is a detection problem, not just a ransomware problem. The malware’s non-determinism means a single signature or one-time reverse-engineering exercise may not capture the full threat pattern. The right analytical unit is the behaviour chain, especially file discovery, exfiltration, and encryption activity that emerges at execution time. The practitioner conclusion is to prioritise telemetry that survives code variation.

AI governance has a direct security boundary when models are used to generate executable logic. The article sits at the intersection of malware analysis and AI security because the model is not producing prose, but operational script content. That makes the AI system part of the threat surface, even if the malware itself remains the primary risk. The practitioner conclusion is to treat model access and tool use as part of security architecture, not just innovation plumbing.

What this signals

Runtime variation is the core defence challenge here. When malware can generate new logic during execution, the control that fails is not simply endpoint blocking but the assumption that one analysed sample represents future runs. Detection has to move closer to behaviour, especially where script generation, file access, and exfiltration appear in sequence.

AI tools become part of the attack surface once they can emit executable logic. That creates a governance issue for defenders using local or hosted models in operational workflows, because malicious processes can now try to turn model access into code generation. The practical response is to govern model access like any other privileged execution path.

For practitioners

• Monitor runtime script generation Instrument endpoints and sandboxes to flag malware that requests model output or emits new scripts during execution, especially where behaviour changes between runs.
• Prioritise behaviour-based detections Tune detections to file discovery, exfiltration, and encryption sequences rather than relying on static hashes, strings, or one-off sample indicators.
• Harden access to model APIs Restrict outbound access to local or remote model endpoints from untrusted processes so malware cannot freely call an LLM to generate attack logic.
• Review sandbox coverage for non-deterministic samples Use multiple execution paths and repeated detonations when testing suspicious binaries that may change control flow across runs.

Key takeaways

• PromptLock demonstrates that AI-generated malware can vary its runtime logic, which weakens the reliability of static detection methods.
• The article points to a broader shift from fixed malicious artefacts to behaviour that must be identified as it unfolds.
• Defenders should respond by weighting telemetry, sandbox analysis, and model access controls more heavily than single-sample signatures.

Key terms

• Non-Deterministic Malware: Malware that can change its internal logic or execution path from run to run while keeping the same malicious goal. This makes it harder to identify with fixed signatures and shifts detection toward behaviour, telemetry, and repeated execution analysis.
• Runtime Code Generation: Runtime code generation is the practice of turning data or metadata into executable program code while the application is running. It improves flexibility and performance, but it becomes dangerous when untrusted inputs can influence the generated source or its execution path.
• Behavioral Detection: A monitoring approach that looks for unusual activity rather than relying only on static inventories. For SaaS integrations, it detects drift in token use, data movement, timing, and endpoint behavior so teams can spot compromise, misuse, or automation that no longer matches its expected pattern.
• Model API Exposure: The risk that a process can use access to a language model interface to generate harmful output or code. When that access is uncontrolled, the model becomes part of the attack surface and can be abused to accelerate malicious automation.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is a practical fit for security teams that need to govern non-human access, automation, and emerging AI-driven risks.