Detect Multi-Stage Channels in Elastic Security
Adversaries may create multiple stages for command and control that are employed under different conditions or for certain functions. Use of multiple stages may obfuscate the command and control channel to make detection more difficult. Remote access tools will call back to the first-stage command and control server for instructions. The first stage may have automated capabilities to collect basic host information, update tools, and upload additional files. A second remote access tool (RAT) could be uploaded at that point to redirect the host to the second-stage command and control server. The second stage will likely be more fully featured and allow the adversary to interact with the system through a reverse shell and additional RAT features. The different stages will likely be hosted separately with no overlapping infrastructure. The loader may also have backup first-stage callbacks or Fallback Channels in case the original first-stage communication path is discovered and blocked. Known real-world examples include APT3 using SOCKS5 to proxy through 192.157.198[.]103 before connecting to a second IP on TCP/81, Lazarus Group injecting later stages into separate processes, Bazar loader downloading the Bazar backdoor as a second-stage implant, and LunarWeb using one URL for initial host profiling and two additional URLs for command retrieval.
MITRE ATT&CK
- Tactic
- Command and Control
- Technique
- T1104 Multi-Stage Channels
- Canonical reference
- https://attack.mitre.org/techniques/T1104/
Elastic Detection Query
// T1104 Multi-Stage Channels — Elastic EQL
// Sequence: a non-browser process makes a network connection, then a child of that process makes a network connection to a DIFFERENT external IP
sequence by host.name with maxspan=30m
[network where event.type == "connection" and event.action == "connection_attempted"
and not process.name in ("chrome.exe", "msedge.exe", "firefox.exe", "iexplore.exe", "opera.exe", "brave.exe",
"OneDrive.exe", "Dropbox.exe", "Teams.exe", "Outlook.exe", "thunderbird.exe",
"svchost.exe", "MsMpEng.exe", "DiagTrack.exe", "wuauclt.exe", "WaaSMedicAgent.exe",
"SearchIndexer.exe", "backgroundTaskHost.exe", "RuntimeBroker.exe")
and not cidrmatch(destination.ip, "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16", "127.0.0.0/8", "::1/128", "169.254.0.0/16")
] by process.entity_id, destination.ip as first_external_ip
[network where event.type == "connection" and event.action == "connection_attempted"
and not process.name in ("chrome.exe", "msedge.exe", "firefox.exe", "iexplore.exe", "opera.exe", "brave.exe",
"OneDrive.exe", "Dropbox.exe", "Teams.exe", "Outlook.exe", "thunderbird.exe",
"svchost.exe", "MsMpEng.exe", "DiagTrack.exe", "wuauclt.exe", "WaaSMedicAgent.exe")
and not cidrmatch(destination.ip, "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16", "127.0.0.0/8", "::1/128", "169.254.0.0/16")
] by process.parent.entity_id, destination.ip != first_external_ip
// Alternate: single process connecting to 3+ distinct external IPs (aggregation via ES|QL or threshold rule)
// Use a threshold alert on top of this base query:
// FROM logs-endpoint.events.network*
// | WHERE event.action == "connection_attempted"
// AND NOT process.name IN ("chrome.exe", "msedge.exe", "firefox.exe", "svchost.exe", "MsMpEng.exe")
// AND NOT CIDR_MATCH(destination.ip, "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16", "127.0.0.0/8")
// | STATS unique_ips = COUNT_DISTINCT(destination.ip), ip_list = VALUES(destination.ip),
// port_list = VALUES(destination.port), conn_count = COUNT() BY host.name, process.name, process.command_line, process.pid
// | WHERE unique_ips >= 2
// | SORT unique_ips DESCDetects multi-stage C2 channel behavior using two complementary patterns: (1) a parent process connects to an external IP and its child process subsequently connects to a DIFFERENT external IP within 30 minutes, indicating a first-to-second-stage handoff; (2) an alternate ES|QL aggregation query for single processes contacting 2+ distinct external IPs. Both patterns exclude common browsers, cloud sync, and Windows telemetry processes, and filter RFC1918/loopback addresses.
Data Sources
Required Tables
False Positives & Tuning
- Legitimate update agents (e.g., software auto-updaters) that download a new binary from one server and then beacon home to a second analytics endpoint
- Security tools such as EDR agents, vulnerability scanners, or SIEM forwarders that contact multiple cloud infrastructure IPs during normal operation
- Developer toolchains (npm, pip, cargo) that pull packages from a CDN then report telemetry to a separate analytics service; exclude by process parent (IDE processes)
- Load-balanced SaaS applications where DNS round-robin resolves to multiple distinct public IPs for the same service, producing multiple unique IP connections
Other platforms for T1104
Testing Methodology
Validate this detection against 5 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1Two-Stage PowerShell C2 Simulation (Windows)
Expected signal: Sysmon Event ID 1: Process Create for powershell.exe with the multi-stage command line. Sysmon Event ID 3: two distinct Network Connection events from the same ProcessId — one to 127.0.0.1:8080 and one to 127.0.0.1:8081. Note: loopback IPs will be filtered from the public-IP detection rules, so to fully validate the detection in a lab, replace 127.0.0.1 with two distinct external test IPs (e.g., dedicated canary hosts).
- Test 2First-Stage Downloader Dropping Second-Stage Binary (Windows)
Expected signal: Sysmon Event ID 11: FileCreate for stage2_test.exe in %TEMP% initiated by powershell.exe. Sysmon Event ID 1: Process Create for stage2_test.exe with parent powershell.exe. The loader-to-dropped-binary pattern is visible in the process chain. In a full lab scenario with a second-stage that makes outbound connections to a different IP than the downloader, Sysmon Event ID 3 records from both the parent PowerShell and the child stage2_test.exe would show different destination IPs.
- Test 3SOCKS5 Proxy Connection via PowerShell (Windows — First-Stage Pattern)
Expected signal: Sysmon Event ID 3: Network Connection events from powershell.exe to 127.0.0.1:1080 and 127.0.0.1:1913. In a real scenario with external IPs, these would appear in DeviceNetworkEvents. The connection to TCP/1913 specifically matches the APT3 Operation Double Tap SOCKS5 first-stage pattern.
- Test 4Multi-Stage C2 via curl Chain (Linux)
Expected signal: Linux auditd SYSCALL records: execve for curl with distinct destination arguments, socketcall/connect system calls to two distinct destination ports. If using Sysmon for Linux: Event ID 3 (Network Connection) for each curl process with different DestinationIp/DestinationPort values. Process tree shows sequential curl invocations from a parent shell process. /tmp file creation events for downloaded artifacts.
- Test 5Process Injection Multi-Stage Simulation (Windows — Lazarus Pattern)
Expected signal: Sysmon Event ID 1: Process Create for notepad.exe and child powershell.exe. Sysmon Event ID 10 (ProcessAccess): source PowerShell process accessing notepad.exe handle — this is the process access event that precedes injection in real attacks. Sysmon Event ID 3: Network Connection from child powershell.exe to 127.0.0.1:9002, distinct from any connections the parent makes. Security Event ID 4688 for all process creation events if command-line auditing is enabled.
References (9)
- https://attack.mitre.org/techniques/T1104/
- https://www.fireeye.com/blog/threat-research/2014/11/operation_doubletap.html
- https://www.welivesecurity.com/en/eset-research/lunar-toolset-undocumented-backdoors-turla/
- https://unit42.paloaltonetworks.com/valak-malware/
- https://www.cybereason.com/blog/a-bazar-of-tricks-following-team9s-development-cycles
- https://blog.morphisec.com/snip3-an-investigation-into-new-crypter-as-a-service
- https://blog.talosintelligence.com/muddywater/
- https://blog.talosintelligence.com/salt-typhoon-analysis/
- https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1104/T1104.md
Unlock Pro Content
Get the full detection package for T1104 including response playbook, investigation guide, and atomic red team tests.