How Cybercriminals Use LLMs to Write Malicious Code (And How to Defend Against It)

Large Language Models (LLMs) have changed the way people write software. Unfortunately, they’ve also changed the way attackers operate. Cybercriminals are increasingly using LLMs to accelerate development of malicious code, automate reconnaissance-to-exploit workflows, and lower the skill barrier for generating malware, phishing content, and backdoor scripts.

This article explains how that works, where the real risk lives (beyond the hype), and what defenders can do to reduce both the likelihood and impact of LLM-assisted attacks.

Why LLMs Are a Game-Changer for Malicious Code

LLMs can translate intent into output: you ask for a function, a script, a configuration, or an explanation, and you receive working code patterns. In legitimate settings, that’s powerful. In adversarial settings, it becomes a force multiplier.

Rather than starting from scratch, an attacker can prompt an LLM to:

• Generate boilerplate exploit scaffolding or payload wrappers
• Produce variants of malicious scripts to evade simplistic signatures
• Convert malicious logic across languages (e.g., Python to PowerShell)
• Explain how to deploy, obfuscate, or persist
• Draft instructions for victim targeting, from social engineering to command-and-control

Even when models don’t directly output “perfect malware,” they still reduce time, effort, and experimentation cost—three things attackers always optimize.

The Core Pattern: From Prompt to Payload

Most LLM-driven malicious development follows a recognizable pipeline:

• Goal framing: The attacker specifies capabilities (e.g., credential theft, persistence, lateral movement) and constraints (target OS, delivery method).
• Code generation: The LLM produces initial code or pseudocode, often with missing details that the attacker fills in.
• Iteration: The attacker asks for fixes, edge-case handling, reduced detection, or different packaging formats.
• Obfuscation and adaptation: The attacker transforms output to better match their environment and evade defenses.
• Operationalization: The attacker builds tooling around it: installers, scripts, command-and-control logic, logs, and deployment automation.

This is not “magic.” It’s rapid prototyping with conversational interfaces. And that speed is exactly what cybercriminals want.

How Cybercriminals Use LLMs to Write Malicious Code

1) Accelerating Malware Development with Code Templates

Attackers can prompt LLMs to output common components used in real malware ecosystems: process injection scaffolds, persistence mechanisms, data collection routines, and network beacons. Even if the generated code isn’t fully functional on the first try, it gives the attacker a head start.

Why it matters: Malware authors historically spent time searching for public snippets, stitching them together, and debugging. LLMs collapse many of those steps into a conversational loop.

2) Generating Script Variants to Evade Detection

Signature-based detection struggles when attackers change formatting, variable names, control flow, or output structures. LLMs can help produce multiple variants quickly.

For example, an attacker might ask for:

• Different ways to retrieve system info
• Alternative methods to execute commands (where permitted)
• Different encoding/serialization approaches
• Obfuscated but functionally similar scripts

Net effect: Defenders may need to create and maintain broader detection rules, increasing cost and reducing coverage.

3) Translating Attacks Across Languages and Platforms

Not every target uses the same stack. An attacker may need a payload for Windows, a loader for Linux, or a command wrapper for PowerShell vs. Python. LLMs can act as a translator—turning logic expressed in one language into code in another.

Example workflow: An attacker drafts malicious behavior at a high level, generates code in one language, then requests a translation to the language best suited for the target environment.

This reduces dependency on deep language expertise and expands attacker reach.

4) Building “Glue Code” That Connects Real Attack Components

Many successful intrusions rely on more than one component: dropper + persistence + credential theft + exfiltration + C2 communication. LLMs are especially good at glue code—the pieces that wire together existing modules and protocols.

Attackers can prompt for:

• Configuration parsing and environment checks
• Network request wrappers and retries
• Local file discovery and packaging routines
• Compression/encryption placeholders

Even if the underlying exploit is sourced elsewhere, LLMs streamline assembly and orchestration.

5) Enhancing Phishing and Delivery Mechanisms

Malicious code often succeeds because delivery succeeds. LLMs can generate targeted phishing messages, realistic lures, and instruction strings that tell victims how to download or run something.

While this content may not be “code” per se, it directly supports the deployment pipeline. Attackers can also generate scripts embedded in emails or hosted as downloads—then iterate based on observed results.

Defender takeaway: If you only detect malware after execution, you’ll miss much of the attacker advantage.

6) Automating Recon-to-Exploit Logic (Reducing Human Error)

Attackers often need to map from information to action: identify services, infer possible weaknesses, and choose an approach. LLMs can help produce command sequences and decision trees.

For instance, an attacker could use an LLM to:

• Summarize scan output and suggest next steps
• Draft exploit attempts with parameter suggestions
• Generate operational runbooks for a campaign

Why this is dangerous: It shortens the time between reconnaissance and exploitation—and helps attackers scale processes across more targets.

7) Creating Obfuscation and Evasion Strategies

Defenders fight obfuscation: code that’s hard to read, patterns that change, and payloads that conceal their intent. LLMs can assist by proposing transformations and alternative execution flows.

Common categories include:

• String manipulation and encoding approaches
• Polymorphic code style changes
• Minification and structure alterations
• Packaging variations (e.g., different loader styles)

Even when the model doesn’t produce perfect evasion, it increases experimentation velocity.

Where LLM-Assisted Malware Still Struggles

