cron 执行历史能证明什么
计划任务是否真的跑过、以哪个用户跑，都会留下执行记录：RHEL 系在 /var/log/cron，Debian 系混在 /var/log/syslog 的 CRON 行里，systemd 系统还可以用 journalctl -u cron 查。把执行记录与 crontab 内容对照，能发现最典型的一类攻击痕迹——「跑过但没有对应配置」，因为攻击者的计划任务常常执行一次就删掉。
基本信息
| 记录位置 | /var/log/cron、/var/log/syslog、journalctl -u cron |
|---|---|
| 关键内容 | CMD 行含实际命令与执行用户 |
| 配置对照 | crontab -l、/etc/cron.d/、/var/spool/cron/ |
| 异常特征 | 有执行记录但配置中找不到对应行 |
| 时间窗要求 | 记录必须覆盖完整排查区间 |
| 轮转归档 | logrotate 会切走老记录，注意 .1 与 .gz 文件 |
典型使用场景
- 寻找「执行过但配置已被删除」的攻击痕迹
- 确认某个计划任务是否真的运行、运行了多久
- 排查非工作时间以 root 身份执行的命令
- 与 /var/spool/cron 下各用户的任务清单逐一对账
- 把 cron 执行记录并入统一时间线做事件还原
- 处置后验证恶意计划任务不再触发
- 老系统迁移前梳理现存任务，避免把攻击者留下的任务一起带过去
查执行记录与配置
查执行记录与配置
journalctl -u cron --since "today" --no-pager | tail -n 40 # systemd 系统的 cron 记录
grep -h 'CRON' /var/log/syslog 2>/dev/null | tail -n 30 # Debian 系
grep -h 'CMD' /var/log/cron 2>/dev/null | tail -n 30 # RHEL 系
sudo ls -la /var/spool/cron/ /var/spool/cron/crontabs/ 2>/dev/null # 各用户的 crontab
sudo crontab -l -u www-data 2>/dev/null # 指定用户的任务清单
zgrep -h 'CMD' /var/log/cron*.gz 2>/dev/null | tail -n 20 # 轮转归档里的记录记录字段读法
| 字段 | 含义 | 判读要点 |
|---|---|---|
| 时间戳 | 任务触发时刻 | 与事件时间线对齐分析 |
| 用户名 | 以哪个账号执行 | root 与 Web 账号的非常规任务最可疑 |
| CMD | 实际执行的命令行 | 出现下载、base64、写入临时目录需重点看 |
| 来源路径 | 对应的 crontab 文件 | 找不到来源即属异常 |
| 执行间隔 | 触发频率 | 高频任务要核实必要性 |
各发行版记录位置不同：RHEL 系在 /var/log/cron，Debian 系混在 syslog，systemd 系统优先用 journalctl -u cron，并确认 journal 已配置持久化，否则重启后记录消失。
攻击者的 cron 常「跑一次就删」：执行历史是抓现行与取证的关键，必须先保全日志再清理配置，顺序颠倒就等于丢证据。
除了 CMD 行本身，还要看同一时刻前后是否有会话登录与网络连接记录：三者时间吻合，才能说明这条任务确实是被攻击者执行的，而不是遗留的运维脚本。