不能只盯sudo和shell进程，因现代提权攻击（如cve-2021-4034、cve-2022-0847）常绕过它们，直接触发内核漏洞或滥用capabilities，真实提权动作需通过execve事件链结合cap_setpcap、setuid等系统调用上下文联合分析才能准确定位。
直接查 execve 事件链，配合 cap_setpcap、setuid、setgid 等系统调用上下文，才能定位真实提权动作。单纯 grep /usr/bin/sudo 或 bash 很容易漏掉内核级提权或 capability 绕过。
为什么不能只盯 sudo 和 shell 进程
现代提权攻击（如 CVE-2021-4034、CVE-2022-0847）往往不经过 sudo 或交互式 shell，而是直接触发内核漏洞或滥用文件能力。auditd 日志里可能只看到一个看似普通的 execve 调用，但紧随其后是 cap_setpcap 或 setresuid(0,0,0)——这才是关键信号。
- 普通用户执行
pkexec时，audit log 中execve的euid仍是 1000，但之后立刻出现cap_setpcap+setuid事件，构成完整提权链 - Dirty Pipe 利用中，
execve调用本身权限正常，但后续openat+write对/proc/self/exe的篡改行为会伴随cap_dac_override生效痕迹 -
ausearch -m EXECVE -ui 1000查到的只是“起点”，必须用--start/--end锁定时间窗口，再叠加-m SETUID或-m CAPSET一起查
怎么用 ausearch 抓住提权上下文
单条命令无法覆盖提权全过程，必须组合多个 -m 类型并限定时间范围。auditd 默认不记录所有系统调用，所以得先确认规则已启用：auditctl -s | grep "enabled\|pid" 应显示 enabled=1，且有对应规则加载。
- 查某用户 5 分钟内所有可能提权相关的系统调用：
ausearch -ui $(id -u username) -m EXECVE,SETUID,SETGID,CAPSET -ts recent -te $(date -d '5 minutes ago' +%H:%M:%S) | aureport -f -i - 过滤出真正可疑的 execve：加
-F auid!=uid（表示登录 UID 与实际执行 UID 不一致），再排除已知白名单路径如/usr/bin/sudo、/bin/bash - 重点看
cap_setpcap事件是否出现在非 root 进程上下文中——这几乎 100% 表示能力劫持，ausearch -m CAPSET -sv no可快速筛查失败但尝试过的提权动作
auditd 规则没配对，日志就等于没开
很多环境 auditd 服务开着，但规则只监控了 /etc/shadow 或 sudo 命令，根本捕获不到内核态提权行为。默认规则不记录 cap_* 类系统调用，必须手动加。
- 补全关键系统调用监控：
auditctl -a always,exit -F arch=b64 -S capset,cap_getcap,setuid,setgid,setresuid,setresgid,execve - 避免漏掉 32 位兼容调用（尤其在 x86_64 上运行旧程序时）：
auditctl -a always,exit -F arch=b32 -S capset,setuid,setgid,execve - 路径监控要覆盖符号链接目标：比如监控
/usr/bin/pkexec时，也要确认它不是指向/tmp/hack的软链——用readlink -f /usr/bin/pkexec查真实路径再写-F path=
真正难的是把零散的系统调用串成攻击链。比如一条 execve 后隔了 3 条无关日志，才出现 cap_setpcap，人工很难关联。这时候 aureport -m --key priv_esc（需提前用 -k priv_esc 打标签）比临时拼接更可靠——但前提是规则里已经用 -k 显式标记了高危行为。
