文章总结： 本文通过分析SSH暴力破解案例，演示如何利用auth.log和wtmp日志进行取证分析。详细还原了攻击链：从爆破尝试识别、成功登录定位到会话追踪，重点展示了通过last命令解析wtmp获取登录时间戳、计算会话时长279秒的全过程。文章强调时区差异注意事项，并总结日志分析在应急响应中的实用价值。 综合评分： 94 文章分类： 应急响应,取证分析,实战经验,安全意识,WEB安全

Brutus – 从一次 SSH 爆破，看 auth.log 与 wtmp 取证之美

原创

漫路修行 漫路修行

微痕鉴远

2026年6月30日 22:44 广东

在小说阅读器读本章

去阅读

当攻击者通过 SSH 暴力破解进入一台 Confluence 服务器，我们能从系统日志里挖出多少秘密？本文带你用 auth.log 与 wtmp 两件”老兵器”，还原一场真实的入侵链：爆破 → 登录 → 持久化，再到精确计算攻击者的会话时长。

0x00 题目背景

题目只给了我们两份”原料”：

• auth.log：Linux 认证日志，记录 SSH 登录成败、会话创建、命令执行等
• wtmp：二进制登录记录文件，记录用户的登录/登出历史

In this very easy Sherlock, you will familiarize yourself with Unix auth.log and wtmp logs. We’ll explore a scenario where a Confluence server was brute-forced via its SSH service. After gaining access to the server, the attacker performed additional activities, which we can track using auth.log. Although auth.log is primarily used for brute-force analysis, we will delve into the full potential of this artifact in our investigation, including aspects of privilege escalation, persistence, and even some visibility into command execution.

虽然难度标签是”very easy”，但 auth.log 的取证价值远不止”看看爆破”那么简单。它几乎覆盖了入侵生命周期的每一个阶段：提权、持久化，甚至部分命令执行的痕迹，都能在其中找到蛛丝马迹。

下面我们按”攻击时间线”逐层拆解。

0x01 第一步：定位爆破尝试

攻击从哪开始？当然是那一长串的 Failed password。

我们在 auth.log 里搜索失败登录记录：

Failed password.*

可以看到日志里密密麻麻的认证失败记录，配合 MaxStartups throttling（连接节流）的告警，这是一次典型的字典/暴力破解。从 IP 和节奏基本能判定：攻击者使用了自动化脚本，对多个用户名（如 backup、root 等）进行高频尝试。

💡 小贴士：sshd 在并发连接过多时会触发 MaxStartups 限流并主动丢弃连接，日志里那句 exited MaxStartups throttling after ... 往往就是大规模爆破的”指纹”。

0x02 第二步：抓住那次”成功登录”

爆破的终点，是一次成功认证。把搜索条件换成成功登录：

Accepted password for root from

可以看到，攻击者最终以 root 身份成功登录。这也意味着——服务器的大门被踹开了，后续的所有动作都属于”入侵后活动”。

0x03 第三步：找到攻击者的会话编号

Q1： SSH 登录会话在建立时会被分配一个 session number。攻击者从 root 账户登录时被分配的会话编号是多少？

在 auth.log 中搜索新会话的创建记录：

New Session

定位到攻击者这次成功登录对应的记录后，可以读出：

答案：session 37

这个编号在后续追踪中很关键——它会贯穿攻击者整条会话生命周期的日志条目。

0x04 第四步：还原手动登录的时间戳

Q2： 攻击者手动登录服务器、开始实施目标的精确时间戳是什么？

这一问要从 wtmp 文件入手。wtmp 是二进制格式，不能直接 cat，得借助专门的工具解析。这里用到的是经典命令 last。

先科普一下 last 输出的每一列含义（每一列都很关键）：

• 第一列：用户名

• 第二列：终端位置

