How can security teams detect LunarMail?

How to spot LunarMail in mail, endpoint, and DNS telemetry

LunarMail detection works best when you treat the email as the start of a chain, not the whole incident. The useful question is whether delivery is followed by attachment execution, script activity, or a new process lineage on the recipient host. That makes the mail gateway, endpoint telemetry, and DNS logs complementary rather than interchangeable.

Look first for the delivery-to-execution handoff. Suspicious attachments matter most when they are paired with a spawned script host, loader, or unusual child process shortly after message receipt. If the attachment is benign-looking but the endpoint shows a process tree that does not match normal user behavior, the message is likely the trigger rather than the payload itself. The detection challenge is correlation, not simple attachment matching.

Outbound network activity is the second major clue. Once execution begins, watch for staging traffic, beacon-like patterns, or DNS lookups that do not fit the recipient's normal application set. When email delivery, process execution, and network egress line up in the same time window, you have a stronger case than any single alert on its own.

A practical way to investigate is to build the timeline backwards: identify the message, inspect the attachment or embedded content, confirm whether a local process was launched, then check whether that process generated network activity. That sequence helps separate a one-off suspicious email from a real intrusion chain. It also reduces false positives from legitimate attachments that never execute or from unrelated endpoint noise.

Where LunarMail detection breaks down

The main failure mode is overreliance on the mail gateway. Gateways can flag malicious content, but they do not always show whether a user opened the message, launched a file, or triggered post-delivery activity. If defenders stop at the inbox, they miss the downstream endpoint behavior that often provides the clearest evidence.

Another blind spot is sparse endpoint telemetry. If process creation, command-line detail, or parent-child relationships are missing, the investigation may only show that a message arrived and a connection left the host. That is usually enough to raise suspicion, but not enough to explain the payload path or assess spread. DNS logging fills part of that gap by exposing staging domains, resolution bursts, or lookups that precede command-and-control traffic.

Malware Guide is useful here because LunarMail detection depends on the same loader, execution, and post-delivery patterns used by many malware families. The shared lesson is to treat the initial email as one event in a broader malware chain, not as the complete detection surface.

What a useful LunarMail hunt should collect

A good hunt builds evidence across three layers: the message, the process chain, and the network trail. That means preserving message metadata, attachment hashes or samples where available, endpoint process trees, command-line arguments, and any DNS or outbound connection records tied to the recipient host. Without that set, it is hard to prove whether the email merely arrived or whether it successfully executed code.

Correlation windows matter. If the same host receives the message, spawns a suspicious child process, and then contacts an external domain shortly afterward, the combined signal is far more actionable than a standalone signature hit. Security teams should also compare the activity to the user's normal mail and application behavior so that unusual process launches are not dismissed as routine productivity software.

MITRE ATT&CK Enterprise Matrix helps structure that hunt because LunarMail-style activity maps naturally to delivery, execution, command-and-control, and post-compromise behaviors. Using ATT&CK as the common language makes it easier to align email, endpoint, and DNS alerts into one investigation path.

Risk and Threat Considerations

LunarMail is dangerous because email delivery gives it a trusted entry point, while endpoint execution and outbound traffic can turn a single message into broader compromise. The risk is not just malicious content in the inbox, but the possibility that a user action triggers code execution and external communication before the security team sees enough context.

Failure mechanism: Defenders monitor only message content or gateway verdicts, while the actual compromise happens after the recipient host opens the attachment or follows embedded content, causing script execution, loader activity, or beaconing that the mail layer alone may not surface.

Impact: The result can be credential theft, internal reconnaissance, additional payload delivery, or lateral movement, especially if outbound connections blend into normal traffic and the original email is not linked quickly to endpoint behavior.

Practitioner Guidance

What to prioritise: Correlate email receipt time with endpoint process creation and DNS activity on the same host. If you can only validate one thing first, validate whether the message was followed by execution.

What to verify: Confirm the parent-child process chain, the attachment or embedded object involved, and whether the outbound destination is newly observed or inconsistent with the user's normal software footprint.

Decision rule: If a suspicious email has already led to script, loader, or unusual child-process activity, treat it as a host investigation, not just a mail quarantine event. The alert scope should expand to the recipient endpoint and its recent network history.

Practitioner takeaway: LunarMail detection is strongest when teams prove the transition from message delivery to host execution to outbound signaling, because that chain is what turns an email artifact into an intrusion indicator.

Related resources from NHI Mgmt Group

• Why are NHIs a critical concern for security teams?
• What steps should security teams take to prevent Shadow AI risks?
• Why is the abuse of NHIs a priority for security teams?
• What is the difference between SAST and DAST for security teams?