lsof无法识别进程劫持，仅显示合法socket条目；需结合maps内存分析、ps参数比对、tcpdump流量验证及eBPF实时监控交叉确认。
直接用 lsof 查被劫持进程的异常网络连接效果有限，需结合其他工具交叉验证。lsof 本身不区分连接是否由原始进程主动建立，也无法识别进程内存已被注入、控制流已被劫持的情况（例如通过 ptrace、LD_PRELOAD、syscall hook 或 inline hook 实现的反弹 shell）。它只能显示当前文件描述符表里的 socket 条目——而这些条目在劫持后依然“合法存在”，看起来和正常连接无异。
识别“看似正常、实则可疑”的网络连接
重点不是找“陌生端口”，而是找与进程行为不匹配的连接：
- Web 服务器（如 nginx、apache）建立了到外网 IP 的 ESTABLISHED 连接，且目标非 CDN、监控或日志上报地址
- 数据库进程（mysqld、postgres）向外发起连接，而非仅监听本地/内网端口
- 系统守护进程（如 cron、rsyslog、dbus-daemon）建立了 TCP 连接，尤其是到非常规端口（如 4444、5555、8080、9999）
- 连接状态为 ESTABLISHED，但对应进程无网络通信逻辑（可通过 strace -p PID -e trace=connect,sendto,recvfrom 简单验证）
用 lsof 配合关键参数缩小排查范围
避免全量扫描，聚焦高风险维度：
- lsof -iTCP -sTCP:ESTABLISHED -Pn：只看活跃 TCP 连接，禁用端口名解析、主机名解析，输出更干净
- lsof -i @1.2.3.4：检查与特定外网 IP 的所有连接（替换为可疑 IP）
- lsof -i :4444：定位使用可疑端口的进程（常见 Meterpreter、CS 默认端口）
- lsof -p PID -i：对疑似被劫持进程（如一个本不该联网的 /usr/bin/python3 进程）单独检查其 socket
必须联动的辅助手段（lsof 单独无法确认劫持）
仅靠 lsof 无法判断进程是否被注入或接管，需组合验证：
- 检查进程内存映射：用 cat /proc/PID/maps | grep -E "(rwx|rw.x)" 查可执行+可写内存段（典型 shellcode 注入特征）
- 对比进程启动参数与当前行为：运行 ps -o pid,ppid,comm,args -p PID，看命令行是否被篡改（如伪装成 /bin/sh 但实际是恶意 payload）
- 检查动态库加载：运行 cat /proc/PID/maps | awk '{print $6}' | grep '\.so$' | sort -u，确认是否有异常 .so（如 /tmp/libhook.so、/dev/shm/ld.so）
- 抓包比对：用 tcpdump -i any -n host TARGET_IP and port TARGET_PORT -w suspicious.pcap，分析流量内容是否符合该进程协议（如 httpd 发送非 HTTP 流量）
进阶：用 eBPF 工具实时监控异常 socket 行为（推荐）
传统 lsof 是快照式检查，而基于 eBPF 的工具能捕获连接建立源头：
- bpftrace -e 'tracepoint:syscalls:sys_enter_connect { printf("PID %d (%s) connect to %s:%d\n", pid, comm, args->uservaddr->sa_data, args->uservaddr->sa_data[2] * 256 + args->uservaddr->sa_data[3]); }'
- 使用 bcc 工具集中的 opensnoop、tcplife、gethostlatency，观察谁在什么时间点发起连接、是否绕过 glibc（如直接 syscall）
- 若环境支持，部署 Falco 或 Tracee 设置规则：检测 “非白名单进程调用 connect() 到外网” 或 “进程加载非常规路径 .so”
