The quiet first callback after an infection is rarely the server the operator will use for hands-on work: it is a gate that decides whether the host deserves a second, louder channel. MITRE ATT&CK T1104 Multi-Stage Channels, a Command and Control (TA0011) technique for Windows, Linux, macOS and ESXi, describes adversaries splitting C2 into stages hosted separately, with no shared infrastructure, used under different conditions or for different functions. Blocking one stage does not reveal the others, and the stage that matters most only appears for chosen victims. This guide covers the recorded procedures, the v20 detection strategy, mitigations and testing. It is for detection engineers, threat hunters and incident responders. For C2 in general, see the Command and Control (C2) Guide.
Key takeaways
- The handover is the detection point. A process that receives data from one destination and then spawns or injects into a process talking to an unrelated destination is the pattern ATT&CK's analytics hunt for.
- Stages share nothing on purpose. Indicators from the first stage rarely lead to the second, so pivot on host behaviour, not just infrastructure.
- Loaders are the common case. Commodity loaders such as Latrodectus and Bazar fetch follow-on payloads that bring their own C2, often for a different operator.
- Network devices are not exempt. Cisco Talos reported Salt Typhoon's JumbledPath sending requests through one chain of jump hosts and returning results through another.
- Scope every finding for the next stage. Blocking the first-stage domain is containment, not eradication; check for second-stage implants, fallback channels and credentials the host held.
What T1104 covers
ATT&CK v20 (technique version 1.1) describes a first-stage server with automated functions such as collecting basic host information, updating tools and uploading files. A second remote access tool may then redirect the host to a second-stage server that is more fully featured, with reverse shell and other interactive features. ATT&CK notes the loader may also have backup first-stage callbacks or fallback channels. The common designs differ in what they give the defender:
| Design | How it works | Defender opportunity |
|---|---|---|
| Loader to backdoor | A small first stage checks in, then downloads and runs a fuller implant with its own C2 | Download followed by new process and new destination; first-stage indicators are well shared by threat intelligence |
| Gatekeeper stage | A first-stage server decides whether to hand the host to the second stage | Long quiet periods followed by a sudden change in destination and traffic volume |
| Split by function | One channel for check-in and upload, others for tasking or for returning data | One process talking to several unrelated hosts, each with a distinct traffic shape |
| Tiered infrastructure | Victim-facing servers relay to hidden upstream servers | Victim-facing tier is visible; upstream is for threat intelligence partners |
| Chained hops on network devices | Requests and results take different paths through compromised devices | Device-to-device sessions and log gaps on network infrastructure |
Related techniques are separate pages: T1008 Fallback Channels covers backup routes when the main channel fails, T1105 Ingress Tool Transfer covers fetching the second-stage tool, and T1090 Proxy covers relaying traffic. See MITRE ATT&CK T1008 Fallback Channels and the T1105 Ingress Tool Transfer Defensive Guide.
How adversaries use it
- Salt Typhoon, JumbledPath: Cisco Talos reported in February 2025 that this Go utility, found in actor-configured Guestshell instances on Cisco Nexus devices, ran packet captures on remote Cisco devices by starting the capture through one set of actor-defined jump hosts and returning the compressed, encrypted result through a different set. That hid the true source and destination and reached devices that were not publicly routable. It also tried to clear logs along the path. Talos found initial access came from valid victim credentials in all but one investigated incident. See the Salt Typhoon telecom intrusions analysis.
- Latrodectus: Proofpoint and Team Cymru reported in April 2024 a loader used by initial access brokers, with victim-facing Tier 1 C2 servers that connected upstream to a Tier 2 server over TCP port 80. The loader can download and run further executables and DLLs, each potentially with its own C2.
- LunarWeb (Turla, medium confidence per ESET): ESET reported in May 2024 that LunarWeb used one C2 URL for first contact and uploading host information, and two other URLs on different servers to fetch commands, while mimicking Windows Update and other legitimate traffic. See the Turla Threat Actor Profile.
- BACKSPACE (APT30): ATT&CK records the malware checking a first-stage server to decide whether to connect to the second stage, which carries out the "louder" interactions.
- MuddyWater: ATT&CK records the group using one C2 to deliver enumeration scripts and monitor web logs, and a different C2 to receive data. See the MuddyWater Threat Actor Profile.
- Others ATT&CK records: the Bazar loader downloading the Bazar backdoor, APT41 using a BEACON backdoor to download a secondary backdoor, Lazarus Group multi-stage malware injecting later stages into separate processes, and UNC3886 malware with separate channels to request and carry out tasks during the RedPenguin campaign against Juniper routers.
What to detect and where
ATT&CK v20 assigns detection strategy DET0228 Detect Multi-Stage Command and Control Channels. Every analytic has the same shape: first outbound contact, something received, then a new or injected process opening a connection to an unrelated destination.
| Analytic | Platform | Behaviour | Data components and log sources ATT&CK lists |
|---|---|---|---|
| AN0637 | Windows | Process contacts first-stage C2, receives payload or commands, then spawns or injects into a second process that connects to an unrelated destination | DC0082 Network Connection Creation (Sysmon Event ID 3 and 22), DC0032 Process Creation (Sysmon Event ID 1) |
| AN0638 | Linux | Script or binary fetches from a staging host, writes to disk or memory, then launches a process that connects to a different IP or host | DC0032 (auditd execve and connect), DC0078 Network Traffic Flow (iptables outbound logging) |
| AN0639 | macOS | Process contacts a staging domain, followed by a reverse shell or remote access tool connecting to an unrelated server | DC0032 (Endpoint Security exec events), DC0078 (unified log TCP and UDP) |
| AN0640 | ESXi | Hypervisor command line or API call to an external staging host, then a connection to a second external IP by a spawned process or scheduled task | DC0078 (hostd command line network calls), DC0032 (cron activity) |
Building the sequence detection
- Join on process lineage and time: correlate a network connection from process A, a file write or memory injection by A, and a new connection from child or target process B within a short window, typically minutes. Sysmon Event ID 8 (CreateRemoteThread) and 10 (ProcessAccess) help with injection on Windows.
- Score destination novelty: the second-stage destination is usually new to the environment, newly registered or low prevalence; weight the alert on that.
- Watch for traffic shape changes: a host that beaconed quietly for days and then starts an interactive, high-volume session to a different destination has likely been promoted. Pair this with the Beaconing and C2 Detection Guide.
- Network devices: follow Talos's advice to monitor authentication, authorisation and command logs, watch syslog and AAA logs for gaps, and profile devices with NetFlow for new ports and peers. Device-to-device sessions that were never part of normal management are the JumbledPath pattern.
- Retrospective hunting: when threat intelligence publishes a first-stage indicator, search back for hosts that reached it, then look at what those hosts did next.
Mitigations
| Control | Source | What it does against T1104 |
|---|---|---|
| M1031 Network Intrusion Prevention | ATT&CK v20 | Signatures for specific malware traffic can block known stages at the network level |
| Egress allowlisting for servers, appliances and hypervisors | NHI Mgmt Group recommendation | A second stage needs a new destination; deny by default where needs are predictable. See M1037 Filter Network Traffic |
| Protective DNS and newly registered domain blocking | NHI Mgmt Group recommendation | Cuts off fresh second-stage infrastructure before it builds reputation |
| Application control on endpoints and servers | NHI Mgmt Group recommendation | Stops the downloaded second-stage binary or DLL from running. See M1038 Execution Prevention |
| Management plane isolation for network devices | Cisco Talos hardening advice | Disable unneeded services such as Guest Shell and HTTP management, restrict management protocols with ACLs, require MFA and central AAA |
| Threat intelligence feeds with loader infrastructure | NHI Mgmt Group recommendation | First-stage infrastructure of common loaders is widely tracked; block and hunt on it |
See M1031 Network Intrusion Prevention for the mitigation in depth.
Where identity fits
The second stage is usually where credentials are stolen and used: interactive operators dump tokens, read configuration files and move on with service accounts. In the Salt Typhoon case the movement between devices relied on credentials, shared secrets and SNMP community strings taken from device configurations and captured traffic. When a host is confirmed to have reached any C2 stage, treat every secret it stored or could read as exposed, rotate service account passwords, API keys and device shared secrets, and review where those identities were used afterwards. See the Salt Typhoon Threat Actor Profile for the identity lessons from network device intrusions.
Responding to a first-stage finding
- Do not stop at the indicator: blocking the first-stage domain or IP is containment; assume a later stage may already be running.
- Isolate and capture: isolate the host through EDR, capture memory and recent network flows before reimaging, so injected stages and their destinations are preserved.
- Find the next destination: look at every process and connection that followed the first-stage contact on that host, and search the estate for other hosts reaching the same new destinations.
- Check for fallbacks: look for backup callbacks and alternative channels configured in the sample or seen in traffic.
- Rotate credentials: rotate secrets the host held or could read, and review their use since first contact.
- Feed it back: add second-stage destinations and behaviours to detections and share them with intelligence partners.
Rolling out the detections
- Collect the data components: process creation and network connection events with process attribution (DC0032, DC0082) from endpoints, servers and ESXi hosts, plus network flow (DC0078) at egress.
- Build the Windows sequence first: AN0637 has the richest telemetry; run it as a scheduled hunt for a month to measure noise from software updaters and installers.
- Allowlist known updaters: exclude signed updaters by publisher and destination, not by process name alone, and review the exclusions quarterly.
- Extend to Linux, macOS and ESXi using the matching analytics, starting with internet-facing servers and hypervisors.
- Add network device monitoring: AAA, command and syslog collection with alerting on log gaps and new device-to-device sessions.
- Roll back safely: keep new analytics in alert-only mode with a review queue before any automated isolation.
How to test
- Staged C2 simulation: in an authorised purple team exercise, use a benign test loader that contacts one controlled server, downloads a second benign binary, and has it connect to a different controlled server. Confirm the sequence analytic fires and links both destinations.
- Injection variant: repeat with the second stage injected into an existing process to test lineage-based correlation.
- Network device exercise: with the network team, open a management session from one lab device to another outside normal paths and confirm AAA and NetFlow monitoring flag it.
- Response drill: hand responders only the first-stage indicator and measure whether they find the second destination.
Decision guidance
- Infrastructure blocking or behaviour detection: blocking known stages is fast and cheap but stage infrastructure changes constantly. Fund behaviour sequence detection where you have process-level telemetry.
- Automated isolation: isolate automatically only when a sequence alert also has a low-prevalence second destination; otherwise route to an analyst.
- Small organisations: EDR with network telemetry, protective DNS and egress filtering for servers cover most loader-to-backdoor chains.
- Large organisations and service providers: add NDR, network device AAA and log-gap monitoring, and retrospective hunting from intelligence feeds.
Measurement
- Sequence coverage: share of hosts, by platform, whose telemetry supports the DET0228 analytics.
- Next-stage discovery rate: share of first-stage findings where responders confirmed or ruled out a second stage.
- Time from first stage to containment: median time from first-stage contact to host isolation.
- Exercise detection: whether simulated staged C2 was detected, and at which stage.
- Network device log health: share of network devices sending AAA, command and syslog data without gaps.
Common failure patterns
- Closing the ticket at the block: blocking the first-stage domain and reimaging nothing, while the second stage keeps working from a different destination.
- Reimaging before capture: losing the memory and flow data that would show where the injected stage was talking.
- Allowlisting updaters by name: excluding any process called an updater, which is where loaders like to hide.
- Ignoring network devices: no AAA or command logging on routers and switches, the gap Salt Typhoon used for years.
- Infrastructure-only intelligence: relying on indicator feeds when stages are designed to share no infrastructure.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATT&CK v20 | T1104, TA0011; related T1008, T1105, T1090, T1071; mitigation M1031; detection strategy DET0228 | Technique, procedures, analytics |
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring, SC-7 Boundary Protection, IR-4 Incident Handling, CA-7 Continuous Monitoring | Monitoring, egress control, scoping and handling incidents |
| NIST CSF 2.0 | DE.CM-01, DE.CM-09, DE.AE-02 | Network and runtime monitoring, event analysis |
The tactic view is in the ATT&CK Command and Control Tactic guide.
Practitioner checklist
- Collect process and network connection telemetry from endpoints, servers and hypervisors.
- Deploy a sequence analytic: first-stage contact, payload received, new process to an unrelated destination.
- Score second-stage destinations for novelty and prevalence.
- Put servers, appliances and hypervisors on allowlisted egress.
- Collect AAA, command and syslog data from network devices and alert on gaps.
- Treat every first-stage finding as a possible second stage: capture memory and flows before reimaging.
- Rotate credentials held by any host that reached C2.
- Test with an authorised staged C2 simulation at least yearly.
Standards and references
- MITRE ATT&CK: T1104 Multi-Stage Channels
- MITRE ATT&CK: M1031 Network Intrusion Prevention
- Cisco Talos: Salt Typhoon analysis of activity on Cisco devices
- Proofpoint and Team Cymru: Latrodectus loader research
- ESET Research: Turla Lunar toolset, LunarWeb and LunarMail backdoors
- NIST: SP 800-53 Rev 5, Security and Privacy Controls for Information Systems and Organizations
Related NHI Mgmt Group resources: Command and Control (C2) Guide, Beaconing and C2 Detection Guide, MITRE ATT&CK T1008 Fallback Channels, T1090 Proxy Defensive Guide, NDR Guide, MITRE ATT&.