MITRE ATT&CK T1205 Traffic Signaling: Detecting Evasion

A backdoor that never opens a listening port and never beacons out can sit silently on a server or network appliance until one specially crafted packet wakes it up. MITRE ATT&CK tracks this as T1205 Traffic Signaling, listed under Stealth (TA0005), Persistence (TA0003) and Command and Control (TA0011) in ATT&CK v20, with two sub-techniques: T1205.001 Port Knocking and T1205.002 Socket Filters. The Command and Control (C2) Guide places T1205 among C2 resilience techniques; this page goes deeper: how signalling backdoors work on hosts and network devices, the ATT&CK detection strategies for each variant, how to hunt for passive listeners, and how to respond. It is for detection engineers, network security teams and incident responders covering Linux servers, Windows, macOS and edge devices.

Key takeaways

• Silence is the design. A passive backdoor shows no open port to a scan and no outbound traffic until triggered, so port scans and beacon hunting both miss it.
• Hunt the listener, not the packet. The most reliable host signal is a process holding a raw or packet socket, or an attached packet filter, that has no business doing so.
• Correlate three steps. ATT&CK's detection strategies look for an unusual inbound packet or sequence, then a host change, then a connection to or from the same source, within a short window.
• Edge devices are a favoured home. ATT&CK links T1205 to implants on routers, firewalls and VPN appliances, where endpoint tooling is thin.
• Stateful filtering helps, but only partly. ATT&CK's mitigation M1037 Filter Network Traffic says stateful firewalls mitigate some variants, depending on implementation; a filter attached to an already open port is not stopped by them.

How traffic signalling works

ATT&CK describes traffic signalling as the use of a magic value or sequence that must be sent to a system to trigger a special response, such as opening a closed port or running a task. The listener can watch traffic in several ways.

On network devices ATT&CK notes that signalling usually depends on first achieving T1601.001 Patch System Image, and it can enable T1556.004 Network Device Authentication, a hidden login that bypasses normal credentials. On Linux, the socket(7) manual page documents SO_ATTACH_FILTER (classic BPF) and SO_ATTACH_BPF (extended BPF) for attaching filters, and packet(7) states that opening an AF_PACKET socket requires the CAP_NET_RAW capability. That privilege requirement is what makes the listener visible to defenders.

Detection: the ATT&CK v20 strategies

ATT&CK v20 publishes three detection strategies for T1205, each with analytics per platform. The shared logic is a short correlation window, which ATT&CK lists as a tunable value (for example 60 to 300 seconds).

Network device analytics

For routers and switches, ATT&CK's analytics look for one source touching the device's unicast, broadcast and network addresses on the same or stepped ports in a short window, followed by ACL, line or service changes, image or module changes, and a first management session. It suggests focusing on management ports such as 22, 23, 2323, 80, 443, 161 and 4786, with tighter thresholds on internet-facing devices.

Hunting for passive listeners

• Packet socket inventory: list processes that hold raw or AF_PACKET sockets and compare with an allowlist. ATT&CK's examples of expected holders include DHCP clients, keepalived, LLDP and monitoring agents.
• Attached filters: on Linux, look for processes with socket filters or BPF programs that are not part of approved tooling; see the eBPF Security Guide for who can load BPF and how to log it.
• Capture libraries on Windows: WinPcap or Npcap drivers and DLLs loaded by processes other than approved tools.
• Odd process context: a raw socket held by a process with a generic or misleading name, running from a temporary path, or with no package owner.
• Single-packet then outbound: flow data showing one unusual inbound packet (ICMP, UDP or TCP to an uncommon port) followed by an outbound session from the same host to that source.

Prevention and hardening

The steps below are NHI Mgmt Group recommendations, drawn from the ATT&CK mitigations and our own practice.

1. Restrict raw socket privilege. Keep CAP_NET_RAW and root to the services that need it, remove it from containers by default, and review binaries with file capabilities. NIST SP 800-53 AC-6 Least Privilege and CM-7 Least Functionality apply.
2. Filter at the edge and in segments. ATT&CK M1037 Filter Network Traffic: stateful, deny-by-default rules (SC-7(5)) limit which hosts can receive a knock at all. Block inbound ICMP types you do not need to internet-facing systems.
3. Disable Wake-on-LAN where unused, as ATT&CK M1042 Disable or Remove Feature or Program recommends for this technique.
4. Protect device images. On network devices, use image signature verification and secure boot where supported (general ATT&CK mitigations M1045 Code Signing and M1046 Boot Integrity; ATT&CK does not map them to T1205), and compare running images with known-good hashes.
5. Isolate management planes. Management interfaces reachable only from a dedicated network make a knock from the internet useless.
6. Allowlist expected listeners. Maintain the list of processes allowed packet sockets or capture drivers per server role, so anything else stands out.

