Malware that calls a large language model while it is running to decide what to do next. The model can generate commands, rewrite code, or adapt behaviour based on the target environment, making the payload dynamic rather than fixed.
What LLM-Querying Malware Is
LLM-querying malware is malicious code that treats a large language model as part of its runtime decision engine. Instead of following a fixed script, it can ask the model to choose commands, rewrite payload logic, or adapt to the environment it finds.
How It Changes Malware Behaviour
This pattern makes the payload less deterministic. A traditional sample usually encodes its next steps in advance, while LLM-querying malware can vary those steps based on prompts, context, or environmental cues, which complicates static analysis and signature-based detection.
The behaviour is especially relevant when the malware can use the model to transform instructions into new commands or code paths during execution. That can allow the same base binary to behave differently across hosts, sessions, or targets, even when the operator starts from one initial build.
Why It Matters for Defenders
For defenders, the important shift is not that the malware “uses AI” in a general sense, but that its logic becomes partially externalised. Analysts may need to inspect prompts, model outputs, API usage, and surrounding orchestration to understand what the payload will do next, especially if the malware is designed to select between multiple actions at runtime.
This also changes the detection problem. Indicators may no longer be limited to a single hash, fixed string, or known command sequence; defenders have to watch for unusual model access, prompt construction, and abrupt behavioural branching that looks more like runtime reasoning than ordinary automation.
Operational Security Implications
LLM-querying malware can increase uncertainty in incident response because the same sample may produce different actions in different environments. That makes containment, reverse engineering, and reproduction harder, and it can blur the line between a single binary and the broader model-enabled workflow behind it.
It can also widen the attack surface if the malware depends on external model services, stolen credentials, or abused API access to function. In those cases, the security problem is not only the malicious binary itself, but also the trust relationships and service dependencies it relies on to keep adapting.
Risk and Threat Considerations
LLM-querying malware raises the cost of analysis and improves attacker flexibility because its behaviour is not fully fixed at compile time. That creates more room for evasion, environment-specific branching, and rapid variation in how the payload operates after initial execution.
Failure mechanism: The malware can query a model at runtime to decide the next command, rewrite its own logic, or choose between alternative actions based on the host, network, or response it receives.
Impact: Security teams may face less reliable signatures, slower triage, more difficult reproduction of malicious behaviour, and a wider set of execution paths to account for during investigation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1204 — User Execution | Runtime model-driven actions still depend on adversary execution paths and malicious tasking. |
| T1059 — Command and Scripting Interpreter | The malware can generate or rewrite commands during execution, which fits command-interpreter abuse. | |
| T1027 — Obfuscated Files or Information | Adaptive, model-generated behaviour can function as dynamic obfuscation that frustrates static analysis. | |
| Recommendation — Map observed execution chains to ATT&CK and hunt for the initial access and execution steps that trigger model use. Inspect generated commands and script execution for abnormal interpreter activity and chained tooling. Correlate runtime behaviour with static artefacts to detect code that changes shape during execution. | ||
| CIS Controls v8 | CIS-10 — Malware Defenses | The term describes malware behaviour that needs layered malware detection and response coverage. |
| CIS-17 — Incident Response Management | Adaptive malware requires stronger containment, analysis, and response workflows. | |
| Recommendation — Use layered malware defenses and behavioural detection to identify runtime-generated actions. Update incident response handling to capture prompts, outputs, and model-access evidence during analysis. | ||
Practitioner Guidance
What to watch for: Treat unexpected model calls, prompt construction inside suspicious processes, and sudden changes in command selection as meaningful behavioural signals. When a sample appears to delegate decisions to an external model, analyse the surrounding request and response flow as part of the malware itself, not just as background traffic.
Practitioner takeaway: The core challenge is behavioural opacity, so investigation has to cover both the binary and the model-mediated decision chain it uses.
Related resources from NHI Mgmt Group
- How should security teams defend against LLM-powered malware that adapts during an attack?
- What breaks when malware generates commands through an LLM at runtime?
- How should security teams respond when phishing chains start using LLM-generated scripts and stealer malware together?
- What are the signs that a malware campaign is using LLM-assisted code or rewritten scripts?