Detect Multi-Stage Channels in CrowdStrike LogScale
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/
LogScale Detection Query
// T1104 Multi-Stage Channels — CrowdStrike LogScale (Falcon CQL)
// Primary: non-browser process contacting 2+ distinct external IPs within a 24h window
#event_simpleName = NetworkConnectIP4
| !match(field=ImageFileName, values=["*\\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"], ignoreCase=true)
// Exclude RFC1918, loopback, link-local
| !cidr(RemoteAddressIP4, subnet=["10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16", "127.0.0.0/8", "169.254.0.0/16", "0.0.0.0/32"])
// Aggregate by host and process to find multi-destination connections
| groupBy([ComputerName, UserName, ImageFileName, CommandLine, TargetProcessId], function=[
count() as ConnectionCount,
count(RemoteAddressIP4, distinct=true) as UniqueExternalIPs,
collect(RemoteAddressIP4, limit=15) as IPList,
collect(RemotePort, limit=10) as PortList,
min(@timestamp) as FirstContact,
max(@timestamp) as LastContact
])
| UniqueExternalIPs >= 2
| DurationMins := (LastContact - FirstContact) / 60000
| StrongIndicator := if(UniqueExternalIPs >= 3, "true", "false")
| DetectionType := "SingleProcessMultiStageC2"
| sort(UniqueExternalIPs, order=desc)
| select([LastContact, ComputerName, UserName, ImageFileName, CommandLine, TargetProcessId, UniqueExternalIPs, IPList, PortList, ConnectionCount, DurationMins, StrongIndicator, DetectionType])
// ---
// Parent-child C2 handoff: correlate parent's external IPs with child's external IPs
// First query — collect parent network connections:
// #event_simpleName = NetworkConnectIP4
// | !cidr(RemoteAddressIP4, subnet=["10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16", "127.0.0.0/8"])
// | !match(field=ImageFileName, values=["*\\chrome.exe", "*\\svchost.exe", "*\\MsMpEng.exe"], ignoreCase=true)
// | groupBy([ComputerName, TargetProcessId as ParentPID], function=[collect(RemoteAddressIP4) as ParentIPs])
//
// Second query — collect child network connections and join:
// #event_simpleName = NetworkConnectIP4
// | !cidr(RemoteAddressIP4, subnet=["10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16", "127.0.0.0/8"])
// | join({#event_simpleName=ProcessRollup2 | select([ComputerName, TargetProcessId as ChildPID, ParentProcessId as ParentPID, ImageFileName as ChildImage])},
// field=[ComputerName, TargetProcessId], key=[ComputerName, ChildPID])
// | join(ParentIPQuery, field=[ComputerName, ParentPID], key=[ComputerName, ParentPID])
// | where !in(RemoteAddressIP4, values=ParentIPs)
// | eval DetectionType="ParentChildC2Handoff", StrongIndicator="true"Detects T1104 Multi-Stage Channels using CrowdStrike Falcon telemetry. The primary LogScale CQL query filters NetworkConnectIP4 events to identify non-browser, non-system processes contacting 2 or more distinct external public IPs within the search window, using CIDR exclusions for private address space. Processes are grouped by host, user, and process identity to count unique external IPs and flag strong indicators (3+ IPs). A commented secondary query pattern demonstrates the parent-child C2 handoff detection using ProcessRollup2 events to correlate parent process network connections with child process network connections to different external IPs.
Data Sources
Required Tables
False Positives & Tuning
- CrowdStrike Falcon sensor itself or other EDR agents making connections to multiple cloud telemetry and update endpoints simultaneously from the same sensor process
- Enterprise software with split architecture where an installed client connects to a licensing server for authentication and separately connects to a delivery CDN for content (e.g., Adobe Creative Cloud, Autodesk)
- IT management agents (BigFix, Tanium, ManageEngine) that poll a management server for instructions and separately upload inventory/compliance data to a different endpoint
- Network monitoring agents that actively probe multiple external IPs as part of their normal latency or reachability monitoring functions
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.