系统时间被恶意篡改后如何通过 last / wtmp / utmp 找入侵痕迹

last输出时间混乱主因是wtmp被篡改或系统时间跳变；应通过stat与last对比mtime、用w/ps/loginctl交叉验证活跃会话、以lastb和journalctl获取可信时间线索。

last 命令输出时间混乱？先确认 wtmp 文件是否被篡改

系统时间被恶意回拨或跳变后，last 显示的登录时间会严重失真——比如显示“Thu Jan 1 00:00:00 1970”或大量集中在某一天。这不是 last 本身出错，而是它读取的 /var/log/wtmp 中的时间戳已被写入错误值（攻击者常配合修改系统时间+清空/覆盖 wtmp 来干扰审计）。
关键判断点：对比 wtmp 文件的磁盘修改时间与其中记录的最后登录时间：

• stat /var/log/wtmp 查看文件实际 mtime（最后一次被写入的时间）
• last -n 1 看最新一条记录的时间
• 若 mtime 比 last 显示的“最新登录时间”还早数小时甚至数天，说明 wtmp 很可能被重写过（例如用伪造的 wtmp 替换）

绕过时间戳，用 utmp + 进程状态交叉验证活跃会话

w 命令依赖 /var/run/utmp，而该文件只记录当前在线用户，不存历史、也不受系统时间回拨影响（内核写入的是单调递增的 boot-time 时间戳，非 wall-clock）。即使时间被篡改，只要会话未退出，w 仍能反映真实在线状态。
但注意：攻击者用 ssh user@host /bin/bash 这类非交互式登录，不会写入 utmp，因此 w 里看不到——这正是隐蔽后门的常见手法。
实操建议：

• 运行 w 和 ps aux | grep "sshd:" | grep -v "sshd:" 对比：若存在 sshd: 进程但 w 无对应用户，极可能为 no-tty 会话
• 检查 lsof -i :22 -sTCP:ESTABLISHED，看连接对应的 PID 是否在 ps 中显示为 notty 或缺少 TTY 字段
• loginctl list-sessions（systemd 系统）可补全 utmp 缺失项，它基于内核 session ID，更难被绕过

btmp + lastb 是唯一不受系统时间欺骗的失败登录证据

/var/log/btmp 记录所有失败登录尝试，它的写入由 PAM 模块触发，且**不依赖系统 wall-clock 时间**——内核使用 CLOCK_MONOTONIC 或 boot-time 偏移写入时间字段。即使攻击者把系统时间调回 1970 年，lastb 输出的时间戳依然可信（表现为自启动以来的秒数偏移，lastb -i 可强制解析为相对时间）。
这是时间篡改场景下最硬的入侵线索：

QIMI奇觅

美图推出的游戏行业广告AI制作与投放一体化平台

下载

• lastb -n 20 快速查看最近 20 次失败登录，重点关注 invalid user 或高频 IP
• lastb | awk '{print $3}' | sort | uniq -c | sort -nr | head -5 统计撞库源 IP
• 若 btmp 大小为 0 或被删，ls -la /var/log/btmp* 查看是否有备份（如 btmp-20260128），攻击者常忽略轮转日志

当 wtmp 不可靠时，用 journalctl 回溯认证事件原始时间

现代 Linux 发行版（RHEL 8+/Ubuntu 20.04+）的 SSH 登录事件同时写入 journald 和 /var/log/secure。journal 日志使用独立的 monotonic 时间戳，不受系统时间修改影响，且带纳秒精度。
直接查原始认证动作，比依赖 wtmp 更可靠：

• journalctl _COMM=sshd -S "2026-01-28 00:00:00" --no-hostname -o short-iso | grep -E "(Accepted|Failed)"（-S 指定起始时间，journald 自动按真实写入顺序返回）
• 若 journal 被清空，检查 /var/log/secure 文件本身的 stat 修改时间，再用 sed -n '/Jan 28.*sshd/p' /var/log/secure 手动按日期字符串提取（攻击者很难批量替换日志中的时间字符串）
• 注意：journalctl --since "2 hours ago" 这类相对时间语法会受系统时间影响，必须用绝对 ISO 时间格式