Why do LLMs struggle with malware analysis when only static code is available?

Why static-only malware analysis misses the behaviour that matters

Static code can show strings, imports, structure and some obvious intent, but it often cannot prove what the sample actually does at runtime. Malware frequently hides its real behaviour behind branches that only execute in certain environments, decrypted payloads, unpacking stubs, or API calls that only make sense once the code is running. That is why static-only review is useful for triage, but weak for confident behaviour attribution.

When behaviour depends on context, the analyst needs execution traces, not just text or disassembly. A static view may expose suspicious fragments, yet still leave uncertainty about whether those fragments are active logic, dead paths, or decoys. The harder the sample tries to delay, decode or conditionally reveal itself, the less reliable static interpretation becomes.

For defenders, the practical implication is that static analysis can answer “what might this sample be?” far more easily than “what will this sample do on a real host?” That gap matters because the actions that create impact, such as persistence, injection or credential theft, often only become visible when the malware reaches the right runtime state.

For a broader defender workflow, Malware Analysis Guide for Defenders is the best starting point because it separates triage, static inspection and dynamic detonation into the right sequence.

Why control flow, environment checks and unpacking defeat static reasoning

Malware authors design code to look misleading when it is not executed. Opaque predicates can make dead branches appear meaningful, while environment checks can suppress the malicious path unless the sample sees a specific locale, domain, process list, or lab condition. Packed or encrypted payloads raise the same problem: the visible file may contain only a loader, while the real payload exists only after unpacking or decryption.

That means static analysis often overweights source-like artefacts and underweights runtime dependencies. A line of code may look important, but if it is guarded by a branch that never executes on the sample you are examining, it is not operationally useful. Conversely, the most important code may be absent from the on-disk view entirely until the malware derives a key, resolves an API dynamically, or reconstructs a second stage in memory.

Static-only review also struggles when malware uses API indirection or runtime resolution to conceal its purpose. Import tables can be sparse, function names can be resolved dynamically, and the sample may only reveal its real dependencies after execution starts. That is one reason static disassembly alone rarely gives a complete picture of malware capability.

The Malware Guide is useful here because it covers loaders, sandbox evasion and the common techniques that make runtime behaviour disappear from a purely static view.

What static analysis can still tell you, and where it stops

Static analysis remains valuable for fast screening, family hints and safe inspection. It can reveal obvious indicators such as embedded URLs, suspicious imports, hard-coded commands, packer signatures and strings that help you cluster samples or build detections. It is also safer than execution when you only need an initial judgement and cannot afford live detonation.

Its limit is that evidence of capability is not evidence of effect. A sample may contain code for persistence, process injection or decryption, but the analyst still needs dynamic evidence to know whether those paths are reachable, whether they are triggered by the intended conditions, and what side effects they produce on a real endpoint. That distinction is especially important when the malware is built to fragment logic across stages.

In practice, static-only findings should be treated as hypotheses. They are often enough to prioritise a sample, but not enough to characterise the full kill chain or to confirm impact. If the question is whether the malware would alter state, spread, evade controls or modify another process, static code alone is usually insufficient.

For a behaviour-first workflow that turns static clues into observable detections, Malware Analysis Guide for Defenders gives the clearest path from triage to dynamic confirmation.

Practitioner Guidance

What to verify: Treat static findings as leads, then verify whether the suspicious branch is actually reachable, whether the sample unpacks itself, and whether runtime conditions change the code path. If those questions remain unanswered, do not overstate confidence in your analysis.

Decision rule: If the sample shows obfuscation, staged payloads, environment checks or dynamic API resolution, escalate to dynamic analysis rather than trying to “reason it out” from the file alone. Static-only review is acceptable for triage, not for final behavioural judgement.

Practitioner takeaway: The real weakness of static-only malware analysis is not that it finds nothing, but that it can find the wrong thing with high confidence; runtime observation is what separates suspicious code from confirmed behaviour.

Related resources from NHI Mgmt Group

• What do teams get wrong about automating code migrations with static analysis and LLMs?
• What breaks when static analysis is used as the main AppSec control for AI code?
• What breaks when static analysis does not cover secrets found in source code?
• What do teams get wrong about static code analysis and AI-assisted development?