What T1104 multi-stage channels let an attacker keep
A SOC lead facing a suspected command and control session often sees beaconing from one host but cannot find the outbound connection that carries the operator's commands. That gap is the signature of multi-stage channels (T1104): the control traffic is split across more than one link, so a foothold on an internal system relays instructions through a second system before they reach the compromised host. MITRE defines the parent tactic, Command and Control (TA0011), as the adversary trying to communicate with compromised systems to control them. T1104 describes one way that communication is arranged, with stages that keep the operator one hop removed from any single connection.
In intrusions, this pattern usually appears where a stager or relay is placed on a system that has legitimate reasons to talk to the internet or to other internal segments, such as a jump host, build server or application node. Defenders rarely see one clean event. They see several linked records: a network connection from the first host to an intermediate system, a second connection onward, and a process on the intermediate system that handles relayed traffic. Correlating these records by time, host and process lineage is what turns a set of unrelated flows into a single suspected channel. Check whether your sensors preserve the process that owned each connection, because without it the links cannot be joined.
Detection logic is tied to the ATT&CK version it targets. Before you build or import rules, confirm the current technique mapping, its sub-techniques and the data components referenced for T1104 in the enterprise-attack 20.0 STIX bundle, and record the version in each rule's metadata. Techniques can be renamed, deprecated or revoked between releases, so a rule written against an older mapping can silently stop matching. Use the MITRE ATT&CK tactic page for Command and Control as the starting reference for scope, then verify the technique entry directly in the bundle.
Which telemetry reveals T1104 on Linux, macOS, Windows and ESXi
This table compares the four data components most useful for spotting T1104 Multi-Stage Channels, with the signal to look for, the platforms where each applies, and an open-source collector to start with. Read each row as a source of evidence, then confirm platform applicability against the ATT&CK data for the version you target. The main takeaway is that no single component covers the technique, so pair host-side process and connection telemetry with network flow and content visibility.
| Data component | Signal to look for | Platforms and open-source collector |
|---|---|---|
| Network Connection Creation (DC0082) | Long-lived outbound sessions from a process that does not normally talk to the internet, followed by new sessions from a different process to the same destination after the first stage runs. | Linux, macOS, Windows, ESXi where host telemetry exists. Collect with the Wazuh agent or Velociraptor. Confirm ESXi coverage with your own build. |
| Process Creation (DC0032) | A process started by an earlier stage that then spawns a second process which opens its own channel, showing a staged chain of parent and child relationships. | Linux, macOS, Windows. Collect with the Wazuh agent (auditd, Sysmon-equivalent event feeds) or Velociraptor artifacts. Confirm ESXi process visibility before relying on it. |
| Network Traffic Flow (DC0078) | Flow records showing a single internal host with several outbound channels that open in sequence, carry small periodic exchanges and change destination after an initial callback. | Platform-independent at the network layer. Collect with Zeek connection logs or Security Onion sessions, and Suricata flow records where enabled. |
| Network Traffic Content (DC0085) | Payload-level evidence that the second channel is a separate protocol or encoding carried inside the first, visible only where traffic is decrypted or inspected. | Platform-independent at the network layer, limited for encrypted traffic. Collect with Suricata rules and Zeek protocol analyzers. Confirm inspection points with your architecture team. |
| File Creation (DC0039), context only | Staged payload or configuration files written to disk before a later channel starts, which can support the timeline from the other rows. | Useful on Windows and ESXi hosts for context. Collect with Wazuh file integrity monitoring or Velociraptor. Confirm the file paths your platform exposes. |
How to detect T1104 multi-stage channels with Sigma, Zeek and Wazuh
T1104 Multi-stage channels is hard to catch with a single signature because its traffic looks like ordinary sessions at each hop. The cards below describe detection ideas that combine host telemetry, flow data and network sensors, so that analysts can connect a process, a host and a session over time.
Correlate outbound connections with their process
Link each new outbound connection to the process that opened it, then flag interpreters, script hosts or unsigned binaries that reach external addresses they have never contacted before. For T1104, the first stage often runs under a benign-looking parent, so the question is which child process owns the session. Write the rule in Sigma against Network Connection Creation and Process Creation events, and confirm your Wazuh agents collect both. Tune the allowlist by parent path and destination ASN. Expect false positives from backup agents, monitoring tools and package update services that call home on schedule.
Flag repeated short-interval beacons
Look for outbound sessions from several internal hosts to the same external endpoint, or to a chain of endpoints, at a steady interval with similar byte counts. Zeek connection logs and Suricata flow records give you the timing and volume needed to score regularity. Set the interval band and the minimum number of sessions per window for your environment, and start with a long observation period before alerting. Expect false positives from health checks, NTP, endpoint management and cloud agents, which beacon by design and should be listed by owner rather than silenced globally.
Spot hosts relaying traffic for others
Identify an internal host that receives inbound sessions from one internal address and opens outbound sessions to external destinations at nearly the same time and volume. This pattern suggests the host is passing traffic along a second stage. Build the pairing logic from Zeek connection records joined on time windows, and review hosts that were never designed as proxies. Tune the time window and the byte-ratio tolerance. Expect false positives from load balancers, reverse proxies, VPN concentrators and jump hosts, which relay by design and belong on a documented inventory.
Watch new long-lived sessions after launch
Alert when a process starts and, within a short window, establishes an outbound session that stays open far longer than the application normally needs. Long-lived sessions after a fresh launch are a common sign of a staged channel waiting for tasking. Use Network Traffic Flow durations from Zeek or Suricata, matched against Process Creation events in Wazuh, and compare against a baseline of the same application over several weeks. Confirm the duration threshold with the application owner. Expect false positives from remote support sessions, database replication, message queues and file sync clients that keep sessions open legitimately.
How to validate T1104 multi-stage channel detections before production
This sequence proves that a T1104 detection fires for the behavior it claims to cover, that it stays quiet on normal traffic, and that the evidence is recorded well enough for a second engineer or an auditor to reproduce the result. It turns a rule idea into a tested, versioned detection with known limits.
Pin the ATT&CK version and detection strategy
Start by naming the ATT&CK version the detection targets, for example Enterprise ATT&CK 20.0, and the detection strategy and analytics for T1104 in that version. Confirm the data components the analytics rely on, such as Network Connection Creation, Process Creation and Network Traffic Flow, and check which of them your sensors actually collect on Linux, macOS, Windows and ESXi. Record the version, strategy identifier and the list of required data sources in the detection repository before any testing starts. The step is done when a reviewer can point to the exact ATT&CK release and the telemetry gaps that remain.
Build a controlled emulation plan
Write an emulation plan that describes the communication pattern to be staged in a private lab or cyber range, such as a multi-hop relay between defined test hosts, without writing commands, payloads or evasion steps into the plan. Specify the source and destination hosts, the expected network path, the time window and the people allowed to start and stop the exercise. Agree the expected observable outcome for each data component, so that the result can be scored against it. The step is done when the plan is approved by the owners of the range and the detection engineering lead.
Run the emulation with logging enabled
Run the staged exercise in the range with endpoint, network and sensor logging confirmed as active before the first action. Verify that the Wazuh agents, Zeek, Suricata or Security Onion sensors and any other collectors report healthy status, and capture a clock check so timestamps line up across sources. Keep the exercise log, which records start and end times, the test host names and the operator who ran each stage. The step is done when the raw logs for every stage are stored in the evidence location with a hash or retention record.
Record which data components fired
Review the collected telemetry against the expected outcomes in the plan and note, for each stage, which data components produced events and which stayed silent. Capture the sensor IDs, the event identifiers and the timestamps that link each alert to its stage in the exercise. Mark any stage where the telemetry was present but the rule did not match, and any stage where the telemetry was missing entirely, because these point to different fixes. The step is done when every planned stage has a recorded result of detected, missed or not observable.
Measure false positives on baseline traffic
Run the same rule version against a representative window of normal traffic from the same network segments, ideally captured outside the exercise period, and count the alerts it raises. Group the alerts by source process, destination service and host role so that the causes are visible, for example scheduled jobs, backup tools or monitoring agents. Ask the operations team to confirm which of these are legitimate business activity. The step is done when every false positive has a documented cause and an owner, and the rate is recorded against the baseline window used.
Tune the rule and retest
Adjust the rule logic or its allowlists to remove the causes identified in the baseline review, and record each change as a new rule version with a reason. Rerun the same emulation plan and the same baseline window so that the before and after results can be compared directly. Confirm that tuning did not remove coverage for the planned stages, because a rule that is quiet for the wrong reason is a gap. The step is done when the retest shows the intended detections still firing and the baseline noise reduced, with both results saved.
Document the result in the detection repository
Store the final rule, its version, the ATT&CK version and strategy identifier, the emulation plan, the sensor list, the baseline window and the known limitations in the detection repository. Include the list of stages that were not observable, the data source gaps and the approval record from the range owner and detection lead. Set a review point tied to the next ATT&CK release, since releases can rename, deprecate or revoke techniques. The step is done when another engineer can reproduce the test from the repository alone and the open gaps are assigned to an owner.
Which preventive controls reduce T1104 exposure
Preventive controls cannot stop every multi-stage channel, but they make each stage harder to establish and easier to see. The cards below cover the two ATT&CK mitigations named for this technique, how each one applies in your environment, and the mapping check to run before you rely on them.
Inline blocking at the perimeter
Network Intrusion Prevention (M1031) is the primary control named for T1104 Multi-stage channels. At the perimeter, an inline intrusion prevention system can drop traffic that matches known staging or relay patterns before a second channel forms. Confirm that the sensor can inspect the content it needs to judge, because encrypted sessions limit signature visibility. Check that blocking is enabled in production, since alert-only operation leaves the channel open while still generating records.
East-west and host-level inspection
The same intrusion prevention logic can be applied between internal segments and on hosts, where a compromised system relays traffic to a second internal system before anything leaves the network. Placing inspection on east-west paths, such as between server zones and user networks, exposes relays that a perimeter sensor never sees. Ask the vendor whether the sensor can run on the hosts or segments you intend to cover, including the Linux, macOS and Windows endpoints in your estate. Map these placements to your asset inventory before you count coverage.
Egress policy with traffic filtering
Filter Network Traffic (M1037) is a related control for egress policy. Allowing outbound connections only from defined sources to defined destinations and ports forces a multi-stage channel onto an approved path or causes it to fail. Egress rules are most useful on servers, which rarely need arbitrary outbound access, and on segments that hold sensitive data. Review exceptions on a fixed schedule, because each broad exception gives a staged channel a route out.
Confirm mappings in ATT&CK 20.0
Releases can rename, deprecate or revoke techniques, so record the ATT&CK version alongside each control. The pages in this series target Enterprise ATT&CK 20.0. Check the relationships between T1104, M1031 and M1037 in the STIX bundle for that version, and read the mitigation text for each mapping. A mapping describes a relationship and does not guarantee coverage. Repeat the check when you adopt a newer release and keep the result with your detection engineering records.
How to respond when a T1104 detection fires
Start by deciding whether the alert describes a known benign flow or a multi-stage channel that needs containment. Check the alert against the approved baseline of outbound paths for the host, including scheduled backups, endpoint agent check-ins, patch sources and any relay service your team has documented. Confirm the change history for the host and the owner of the workload. If the flow matches an approved pattern, record why, then tighten the rule so it does not fire again on the same pattern. If it does not match, treat it as suspicious and move to scoping before anything is changed on the host.
Next, establish the chain. Identify the first host that initiated the outbound connection, then the hosts it connected to or received traffic from in the same window, and any internal systems that appear as a second or third stage. Use Network Connection Creation and Network Traffic Flow records to pair source, destination and time, and Process Creation records on each endpoint to tie a connection to the process that made it. Before you isolate anything, capture volatile evidence with Velociraptor or your existing endpoint agent, following your forensic procedure: record the hash of each collected artifact, keep the chain of custody, and avoid rebooting or altering the host. Containment decisions come next. Isolating the first host or blocking the egress path at the firewall or proxy is usually the fastest way to stop further stages, but confirm the business impact with the system owner and log who approved the action. Escalate to the incident commander when the chain reaches a second internal host, when credentials or sensitive data may be involved, or when the destination cannot be explained by the baseline.
Review other hosts for similar linked flows using the same destinations, timing pattern and process names, and record the results in a single timeline that lists each observation, its source, and the time it was recorded in UTC. Keep the timeline factual so it can support a later review by legal, compliance or an independent assessor. Finally, feed the findings back into detection tuning: document which indicators were true positives, which baseline entries were missing, and which rule thresholds produced noise. Each change should name the ATT&CK version the rule targets, and the rule should be retested in your cyber range before it is promoted to production.
How to rehearse T1104 detection and response in a private cyber range
Build the range with a small set of Linux and macOS endpoints enrolled in your open-source monitoring stack, such as Wazuh agents or a Velociraptor deployment, plus one internal server that acts as the stand-in for an external listener. Keep the topology isolated so that every outbound path from the range goes through a controlled gateway. Facilitators describe injects in words only, for example a staged exchange in which one internal host relays communication through a second internal host before any traffic reaches the boundary. Detection should show up as network connection records tied to a specific process, with the process lineage and the destination visible in the same case. Response should produce a ticket that names the affected hosts, the process, the destination and the containment decision, followed by a documented isolation step and a memory or artifact capture.
- Telemetry coverage: Confirm that Network Connection Creation and Process Creation records are collected on every endpoint in the range, and that the agent version is recorded.
- Relay chain logic: Rehearse a case where the first hop is an internal host with no direct external reason to talk to the boundary, and check whether the analyst links the two hops.
- Alert quality: Score whether the alert names both hosts and the process, not just a single destination address.
- Containment: Practice isolating one host while preserving the other, and document the order of steps.
- Evidence handling: Confirm that artifacts are collected before the host is reimaged.
Check that each exercise ends with a written timeline that a second analyst can follow without the facilitator present.
Build the Windows segment with workstations and one member server, all forwarding Sysmon-style process and network events and Windows event logs into the same SIEM used for the Linux and macOS hosts. Keep the range isolated from production directory services and business networks, and use synthetic accounts only. Facilitators plan injects in words, such as a staged exchange where a process on one workstation passes data to a process on a second workstation before the data leaves through the boundary. Good detection links the network connection to the parent process, the user context and the earlier internal hop. Good response covers isolation through endpoint management or the EDR tooling your organization already runs, along with a ticket that records the scope of the internal hops.
- Event forwarding: Verify that process creation and network connection events arrive at the SIEM within the window your runbook expects.
- Cross-host correlation: Check that the analyst can connect an internal connection on one host to a related connection on another host.
- Account context: Rehearse a case where the process runs under a service account, and confirm the alert shows who owned the process.
- Containment choices: Decide in advance whether the team isolates one host or the group, and rehearse that decision.
- Ticket content: Require the ticket to list every host touched by the staged path, not only the first one flagged.
Check that the exercise produces a clear record of which controls fired and which did not.
Build a small ESXi environment in the range with a management network separated from the virtual machine networks, and place a few lab virtual machines behind it. Collect host-side logs and network flow data from the hypervisor management plane into the monitoring stack. Facilitators describe a plan in words: a lab virtual machine sends staged traffic to a management-side service, which then sends a further hop onward. Good detection depends on whether the team sees both the virtual machine-side and hypervisor-side records, and whether it can tell normal management traffic from unexpected relay behavior. Good response includes verifying the hypervisor change record, isolating the affected virtual machine at the network layer, and avoiding disruption to other tenants in the range.
- Log sources: Confirm which hypervisor logs are forwarded, and note any that the team cannot access in the range.
- Management traffic baseline: Establish what normal management traffic looks like before the exercise begins.
- Virtual machine isolation: Practice moving one virtual machine to a quarantine network segment without touching the rest of the range.
- Change verification: Require the analyst to check configuration changes on the host before concluding the activity is malicious.
- Escalation path: Define who on the platform team can approve host-level actions during the exercise.
Check that the team has written down which ESXi telemetry it expects to see, and whether the vendor documentation confirms that each source is available in your version.
Place network sensors such as Zeek and Suricata at the range boundary and on the internal segments between hosts, so that the staged hops are visible as flows and as protocol content where it is available. Facilitators plan injects in words, for example an internal flow that is followed by a boundary flow with a similar pattern and a short gap. Good detection shows the flow records for each hop, the time ordering between them and the internal-to-boundary correlation. Good response includes a Suricata or Zeek rule update tested in the range, a block or drop rule that matches the mitigation Network Intrusion Prevention, and a note on the false positive risk to other traffic in the range. Rule changes should go through the same change record the team uses for production.
- Sensor placement: Confirm that the sensors see both the internal segment and the boundary, so the staged path is not split across blind spots.
- Flow correlation: Rehearse matching internal and boundary flows by time and host, and record how many false matches the analyst reviews.
- Rule testing: Validate any new detection in the range before it reaches production, and record the result.
- Prevention decisions: Decide when the team moves from alerting to blocking, and rehearse that threshold.
- Packet retention: Confirm how long packet or flow data is kept in the range, so the analyst can review the full sequence.
Check that the rule change, its test results and the rollback step are all recorded before the exercise closes.
Common questions about detecting T1104 multi-stage channels
How do I separate T1104 detections from T1071 and T1573 detections?
Treat T1104 as a relay pattern and keep its logic separate from the protocol and encryption detections. T1071 covers what protocol is used at the application layer and T1573 covers whether the channel is encrypted, while T1104 looks for a chain of staged connections where one compromised host passes traffic to another. Tag each alert with its own technique ID so overlapping hits can be counted once, and review shared data sources such as Network Connection Creation together so the same event does not inflate three separate queues. Confirm the exact mapping for your ATT&CK version before you finalize rule tags.
How do I tune T1104 rules so legitimate relay traffic stops firing?
Start by building an inventory of approved relays, such as load balancers, jump hosts, reverse proxies, backup agents and monitoring collectors, and record their source, destination and port pairs. Exclude those pairs by asset owner and change record rather than by broad subnet, so a compromised relay host still produces alerts for unexpected destinations. Review suppressions on a fixed schedule and require a documented reason for each one. Your own baseline from Network Traffic Flow in Wazuh, Zeek or Security Onion will tell you which relays are normal in your environment.
Which ATT&CK data components should I build T1104 coverage on first?
Prioritize Network Connection Creation (DC0082) and Network Traffic Flow (DC0078). Together they show which hosts talk to which, on what ports and in what sequence, which is the core evidence for a multi-hop channel. Process Creation (DC0032) comes next, because it links a network connection to the process that opened it. Network Traffic Content (DC0085) is useful for deeper validation but usually has the highest storage and privacy cost, so add it once the flow-based logic is stable. Check the current data component descriptions in the ATT&CK STIX bundle for the version you target.
How do I handle ESXi visibility gaps when detecting T1104?
Be explicit about what you can and cannot see. ESXi hosts often generate limited process telemetry, so relay behavior may only be visible through the network path around the hypervisor, such as firewall flow logs, virtual switch mirroring or host-level connection records where they are available. Document each gap in your coverage matrix, name the compensating sensor, and mark the technique as partially covered until you verify it. Confirm with your virtualization platform vendor which logs and mirroring options exist in your version before you rely on them.
How do I map T1104 detections to the ATT&CK version my team uses?
Record the ATT&CK version in every rule's metadata, and pin your mapping to that version's Enterprise STIX bundle. MITRE releases new versions periodically, and releases can rename, deprecate or revoke techniques, so a rule tagged to an older technique ID may need review after an update. Check the ATT&CK updates page each time you upgrade your reference data, and keep a changelog that shows which technique IDs, sub-techniques and detection strategies changed. Ask your team to confirm the version used in your coverage reports before quarterly reviews.
How do I know when a T1104 detection has regressed?
A detection has regressed when it stops producing expected results against known test activity or when a log source it depends on silently stops arriving. Run scheduled validation in a private cyber range that replays benign relay scenarios and confirms the alert still fires, and monitor the volume of each data source so a sudden drop is flagged as a health issue. Track the time between the test and the alert, and record every change to the rule or its exclusions. Set an owner for each rule so a failed validation has a clear path to a fix.
How DeployOpen builds T1104 detections and range scenarios
DeployOpen works on T1104 Multi-stage channels as a fixed-scope engagement inside your own infrastructure, agreed in writing before work starts. The work moves from telemetry review to detection content, cyber range rehearsal and documented handover, with ongoing support available as a retainer.
How we scope
- Confirm which platforms are in the written scope, such as Linux, macOS, Windows and ESXi hosts for T1104.
- Inventory existing Network Connection Creation, Process Creation and Network Traffic Flow telemetry and where it is collected today.
- Agree the ATT&CK version the detections will target, recorded in the written scope, since releases can change technique mappings.
How we build
- Write detection logic for multi-hop relay behavior in plain language, then express it as Sigma rules and Wazuh or Security Onion content.
- Map detections to the ATT&CK detection strategies and data components referenced for T1104, noting any gaps in host or network coverage.
- Tune Network Intrusion Prevention rules on Suricata or Zeek sensors for the networks in scope, with documented exclusions for approved relays.
How we hand over
- Deliver a cyber range scenario that replays multi-stage channel traffic in a private range so your team can rehearse detection.
- Provide validation records showing which alerts fired, which did not, and the telemetry each detection depends on.
- Document runbooks for triage and response, mapped to your own escalation path, and train the analysts who will use them.
How we support
- Review detection performance after each agreed period of operation and adjust logic when your network or ATT&CK version changes.
- Retest T1104 detections in the cyber range after upgrades, rule changes or new platform onboarding, under a retainer where agreed.
- Prepare detection and response evidence for your compliance assessors, while the independent auditor or certification body makes the determination.
