How T1205 traffic signaling hides a backdoor in normal network traffic
T1205 Traffic signaling lets an adversary keep a backdoor closed to ordinary scanning and open it only when it receives a specific pattern of network traffic. Under the Stealth tactic (TA0005), this means the service may never appear in a normal port scan, and the attacker's activity looks like routine traffic. A SOC lead who finds a listener that answers only unusual traffic should treat it as a possible T1205 case until proven otherwise. The MITRE ATT&CK tactic page for Stealth defines the goal as hiding and concealing actions so they appear as normal behavior.
ATT&CK lists two sub-techniques: Port Knocking (T1205.001), where a sequence of connection attempts to closed ports signals the host to open a service, and Socket Filters (T1205.002), where a packet filter attached to a socket watches for a trigger inside incoming traffic before it responds. Both are common in intrusions where an attacker wants persistent access to an edge device, a Linux server or a network device that is not patched or monitored closely. Because the trigger traffic can resemble ordinary connections, the signal is often found in network telemetry and host configuration rather than in process alerts alone.
Start by confirming which ATT&CK version your detection content targets. This page uses Enterprise ATT&CK version 20.0, released by MITRE on October 13, 2026. Record that version in every detection mapping, because releases can rename, deprecate or revoke techniques. Then ask your team to inventory every listening service on in-scope hosts and devices, confirm which ones were deliberately configured, and identify who owns each change. Any listener without an owner or a change record is the first item to investigate.
Telemetry sources that reveal traffic signaling on each platform
This table maps Process Creation, Command Execution and Network Connection Creation to the signal each reveals for T1205 Traffic Signaling on Linux, macOS, network devices and Windows, with the open-source collector that typically gathers it. Read each row as a starting point: the signal only becomes useful once the reader confirms that the collector is deployed, logging the right events and retained long enough to investigate.
| Telemetry source | Signal to look for | Collector to confirm |
|---|---|---|
| Process Creation (DC0032) on Linux | Unexpected listening or packet-handling processes started by non-standard parents, especially those tied to firewall or port-knocking style rules | Wazuh agent with auditd or process monitoring enabled; Velociraptor for hunting |
| Command Execution (DC0064) on Linux | Command lines that alter firewall rules or open listeners outside change windows, which can indicate traffic signaling setup | Wazuh command monitoring; confirm the audit rules that capture command arguments on each host |
| Process Creation (DC0032) on macOS | Unsigned or unfamiliar binaries launched from user directories that establish listening sockets | Wazuh agent for macOS where supported; Velociraptor artifacts; confirm endpoint logging coverage with the vendor |
| Command Execution (DC0064) on macOS | Firewall configuration changes or packet filter edits run from non-administrative sessions | Wazuh or Velociraptor collection; confirm which unified log events your macOS versions expose |
| Network Connection Creation (DC0082) on network devices | Inbound connections to unusual ports on devices that normally carry only management traffic | Zeek or Suricata sensors on mirrored or tapped segments; device syslog forwarded to Wazuh |
| Network Connection Creation (DC0082) on Windows | Listening sockets created by processes that do not normally accept inbound connections | Sysmon-equivalent endpoint logging forwarded to Wazuh; Velociraptor for live socket inventory |
| Process Creation (DC0032) on Windows | Processes that open listeners or change host firewall rules without a matching change record | Sysmon-equivalent process logging forwarded to Wazuh; confirm event IDs collected and retention period |
| Command Execution (DC0064) on Windows | Firewall rule additions, port proxy or netsh-style configuration changes issued outside approved administration | Sysmon-equivalent and PowerShell logging forwarded to Wazuh; confirm script block logging is enabled |
Detection logic for traffic signaling that avoids false positives
T1205 Traffic Signaling hides a listener behind inbound traffic that looks like nothing. The detections below combine process, service, and network telemetry so that a single event never drives an alert on its own. Each card names the logic, what to tune, and the benign activity that will trip it if you do not account for it first.
Unexpected listener activated by inbound pattern
Alert when a process or service begins listening on a port that is not in the host's approved baseline, and the listener starts within a short window after inbound connection attempts to closed ports. Tune the window and the port baseline per host role, since a server that normally accepts many connections will produce more noise. Expect false positives from port-knocking admin access that operations teams have documented, and from monitoring agents that open ports on demand. Keep an allowlist keyed on the binary path, the signed owner, and the change ticket, not on the port alone. Confirm each allowlist entry against a named owner before tuning.
Service start correlated with connections
Correlate Process Creation events for service starts with Network Connection Creation events on the same host within a defined time window. The signal is a service that starts shortly after an inbound connection from an unfamiliar source, then exits or goes quiet soon after. Tune the correlation window and the source address list, because scheduled jobs, backup agents, and configuration management runs can produce the same sequence. Suppress known maintenance windows and host groups that run scheduled restarts. Record the parent process and the account that started the service so analysts can separate administrative activity from unexpected activity.
Network device configuration changes
Alert on configuration changes on network devices that add access control entries, enable a management service, or alter the handling of traffic to a specific port, especially when the change is made outside a change window. Compare the running configuration against a stored baseline on a fixed schedule and on each change event. Tune by change category rather than by raw diff volume, since routine rule updates generate frequent changes. Common false positives include approved firmware upgrades, vendor-managed templates, and emergency changes that are recorded late. Require that each alert link to a change ticket before closing it.
Baseline and allowlist governance
Detection quality depends on a maintained inventory of listening ports, services, and device configurations for each system. Assign an owner for each baseline and review it on a regular schedule, and after any change to the platform. Without that ownership, allowlists grow until they hide the activity they were meant to flag. Document each exception with a reason, an expiry date, and the approver. Ask your team to show how exceptions are removed when the underlying need ends, and check that the review is recorded.
Validate with benign look-alikes
Before relying on these detections, run benign look-alike activity in a private cyber range: a documented knock-based admin session, a monitoring agent that opens a port on demand, and a scheduled restart. Measure how many of these trigger each rule and adjust thresholds until the benign cases are handled by allowlists rather than by suppression. Keep the test cases and results as evidence for detection engineering reviews. Verify that the telemetry these rules need is actually collected on each platform, since missing Network Connection Creation data will make the correlation silent rather than accurate.
How to validate that the T1205 detections fire
This sequence tests whether the T1205 detections fire on each in-scope platform, with every run tied to the ATT&CK version under test. It produces an evidence pack that shows which expected events reached the SIEM, how long alerting took and which events were missed.
Define the traffic signaling behavior to simulate
The detection lead writes a short emulation plan that describes the benign traffic signaling behavior to simulate in the lab, covering both T1205 sub-techniques. The plan names each platform in scope, including Linux, macOS, network devices and Windows, and lists the expected telemetry for Process Creation (DC0032), Command Execution (DC0064) and Network Connection Creation (DC0082). It also records the ATT&CK version under test. The step is done when a peer reviewer can read the plan and predict which events should appear on each host.
Confirm the lab matches production logging
The platform team confirms that the private cyber range runs the same agent, audit and network sensor configuration as the environment the detections will protect. On Linux and macOS hosts, process execution auditing and command capture must be enabled. On Windows, process creation auditing with command line logging must be on, and network devices must send connection logs to the collector. Ask your vendors or platform owners to confirm which fields each source emits, since field names differ between products. The step closes when a test event from each platform arrives in the SIEM with its source timestamp intact.
Run the emulation on each platform
A trained engineer or red team member runs the planned traffic signaling behavior on each in-scope platform, one platform at a time. Each action is logged with its start and end time in a run sheet. Keep activity to the defined sequence so every event can be matched to a planned action later, and avoid unplanned actions on the same hosts during the window. The step is done when the run sheet has a timestamped entry for every planned action and the range operator confirms the run ended cleanly.
Map expected events to collected logs
The analyst compares the run sheet with the events in the SIEM and sorts each expected event under DC0032, DC0064 or DC0082. For each data component, the analyst notes the event source, the matching fields and whether the detection analytic linked to T1205 produced an alert. Where a planned action has no log entry, the analyst records a gap and checks whether the sensor was running, the audit policy was applied and the parser accepted the record. The step closes with a matrix that marks every expected event as found, partial or missing.
Measure time to alert and missed events
The analyst calculates time to alert for each detection by subtracting the run sheet timestamp from the alert timestamp, and records every missed event as a separate finding. Results are recorded per platform so a gap on one operating system does not obscure a pass on another. Compare timing across runs only when they use the same ATT&CK version under test and the same log configuration. Ask your SOC lead to set the alert timing target before the run so results are judged against an agreed standard. The step is done when every detection has a recorded time to alert or a documented miss.
Tie results to the ATT&CK version under test
The detection lead labels the evidence pack with the ATT&CK version the detections target, such as v20 for the pages in this series, along with the STIX bundle used for the mapping. If MITRE later renames, deprecates or revokes a technique or changes its data components, the detections and results are checked against the new version before reuse. The mapping, run sheet, matrix and timing record are stored together under change control. The step closes when a second engineer can reproduce the findings from the evidence pack alone.
Review findings and schedule retests
The security team reviews each gap with the SOC, platform owners and the detection engineer, and assigns every fix a named owner. Fixes can include adjusting audit policy, adding a parser for a missing field or tuning the analytic. Each affected event is retested in the same cyber range after a change, before the item is closed. The step is done when every gap has either a passing retest or a documented risk acceptance signed by the accountable owner.
Preventive controls that limit traffic signaling
Traffic signaling depends on something on the host or device listening for, or accepting, unexpected traffic. The two ATT&CK mitigations, Disable or Remove Feature or Program and Filter Network Traffic, shrink that opportunity at the source. The cards below cover how to find and retire unneeded listeners, and how to limit which traffic reaches them.
Inventory open listeners on hosts
Start by listing every listening socket on Linux, macOS and Windows hosts, with the owning process and the service account it runs under. Compare the list against the approved service catalog for each role. Any listener without a named owner, business purpose or documented change record is a candidate for removal. Review the list on a schedule, because software updates and new agents can reopen ports that were closed earlier. Record the decision for each listener so that auditors and responders can trace why it exists.
Remove unused features on devices
Network devices, appliances and embedded management interfaces often ship with optional services enabled, such as older management protocols, debug functions or unused web interfaces. Disable each feature that the operating role does not require, and remove packages or modules that are installed but idle. Ask each vendor which features are optional, which are enabled by default, and whether disabling one affects health checks, licensing or high availability before you change production configuration.
Default deny inbound on hosts
Host firewalls should deny inbound connections by default and allow only the ports that each service needs, scoped to the source networks that actually use them. On Linux this is usually handled by nftables or iptables policy, and on Windows by Windows Defender Firewall rules tied to specific programs or ports. Review rules after every deployment, since a rule added for troubleshooting often outlives the troubleshooting. Log dropped inbound connections so that new signaling attempts show up in your telemetry.
Filter traffic at network boundaries
Segment firewalls, routers and cloud security groups should permit only the flows that are documented in your architecture. Block unsolicited inbound traffic from untrusted networks to internal hosts, and restrict east-west flows between segments to named services. Confirm with each device vendor which access control features are available, whether denied flows can be logged with enough detail to support investigation, and what performance cost applies when logging is enabled on high-volume rule sets.
Test that filtering holds
Preventive rules drift over time, so validate them. Run authorized scans from approved source networks against a sample of hosts and devices, and compare the open ports with the approved baseline. Treat any unexpected open port as a finding to investigate, not only a configuration fix. Use the results to tune detections, because a listener that was removed should no longer produce signaling events. Keep the baseline under change control so that approved exceptions have an owner and an expiry date.
Triage steps when a traffic signaling alert fires
Start by confirming which process owns the listening socket or outbound flow that raised the alert, because T1205 Traffic signaling is only meaningful once a specific binary, service account and listener are tied to the traffic. On Linux and macOS, your analysts should capture the owning process, its parent, its executable path and the account it runs under, then compare those values against the asset's known-good baseline and change records. On Windows, the same check runs against the owning process and any service it belongs to. Treat an unexplained listener as a suspected intrusion until a named owner or change ticket explains it. Record what you find in the case notes before anyone restarts a service or kills a process, since restarting destroys the evidence you need to judge the alert.
Next, correlate the triggering network flow with the host event that produced it. Pull the Network Connection Creation record and the Process Creation or Command Execution record that share the same local port, process identifier and timestamp window, and confirm that the pairing holds in both your host telemetry and your sensor data. Mismatches matter: a flow with no matching process event, or a process event with no flow, can mean the telemetry gap itself needs investigation. Preserve volatile evidence in parallel, including open sockets, running process lists, loaded modules and memory where your runbook allows, and collect it with a tool your team has validated in the cyber range. Do not rely on a single data source to close the alert.
Then isolate the affected asset according to your containment runbook, which should name who can approve network isolation for each asset class and how isolation is reversed. Isolation should cut the suspicious path while keeping management access for responders. Finally, check network devices for configuration changes made in the same window, including firewall rules, NAT entries, port mappings, access control lists and recent administrative logins, and compare them against the change management system. Confirm with your network team which devices are in scope and how their configuration backups are retrieved, because a traffic signaling change that is only visible on a device can be missed by host-only triage.
Rehearsing T1205 detection in a private cyber range
A Linux and macOS range should mirror a typical server and workstation fleet: two or three hardened Linux hosts built from one image and one macOS workstation, all on an isolated segment. Each host forwards process, command and network telemetry to the SIEM, and host firewall policy sits under change control so that any change is visible. Purple team injects are scheduled, labeled changes that an operator triggers on a designated host, so defenders know the exercise window while analysts still work the event as if it were live.
- Range topology: Hosts run a log agent that forwards audit, process and connection records to a Wazuh manager or an equivalent SIEM, with host identity preserved in every event.
- Purple team injects: A firewall or listener change made outside the change window, followed by inbound contact from an unexpected source, to test whether analysts connect the two events.
- Good detection: Alerts fire on new or modified host firewall rules and on process activity from tools that manage packet filters, attributed to the host and user, and they correlate with network connection records.
- Strong response: Analysts check the change against the change record, isolate the host through a documented playbook, preserve the rule set and process metadata, and decide on rollback with the system owner.
Confirm that agents keep forwarding during the exercise, because correlation fails quietly when a log source drops events.
A network device range needs an edge router or firewall pair, a managed switch, a syslog collector and a sensor that records flows from a mirror port, such as a Zeek or Suricata deployment. Management access should run through an approved administrative path with named accounts, so every configuration change is attributable. Because much of the signal sits in configuration logs and flow records rather than endpoint telemetry, the range must prove that both sources reach the SIEM and share a common time base.
- Range topology: A lab edge device, a switch and a flow sensor on a mirror port, with configuration-change logs and flow records both forwarded to the SIEM and time-synchronized.
- Purple team injects: A configuration change on a lab device through the approved management path, followed by a short series of out-of-pattern sessions from a test source, to see whether analysts link the change to the traffic.
- Good detection: Configuration-change logs name the device, account and time, and flow records show the new session pattern, so a single correlated case is opened for both.
- Strong response: Analysts compare the running configuration with the most recent backup, identify the administrative account used, block the test source upstream, and preserve configuration history for review.
Check that the team can restore a known-good configuration from backup within the exercise, since the response depends on it.
A Windows range should include a domain controller, two member servers and a workstation, with endpoint telemetry from Sysmon or an EDR agent and firewall change logging enabled on every host. Administrative actions should run under named privileged accounts that are monitored, so the exercise tests whether an unexpected change stands out from routine administration. The range also needs a documented change calendar, because many Windows firewall and policy changes look ordinary without it.
- Range topology: A domain controller, two member servers and a workstation, each forwarding process creation, command execution and firewall policy change records to Wazuh or Security Onion.
- Purple team injects: A firewall policy change made with a privileged account outside the change calendar, followed by traffic that matches the new policy, to test whether the change and the traffic are linked.
- Good detection: Process creation records show the management tool that made the change, and firewall policy change records and the subsequent network connection records appear in one correlated case.
- Strong response: Analysts confirm the change with the change calendar, review the privileged account's recent activity, revert the policy through the approved path, and escalate to the identity team if the account is unexpected.
Verify that the detection rules are mapped to the ATT&CK version your team targets, since detection content changes between releases.
Questions SOC leads ask about detecting T1205 traffic signaling
How do I separate legitimate knock-based access from traffic signaling?
Start by building a baseline of which hosts send knock-style connection sequences to which servers, and when. Legitimate knock-based access usually comes from a short list of known administrator hosts, follows documented change windows and ends in an expected authenticated session. Signaling that deserves attention shows sequences from unfamiliar sources, sequences aimed at hosts that normally expose no listener, or a service opening shortly after a sequence with no matching change record. Correlate network connection events with process creation and authentication logs on the target host, and keep an allow list that owners review on a fixed schedule. Confirm with your own administrators which access paths are documented before you suppress any alert.
Which data components should my team prioritize for this technique?
Prioritize Network Connection Creation, Process Creation and Command Execution. Network Connection Creation shows the connection attempts that make up a signal, including source, destination and port patterns. Process Creation and Command Execution show which process or command opened a listener or changed a filter on the host, which is where a signal turns into a state change. On Linux and macOS, focus on process and command records tied to firewall or socket configuration. On Windows, focus on process records tied to filtering or network configuration utilities. Map each data component to the log source you actually collect, and document any gaps before you write detection logic against it.
How do I detect traffic signaling on network devices without endpoint agents?
Rely on network-side telemetry. Forward firewall and router logs, flow records and configuration change logs to your SIEM, and build detections around connection attempts that hit closed ports in a fixed sequence before a permitted port changes state. Configuration audit logs matter here because a filter or access list change is often the observable result. Confirm with each vendor which log fields, flow formats and configuration audit features your device model supports, and whether they can be exported without a licensed add-on. Where a device cannot send logs, document the gap, add compensating monitoring on adjacent hosts and record the risk decision with its owner.
How do I write Sigma rules for traffic signaling?
Write one rule per log source category rather than one rule for every platform. Describe the logic in plain terms: a source address produces a series of connection attempts to closed ports on one host within a short window, followed by a state change on a permitted port. Keep the field names in the rule tied to the log schema your SIEM actually parses, and test the rule against both benign administrator sessions and recorded signaling activity in a lab. Use a Sigma converter for your SIEM backend, then review the converted query by hand. Add the ATT&CK technique and sub-technique tags, and record the ATT&CK version the rule targets in its metadata.
How often should we retest detections after an ATT&CK version change?
Retest whenever a new ATT&CK release touches the technique or its data components, and treat each release date as a review trigger. MITRE published v18 on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026. Releases can rename, deprecate or revoke techniques and change data component mappings, so compare the technique page for your target version against your detection inventory after each release. Retest the affected detections in your cyber range, record the results and update the version reference in each rule. Confirm your internal review cadence with your governance owner, and read the ATT&CK updates page for each release.
Can our own team detect traffic signaling, or do we need a partner?
Your team can build and run these detections in-house if it has log collection, SIEM content ownership and network engineers who understand the devices in scope. A partner is most useful for scoping the work, building the lab, and running a structured rehearsal that tests whether alerts fire and reach an analyst. DeployOpen plans, implements and documents open-source security platforms inside your own infrastructure, and runs security testing and private cyber ranges. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask any provider to define the log sources in scope, who owns the rules afterward and what handover documentation you receive.
What should a cyber range rehearsal of traffic signaling include?
A rehearsal should include an isolated range that mirrors your log sources, a written test plan that describes the expected signaling behavior in words, and defined pass criteria. Run the scenario against a host you control, then check whether the expected events reached the SIEM, whether the detection fired and whether an analyst could triage it with the available context. Include benign administrator activity in the same run, so you can measure false positives as well as misses. Record each result against the ATT&CK version you target, and fix gaps in log collection before you tune thresholds. Keep the range isolated from production and confirm the test scope with your change owner in advance.
Which mitigations reduce exposure to traffic signaling?
The two ATT&CK mitigations most relevant here are Filter Network Traffic and Disable or Remove Feature or Program. Filter Network Traffic means limiting which sources can reach which ports and services, so fewer hosts can take part in a signal. Disable or Remove Feature or Program means removing unneeded filtering or knock-style listeners that no owner can justify. Review both mitigations with each host owner, and record which exposures you accept. Confirm how your firewall and host filtering tools are configured, because the effect of a mitigation depends on the policy actually deployed. Pair these changes with configuration audit logging, so you can see when a filter changes.
How DeployOpen builds T1205 detections and range exercises
DeployOpen approaches T1205 Traffic signaling as a fixed-scope engagement inside the client's own environment, where detection logic is written, tested and documented against the telemetry the client actually collects. Work covers the platform, the detection content and the range rehearsal, with ongoing support available as a retainer.
How we scope
- Agree in writing which operating systems and network devices in scope can produce T1205 telemetry, such as Linux, macOS, Windows and network devices.
- Confirm which data sources feed the SIEM for Process Creation, Command Execution and Network Connection Creation, and where gaps exist.
- Record the ATT&CK version the detections target, including the sub-techniques T1205.001 and T1205.002 covered and any exclusions.
How we build
- Write detection logic in words and as Sigma rules, mapped to the ATT&CK data components referenced for T1205.
- Deploy open-source collection and analytics, such as Wazuh, Zeek, Suricata or Security Onion, to the client's infrastructure with agreed log sources.
- Tune the detections against the client's normal network and administrative traffic to reduce false positives before handover.
How we hand over
- Deliver a validation plan describing which detections were exercised in the private cyber range and what each test showed.
- Document response runbooks for alerts on T1205 activity, including triage steps, evidence to preserve and escalation paths.
- Map detections and mitigations, including Filter Network Traffic and Disable or Remove Feature or Program, to the client's control evidence for their assessors.
How we support
- Review detections when ATT&CK releases rename, deprecate or revoke techniques, and when the client changes its logging stack.
- Repeat range exercises on a schedule agreed with the client to confirm that T1205 detections still fire after platform upgrades.
- Offer ongoing support, upgrades and continuous testing as a retainer, with scope and deliverables agreed in writing.
