Detect Multi-Stage Channels in Google Chronicle
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/
YARA-L Detection Query
rule t1104_multi_stage_channels_single_process {
meta:
author = "Argus Detection Engineering"
description = "Detects T1104 Multi-Stage Channels: a non-browser process connects to multiple distinct external IPs suggesting first-to-second-stage C2 infrastructure handoff"
mitre_attack_tactic = "Command and Control"
mitre_attack_technique = "T1104"
severity = "HIGH"
priority = "HIGH"
rule_version = "1.0"
created = "2026-04-17"
platforms = "Windows"
events:
$e1.metadata.event_type = "NETWORK_CONNECTION"
$e1.principal.hostname = $host
$e1.principal.process.file.full_path != /(?i)(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)/
$e1.principal.process.file.full_path = $proc_path
$e1.principal.process.pid = $pid
// Filter out RFC1918 and loopback destinations
not $e1.target.ip = /^(10\.|172\.(1[6-9]|2[0-9]|3[0-1])\.|192\.168\.|127\.|0\.0\.0\.0|::1)/
$e1.target.ip = $first_ip
$e2.metadata.event_type = "NETWORK_CONNECTION"
$e2.principal.hostname = $host
$e2.principal.process.file.full_path = $proc_path
$e2.principal.process.pid = $pid
not $e2.target.ip = /^(10\.|172\.(1[6-9]|2[0-9]|3[0-1])\.|192\.168\.|127\.|0\.0\.0\.0|::1)/
$e2.target.ip = $second_ip
$second_ip != $first_ip
$e1.metadata.event_timestamp.seconds <= $e2.metadata.event_timestamp.seconds
$e2.metadata.event_timestamp.seconds - $e1.metadata.event_timestamp.seconds <= 86400
match:
$host, $proc_path, $pid over 24h
outcome:
$risk_score = max(if($e2.metadata.event_timestamp.seconds - $e1.metadata.event_timestamp.seconds < 300, 90, 70))
$detection_type = "SingleProcessMultiStageC2"
$process_name = $proc_path
$first_stage_ip = array_distinct($first_ip)
$second_stage_ip = array_distinct($second_ip)
$hostname = $host
condition:
$e1 and $e2
}
rule t1104_parent_child_c2_handoff {
meta:
author = "Argus Detection Engineering"
description = "Detects T1104 Multi-Stage Channels parent-child handoff: parent process contacts external IP, spawns child that contacts a DIFFERENT external IP within 30 minutes"
mitre_attack_tactic = "Command and Control"
mitre_attack_technique = "T1104"
severity = "CRITICAL"
priority = "HIGH"
rule_version = "1.0"
created = "2026-04-17"
events:
// Parent network connection to external IP
$parent_net.metadata.event_type = "NETWORK_CONNECTION"
$parent_net.principal.hostname = $host
$parent_net.principal.process.pid = $parent_pid
$parent_net.principal.process.file.full_path != /(?i)(chrome\.exe|msedge\.exe|firefox\.exe|iexplore\.exe|svchost\.exe|MsMpEng\.exe)/
not $parent_net.target.ip = /^(10\.|172\.(1[6-9]|2[0-9]|3[0-1])\.|192\.168\.|127\.|::1)/
$parent_net.target.ip = $parent_ip
// Child process spawned by parent
$proc_create.metadata.event_type = "PROCESS_LAUNCH"
$proc_create.principal.hostname = $host
$proc_create.principal.process.pid = $parent_pid
$proc_create.target.process.pid = $child_pid
$proc_create.target.process.file.full_path != /(?i)(chrome\.exe|msedge\.exe|firefox\.exe|iexplore\.exe|svchost\.exe)/
// Child network connection to DIFFERENT external IP
$child_net.metadata.event_type = "NETWORK_CONNECTION"
$child_net.principal.hostname = $host
$child_net.principal.process.pid = $child_pid
not $child_net.target.ip = /^(10\.|172\.(1[6-9]|2[0-9]|3[0-1])\.|192\.168\.|127\.|::1)/
$child_net.target.ip = $child_ip
$child_ip != $parent_ip
match:
$host, $parent_pid over 30m
outcome:
$risk_score = 95
$detection_type = "ParentChildC2Handoff"
$parent_c2_ip = array_distinct($parent_ip)
$child_c2_ip = array_distinct($child_ip)
$hostname = $host
condition:
$parent_net and $proc_create and $child_net
}Two Chronicle YARA-L 2.0 rules detecting T1104 Multi-Stage Channels. Rule 1 (t1104_multi_stage_channels_single_process) identifies a single non-browser process connecting to two or more distinct external IPs within a 24-hour window, indicating potential first-to-second-stage C2 redirection. Rule 2 (t1104_parent_child_c2_handoff) detects the parent-child process handoff pattern where a parent process connects to one external IP, spawns a child process, and that child then connects to a different external IP within 30 minutes. Both rules use UDM normalized fields and filter RFC1918/loopback space.
Data Sources
Required Tables
False Positives & Tuning
- Legitimate enterprise agent software (MDM, DLP, backup) that performs initial registration to a cloud enrollment server and then connects to a separate data transfer endpoint
- Browser extension processes or electron-based apps that maintain connections to multiple cloud API endpoints simultaneously for feature functionality
- DevOps tooling (Terraform, kubectl, Helm) that contacts a cloud provider control plane API and separately contacts a metrics/logging endpoint during provisioning
- Security awareness training platforms that launch from an email client, contact their primary SaaS platform, and separately report completion data to an analytics service
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.