最可信的eBPF Rootkit检测方式是交叉验证bpftool prog/map list、dmesg加载日志、/sys/kernel/btf/vmlinux状态、ss/lsof端口归属及bpf_stats_enabled等内核参数，因eBPF可劫持系统调用使用户态工具失真。
直接看bpftool输出是否可信
别信ps、lsmod或云安全中心的“无异常”提示——eBPF Rootkit（比如BPFDoor）不碰内核模块，也不改/proc目录结构，它靠挂载eBPF程序劫持系统调用路径，在用户态工具读取数据前就过滤掉恶意进程。最直接的判断依据是：bpftool prog list和bpftool map list本身是否被污染。
实操建议：
- 从干净环境（如离线Live USB或另一台同版本系统）拷贝静态编译的
bpftool二进制，避免依赖被劫持的glibc或LD_PRELOAD； - 运行
bpftool prog list后，重点检查name字段是否为空、是否含hidden、filter、hook等关键词，以及type是否为lsm、tracing或syscall——这些类型最容易用于隐藏； - 比对
bpftool prog list与bpftool prog list -j（JSON格式）输出：部分变种会篡改人类可读格式，但JSON未做处理，字段缺失或值异常（如owner_pid为0但pid非0）即为可疑； - 若
bpftool命令不存在或报Operation not permitted，先确认kernel.unprivileged_bpf_disabled=0（sysctl kernel.unprivileged_bpf_disabled），再检查/proc/sys/kernel/unprivileged_bpf_disabled是否被篡改。
查/sys/kernel/btf/vmlinux和dmesg里的eBPF加载痕迹
eBPF程序加载必须依赖内核BTF信息，且每次加载都会在内核日志留下记录。攻击者可以伪造bpftool输出，但很难抹净dmesg里由内核自身写入的加载事件，尤其当BTF校验失败或程序attach失败时。
实操建议：
- 执行
dmesg -T | grep -i "bpf\|prog\|verifier"，关注时间戳异常（如凌晨3点出现大量Loaded program）、prog type LSM或tracing字样； - 检查
/sys/kernel/btf/vmlinux是否存在且可读：ls -l /sys/kernel/btf/vmlinux；若文件权限为----------或返回No such file，说明BTF被禁用或内核被定制过，需警惕； - 对比
cat /proc/kallsyms | grep bpf与grep -r "bpf_" /lib/modules/$(uname -r)/build/，若前者导出符号远少于后者源码定义，可能BTF被裁剪，为规避检测做准备； - 运行
strace -e trace=bpf bpftool prog list 2>&1 | grep -E "(bpf|fd=)"，观察系统调用参数中cmd值是否为BPF_PROG_LOAD（0x6）或BPF_OBJ_GET（0xc），确认bpftool是否真的在调用eBPF接口。
用ss + lsof交叉验证监听端口归属
eBPF Rootkit常隐藏反弹Shell或C2通信进程，但TCP连接状态仍存在于内核网络栈中。此时ss -tunlp可能显示PID为空或can't identify protocol，而lsof -i :PORT也查不到进程——这恰恰是eBPF挂钩了socket相关系统调用（如getsockname、getpeername）的典型信号。
实操建议：
- 对每个可疑监听端口（尤其是非标准端口如
31337、54321），运行ss -tunlp | grep :PORT，若PID/Program name列为-或空白，立即标记； - 用
lsof -i :PORT -n -P再试一次，若仍无输出，尝试cat /proc/net/tcp | awk '$2~/:[0-9A-F]{4}/ {print "0x" $2}' | xargs -I{} printf "%d\n" {} 2>/dev/null | grep -q PORT_HEX（手动解析十六进制端口号），绕过用户态工具过滤； - 检查
/proc/net/nf_conntrack中对应连接是否长期ESTABLISHED但无关联进程：eBPF隐藏进程后，连接跟踪表仍正常更新，但conntrack -L无法反查到发起进程； - 若发现端口有连接但无进程，立刻抓包：
tcpdump -i any port PORT -w suspicious.pcap，分析流量特征（如固定UA、base64载荷、心跳包间隔），确认是否C2通信。
检查/proc/sys/kernel/bpf_stats_enabled和perf_event_paranoid
eBPF Rootkit需要启用内核统计和性能事件功能才能稳定驻留。攻击者往往会悄悄开启这些开关，而它们本身不是默认启用项。这个配置项改动极难被常规巡检覆盖，却是eBPF持久化的关键指纹。
实操建议：
- 运行
cat /proc/sys/kernel/bpf_stats_enabled：正常应为0，若为1，说明内核开启了eBPF程序运行时统计，便于Rootkit监控自身行为——但生产环境几乎不需要； - 检查
cat /proc/sys/kernel/perf_event_paranoid：值为-1或0表示允许非特权用户使用perf事件，eBPF程序常借此实现隐蔽trace； - 对比
sysctl -a | grep -E "(bpf|perf)"输出与基线配置（如刚装系统的备份），重点关注net.core.bpf_jit_enable（若为1，JIT编译开启，性能更高但也更难检测）； - 注意：修改这些参数无需root权限（只要
perf_event_paranoid足够低），所以即使你没动过，也不能排除被篡改可能——必须结合dmesg和bpftool综合判断。
真正难搞的不是eBPF本身，而是它能让所有用户态工具“集体失明”。哪怕你把bpftool、ss、lsof全换成静态版，只要没关掉eBPF JIT或没锁定BTF，攻击者就能在下次加载时重新污染。排查时优先保现场：别重启、别删文件、先存dmesg快照和/proc/net/全量内容，再动手。
