How do attackers use LunarLoader?

How LunarLoader turns the first stage of an intrusion into a delivery mechanism

LunarLoader is used as a staging component, not the end payload. Attackers rely on it to keep the final malware hidden until execution, which makes static inspection less useful and gives the operator flexibility to swap in different second-stage payloads. That pattern is common in loader-based intrusions, where the goal is to separate initial access from visible malicious behaviour.

Because the loader’s job is to decrypt and launch later-stage code, defenders should expect the early execution chain to look ordinary at first glance. The important question is not just whether a process exists, but whether it is unpacking, decrypting, or spawning content that was not present on disk in a readable form.

What attackers gain by using a loader instead of dropping the final payload directly

A loader changes the defender’s timeline. By delaying exposure of the real payload, attackers can reduce the chance that file-based scanning, reputation checks, or simple sandboxing will identify the full malicious intent before execution. It also lets the operator reuse one loader across campaigns while varying the second stage as needed.

This is why layered execution matters. A seemingly small bootstrapper may only exist to establish the conditions for a later payload, so the observable risk is often broader than the first process suggests. The loader is part of the intrusion chain, and its value to attackers is in hiding the next step until they control the runtime environment.

What defenders should look for during execution

Watch for process chains that do not match the parent application’s normal behaviour, especially when a signed or benign-looking program suddenly allocates memory, writes decrypted content, or launches an unknown child process. Unusual memory activity, script spawning, and short-lived helper processes are all strong clues that a loader is unpacking a second stage.

Correlate those signals with endpoint telemetry and command-line detail so you can distinguish legitimate software updates from staged malware delivery. A loader often leaves more behavioural evidence than binary evidence, which means runtime observation is usually more valuable than relying only on file hashes.

Risk and Threat Considerations

Loader malware creates a detection gap between the initial foothold and the final malicious action. That gap matters because the first executable may appear low-risk, while the real damage only begins after decryption or in-memory execution of a hidden payload.

Failure mechanism: The attacker splits execution into stages so the visible binary is not the payload of greatest concern, then uses memory-resident or transient execution to reduce the chance of inspection.

Impact: Defenders may miss the true objective of the intrusion until follow-on actions such as credential theft, persistence, lateral movement, or data theft are already underway.

Practitioner Guidance

What to verify: Confirm whether the suspicious process creates a child process, injects code, allocates executable memory, or runs scripts that are not part of the expected application workflow. If any of those occur, treat the process tree as a staging event rather than a single-file alert.

Decision rule: If the binary is only a launcher and the decoded or spawned content is unknown, prioritise containment and payload discovery before broad cleanup. The loader itself may be replaceable, but the second stage determines the real blast radius.

Practitioner takeaway: The key judgement is to treat loaders as evidence of an active delivery chain, not as low-value noise, because the hidden payload is usually what defines the compromise.

Related resources from NHI Mgmt Group

• Guide: Malware Guide
• How do attackers turn a supply-chain incident into wider NHI compromise?
• How do attackers operationalise stolen OAuth tokens at scale?
• Why do attackers often check model availability before trying to generate content?
• How do attackers turn stolen npm secrets into broader compromise?