Socket Filters (MITRE ATT&CK T1205.002) is a sub-technique of traffic signaling. The adversary attaches a filter to a network socket to watch for a trigger that activates a backdoor used for persistence or command and control. MITRE files it under Stealth, Persistence and Command and Control, and lists Linux, Windows and macOS.
The backdoor does nothing visible until the right packet arrives.
How attackers use it
With elevated permissions, an adversary can use features such as the libpcap library to open sockets and install filters that allow or block certain types of data. The filter can apply to all traffic on a network interface, or on every interface if none is named. When a packet that matches the filter criteria arrives, the host can take additional actions, such as starting a reverse shell.
To connect, the adversary sends a crafted packet to the host that matches the filter. MITRE says adversaries have used socket filters to trigger the installation of implants, to conduct ping backs and to invoke command shells. The communication may also be used together with protocol tunneling.
Filters can be installed on any Unix-like platform with libpcap installed, or on Windows hosts with WinPcap. Adversaries may use libpcap with pcap_setfilter, or the standard library function setsockopt with SO_ATTACH_FILTER options.
MITRE highlights why this is hard to see. The socket connection is not active until the packet arrives. There is little activity on the host, low CPU overhead and limited visibility into raw socket use.
The MITRE page lists a Linux backdoor that attaches a filter with BPF bytecode to view ICMP, UDP or TCP packets on ports 22, 80 and 443, and that parses a packet containing its magic bytes before forking to run the instructions. It also lists malware that listens for a specialized ICMP packet on network devices, and another that installs TCP and UDP filters on the eth0 interface.
How to detect it
MITRE's detection strategy is a chain: socket filter trigger, host raw-socket activity, then a reverse connection.
Windows. A process loads packet capture capability (WinPcap or Npcap, the wpcap or packet DLLs, or raw socket attach) and sets a filter. A crafted inbound packet arrives. Shortly after, the same process that loaded the capture libraries starts an outbound connection, such as a reverse shell, to the origin of the packet.
Linux. A process creates a raw or packet socket and attaches a (e)BPF filter, using setsockopt with SO_ATTACH_FILTER or ATTACH_BPF, or bpf with BPF_PROG_LOAD. Right after a matching inbound packet, the same process binds or connects outward to a remote host.
macOS. A process opens /dev/bpf devices (libpcap) or loads a NetworkExtension filter, and after a crafted inbound packet the same process makes an outbound connection to the trigger origin.
The key idea is the combination: a process with packet capture ability that then makes an outbound connection to the same address that just sent it a packet. On Linux, auditd rules on the bpf and setsockopt system calls, and EDR telemetry for raw socket creation, provide the data.
How to reduce the risk
MITRE lists one mitigation:
- Filter network traffic. Stateful firewalls can mitigate some variants of this technique, depending on how it is implemented.
Since the technique needs elevated permissions to install a filter, controlling who has root or administrator rights, and watching for packet capture libraries on systems that have no reason to use them, narrow the opportunity.
Check your own environment
Read-only checks on Linux. List packet sockets with the owning process (run as root):
sudo ss -0pb
List loaded eBPF programs:
sudo bpftool prog show
Then ask:
- Which processes on this server should hold a packet socket? Typical answers are a DHCP client, a network monitor or a packet capture tool you run on purpose.
- Is anything else on the list, especially a process with an unfamiliar name or path?
- Is WinPcap or Npcap installed on Windows hosts that have no reason to capture traffic?
- Do your servers allow outbound connections to any address, or only to expected ones?
Quick check
Why is this technique hard to spot at runtime?
The socket is passive until a matching packet arrives, so there is little activity, low CPU use and limited visibility into raw socket usage.
Which two ways to install a filter does MITRE name?
libpcap with pcap_setfilter, or the standard library function setsockopt with SO_ATTACH_FILTER options.