The international edge device guidance released by CISA and partner agencies in February 2025, including the NCSC-UK "Guidance on digital forensics and protective monitoring specifications for producers of network devices and appliances", sets expectations for the logging that makes network device analytics possible. See the Edge Device Security Guide.

Choosing where to invest

Smaller teams should start with edge devices and internet-facing Linux servers, where ATT&CK's examples cluster. Larger teams with flow data from network detection tools can build the full three-step correlation.

Responding to a signalling backdoor

1. Do not trigger it. Avoid sending test packets that might activate destructive functions. Preserve memory and disk before killing the process where possible.
2. Capture the evidence. Collect the process, its open sockets, attached filters, binary and parent chain. On devices, collect the running image and configuration through the vendor's supported forensic method. See the Edge Device Compromise Investigation Playbook.
3. Scope by the trigger. Use flow records to find which sources sent matching packets and which hosts answered, then sweep the fleet for the same listener.
4. Rotate credentials the host held. Passive backdoors are used for long-term access: rotate service account passwords, SSH keys, API tokens and device local accounts on and reachable from the affected systems.
5. Rebuild, do not clean. Re-image hosts and reload device images from trusted media, then verify integrity.

Where identity fits

Traffic signalling often guards a door that leads to credentials. On network devices, T1556.004 Network Device Authentication gives the attacker a hidden login; on servers, the reverse shell runs as a privileged account with access to stored keys. Treat any confirmed signalling implant as exposure of every machine credential on the host, and track those identities in your NHI inventory so they can be rotated quickly.

Detection and measurement

• Listener allowlist coverage: share of servers where packet socket and capture driver holders are compared against an approved list.
• Raw privilege exposure: number of non-allowlisted processes or containers holding CAP_NET_RAW.
• Device integrity checks: share of network devices with a verified running image in the last 30 days.
• Flow coverage: share of internet-facing segments with flow records retained long enough to correlate a knock with later sessions.
• Time to rotate: hours from confirmed implant to rotation of all credentials on the host.

Framework mapping

Common failure patterns

• Relying on port scans: a passive listener on a closed port, or on an open port used by a legitimate service, does not show up.
• No flow data at the edge: the knock happened, but nothing recorded it.
• Every container gets CAP_NET_RAW: default runtime settings leave raw sockets available everywhere.
• Trusting appliance health checks: a patched device image reports normal status while hosting an implant.
• Cleaning in place: the obvious process is killed, but persistence in the image or startup scripts remains.

Practitioner checklist

• Build an allowlist of processes permitted raw or packet sockets and capture drivers per server role.
• Collect auditd or EDR events for raw socket creation, filter attach and BPF program loads.
• Collect Sysmon 1, 3, 6, 7 and 22 plus Windows Firewall 2004 to 2006 on Windows servers.
• Retain flow records for internet-facing segments and correlate knocks with later sessions.
• Remove CAP_NET_RAW from containers and services that do not need it.
• Verify network device images regularly and isolate management interfaces.
• Disable Wake-on-LAN where it is not used.
• On a confirmed implant, preserve evidence, sweep the fleet, rotate credentials and rebuild.

Standards and references

• MITRE ATT&CK: Traffic Signaling (T1205)
• MITRE ATT&CK: Port Knocking (T1205.001)
• MITRE ATT&CK: Socket Filters (T1205.002)
• MITRE ATT&CK: Filter Network Traffic (M1037)
• Linux man-pages: socket(7)
• Linux man-pages: packet(7)
• NCSC-UK: Guidance on digital forensics and protective monitoring specifications for producers of network devices and appliances (4 February 2025)
• CISA: CISA and Partners Release Guidance on Edge Devices
• MITRE D3FEND: Network Traffic Analysis

Related NHI Mgmt Group resources: Command and Control (C2) Guide · eBPF Security Guide · Edge Device Exploitation by Threat Actors Guide · Edge Device Security Guide