• pts/*：来自 SSH / Telnet 的远程连接

• tty*：本地直接连接

• 第三列：登录 IP 或内核（0.0 或为空表示本地登录；重启活动会显示内核版本）

• 第四列：登录开始时间

• 第五列：登录结束时间（still logged in 仍在登录；down 直到正常关机；crash 直到强制关机）

• 第六列：持续时长

last 的常用参数也顺手记下：

last [-adRx] [-f 记录文件] [-n 显示列数]    -a   把登录主机名/IP 显示在最后一列    -d   将 IP 反解为主机名    -x   显示系统关机、登录与登出的历史    -f   指定记录文件（默认来自 /var/log/wtmp）

于是我们用以下几条命令解析题目给的 wtmp：

last -a -x -F -f wtmplast -a -d -x -F -f wtmpwho -T -H ./wtmp

从输出可以清晰看到攻击者（65.2.161.68）以 root 登录的那条记录：

root  pts/1  Wed Mar 6 01:32:45 2024 - Wed Mar 6 01:37:24 2024  (00:04)  65.2.161.68

答案：2024-03-06 06:32:45（UTC 时间）

⚠️ 重要提醒：注意时区差异！

这里有一个非常容易踩坑的地方：日志记录的其实是 UTC 时间（06:32:45），而你在自己机器上用 last 解析 wtmp 时，显示的时间（01:32:45）会被你本机时区”翻译”一遍。目标机器的时区和你本机的时区并不一样，所以务必搞清楚题目要的是哪一个时区下的时间，否则就会差出整整几个小时。

0x05 第五步：精确计算会话持续时长

Q3： 基于前面确认的认证时间，以及 auth.log 中会话 37 的结束时间，攻击者的首次 SSH 会话持续了多少秒？

会话的结束记录同样藏在 auth.log 里：

时间轴对齐后：

• 会话开始（wtmp）：06:32:45
• 会话结束（auth.log）：06:37:24

做一个简单的减法：

37:24 - 32:45

用 Python 算一下（把分秒换算成纯秒）：

python -c 'print(eval("(7 * 60 + 24) - (2 * 60 + 45)"))'

答案：279 秒

python -c 'print(eval("(7 * 60 + 24) - (2 * 60 + 44)"))'

也就是说，攻击者这次 root 会话只持续了不到 5 分钟。在这短短几分钟里，他已经完成了登录、执行目标操作、登出的全过程——对于熟练的攻击者而言，这点时间已经足够造成破坏。

0x06 复盘：两条日志，一条完整的入侵链

回顾整个挑战，我们用到的工具不过是 grep 思路 + last 命令，却把攻击者的行为链拼出了清晰的轮廓：

| 阶段 | 日志痕迹 | 关键证据 | | — | — | — | | 爆破 | Failed password + MaxStartups throttling | 大量失败认证 | | 登录 | Accepted password for root | 攻击者成功以 root 进入 | | 会话 | New Session | 会话编号 37 | | 行为 | wtmp + last | 登录时间 06:32:45，IP 65.2.161.68 | | 离场 | 会话结束记录 | 时长 279 秒 |

几个值得带走的实战经验：

1. auth.log 是 Linux 取证的金矿：爆破、登录、提权、持久化、命令执行，几乎都能在这里找到回响。
2. wtmp 配合 last 是查看登录史的标准姿势：二进制日志必须用专门工具解析，直接 cat 会得到乱码。
3. 永远警惕时区陷阱：日志里写的是 UTC，本机解析时会按本机时区换算，答题和写报告时务必统一口径。
4. 善用 -x -F -a 等参数：它们能让 last 的输出信息更完整、时间戳更精确，避免遗漏关键细节。

0x07 写在最后

Brutus 虽然被标为 very easy，但它把”日志取证”这套基本功讲得非常扎实。真实事件响应里，攻击者不会留下”我被爆破啦”的提示语，所有真相都藏在 auth.log 和 wtmp 这种不起眼的日志文件里。能把这两类日志读熟、读透，是每个蓝队/取证人员的基本功。

相关阅读：last 命令详解可参考 Linux迷 (linuxmi.com)

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：微痕鉴远 漫路修行 漫路修行《Brutus – 从一次 SSH 爆破，看 auth.log 与 wtmp 取证之美》