It’s important to avoid complacency on the other side of the story. LLMs can generate dangerous output—but they aren’t omnipotent. They may output:

• Inaccurate APIs or outdated libraries
• Logic that fails due to environment mismatch
• Code that compiles but doesn’t behave as intended

However, attackers don’t need perfection. They need enough functionality to test, refine, and deploy. LLMs reduce iteration cycles, and that’s often sufficient.

Realistic Attack Scenarios (Without “How-To” Details)

To understand risk, it helps to see plausible scenarios at a high level. The details below focus on defender-relevant patterns, not operational instructions.

Scenario A: LLM-Generated Loader + Managed Deployment

An attacker uses an LLM to create a lightweight loader script and iterates until it reliably triggers in the target environment. They wrap it with deployment logic to run consistently across a campaign.

Signals defenders can watch: unusual script execution patterns, abnormal child process trees, suspicious persistence events, and odd network beacons soon after execution.

Scenario B: Rapid Variant Generation After Detection

Once defenders block a payload, the attacker uses LLM prompting to produce multiple variants—changing superficial structure while retaining the same malicious goal.

Signals: repeated attempts with similar behavioral intent but different file hashes and scripting styles; spikes in blocked detections across closely related campaigns.

Scenario C: Cross-Platform Adaptation for Wider Coverage

A threat actor writes a component targeting one environment, then asks the LLM to adapt the logic for another OS or scripting runtime.

Signals: similar network behavior and workflow across different endpoint types; common “intent” patterns showing up in different tooling signatures.

Defense: How to Reduce Risk from LLM-Assisted Code

Defending against LLM-enabled threats is less about “stopping prompts” and more about hardening the environment so that generated code still fails to achieve outcomes.

1) Treat LLM Output as Untrusted (Even If It Looks Legit)

If your developers use LLMs for code generation, introduce policy that any produced code must be reviewed and tested like external code. Require:

• Static analysis (SAST) before merge
• Dependency scanning (SCA)
• Peer review for code touching auth, networking, persistence, or file operations

Key idea: LLMs can produce plausible-but-dangerous patterns. Your pipeline must catch them.

2) Strengthen Detection Around Behavior, Not Just Signatures

Attackers can change text, formatting, and hashes. Behavior-based detections are more robust. Focus on suspicious sequences such as:

• Unusual process creation chains
• Execution of scripts from unexpected directories
• Access to credential stores or sensitive files
• Rapid staging followed by outbound connections to new or unusual endpoints

Use EDR telemetry and correlate events rather than relying solely on static signatures.

3) Implement Application Allowlisting and Least Privilege

Limiting what can run drastically reduces the blast radius of any malicious code. Consider:

• Application allowlisting (where feasible)
• Restricting script runtimes and admin capabilities
• Separating user and admin privileges

If malicious code can’t run—or can’t run with the right permissions—impact drops immediately.

4) Harden LLM-Adjacent Workflows in Your Organization

If your organization uses LLM tools for development, include guardrails such as:

• Data loss prevention (DLP) to prevent sensitive prompt leakage
• Logging and auditing for high-risk prompts or generated artifacts
• Model output screening for suspicious patterns

Why it matters: Attackers may also attempt to use LLMs to exfiltrate secrets from prompts or from developer workflows.

5) Improve Phishing Resistance and Delivery Controls

Since LLMs can strengthen social engineering, defend the delivery layer:

• Secure email gateways and URL detonation
• Attachment sandboxing
• MFA everywhere (especially for high-privilege accounts)
• User training that emphasizes verification steps

Even strong code is powerless if delivery fails.

How Security Teams Can Prepare for the “Iteration Advantage”

The biggest change isn’t that LLMs “create malware instantly.” It’s that they enable rapid iteration. Attackers can test hypotheses faster and adjust quickly.

To meet that pace:

• Use rapid triage: automate initial enrichment and containment actions where possible.
• Hunt behavior: build detections for repeated actions (staging, persistence, beaconing) rather than single artifacts.
• Run tabletop exercises: practice response to polymorphic payloads and fast-changing threats.

Frequently Asked Questions

Can LLMs write malware that bypasses antivirus?

They can help generate code, but bypassing antivirus depends on execution context, obfuscation quality, and runtime behavior. Defenders should focus on behavior detection and hardening, not just signature updates.

Does this mean LLMs are inherently unsafe?

LLMs aren’t automatically “malicious.” The risk comes from how people use them and where organizations lack controls. Responsible development practices and security monitoring reduce harm.

What’s the most important defense for organizations?

A combination of least privilege, strong endpoint controls, behavior-based detections, and hardened delivery pathways is the most effective approach.

Conclusion: The Threat Is Real—But Defensible

Cybercriminals are using LLMs to move faster: generating code scaffolds, producing script variants, translating logic across environments, and improving delivery and iteration. The result is more efficient development cycles and wider targeting.

The good news is that you can defend against this shift. When you move from “detecting known files” to “detecting malicious behavior,” enforce least privilege and allowlisting, and strengthen delivery controls, you reduce the attacker’s ability to turn LLM output into successful compromise.

If you’re responsible for security, update detection strategies and incident workflows for rapid iteration. If you’re responsible for engineering, treat LLM-generated code as untrusted until it passes robust review and testing. In both cases, your processes—not the model—determine the outcome.