关键在于多源交叉验证：逐层检查crontab、/etc/crontab、/etc/cron.*、systemctl list-timers及shell初始化文件；启动项需覆盖/etc/init.d、systemd服务、/tmp与/dev/shm临时脚本，并结合lsmod、ss和/proc/PID/exe溯源验证。
排查Linux系统中的隐蔽计划任务和恶意启动项，关键不是“找得多”，而是“比得准”——要通过多来源交叉验证，避开被篡改工具的干扰。很多后门任务藏得并不深，只是混在正常配置里，靠人工扫一眼容易漏掉。
计划任务：从用户级到系统级逐层检查
计划任务是持久化最常用的入口，不能只看当前用户 crontab：
- 运行 crontab -l 查当前用户任务，重点留意路径异常（如
/tmp/xxx.sh、/dev/shm/下脚本）、执行频率过高（* * * * *或*/2 * * * *）、命令末尾带&或nohup - 检查系统级任务：cat /etc/crontab 和 ls /etc/cron.*（尤其是
cron.d、cron.hourly），这些目录下可能有非 root 创建的文件 - 查看 systemd 定时器：systemctl list-timers --all，注意状态为
enabled但名称模糊的服务（如update-checker.service、sys-maint.timer），用 systemctl cat 名称 看 ExecStart 是否调用可疑二进制或远程下载命令 - 别忽略用户级 shell 初始化文件：grep -r "curl\|wget\|nohup\|&" ~/.bashrc ~/.profile ~/.bash_profile 2>/dev/null，攻击者常在这里植入一键拉起恶意进程的逻辑
启动项：覆盖 init、systemd 和临时目录伪装
开机自启的载体比想象中更多样，需分层覆盖：
- 传统 SysV 启动项：ls /etc/init.d/，过滤掉明显非官方命名（如
acpid正常，acpi_daemon就可疑）；再用 chkconfig --list（CentOS 6）或 systemctl list-unit-files --type=service | grep enabled（主流发行版）确认实际启用状态 - systemd 服务单元：systemctl list-unit-files --type=service --state=enabled，对每个可疑服务执行 systemctl cat 服务名，检查
ExecStart=路径是否指向/tmp、/dev/shm或 base64 编码命令 - 临时目录伪装启动：find /tmp /dev/shm -type f -name "*.sh" -mtime -7 2>/dev/null，结合 ps auxf 中的进程树，看是否有父进程是
bash但命令行为空或被截断的情况 - 检查内核模块加载行为：lsmod | grep -E "(hide|root|knark|adore)"，若发现异常模块，进一步查 dmesg | tail -30 是否有模块插入日志
验证与溯源：避免误删，也防漏网
找到可疑项后，不能直接删，先确认它是否真在运行、有没有关联行为：
- 对定时任务中提到的脚本，用 cat /path/to/script.sh 查内容，不执行；若内容含
bash -i>&/dev/tcp/、curl -sSL http://、base64 -d等，基本可判定为恶意 - 对启动项对应的服务，用 systemctl status 服务名 看最近启动时间、PID、CGroup 路径；再进 /proc/PID/exe 看是否指向真实文件（若显示
(deleted)，说明原文件已被删但进程仍在跑） - 反查网络行为：ss -tunlp | grep :端口 找监听端口，再用 lsof -i :端口 或直接读 /proc/[pid]/fd/ 下的 socket 链接，确认是否由刚发现的启动项进程持有
- 清理后务必检查是否残留：grep -r "脚本名\|域名\|IP" /etc/cron* /var/spool/cron/ /etc/systemd/system/ 2>/dev/null，防止多个入口点相互备份
不复杂但容易忽略：很多隐蔽任务根本不在标准路径，而是藏在 /etc/cron.d/ 的空格文件名里，或用 @reboot 指令绕过日常检查。动手前先备份原始配置，排查时保持终端干净（不用 alias 过的 ps/top），能少踩一半坑。
