HimitsuShell 这个项目标题很有冲击力它声称能让 Shell 脚本在内核追踪kernel tracing下也完全不可见。对长期使用 strace、ftrace、perf 排查问题的开发者来说这句话既陌生又值得警惕。真正判断它是否成立需要先弄清楚内核跟踪到底能看到什么再理解“看不到”究竟发生在哪一层。这篇文章不教你怎么隐藏自己而是从系统调用、进程执行和内核观测三个层面拆解现象并给出安全人员可以用来发现这类行为的检测思路。1. 先理解内核跟踪到底能看到什么1.1 系统调用是程序与内核之间的规范化通道用户态程序不能直接访问硬件也不能直接修改内核数据结构。唯一正规的入口是系统调用。所谓系统调用就是进程通过 CPU 提供的特定指令把控制权交给内核请求内核完成文件读写、进程创建、网络通信、内存映射等操作。Shell 脚本看起来是文本文件实际执行时由 bash、dash、sh 等解释器逐条解析命令。每条命令最终都会转化为一组系统调用。一个最简单的uname -a在系统调用层至少会经历execve加载/usr/bin/unameopenat、read读取动态链接器或系统库mmap、brk分配内存write把结果写到标准输出close关闭文件描述符exit_group结束进程。只要脚本想完成任何实际工作这些系统调用就一定会发生。也就是说“Shell 脚本执行”和“系统调用”之间存在不可分割的因果关系。即使脚本只是sleep 1也必须通过nanosleep或clock_nanosleep让内核暂停进程。对内核追踪来说系统调用是最重要的观察点。strace、auditd、eBPF、ftrace都围绕系统调用或内核函数事件做文章。理解这一点是一切后续分析的基础。1.2 strace 的跟踪原理ptrace 与系统调用停止strace是典型的用户态跟踪工具。它基于ptrace系统调用工作。ptrace允许一个进程观察和控制另一个进程包括读取寄存器、读取内存、在系统调用入口和出口暂停目标进程。当目标进程执行系统调用时内核会检查它是否被跟踪。如果被跟踪目标进程会进入暂停状态跟踪者通过waitpid拿到事件再通过PTRACE_SYSCALL或PTRACE_GETREGS读取系统调用号和参数。这个机制意味着strace是一个挂在外面的观察者不是内核日志系统目标进程可以感知到自己被跟踪/proc/self/status中的TracerPid字段会显示跟踪者 PID在启用 Yamaptrace_scope的环境中非 root 用户往往无法直接附加到其他进程。正因为strace过度依赖目标进程配合它并不适合作为唯一的安全观测手段。攻击者可以通过检查TracerPid、检测内存中的断点指令、比较系统调用耗时等方式干扰调试器。这些技术统称为反调试但都属于用户态层面的对抗。1.3 ftrace、tracepoint、perf 与 eBPF观测层次不同ftrace是内核自带的跟踪框架它不依赖用户态进程的配合。内核代码中预埋了 tracepoint例如sys_enter_execve、sys_exit_execve系统调用发生时这些 tracepoint 会被触发。即使某个进程设置了反调试逻辑内核 tracepoint 照样执行。perf可以采集系统调用、硬件计数器、内核态调用链。eBPF则允许在内核中运行经过校验的字节码挂载到 tracepoint、kprobe、uprobe 等位置用来统计系统调用、分析网络包、监控进程启动。从观测能力看strace、auditd、tracepoint、eBPF的层次不同可信度也不同观测方式观察点依赖条件能否被普通用户态进程干扰典型工具ptrace/strace系统调用入口和出口yama ptrace_scope、权限可以检测并干扰strace、gdbtracepoint内核代码预埋探针tracefs 挂载、root 或 debugfs 权限可以篡改 tracefs但事件本身仍会触发perf、ftracekprobe/uprobe内核/用户函数动态探针内核配置、rootroot 权限可安装被 hook 后可能失效bpftrace、perfauditd内核审计子系统auditd 服务、rootroot 修改审计规则可能绕过auditctl、ausearcheBPF内核虚拟机执行字节码CAP_BPF、root、内核版本可加载程序也能被内核模块对抗bpftrace、FalcoHypervisor/硬件宿主机或固件侧观测虚拟化平台权限很难被操作系统内进程影响云平台监控、带外管理这个表格透露了一个关键结论越接近内核底层越难被用户态 Shell 脚本轻易干扰越靠近用户态隐藏手段越丰富。所以“对内核追踪不可见”必须说明是“对哪一层追踪不可见”。2. HimitsuShell 的“不可见”可能来自哪一层2.1 “隐藏”不等于“不存在”面对“Shell 脚本对内核追踪不可见”这种说法第一反应应该是区分两个概念事件不存在以及事件存在但观察者看不到。事件不存在意味着进程没有触发系统调用这在实际中几乎不可能。Shell 脚本要创建子进程、读写文件、连接网络每一步都必须通过内核。事件存在但观察者看不到才是这类项目真正可能的手段。具体又分几种情况让跟踪接口抓不到有效信息例如删除 tracefs 文件权限或清空环形缓冲区让跟踪工具解析失败例如动态修改内存中的字符串伪造/proc/pid/cmdline让进程不自称 Shell例如通过exec -a改变 argv[0]把进程名伪装成systemd或nginx让观测框架本身失效例如 root 加载内核模块替换系统调用表或 hook tracepoint。前几种只是障眼法最后一种已经属于 rootkit 行为。一个纯 Shell 脚本如果声称能做到“内核追踪不可见”大概率是组合了多个层级的对抗方式而不是真的让内核事件消失。2.2 用户态隐藏对抗的是观察者而不是内核很多隐藏手段都发生在用户态。一个简单的反调试检测就能让strace看不到后续行为if [ $(awk /TracerPid/{print $2} /proc/self/status) ! 0 ]; then echo traced exit 1 fi这段代码的逻辑是读取/proc/self/status如果TracerPid不是 0说明有 ptrace 跟踪者脚本立即退出。它确实能让 strace 的输出“看起来”少了后续命令但并没有阻止内核事件发生。当追踪者看到脚本退出时前一个execve、openat、read等系统调用早已被内核记录下来。除了反调试常见的用户态隐藏还有使用LD_PRELOAD劫持 libc 函数让常规readdir、getdents看不到文件直接使用syscall指令绕过 libc 封装但这只是绕过了用户态函数系统调用仍然进入内核删除文件后继续运行让/proc/pid/fd中看到deleted状态修改命令行参数让执行器的显示结果与真实行为不一致。这些手段会影响用户态工具的判断但只要将观测点放到内核 tracepoint事件的真实性就不会被改变。2.3 内核态隐藏需要更高权限也更容易留下痕迹如果目标是让ftrace、strace、auditd都看不到仅靠脚本自身是不够的通常需要 root 权限或内核模块。常见的思路包括修改sys_call_table替换系统调用处理函数hook tracepoint 注册流程让新安装的探针无法生效读取并清空内核 ring buffer导致perf、bpftrace丢事件删除或篡改auditd规则使execve事件不被记录修改安全模块回调绕过 seccomp 检查。这些行为都属于恶意软件或 rootkit 的范畴。在公开技术讨论中可以分析其原理但绝不能在生产环境实践也不能在文章中提供可直接利用的代码。对防御者来说这些思路的价值在于提醒我们当系统被 root 权限控制后内核观测框架同样可能失效必须依赖外部日志和硬件层监控。2.4 从标题判断 HimitsuShell 的定位从标题看HimitsuShell 强调“even to kernel tracing”意味着作者把隐藏能力的验证目标从常见strace扩展到了ftrace、perf或同类内核跟踪工具。合理推测这个项目可能结合了进程伪装、无需落盘执行、反调试检测、内核 tracepoint 对抗等多种技术。不过安全社区里宣传“无法被追踪”的项目需要客观看待。大多数测试只在单一环境、特定内核版本、特定权限模型下进行。真实生产环境有多个观测层宿主机监控、云平台审计、网络流量分析、日志采集系统、文件完整性监控。即使一层被欺骗其他层仍可能留下痕迹。因此HimitsuShell 这类项目更值得关注的地方不是“它能不能做到”而是“它揭示了哪些监控盲区”。识别盲区之后防御者才能加固自己的检测体系。3. 从防御者角度看如何还原“不可见”的过程3.1 审计系统auditd 记录关键 execve 事件auditd是 Linux 内核审计子系统和strace完全不同。它不依赖 ptrace也不暂停目标进程而是由内核在系统调用安全点上直接生成审计记录。一个最小规则可以这样添加auditctl -a always,exit -F archb64 -S execve -k exec_trace这条规则表示所有 64 位进程的execve系统调用无论成功还是失败都记录到审计缓冲区并打上exec_trace标签。查看当天的记录ausearch -k exec_trace -ts today输出中能看到的字段包括pid、ppid、exe、cwd、comm、a0等。即使脚本把进程名改成nginxexe字段记录的依然是真实解释器路径例如/usr/bin/bash。需要注意auditd规则本身可以被 root 修改也可以被停止服务。在部署时应把审计日志实时转发到外部 syslog 或对象存储避免本机清理后无据可查。3.2 eBPF 观测从内核事件流中找异常当用户态已经被污染时eBPF 是相对可靠的观测点。执行下面的命令可以打印所有新进程的execvebpftrace -e tracepoint:syscalls:sys_enter_execve { printf(pid%d file%s\n, pid, str(args-filename)); }即使目标脚本检测到strace并退出这个 eBPF 程序仍会输出脚本解释器的启动路径。对于使用memfd_create或从特殊路径执行的情况观察到的file可能是/memfd:shell (deleted)或/tmp/.xxx (deleted)。生产环境中不一定直接跑 bpftrace可以用Falco、Tracee等工具把进程行为规则化。检测点应覆盖新增进程的父进程是否白名单执行路径是否属于常见 Shell是否出现memfd或deleted可执行文件动态加载内核模块的请求。3.3 文件系统和无文件执行的检测无文件执行是“隐藏脚本”常用的途径之一。做法是把 Shell 脚本内容写入内存再通过/dev/fd/N或memfd_create交给解释器执行磁盘上不留普通文件。这时候常规ls /tmp看不到任何异常但/proc文件系统会暴露进程的文件描述符。检查一个进程的所有 fdls -l /proc/pid/fd | grep -E deleted|memfd常见输出lrwx------ 1 root root 64 ... /memfd:script (deleted)也可以扫描系统所有进程find /proc/*/fd -lname *deleted* 2/dev/null | head如果发现异常进程通过memfd或已删除文件运行应立即把进程内存和网络连接保存下来进行分析。3.4 行为监控与异常检测比单点命令更有效的是行为基线。正常服务器上Shell 进程的来源通常有限systemd启动服务、crond 执行定时任务、运维人员通过 SSH 登录、CI/CD 流水线执行脚本。如果发现一个 bash 进程的父进程是 python 进程且命令行带有大量混淆字符串就值得告警。推荐监控规则包括父进程为nginx、java、php等 Web 服务进程时禁止出现子 Shell容器内出现bash、sh、dash进程时对照镜像启动入口进程的argv[0]与真实路径不一致短时间内出现大量短生命周期 Shell 进程Shell 进程主动访问外部地址或读取敏感配置文件。将这些规则转化为 Falco 配置时可以这样写- rule: Unexpected shell from web server desc: Detect shell process spawned from web server process condition: spawned_process and proc.pname in (nginx, apache2, httpd, java) and shell_procs output: Unexpected shell (user%user.name command%proc.cmdline parent%proc.pname) priority: NOTICE这类规则初期可能误报较多需要针对业务镜像做白名单调优。4. 用最小实验理解内核跟踪可见性4.1 准备实验环境建议在虚拟机或一次性容器中做实验不要在重要生产节点上安装调试工具。准备条件如下Ubuntu 22.04 或 24.04内核 5.15 以上已启用CONFIG_FTRACE、CONFIG_BPF_EVENTS安装strace、auditd、bpftrace一个普通用户账号用于运行脚本一个 root 窗口用于查看审计和 eBPF 信息。实验目的不是复现隐蔽技术而是建立“任何脚本执行都会产生内核事件”的直觉。4.2 用 strace 观察普通 Shell 脚本先创建一个测试脚本#!/bin/bash echo before sleep 1 echo after赋予执行权限chmod x sample.sh用 strace 跟踪并截取前 50 行strace -f -e traceexecve,clone,read,write,close ./sample.sh 21 | head -50预期输出类似execve(./sample.sh, [./sample.sh], 0x7ffd...) 0 ... clone3({flagsCLONE_VM|CLONE_VFORK, ...}) 123 ... execve(/usr/bin/echo, [echo, before], 0x...) 0 write(1, before\n, 7) 7 ...这段输出说明两个关键点脚本本身需要execve脚本中的每个命令又是新的execve或新的clone。strace可以抓到全过程但它也能被脚本自己检测到。4.3 用 eBPF/tracepoint 观察同一脚本在另一个终端开启 bpftracebpftrace -e tracepoint:syscalls:sys_enter_execve { printf(pid%d file%s\n, pid, str(args-filename)); }再次运行./sample.sh。bpftrace 至少会输出三条记录pid123 file./sample.sh pid124 file/usr/bin/echo pid125 file/usr/bin/sleep这里能明显看到事件由内核 tracepoint 产生不依赖进程是否接受 ptrace。即使脚本中有反调试代码只要内核没被篡改事件就会记录。4.4 检查 /proc 与审计日志脚本运行期间用ps和cat /proc/pid/status观察进程状态ps -ef | grep sample.sh cat /proc/123/status | grep -E Name|PPid|State再启用 auditd 规则并运行脚本auditctl -a always,exit -F archb64 -S execve -k exp ./sample.sh ausearch -k exp -ts recent审计日志中能看到每个execve的完整上下文包括父进程 PID、执行文件、系统调用结果。这个实验可以证明即使某些工具在特定场景下失效内核审计和 eBPF 依然能还原大部分执行链。5. 检测手段与生产落地清单5.1 工具选择与观测层次速查目标推荐工具适用场景主要限制调试单个程序strace、gdb开发排查容易被反调试全量系统调用审计auditd合规、取证日志量大需要调优内核函数跟踪ftrace、kprobe内核问题定位需要 root可能影响性能事件流监控bpftrace、Falco安全监控依赖内核能力需要维护规则容器运行时安全Falco、Tracee容器逃逸检测部署复杂现场排查/proc、lsof、ss单点确认系统被控后可能不可信5.2 生产环境监控清单对所有关键服务器启用 auditd记录execve、setuid、文件删除、内核模块加载事件将审计日志实时同步到外部系统避免本机日志被清空在集群节点部署 eBPF agent监控新进程、可疑 shell、memfd 执行容器默认启用 seccomp过滤业务不需要的系统调用为常见 cron、CI/CD、配置管理工具建立命令白名单告警必须包含时间、节点、用户、父进程、目标路径、命令哈希对可疑临时文件目录/tmp、/dev/shm、/var/tmp定期扫描对删除文件后仍运行的进程做实时报警。5.3 学习环境建议学习内核跟踪的合理路径是先用strace观察普通命令再用 auditd 查看审计日志用 bpftrace 观察 execve 事件用容器或 namespace 测试隔离环境最后分析一个被删除文件或 memfd 进程的完整链路。每一步都要在隔离虚拟机里操作保持最小权限不为实验引入不必要的内核模块。6. 常见误区与排查路径6.1 误区一strace 没看到就说明内核无异常strace是用户态工具可能被反调试干扰。它的“看不到”只能说明当前观察点失效。应该切换到auditd、bpftrace、/proc文件系统等多种观察点。如果所有点都失效再考虑内核观测框架本身是否被篡改。6.2 误区二能清理 Shell 历史就代表系统是安全的清理.bash_history只是删除了终端历史系统日志、进程账目、文件访问时间、审计日志、Web 访问记录仍然存在。真正的安全事件追踪依赖这些客观记录而不是终端历史。6.3 排查可疑进程的标准步骤当发现一个可疑 Shell 进程时建议按顺序操作。第一步确认进程身份ps -ef | grep -E bash|sh|dash cat /proc/pid/cmdline第二步查看文件描述符和工作目录ls -l /proc/pid/fd readlink /proc/pid/cwd第三步检查网络连接ss -tunap | grep pid第四步查询审计日志ausearch -p pid -ts recent第五步检查相关文件stat /tmp/.xxx lsof -p pid | grep deleted第六步实时跟踪新进程bpftrace -e tracepoint:syscalls:sys_enter_execve { printf(%d %s\n, pid, str(args-filename)); }如果进程已经退出则需要依赖外部日志系统、内存镜像、核心转储文件进行分析。6.4 什么时候需要内核模块和内存取证出现以下信号时用户态工具已经不可信lsmod看不到可疑内核模块但系统调用行为异常tracefs 文件权限被异常修改auditd 规则被批量删除bpftrace 无法加载程序或输出被截断/proc 下的 PID 数量与系统线程数量不匹配。这时应立即视为安全事件先记录现场导出内存、备份日志、断开可疑主机网络再通过只读介质分析。不要在目标机器上反复安装新工具安装过程本身可能被覆盖和篡改。7. 最佳实践与扩展方向7.1 对开发者不要为了演示而引入反追踪设计有些项目为了展示技术能力会把“反追踪”“反调试”写进主功能。但在真实业务中主动隐藏自己往往意味着灾难排障时无法用通用工具定位问题安全审计无法信任程序行为杀毒软件更容易把程序标记为可疑一旦误判整个服务可能被隔离。正确的做法是程序行为透明权限最小化异常可观测。需要防护时使用标准的安全机制而不是制造一个黑盒。7.2 对安全研究人员优先发布检测能力而不是触发样本面对 HimitsuShell 这类项目有价值的技术输出是行为指纹和检测规则而不是可复制的反追踪代码。可以发布的成果包括异常进程的 argv 特征/proc/pid/fd中 memfd 或 deleted 的扫描规则auditd 规则和 eBPF 程序Falco 行为规则进程父子关系异常检测模型。不建议在公开博客中直接提供可运行的隐藏代码。这类代码一旦落入攻击者手中会显著提高防护成本。对原理的讨论可以在授权实验环境中进行。7.3 对运维和平台安全纵深防御比单点隐藏更可靠为生产系统开启auditd并将日志发送到外部日志系统容器默认只读文件系统去掉不必要的 capabilities使用 seccomp 限制系统调用对 bash、sh 等解释器进程做行为监控对动态加载 eBPF 程序的能力做收敛只允许安全 agent 使用建立应急响应手册发现异常 shell 时先断网采集内存再用只读介质分析。单点防御容易被绕过多层的日志和审计才能让攻击者留下足够多的证据。7.4 学习路径这套知识体系可以按顺序深入Linux 系统调用man syscalls、straceptrace 与调试gdb、/proc/PID/statustracefs 与 ftrace/sys/kernel/tracing目录结构eBPF 基础bpftrace、libbpf、可观测性内核安全LSM、seccomp、Capabilities、Audit取证基础进程内存分析、审计日志分析、日志聚合。回到标题Shell 脚本能不能真的对内核跟踪不可见从系统调用层看不能从观察者层看也许可以干扰特定工具。真正值得投入的不是寻找绝对隐藏而是在多层观察点下快速发现异常并保留证据。理解 HimitsuShell 这类概念的真正价值不在于拿到一个“隐形脚本”而在于补齐防御盲区让安全体系在攻击者自以为隐藏时仍然能够还原真相。
