Traffic Signaling (MITRE ATT&CK T1205) is the use of a special value or sequence of network traffic to trigger a hidden action. Adversaries use it to hide open ports or other malicious functionality used for persistence or command and control. MITRE files it under Stealth, Persistence and Command and Control, and lists Linux, Network Devices, Windows and macOS as platforms.
The attraction for an attacker is that a port scan finds nothing. The backdoor listens quietly and only responds to someone who knows the secret.
It has two sub-techniques: port knocking (T1205.001) and socket filters (T1205.002).
How attackers use it
MITRE describes a "magic value or sequence" that has to reach a system before it responds. It may open a closed port or run a malicious task. Typically it is a series of connection attempts to a predefined sequence of closed ports, which is port knocking. It can also involve unusual flags, specific strings or other unique characteristics. After the sequence is complete, opening a port may be done by the host-based firewall or by custom software.
Adversaries may also talk to a port that is already open, where the listening service only reacts if it receives the right magic values.
How does the system see the signal? MITRE names two methods. One, originally implemented by a tool called Cd00r, uses the libpcap libraries to sniff for the packets. The other uses raw sockets, which lets malware use ports that other programs already have open.
Network devices. Adversaries may use crafted packets to enable network device authentication for standard services such as telnet, to open a closed service port, or to change malware modules on the device. They may send packets to open or closed ports and to the router interface, broadcast and network address on the same port. MITRE adds that to do this on embedded devices an adversary must first modify the system image, because of how monolithic these systems are.
Wake-on-LAN. Adversaries may use the Wake-on-LAN feature to power on systems that are off. A magic packet wakes a powered-down machine, which may then become a target for lateral movement.
The MITRE page lists real malware that watches inbound VPN traffic for a magic string instead of beaconing out, that changes a module on a VPN appliance so it activates depending on the user agent in incoming requests, and that starts a reverse shell on a packet with a special string sent to any port.
How to detect it
MITRE's detection strategy has a chain by platform.
Windows, Linux and macOS. A remote host sends a short sequence of failed connection attempts (RST or ICMP unreachable) to closed ports. Within a short window, the endpoint either adds or enables a firewall rule, or a process that sniffs begins listening or opens a new socket, and then a successful connection occurs. On Linux, the rule change shows up in iptables or nftables. On macOS it shows as a PF or socketfilterfw rule update. MITRE also suggests spotting libpcap or raw-socket sniffers that start to watch for secret values, and Wake-on-LAN magic packets on the local segment.
Network devices. Crafted "synful knock" patterns: the same source reaching the device interface, broadcast and network address on the same port in short order, followed by ACL or telnet or SSH enablement or a module change. Watch device image and ACL updates, then a new management session.
What to log in practice:
- Firewall and flow logs showing a burst of denied or reset connections from one source, followed by a success from the same source
- Host firewall rule changes
- New listening sockets and the process that owns them
- Configuration and image changes on network devices, and new management sessions
How to reduce the risk
MITRE's mitigations are short:
- Disable Wake-on-LAN if you do not need it.
- Filter network traffic. Stateful firewalls can mitigate some variants, depending on how the technique is implemented.
Beyond that, the defensive work is mostly about visibility: knowing what should be listening, and noticing when a rule or a socket changes.
Check your own environment
- Is Wake-on-LAN enabled across your fleet, and is it needed?
- Do you know what should be listening on each server, and can you alert on a new listener?
- Do you log host firewall rule changes?
- Are device configuration and image changes on network gear tracked and reviewed?
- Are your firewalls stateful and logging denied traffic?
On Windows, this read-only command lists devices that are allowed to wake the machine:
powercfg /devicequery wake_armed
On Linux, this shows the Wake-on setting of a network interface (replace eth0 with your interface name). A value that includes g means magic packet wake is enabled:
sudo ethtool eth0
To see current listeners on Linux:
sudo ss -tulpn
Quick check
Why is a port scan not enough to find this kind of backdoor?
The port stays closed or the service stays silent until the right signal arrives, so a scan sees nothing to report.
What pattern in logs suggests port knocking?
A short burst of failed connections to closed ports from one source, then a firewall change or a new listener, then a successful connection from the same source.
What does MITRE recommend about Wake-on-LAN?
Disable it if it is not needed in the environment.
