Detect Multi-Stage Channels in Microsoft Sentinel
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/
KQL Detection Query
// T1104 Multi-Stage Channels
// Primary indicator: non-browser process connects to 2+ distinct external IPs
// suggesting first-stage C2 redirection to second-stage infrastructure
let ExcludedProcs = dynamic([
"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"
]);
let MultiStageConns = DeviceNetworkEvents
| where Timestamp > ago(24h)
| where RemoteIPType == "Public"
| where not(InitiatingProcessFileName has_any (ExcludedProcs))
| where InitiatingProcessIntegrityLevel in ("Medium", "High", "System")
| summarize
UniqueRemoteIPs = dcount(RemoteIP),
RemoteIPList = make_set(RemoteIP, 15),
RemotePorts = make_set(RemotePort, 10),
ConnectionCount = count(),
FirstContact = min(Timestamp),
LastContact = max(Timestamp)
by DeviceName,
AccountName = InitiatingProcessAccountName,
ProcessFileName = InitiatingProcessFileName,
ProcessCommandLine = InitiatingProcessCommandLine,
ProcessId = InitiatingProcessId
| where UniqueRemoteIPs >= 2
| extend DurationMinutes = datetime_diff('minute', LastContact, FirstContact)
| extend StrongIndicator = UniqueRemoteIPs >= 3
| project
LastContact, DeviceName, AccountName, ProcessFileName, ProcessCommandLine,
UniqueRemoteIPs, RemoteIPList, RemotePorts, ConnectionCount, DurationMinutes, StrongIndicator
| sort by UniqueRemoteIPs desc, LastContact desc;
// Secondary indicator: parent process connects to one external IP, spawns child that connects to a DIFFERENT external IP
let ParentNetConns = DeviceNetworkEvents
| where Timestamp > ago(24h)
| where RemoteIPType == "Public"
| where not(InitiatingProcessFileName has_any (ExcludedProcs))
| summarize ParentIPSet = make_set(RemoteIP, 10)
by DeviceName, ParentProcId = InitiatingProcessId, ParentFileName = InitiatingProcessFileName;
let ChildHandoff = DeviceNetworkEvents
| where Timestamp > ago(24h)
| where RemoteIPType == "Public"
| where not(InitiatingProcessFileName has_any (ExcludedProcs))
| join kind=inner (ParentNetConns) on DeviceName,
$left.InitiatingProcessParentId == $right.ParentProcId
| where not(set_has_element(ParentIPSet, RemoteIP))
| project
Timestamp, DeviceName,
ChildFileName = InitiatingProcessFileName,
ChildCommandLine = InitiatingProcessCommandLine,
ChildRemoteIP = RemoteIP, ChildRemotePort = RemotePort,
ParentFileName, ParentIPSet
| extend StrongIndicator = true
| sort by Timestamp desc;
union
(MultiStageConns | extend DetectionType = "SingleProcessMultiStageC2"),
(ChildHandoff | extend DetectionType = "ParentChildC2Handoff", AccountName = "",
ProcessFileName = ChildFileName, ProcessCommandLine = ChildCommandLine,
UniqueRemoteIPs = 2, RemoteIPList = ParentIPSet, RemotePorts = dynamic([]),
ConnectionCount = 1, DurationMinutes = 0, LastContact = Timestamp)
| sort by LastContact descDetects multi-stage C2 channels using two complementary signals in Microsoft Defender for Endpoint telemetry. Signal 1 (SingleProcessMultiStageC2): identifies non-browser processes that connect to 2 or more distinct external IPs — a key behavioral fingerprint of staged loaders that contact a first-stage server and are redirected to a second-stage. Browsers, update services, and common collaboration tools are excluded to reduce noise. Signal 2 (ParentChildC2Handoff): correlates parent-child process pairs where the parent connects to one external IP and the child connects to a completely different external IP, indicating a loader-to-RAT handoff pattern used by groups like Lazarus and APT41. Both signals are unioned into a single result set with a DetectionType field and StrongIndicator flag for triage prioritization.
Data Sources
Required Tables
False Positives & Tuning
- Update managers and package tools (e.g., npm, pip, choco) that sequentially contact CDNs and registries during install — these appear as single process connecting to multiple external IPs
- Security agents and EDR tools that phone home to health endpoints and telemetry endpoints at different IP addresses as part of normal heartbeat operations
- Development toolchains that pull dependencies from multiple distinct external hosts (e.g., cargo, go get, Maven) during build operations from developer workstations
- Remote monitoring and management (RMM) agents such as ConnectWise or NinjaRMM that maintain connections to multiple infrastructure IPs for load balancing and failover
- Backup agents (Veeam, Acronis) that contact licensing servers, cloud repositories, and update endpoints sequentially as part of a backup job
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.