Detect Socket Filters in Splunk
Adversaries may attach Berkeley Packet Filter (BPF) programs or libpcap-based filters to raw network sockets to create passive backdoors that activate only upon receipt of crafted "magic" packets. Unlike conventional backdoors that maintain open listening ports, socket filter implants remain completely dormant—consuming negligible CPU, maintaining no active connections, and appearing nowhere in netstat or ss output—until a specially crafted packet matching the filter criteria arrives on the monitored interface. Implementation uses either libpcap's pcap_setfilter() function or the POSIX setsockopt() system call with SO_ATTACH_FILTER (cBPF, optname 26) or SO_ATTACH_BPF (eBPF, optname 50). The technique requires CAP_NET_RAW or CAP_NET_ADMIN on Linux, or Administrator rights on Windows with WinPcap/Npcap installed. Confirmed real-world malware families include BPFDoor (attaches BPF filters monitoring ICMP, UDP, and TCP traffic on ports 22/80/443, triggered by a "magic" byte sequence in incoming packets to spawn a reverse shell), Penquin/Turla (installs TCP and UDP filters on the eth0 interface for C2 activation), CASTLETAP (listens for specialized ICMP packets on compromised Fortinet devices), and PITSTOP (evaluates commands on a domain socket at /data/runtime/cockpit/wd.fd using a predefined magic byte sequence). Detection is exceptionally difficult due to the passive nature of the implant: no open ports, minimal CPU overhead, and limited enterprise visibility into raw socket API usage.
MITRE ATT&CK
- Technique
- T1205 Traffic Signaling
- Sub-technique
- T1205.002 Socket Filters
- Canonical reference
- https://attack.mitre.org/techniques/T1205/002/
SPL Detection Query
| comment "T1205.002 — Socket Filters / BPF Passive Backdoor Detection"
| comment "Requires: Splunk Add-on for Unix and Linux (TA-nix) or equivalent providing linux_audit sourcetype"
| comment "Deploy auditd rules: -a always,exit -F arch=b64 -S socket -S setsockopt -k bpf_socket_filter"
index=linux sourcetype=linux_audit type=SYSCALL
| eval is_bpf_attach=if(syscall="54" AND a1="1" AND a2="1a", 1, 0)
| eval is_raw_sock_packet=if(syscall="41" AND a0="11", 1, 0)
| eval is_raw_sock_inet=if(syscall="41" AND a0="2" AND a1="3", 1, 0)
| where is_bpf_attach=1 OR is_raw_sock_packet=1 OR is_raw_sock_inet=1
| eval SignalType=case(
is_bpf_attach=1, "BPF_FILTER_SETSOCKOPT",
is_raw_sock_packet=1, "RAW_SOCKET_AF_PACKET",
is_raw_sock_inet=1, "RAW_SOCKET_INET_RAW",
true(), "UNKNOWN"
)
| eval ThreatLevel=if(is_bpf_attach=1, "High", "Medium")
| eval ProcessExe=exe
| where NOT ProcessExe IN (
"/usr/sbin/tcpdump", "/usr/bin/tcpdump",
"/usr/bin/tshark", "/usr/bin/dumpcap",
"/usr/sbin/dhclient", "/sbin/dhclient", "/usr/bin/dhclient",
"/usr/sbin/arping", "/usr/bin/ping", "/bin/ping",
"/usr/bin/nmap", "/usr/sbin/nmap",
"/usr/bin/hping3", "/usr/sbin/hping3"
)
| eval ProcessComm=comm, AuditUID=auid, HostPID=pid, HostPPID=ppid
| table _time, host, ProcessExe, ProcessComm, AuditUID, HostPID, HostPPID,
SignalType, ThreatLevel, syscall, a0, a1, a2
| sort - _timeDetects BPF socket filter installation and raw socket creation on Linux hosts using auditd SYSCALL records ingested via the Splunk Add-on for Unix and Linux (linux_audit sourcetype). The linux_audit sourcetype auto-extracts key=value pairs from auditd records, making syscall arguments (syscall, a0, a1, a2, exe, comm, auid, pid, ppid) directly queryable as fields. Three signals are evaluated: setsockopt with SO_ATTACH_FILTER (syscall=54, a1=1, a2=1a — the direct BPF filter installation mechanism used by BPFDoor and libpcap), raw socket creation via AF_PACKET (syscall=41, a0=11 — the hex value 0x11=17 for AF_PACKET), and raw socket creation via AF_INET+SOCK_RAW (a0=2, a1=3). All signals allowlist known-legitimate capture binaries. Argument values are in hex as auditd records them on x86-64 systems. Requires auditd rules for syscalls 41 and 54 on monitored Linux hosts.
Data Sources
Required Sourcetypes
False Positives & Tuning
- Network monitoring agents (Datadog, New Relic, Dynatrace) using libpcap internally — will trigger the BPF_FILTER_SETSOCKOPT signal and require allowlisting by exe path
- Zeek, Suricata, Snort IDS/IPS sensors using AF_PACKET raw sockets for traffic capture — high volume on dedicated sensor hosts, allowlist by exe path
- DHCP client daemons (dhclient, systemd-networkd, NetworkManager) opening raw sockets for DHCP packet handling — already allowlisted in the query
- Kubernetes CNI plugins (Cilium eBPF, Weave Net) running as containers with host network access — may appear as unfamiliar exe paths requiring per-environment tuning
- Developer workstations where Python Scapy scripts or custom pcap tools are run interactively from home directories or /tmp
Other platforms for T1205.002
Testing Methodology
Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1AF_PACKET Raw Socket Creation (BPFDoor Initial Socket Setup)
Expected signal: auditd SYSCALL record: type=SYSCALL arch=c000003e syscall=41 success=yes a0=11 a1=3 a2=3 comm="python3" exe="/usr/bin/python3" key="bpf_socket_filter". The a0=11 value (hex for AF_PACKET=17) is the primary indicator. MDE on Linux may generate a DeviceProcessEvents record for the python3 process with the command line containing the socket creation code.
- Test 2BPF Filter Attachment via setsockopt(SO_ATTACH_FILTER)
Expected signal: Two auditd SYSCALL records will be generated: (1) socket() — syscall=41, a0=11, a1=3 with key=bpf_socket_filter; (2) setsockopt() — syscall=54, a1=1 (SOL_SOCKET), a2=1a (SO_ATTACH_FILTER=26=0x1a) with success=yes. Both records will have comm="python3" and exe="/usr/bin/python3". This is the highest-fidelity test of the primary detection signal.
- Test 3BPFDoor Binary Staging from Temporary Directory
Expected signal: auditd SYSCALL record for execve (syscall=59) where exe=/dev/shm/.<random_name>. MDE Linux DeviceProcessEvents record with FolderPath='/dev/shm/' and FileName matching the random name. The random filename pattern (8 hex characters) mimics BPFDoor's naming convention. After deletion, a subsequent ls of /dev/shm would not show the file, but /proc/<pid>/exe would show '<path> (deleted)' if the process were still running.
- Test 4Magic Packet Trigger Simulation via ICMP with Specific Payload
Expected signal: auditd SYSCALL records for socket(AF_INET, SOCK_RAW, IPPROTO_ICMP) and sendto(). Network-level: ICMP packet visible in /proc/net/icmp or packet captures. If a network sensor (Zeek, Suricata) is monitoring the interface, the unusual ICMP payload bytes (0xDEADBEEF pattern) will appear in ICMP logs. MDE Network Events may capture the raw socket creation for the sending process.
References (11)
- https://attack.mitre.org/techniques/T1205/002/
- https://exatrack.com/public/Tricephalic_Hellkeeper.pdf
- https://www.crowdstrike.com/blog/how-to-hunt-for-decisivearchitect-and-justforfun-implant/
- https://www.leonardo.com/documents/20142/10868623/Malware+Technical+Insight+_Turla+%E2%80%9CPenquin_x64%E2%80%9D.pdf
- https://www.mandiant.com/resources/blog/fortinet-malware-ecosystem
- https://www.deepinstinct.com/blog/bpfdoor-an-active-chinese-global-surveillance-tool
- https://www.elastic.co/security-labs/a-peek-behind-the-bpfdoor
- https://blog.aquasec.com/ebpf-vulnerability-bpfdoor
- https://man7.org/linux/man-pages/man7/packet.7.html
- https://man7.org/linux/man-pages/man7/socket.7.html
- http://recursos.aldabaknocking.com/libpcapHakin9LuisMartinGarcia.pdf
Unlock Pro Content
Get the full detection package for T1205.002 including response playbook, investigation guide, and atomic red team tests.