Emerging Threats
LLM-enabled malware: how it works, evasion techniques, and detection
Learn how LLM-enabled malware uses AI models for runtime code generation, command execution, and adaptive behavior, with real-world examples and detection techniques.
LLM-enabled malware uses a large language model during runtime to generate, interpret, or adapt commands and code. Unlike malware simply developed with AI assistance, the LLM is part of the malware's operational workflow, accessed through a cloud API, local inference engine, or embedded model, allowing some malicious logic to be generated only when needed.
LLM-enabled malware is malicious software that uses a large language model during execution to generate, interpret, or adapt commands and code. Instead of embedding every instruction in its own code, the malware can send a prompt to an LLM, receive a response, and use that response to determine what to do next.
The key distinction is when the LLM is used. Malware created with AI assistance is still conventional malware if the model is only used during development. With LLM-enabled malware, the model becomes part of the malware's runtime workflow. An LLM can be accessed through a cloud API, a local inference engine, or an embedded model.
LLM-enabled Malware vs. AI-Generated Malware
| Type | How AI is used | Where defenders can look |
|---|---|---|
| AI-generated malware | AI helps create the malware | Files, code, and binaries |
| AI-assisted attacks | AI helps attackers plan or execute an attack | Attacker infrastructure and activity |
| LLM-enabled malware | LLM participates in malware execution | Prompts, API activity, model artifacts, and endpoint behavior |
This distinction is important because an LLM-enabled sample may not contain all of its malicious logic when it first reaches the endpoint. Some of that logic can be generated only when the malware runs.
How does LLM-enabled malware work?
At a high level, the process is straightforward. The malware may first collect information such as the operating system, running processes, username, or installed security products. It then combines this information with a predefined prompt and sends the request to an LLM.
The model returns text, commands, or code. The malware parses that response and passes it to a conventional execution mechanism such as Python, PowerShell, or another system interface. The LLM does not execute the malware itself. It generates the instructions; the compromised endpoint executes them.
A simple example: A conventional malware sample might contain a hardcoded command for system discovery. An LLM-enabled sample could instead provide the current system information to an LLM and ask it to generate an appropriate discovery command. The generated command is then executed locally, and the result can be fed back into the next stage of the workflow. This creates a feedback loop in which the malware can use information from the endpoint to influence its next action.
The important change is not the use of PowerShell, Python, or other execution tools. Attackers have used these mechanisms for years. The difference is that part of the decision-making or code-generation process can happen dynamically at runtime.
How LLMs change malware behavior and evasion
LLMs can give malware greater flexibility by allowing some of its behavior to be generated or adapted during execution. This can make certain aspects of the malware harder to analyze statically.
Dynamic code generation
Instead of storing every malicious function in the payload, malware can request code or commands from an LLM when required. The exact code used during one execution may differ from another, complicating static signature-based detection.
Environment-aware behavior
The malware can include information about the compromised endpoint in its prompts: OS version, running processes, installed security products, network configuration, or VM indicators, allowing the LLM to generate context-specific output.
Prompt-driven adaptation
Prompts can define what the malware should do under specific conditions, effectively moving part of the malware's operational logic from static code into the prompt-and-response layer.
Does this make malware undetectable?
No. Even when an LLM generates the instructions, those instructions still have to produce activity on the endpoint processes, commands, file access, memory changes, and network connections, all of which generate detectable telemetry.
LLM-enabled malware has its own weaknesses. Cloud-connected variants depend on API availability and valid credentials. Model responses can be unpredictable. Safety controls, network disruptions, revoked API keys, and provider-side monitoring can interfere with the malware's operation.
Cloud-connected vs. local LLM-enabled malware
LLM-enabled malware can rely on either an external AI service or a model running locally. Architecture matters because it determines what evidence defenders can look for.
Cloud-connected LLM malware
The malware communicates with an external LLM provider, sends a prompt, receives the model's response, and uses that output locally.
Key artifacts: Embedded API keys, hardcoded AI provider URLs, AI-related SDKs (openai, anthropic, huggingface_hub), unexpected outbound connections to AI infrastructure, API traffic from unusual processes.
Local LLM malware
A local implementation removes the dependency on an external AI provider. The malware interacts with a locally hosted inference engine and model.
Key artifacts: .gguf or .safetensors model files, unexpected local AI runtimes, Ollama processes or model directories, local inference server activity, unusual GPU/NPU utilization.
Blocking access to known AI providers can disrupt cloud-connected samples, but it will not address malware that performs inference locally. This makes local inference particularly relevant from a defensive perspective.
What are "Prompts as Code" in LLM-enabled malware?
In conventional malware, code contains the instructions that determine what the malware does. In LLM-enabled malware, prompts can serve a similar operational role by telling the model what to generate, retrieve, or execute. This makes prompts valuable threat-hunting artifacts. A prompt embedded in a malware sample can reveal the attacker's intent even when the actual command or code does not exist until runtime.
What do malicious prompts look like?
Research into LLM-enabled malware has identified several recurring prompt patterns:
- Role definition: The prompt assigns the model a specific role, such as a Windows administrator or cybersecurity expert.
- Task instructions: The malware asks the model to generate commands or code for activities such as system discovery or file collection.
- Output constraints: Instructions such as returning only commands or excluding Markdown help ensure that the response can be parsed and executed automatically.
- Environment awareness: The prompt may include information collected from the endpoint and ask the model to interpret the environment before generating its response.
- Code generation: The malware can request executable scripts or other code rather than relying entirely on prewritten functionality.
Why prompts matter for threat hunting
Prompt strings can provide a useful detection layer because they may expose the malware's operational intent before or alongside its generated behavior. Analysts can search binaries and scripts for role-based instructions, command-generation requests, code-generation language, output-formatting instructions, system reconnaissance terms, and references to security products or endpoint environments.
When an LLM becomes part of the malware's execution chain, the prompt becomes a potential indicator of compromise not just text inside the malware.
Real-world examples of LLM-enabled malware
Recent research shows that LLMs are being used in malware in different ways from generating code at runtime to serving as a C2 channel. The following examples illustrate how the technology is evolving.
MalTerminal : Early confirmed LLM-enabled malware
MalTerminal is a Python-compiled Windows executable that uses the OpenAI GPT-4 API to generate ransomware code or a reverse shell at runtime. The operator selects either option, and the generated code is executed locally through exec(). SentinelLABS identified MalTerminal through API-key retrohunting on VirusTotal.
Key artifacts: GPT-4 chat completions API · Embedded sk- OpenAI API key · Python-compiled MalTerminal.exe · Runtime code generation through exec()
MITRE ATT&CK: T1059.006 (Python), T1486 (Data Encrypted for Impact), T1059.004 (Unix Shell)
APT28 LameHug / PROMPTSTEAL : LLM-assisted nation-state malware
LameHug, also known as PROMPTSTEAL, is a Python-based Windows malware linked by CERT-UA to APT28. It uses the Hugging Face Inference API to generate system commands, executed through subprocess to collect information and support exfiltration. The malware embeds 284 unique Hugging Face API keys, uses prompts framing the model as a Windows system administrator, and instructs it to return commands without Markdown for easier parsing.
Key artifacts: Hugging Face Inference API · 284 embedded API keys · Runtime command generation through subprocess · SSH-based exfiltration via Paramiko
MITRE ATT&CK: T1059.006, T1033, T1082, T1048, T1078.004
SesameOp : Using an LLM API as a C2 channel
SesameOp demonstrates a different approach: rather than asking an LLM to generate malware code, the backdoor uses the OpenAI Assistants API as a command-and-control relay. Discovered during a July 2025 incident response, the backdoor polls the API for encrypted commands, decrypts and executes them locally, and sends results back through the same API. Its traffic blends with legitimate communication to api.openai.com.
Why it matters: SesameOp shows how legitimate cloud AI infrastructure can be repurposed as C2 without exploiting the provider itself.
MITRE ATT&CK: T1071.001, T1102, T1574.014, T1036, T1090
FunkSec / FunkLocker : AI-assisted ransomware development
FunkSec is an important example of AI-assisted malware development rather than LLM-enabled runtime execution. The ransomware group used LLMs extensively during development, with researchers identifying unusually detailed code comments alongside the group's rudimentary communications. The Rust-based ransomware uses ChaCha20 encryption, PowerShell for defense disabling, and double-extortion tactics.
Key distinction: The LLM helped create the malware but was not part of runtime execution. The resulting ransomware operates as conventional static code.
MITRE ATT&CK: T1036.005, T1489, T1059.001, T1135, T1490
PromptLock : LLM-enabled ransomware proof of concept
PromptLock, a university research proof of concept from NYU, demonstrates how an LLM could drive ransomware operations by generating Lua code for file-system traversal and dynamically producing commands for data exfiltration. Its prompts contain role-based instructions and safeguards designed to keep generated code syntactically valid. Although not deployed as a confirmed malicious campaign, it provides a useful technical model of how LLM-driven ransomware could operate.
What these examples show
| Use of AI | Example | Role |
|---|---|---|
| Runtime LLM integration | MalTerminal, LameHug | Generates commands or code during execution |
| AI infrastructure as C2 | SesameOp | Uses an LLM API as a communication channel |
| AI-assisted development | FunkSec, React2Shell | Uses LLMs to create malware or attack tooling |
| Research / proof of concept | PromptLock | Demonstrates potential LLM-driven malware architecture |
Why is LLM-enabled malware difficult to detect?
LLM-enabled malware can complicate traditional detection because some of its logic may be generated only during execution. But the LLM itself does not make the malware invisible. The challenge is identifying the connection between AI activity and the malicious behavior that follows.
Reduced static visibility
When malware generates commands or code at runtime, the exact malicious logic may not be present in the original binary, reducing what static analysis can identify before execution.
Changing runtime output
LLM responses can vary based on the prompt and system context. The same malware may generate different commands across executions, making fixed signatures less reliable.
Legitimate AI infrastructure
Connections to services such as OpenAI, Hugging Face, or Anthropic are not inherently malicious. Organizations legitimately use these platforms, making network-based detection difficult without endpoint context. SesameOp demonstrated this challenge directly.
Prompt obfuscation and local inference
Attackers can obfuscate or dynamically construct prompts to make string-based detection harder. Malware using a local LLM removes the need for external AI API traffic altogether.
Despite these challenges, LLM-enabled malware must eventually act on the endpoint. Processes are created, commands execute, files are accessed or encrypted, memory is modified, and network connections are established. That makes behavioral telemetry a critical detection layer. The mechanism used to generate a command may change, but the activity produced by that command can still reveal the attack.
How to detect and hunt LLM-enabled malware
Detecting LLM-enabled malware requires more than looking for an AI API connection or a suspicious prompt. The strongest approach is to correlate AI-related artifacts with endpoint behavior.
1. Look for LLM API artifacts
Search endpoint and network telemetry for embedded AI API keys, known LLM provider URLs, AI SDK references (openai, anthropic, huggingface_hub), and unexpected processes communicating with AI infrastructure.
An AI API connection alone is weak evidence. A connection originating from an unusual binary followed by suspicious execution is far more significant.
2. Hunt for embedded prompts
Search binaries and scripts for prompt patterns: role definitions such as "Windows System Administrator", instructions to generate commands or scripts, output constraints such as "Return only commands", system reconnaissance requests, and references to security products or the target environment.
3. Check for local model artifacts
For malware using local inference, investigate unexpected .gguf or .safetensors model files, AI inference runtimes, Ollama processes or model directories, local inference server activity, and GPU/NPU usage on endpoints where AI workloads are not expected.
4. Correlate the full execution chain
The strongest signal comes from connecting individual artifacts into a behavioral sequence. No single indicator is necessarily malicious, the sequence is what matters.
The full execution chain
Unknown binary
An unfamiliar or unexpected executable appears on the endpoint.
LLM API communication or local model activity
The process communicates with an AI provider or local inference engine.
Prompt / code generation
A prompt is sent and a response containing commands or code is received.
PowerShell or shell execution
The generated content is passed to a system execution mechanism.
System discovery
Reconnaissance activity follows : enumerating processes, users, or network configuration.
Credential access or file staging
The malware attempts to access credentials or stage files for exfiltration.
Exfiltration, encryption, or other malicious activity
The attack reaches its objective. The sequence, not any single step, is the indicator.
What defenders should prioritize: Correlate three areas together : AI interaction + suspicious execution + malicious behavior. This approach is more reliable than treating AI API usage, prompt strings, or local model files as standalone indicators.
YARA rules for hunting LLM-enabled malware
YARA can help threat hunters identify artifacts associated with LLM-enabled malware, including AI API keys, provider endpoints, embedded prompts, and execution mechanisms. These rules are hunting starting points, not production signatures, validate them against your environment first.
Rule 1: OpenAI API Artifacts
rule hunt_openai_api_key { meta: description = "Hunts for embedded OpenAI API artifacts" reference = "SentinelLABS LABScon 2025" strings: $key_prefix = "sk-" ascii wide $openai_b64 = "T3BlbkFJ" ascii wide $sdk_import = "import openai" ascii wide nocase $endpoint = "api.openai.com" ascii wide condition: ($key_prefix and $openai_b64) or ($sdk_import and $endpoint)
}Rule 2: Hugging Face API Artifacts
rule hunt_huggingface_artifacts { meta: description = "Hunts for Hugging Face API artifacts" reference = "APT28 LameHug/PROMPTSTEAL — CERT-UA July 2025" strings: $hf_token = /hf_[A-Za-z0-9]{30,50}/ ascii wide $hf_endpoint = "api-inference.huggingface.co" ascii wide $hf_sdk = "huggingface_hub" ascii wide condition: $hf_token or ($hf_endpoint and $hf_sdk)
}Rule 3: Malicious Prompt Patterns
rule hunt_llm_malicious_prompts { meta: description = "Hunts for prompt patterns associated with LLM-enabled malware" reference = "SentinelLABS 2025; CERT-UA LameHug analysis" strings: $role1 = "Windows System Administrator" ascii wide nocase $role2 = "cybersecurity expert" ascii wide nocase $cmd1 = "Return only commands" ascii wide nocase $cmd2 = "without markdown" ascii wide nocase $recon1 = "running processes" ascii wide nocase $recon2 = "system information" ascii wide nocase $codegen1 = "Generate a script" ascii wide nocase $codegen2 = "Write a PowerShell" ascii wide nocase $msg_format = "\"role\": \"system\"" ascii wide condition: pe.is_pe and ( ($msg_format and 1 of ($role*)) or ($msg_format and 1 of ($cmd*)) or (2 of ($recon*) and 1 of ($cmd*)) )
}Rule 4: Combined LLM Malware Artifacts
rule hunt_llm_malware_combined { meta: description = "Hunts for combined LLM malware artifacts" strings: $openai_b64 = "T3BlbkFJ" ascii wide $hf_token = /hf_[A-Za-z0-9]{30,50}/ ascii wide $ant_key = "sk-ant-api03" ascii wide $exec_py = "exec(" ascii wide $invoke_expr = "Invoke-Expression" ascii wide nocase $subprocess = "subprocess" ascii wide $no_markdown = "without markdown" ascii wide nocase $only_cmds = "Return only commands" ascii wide nocase condition: (1 of ($openai_b64, $hf_token, $ant_key)) and (1 of ($exec_py, $invoke_expr, $subprocess)) and (1 of ($no_markdown, $only_cmds))
}Important: These rules can also match legitimate AI software, developer tools, automation, and enterprise applications. Run retrohunts and validate results against your software inventory before adding them to production detection pipelines.
How to prevent and respond to LLM-enabled malware
Defending against LLM-enabled malware does not require blocking AI altogether. The focus should be on controlling how AI services, execution tools, credentials, and endpoints are used and correlating those activities with suspicious behavior.
Prevention
Patch and control execution
- Patch internet-facing systems that could provide an entry point
- Restrict unsigned or unauthorized binaries from running on managed endpoints
- Apply appropriate controls to PowerShell, Python, and other scripting environments
Protect AI credentials
- Treat API keys as sensitive credentials store securely, rotate regularly
- Monitor for API key exposure across repositories and endpoints
- Establish a baseline for legitimate AI services and investigate unexpected processes
Control local AI runtimes
- Restrict unauthorized installation of inference engines and models on managed endpoints
- Monitor for unexpected .gguf, .safetensors, or model configuration files
- Apply least privilege to limit permissions available to users and applications
Detection: the full chain
An AI API connection by itself is not malicious. The stronger signal is:
AI interaction + suspicious execution + malicious behavior = investigate
An unknown executable communicating with an AI API, spawning PowerShell, performing system discovery, and staging files warrants investigation.
Incident response
If LLM-enabled malware is suspected:
- Isolate the endpoint to limit lateral movement and exfiltration
- Preserve prompts and artifacts that may reveal the malware's operational intent
- Capture process and command-line telemetry to reconstruct the execution chain
- Recover generated commands or code from memory, logs, or available network data
- Revoke exposed AI API credentials and notify the relevant provider
- Block identified C2 and exfiltration infrastructure
- Hunt across the environment for matching hashes, prompts, API keys, and model artifacts
- Monitor for recurrence after remediation to confirm persistence has been eliminated
The objective is not simply to identify that malware interacted with an LLM. It is to determine what the LLM interaction enabled the malware to do and detect the endpoint behavior that followed.
Frequently asked questions
What is LLM-enabled malware?
LLM-enabled malware uses a large language model during runtime to generate, interpret, or adapt malicious commands and code. The LLM is part of the malware's operational workflow, accessed through a cloud API, local inference engine, or embedded model, allowing some malicious logic to be generated only when needed.
How is LLM-enabled malware different from AI-generated malware?
AI-generated malware uses AI during development; the resulting malware is static code that operates conventionally. LLM-enabled malware uses an LLM as part of its runtime operation, the model participates in the attack during execution, not just during creation.
Can LLM-enabled malware work without the internet?
Yes. Malware using a local model and inference engine can operate offline. Cloud-based variants require an external LLM API. This makes local inference particularly relevant from a defensive perspective, since blocking AI provider domains cannot address locally operating samples.
What are "prompts as code"?
Prompts as code are embedded or dynamically generated instructions that direct an LLM's behavior within malware. Because prompts can reveal the malware's operational intent even when the resulting code is generated at runtime, they are valuable threat-hunting artifacts, a potential indicator of compromise, not just text inside the malware.
How do you detect LLM-enabled malware?
Correlate LLM artifacts such as API keys, provider URLs, and embedded prompt patterns with process, memory, network, command-line, and behavioral telemetry. The strongest signal is AI interaction combined with suspicious execution and malicious endpoint behavior, no single indicator is sufficient on its own.
Does LLM-enabled malware make traditional antivirus ineffective?
No. Dynamic code generation can reduce static visibility, but endpoint behavior remains observable through file, process, memory, network, and behavioral detection. The mechanism used to generate a command may change, but the malicious activity that command produces can still be detected.
