In 2025–2026 one of the most powerful (and increasingly common) ways malware authors evade static detection and signature-based AV/EDR is letting a large language model rewrite the control-flow graph (CFG) of a binary every single build so that no two samples look the same even though they do exactly the same thing.
This is no longer a research paper idea. Several families and private builders are already doing it in production.
How LLMs Actually Rewrite Control Flow
The high-level workflow attackers use today:
1. Start with clean, high-level logic Usually written in C/C++, Rust, or Go, the “business logic” (steal cookies, dump LSASS, encrypt files, C2 beacon, etc.).
2. Extract semantic blocks split into smaller meaningful units
a) The string decryption routine
b) The HTTP Client/TLS set up
c) Inject stub (process hollow, APC, early bird)
d) Anti-analysis (VM, Debugger, Sandbox)
e) Persistence (Run key, Scheduled Task, WMI event filter)
3. Provide blocks to the Large Language Model with transformation instructions (Typical Prompt) (Paraphrased from leaked builder configs)
You are an expert malware obfuscator.
Take this C function and produce FIVE semantically equivalent but syntactically different versions.
Requirements:
- Preserve exact behavior (same inputs → same outputs)
- Change control flow structure (flatten, add junk branches, use switch over if-else, insert opaque predicates)
- Rename variables meaningfully but differently each time
- Use different loop constructs (for → while → do-while)
- Insert non-trivial but dead code that does not affect outcome
- Avoid compiler optimizations that would make versions look similar
- Output only the C code, no explanations
4. Pick one variant per build Builder randomly chooses one of the five rewrites → compiles with different compiler flags / optimization levels / inline decisions → final binary has completely different CFG, basic-block layout, instruction sequence.
5. Repeat for every major function A single stealer can have 20–60 functions rewritten this way → exponential variation.
Concrete Examples Seen in Wild Campaigns
1. Lumma Stealer family rebuilds (mid-2025 onward) Leaked builder configs show LLM prompts for rewriting the string decryption loop, C2 beacon, clipboard monitor, and injection stub. Same core logic appears in ~40 visually different binaries per day , all pass static engines for 24–72 hours.
2. Private RansomHub / LockBit affiliate builders 2026 underground ads offer “LLM polymorphic engine” add-on: $800–$1,500 extra → every compiled payload gets unique CFG. Analysts report ~70–80 % reduction in signature hits compared to classic obfuscators (Themida, VMProtect, custom packers).
3. Android clipper / banking trojan variants Some loaders use small on-device or cloud-called models to rewrite DEX bytecode sequences at runtime, not full LLM, but same principle: generate semantically equivalent but structurally different code paths per execution.
Detection & Hardening Implications
What breaks with LLM control-flow rewriting
1. All static signatures (YARA, hash, opcode sequences) become useless after one rebuild.
2. Basic block / CFG similarity clustering (used by many sandboxes) fails.
3. Machine-learning models that rely on structural features (control-flow graphs, call graphs) lose effectiveness unless retrained frequently.
What still attracts these samples:
1. The indicators of behavior present in the execution of the samples (API calls that occurred, file/registry/network activity)
2. The use of heuristic rules when unpacking/exploring dynamically loaded code to identify malware
3. Type of memory dump → check for non-standard language model (LLM) inference artifacts (ONNX Runtime Mobile API calls, TensorFlow Lite API calls, GGUF model files found in /data/data/)
4. The pattern formation of C2 traffic in terms of how they are formed/maintained over time (C2 code structure is a lot more stable than that used in the execution path of code samples)
Checklist for Quick Defense
1. All suspicious processes need to be prevented from running (powershell.exe, rundll32.exe, regsvr32.exe, etc.) by forcefully blocking behavioral activity.
2. Alert on dynamic code execution (VirtualAlloc + WriteProcessMemory + CreateThread patterns)
3. Monitor for small GGUF / ONNX files dropped in temp folders or app data
4. Keep endpoint ML models updated weekly , static structure changes, but behavior changes slower
5. Use strict application control (AppLocker, WDAC) to limit what can load code dynamically
LLM-driven control-flow rewriting is one of the clearest signs that malware development is entering the same rapid-iteration loop as legitimate software. The binary you block today will look completely different tomorrow but the malicious behavior stays the same.
That’s where behavioral and memory-based defenses still have the advantage… for now.
