Detect RedLeaves by hunting for remote access behaviour, persistence, and command-and-control traffic that does not match normal operations. Check for suspicious process launches, dropped files, and unusual scripting on compromised hosts. Correlate endpoint alerts with outbound connections, because the malware often reveals itself through repeated beaconing and operator-driven commands.
How to spot RedLeaves in endpoint and network telemetry
Start with behaviour, not just file names. RedLeaves is easier to catch when you look for a cluster of remote-access activity, persistence, and command-and-control patterns that do not fit the host’s normal role. A single alert may look ordinary; the combination of process execution, script activity, dropped artefacts, and unusual outbound connections is what usually makes the infection visible.
One useful way to structure triage is to separate initial execution from follow-on control. If an endpoint launches suspicious parent-child process chains, spawns scripting interpreters unexpectedly, writes files into odd locations, and then starts beaconing outward on a repetitive cadence, treat that as a coherent intrusion pattern rather than isolated noise. That approach also helps you distinguish RedLeaves from generic commodity malware or administrator tooling that may only show one of those behaviours.
Network evidence matters because remote access malware often leaves a more stable trail on the wire than on disk. Watch for long-lived outbound sessions, repeated callbacks at regular intervals, and operator-driven commands that produce bursts of activity after quiet periods. When host telemetry and outbound connections line up, you can usually narrow the hunt faster than by relying on endpoint detections alone. For broader malware detection tradecraft, see Malware Guide and compare the observed pattern with your normal process and scripting baseline.
What evidence should security teams correlate first?
The highest-value correlation is endpoint behaviour plus external communication. A suspicious process tree is useful, but it becomes much stronger when you can pair it with remote connections to unfamiliar hosts, repeated DNS or HTTP activity, or a sequence of commands that appears only after the malware has established control. That correlation is what turns a generic alert into a defensible RedLeaves hypothesis.
Look for three classes of evidence together: process launches that should not occur on the asset, files written by those processes, and network beacons that continue after the process has finished its visible setup stage. If you also see script engines, encoded command lines, or child processes that appear to stage additional payloads, the probability of malicious remote access increases significantly. Hunting in this order reduces false positives because it forces the detection to explain both local execution and external reach-back.
For detection engineering, map these observations to adversary techniques rather than to one indicator at a time. That makes it easier to build durable queries for repeated beaconing, suspicious scripting, and post-compromise command execution. The MITRE ATT&CK Enterprise Matrix is useful here because it helps you translate the observed sequence into hunting logic for remote access, persistence, and command-and-control behaviour.
What should analysts do when the signal is partial?
Partial signal is common with malware that tries to stay quiet. If you only have one indicator, such as a suspicious dropped file or an odd script launch, do not close the case immediately. Instead, look for the next piece of the chain, especially outbound connectivity, follow-on process creation, and any repeat execution that suggests the malware is re-establishing contact with an operator.
Time matters because remote access malware often alternates between dormant and active phases. A host that looks benign at first may become much easier to confirm once the operator issues commands, stages additional tools, or triggers a new persistence action. Analysts should preserve volatile context, including current connections, recent process ancestry, and the sequence of recently written files, because those details are often lost before the host is remediated.
If the environment is already seeing multiple suspicious hosts, prioritise the one with the clearest outbound control traffic first. That asset is often the best place to recover command history, staging artefacts, and artefacts of lateral movement. The practical objective is not to prove every alert is RedLeaves before acting, it is to identify the infection chain early enough that you can contain the host before operator activity expands.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1105 — Ingress Tool Transfer | RedLeaves hunting centers on remote access and operator-driven payload activity. |
| T1059 — Command and Scripting Interpreter | Suspicious scripting is a core detection clue in the RedLeaves behaviour chain. | |
| T1071 — Application Layer Protocol | Repeated C2 beacons over common protocols are central to RedLeaves detection. | |
| Recommendation — Map transfer and staging behaviour to T1105 and hunt for follow-on execution on the same host. Hunt for abnormal script-interpreter launches and correlate them with adjacent beaconing. Inspect regular outbound application-layer traffic for beaconing patterns that do not match baseline. | ||
| NIST CSF 2.0 | DE.CM-01 — The network is monitored to detect potential cybersecurity events | RedLeaves detection relies on monitoring endpoint and network telemetry for anomalies. |
| DE.AE-03 — Anomalous activity is detected and analyzed | The question is about spotting anomalous malware behaviour across host and network signals. | |
| Recommendation — Correlate endpoint and network monitoring to surface repeated beaconing and abnormal execution. Analyze anomalous process, file, and connection patterns as a single intrusion hypothesis. | ||
Practitioner Guidance
What to verify: Confirm that the suspicious process tree, dropped files, and outbound beaconing belong to the same timeline before you escalate. A single isolated indicator is weaker than a short sequence that shows execution, persistence, and communication on the same host.
Decision rule: If a host shows repeated outbound callbacks plus unusual scripting or process creation, treat it as a likely active compromise and move to containment, even if the malware name is not yet proven. If you only have static artefacts without network follow-through, keep hunting rather than overcalling the case.
What practitioners underestimate: RedLeaves-style intrusions are often missed because each artefact looks routine on its own. The useful signal is the relationship between behaviours, especially when endpoint telemetry and outbound traffic reinforce each other over time.
Practitioner takeaway: The fastest path to a reliable RedLeaves detection is to correlate local execution artefacts with sustained remote-control traffic, because the malware is most defensible as a pattern, not as a single indicator.