Detect Socket Filters in CrowdStrike LogScale
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/
LogScale Detection Query
// T1205.002 — Socket Filters / BPF Passive Backdoor Detection
// Signal 1: BPFDoor staging path execution (ProcessRollup2)
// BPFDoor copies itself to /tmp or /dev/shm, executes from that path, attaches BPF filter, then deletes the original
// This signal is available from standard Falcon sensor telemetry without additional auditd configuration
#event_simpleName = "ProcessRollup2"
| event_platform = "Lin"
| ImageFileName = /^(\/tmp\/|\/dev\/shm\/|\/var\/tmp\/|\/run\/shm\/)/
// Exclude known-legitimate parent processes that routinely spawn from temp paths
| ParentBaseFileName != "bash"
| ParentBaseFileName != "sh"
| ParentBaseFileName != "zsh"
| ParentBaseFileName != "dash"
| ParentBaseFileName != "ksh"
| ParentBaseFileName != "apt"
| ParentBaseFileName != "apt-get"
| ParentBaseFileName != "dpkg"
| ParentBaseFileName != "yum"
| ParentBaseFileName != "dnf"
| ParentBaseFileName != "rpm"
| ParentBaseFileName != "pip"
| ParentBaseFileName != "pip3"
| ParentBaseFileName != "make"
| ParentBaseFileName != "gcc"
| ParentBaseFileName != "cc"
| ParentBaseFileName != "g++"
| ParentBaseFileName != "cargo"
| ParentBaseFileName != "go"
// Exclude script interpreters executing temp files (common in CI pipelines)
| not ImageFileName = /\.(py|sh|rb|pl|js)$/
| groupBy(
[ComputerName, ImageFileName, CommandLine, ParentBaseFileName, UserName, ParentProcessId],
function = count(aid, as=EventCount)
)
| sort(EventCount, order=asc)
// =============================================================================
// Signal 2 (companion query — run separately):
// Processes with anomalous CAP_NET_RAW / CAP_NET_ADMIN usage — Falcon eBPF telemetry
// Requires Falcon sensor 7.x+ with enhanced Linux sensor capabilities enabled
// =============================================================================
//
// #event_simpleName = "ProcessRollup2"
// | event_platform = "Lin"
// | EffectiveCapabilities = /0x(2000|4000|[0-9a-f]*2[0-9a-f]{3})/
// | not ImageFileName = /\/(tcpdump|tshark|dumpcap|dhclient|ping|nmap|hping3|ss|ip|netstat)$/
// | groupBy([ComputerName, ImageFileName, UserName, EffectiveCapabilities], function=count(aid, as=EventCount))
// | sort(EventCount, order=desc)
// =============================================================================
// Signal 3 (companion query — run separately):
// Suspicious network socket activity: process bound to port 0 with no listening state
// (passive socket filters don't appear in ss/netstat but Falcon may capture socket metadata)
// =============================================================================
//
// #event_simpleName = "NetworkConnectIP4"
// | event_platform = "Lin"
// | LocalPort = "0"
// | not ImageFileName = /\/(tcpdump|tshark|dumpcap|dhclient|ping|nmap|hping3)$/
// | groupBy([ComputerName, ImageFileName, UserName, RemoteAddressIP4, RemotePort], function=count(aid, as=C))
// | sort(C, order=desc)CrowdStrike LogScale (Humio CQL) query detecting the BPFDoor staging path execution pattern — the implant copies its binary to world-writable directories (/tmp, /dev/shm, /var/tmp, /run/shm), executes from that path, attaches BPF filters to packet sockets, then unlinks the original. This is the primary behavioural signal available from standard Falcon ProcessRollup2 telemetry without requiring auditd integration. Results are sorted ascending by event count to surface rare/single-occurrence executions (implant deployments) at the top. Companion queries (commented) cover CAP_NET_RAW capability anomalies and socket-level network signals requiring enhanced Falcon sensor configuration.
Data Sources
Required Tables
False Positives & Tuning
- Continuous integration and build systems (GitLab Runner, Jenkins agent, GitHub Actions self-hosted runner) routinely execute compiled test artifacts and post-build scripts from /tmp/ directories; filter by UserName matching known CI service account names (gitlab-runner, jenkins, github-actions) to suppress these at the query level
- Software package post-install scripts executed by dpkg/apt/rpm extract and run helper binaries from /tmp/ during package installation; these are excluded via the ParentBaseFileName filter but novel package manager wrappers or custom automation tools may still trigger — correlate with package installation system logs to verify
- Kubernetes init containers and sidecar injection mechanisms (Istio, Linkerd) may execute bootstrapping binaries from mounted tmpfs volumes that resolve to /tmp/ paths; add Kubernetes node hostnames or pod namespace context to an exception list if running Falcon on k8s worker nodes
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.