Detect Multi-Stage Channels in Sumo Logic CSE
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/
Sumo Detection Query
// T1104 Multi-Stage Channels — Sumo Logic CSE (Cloud SIEM Enterprise)
// Primary detection: non-browser process contacting 2+ distinct external IPs
_index=sec_record*
| where metadata_deviceEventId = "windows:sysmon:3" or metadata_deviceEventId = "windows:network:connection"
| where !(srcDevice_ip matches "10.*" or srcDevice_ip matches "172.16.*" or srcDevice_ip matches "172.17.*" or srcDevice_ip matches "172.18.*" or srcDevice_ip matches "172.19.*" or srcDevice_ip matches "172.2*" or srcDevice_ip matches "172.30.*" or srcDevice_ip matches "172.31.*" or srcDevice_ip matches "192.168.*" or srcDevice_ip matches "127.*")
| where !(dstDevice_ip matches "10.*" or dstDevice_ip matches "172.16.*" or dstDevice_ip matches "172.2*" or dstDevice_ip matches "172.30.*" or dstDevice_ip matches "172.31.*" or dstDevice_ip matches "192.168.*" or dstDevice_ip matches "127.*")
| where !(application_name matches "*chrome*" or application_name matches "*msedge*" or application_name matches "*firefox*" or application_name matches "*iexplore*" or application_name matches "*opera*" or application_name matches "*brave*" or application_name matches "*OneDrive*" or application_name matches "*Teams*" or application_name matches "*Outlook*" or application_name matches "*thunderbird*" or application_name matches "*svchost*" or application_name matches "*MsMpEng*" or application_name matches "*WaaSMedicAgent*")
| timeslice 24h
| stats
dcount(dstDevice_ip) as unique_external_ips,
values(dstDevice_ip) as ip_list,
values(dstDevice_port) as port_list,
count as connection_count,
min(_messagetime) as first_contact,
max(_messagetime) as last_contact
by srcDevice_hostname, user_username, application_name, commandLine, _timeslice
| where unique_external_ips >= 2
| eval duration_mins = round((last_contact - first_contact) / 60000, 1)
| eval strong_indicator = if(unique_external_ips >= 3, "true", "false")
| eval detection_type = "SingleProcessMultiStageC2"
| fields _timeslice, srcDevice_hostname, user_username, application_name, commandLine, unique_external_ips, ip_list, port_list, connection_count, duration_mins, strong_indicator, detection_type
| sort by unique_external_ips desc
// Parent-child handoff (run as separate search and correlate via Signal)
// _index=sec_record*
// | where metadata_deviceEventId = "windows:sysmon:3"
// | where !(dstDevice_ip matches "10.*" or dstDevice_ip matches "192.168.*" or dstDevice_ip matches "127.*")
// | stats values(dstDevice_ip) as child_ips by srcDevice_hostname, parentPid, parentProcessName, application_name, commandLine, user_username
// | join (srcDevice_hostname, parentPid)
// [_index=sec_record* | where metadata_deviceEventId = "windows:sysmon:3"
// | stats values(dstDevice_ip) as parent_ips by srcDevice_hostname, pid as parentPid]
// | where !isNull(parent_ips) and !contains(child_ips, parent_ips)
// | eval detection_type = "ParentChildC2Handoff", strong_indicator = "true"Detects T1104 Multi-Stage C2 channels in Sumo Logic CSE using normalized schema fields. The primary query aggregates Sysmon network connection events (Event ID 3) to identify non-browser processes making connections to 2 or more distinct external public IPs within a 24-hour window. Processes known to make multi-destination connections (browsers, cloud sync, Windows telemetry) are excluded. A secondary commented query documents the parent-child C2 handoff pattern where a parent and child process contact different external IPs, suggesting staged payload delivery.
Data Sources
Required Tables
False Positives & Tuning
- Software deployment platforms (Chef, Puppet, Ansible) where a management agent polls a primary orchestrator IP and separately reports metrics to a monitoring endpoint
- Multi-CDN content delivery where a download manager contacts multiple edge nodes (different IPs) to accelerate a large file transfer
- VPN or proxy client software that first connects to an authentication server and then tunnels traffic through a separate VPN concentrator IP
- Automated testing frameworks or CI/CD agents that connect to multiple external test infrastructure endpoints as part of parallel test execution
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.