Overpass 生产环境遭到入侵。该题提供了攻击发生时捕获的 PCAP，目标是从网络证据重建攻击路径，并在重新部署的靶机上验证攻击者遗留的访问方式。
本文按实际发现顺序整理。

TryHackMe 房间说明与 PCAP 分析任务

目标与证据范围

项目内容
平台TryHackMe
房间Overpass 2 Hacked
主题PCAP 取证、WebShell、明文反连、SSH 后门与 SUID 持久化
PCAPoverpass2_1595383502269.pcapng
验证靶机 IP10.144.170.130（本次会话，临时地址）
完成情况已取得 user flag 与 root flag，并复原攻击者遗留的后门访问链

先用 file 确认样本为 pcapng capture file，再计算题目要求的 MD5、SHA-256、SHA-512。MD5 与题目给出的值一致，说明分析对象未在本地下载后被意外替换。

stat 中的 Access/Modify/Change/Birth 时间只描述本地文件系统中的下载、访问或修改时间，不能倒推攻击在何时发生；攻击时间应以 PCAP 帧时间为准。

PCAP 文件类型、MD5、SHA-256 与本地 stat 信息

路径概览

已验证的攻击与验证链

01 · PHP 文件上传

从 HTTP POST 中定位 /development/upload.php，恢复上传的 payload.php。

02 · 反连 Shell 取证

根据 payload 中的 192.168.170.145:4242 聚焦 TCP stream，重建攻击者的明文交互命令。

03 · 历史提权与后门部署

流量证明攻击者切换至 james、读取 /etc/shadow，随后部署伪装 SSH 服务并监听 2222。

04 · 密码派生逻辑与后门验证

根据 Go 源码确定 SHA-512(password + salt)，离线恢复后门口令并连接 2222。

05 · SUID Bash 提权

在 james 家目录发现 root-owned SUID Bash，以保留有效 UID 的方式获得 root shell。

PCAP 初筛：从 HTTP POST 定位上传点

先用显示过滤器缩小 HTTP 请求范围：

1
2
3
4
http.request
http.request.method == "POST"
http.request.uri contains "/development/"
http.request.uri == "/development/upload.php"

第 14 帧是从 192.168.170.145 发往 192.168.170.159:80 的请求：

1
2
3
4
POST /development/upload.php HTTP/1.1
Content-Type: multipart/form-data
filename="payload.php"
Content-Type: application/x-php

这证明攻击者向 /development/upload.php 上传了名为 payload.php 的 PHP 文件。对 multipart 上传内容，也可以用下列过滤器回查：

1
2
3
http contains "Content-Disposition"
http contains "filename="
http contains "<?php"

HTTP POST、multipart 表单字段与 payload.php 内容

上传内容是典型 FIFO 反连 Shell：先删除并创建 /tmp/f 命名管道，再把 /bin/sh -i 的输入输出交给 Netcat。payload 指向 192.168.170.145:4242；因此后续攻击者和目标的交互很可能位于该 TCP 会话，且在本次 PCAP 中以明文出现。

重建反连会话：从 www-data 到 james

对反连流量使用：

1
ip.addr == 192.168.170.145 and tcp.port == 4242

再结合长度较大的数据包或 Follow -> TCP Stream 查看完整对话。流量中首先显示：

1
uid=33(www-data) gid=33(www-data) groups=33(www-data)

这证明上传的 WebShell 初始执行身份是 www-data。攻击者随后使用 Python PTY 改善交互体验，检查上传目录中的文件，再执行 su james。TCP stream 中可见密码输入与随后变为 james@overpass-production 的提示符，因此“切换到 james 成功”是由前后身份输出支持的结论，而非只根据一行密码文本推测。

反连 TCP stream：www-data 身份、su james、sudo 规则与 shadow 读取

攻击者以 james 执行 sudo -l，得到：

1
2
User james may run the following commands on overpass-production:
    (ALL : ALL) ALL

该规则允许 james 以任意用户、任意组执行任意命令；输出中没有 NOPASSWD，所以仍需要完成 sudo 认证。后续 sudo cat /etc/shadow 成功返回系统账户哈希，说明攻击者在捕获时已取得 root 级读取能力。

后门部署：为什么 2222 是 SSH 候选端口

同一 stream 显示攻击者克隆 NinjaJc01/ssh-backdoor、运行 ssh-keygen 生成 id_rsa、给 backdoor 添加执行权限，并以 -a 覆盖其默认认证 hash：

1
2
./backdoor -a <runtime-hash>
SSH - Started SSH backdoor on 0.0.0.0:2222

这里生成的 id_rsa 被该程序作为 SSH 服务端 host key 读取和注册；它不是攻击者以私钥登录系统的用户认证材料。

攻击者生成后门 host key、赋予可执行权限并启动 2222 监听

重新部署的靶机上做 TCP SYN 全端口扫描：

1
sudo nmap -sS -sV -p- -T4 -oN nmap_10.144.170.130 10.144.170.130

扫描结果显示：

端口服务识别证据含义
22/tcpOpenSSH 7.6p1系统原有 SSH 候选服务
80/tcpApache httpd 2.4.29Web 服务
2222/tcpOpenSSH 8.2p1 Debian-4与后门的默认伪装 fingerprint 和监听端口吻合

-sS 的主体是 TCP SYN 扫描，-p- 只覆盖 TCP 1–65535 端口；-sV 再对开放端口进行应用层服务识别。这不是 UDP 扫描。

验证靶机的 22、80 与 2222 TCP 端口

源码逻辑：认证算法与会话行为

以下结论来自题目流量中攻击者克隆的项目源码；这里只分析认证和会话逻辑。

启动配置与运行时 hash

main 的默认配置包括：监听 0.0.0.0:2222、伪装 banner OpenSSH_8.2p1 Debian-4、读取 id_rsa 作为服务端 host key，以及一个可被 -a/--hash 覆盖的全局 hash。PCAP 中的 ./backdoor -a <runtime-hash> 因此覆盖了源码里的默认值；后续认证应以流量中传入的 runtime hash 为准，而不是源码默认 hash。

源码中的默认 hash、2222 端口、监听地址与伪装 banner

认证调用链可概括为：

1
2
3
4
5
SSH 客户端提交 password
  -> passwordHandler
  -> verifyPass(hash, fixedSalt, password)
  -> hashPassword(password, fixedSalt)
  -> SHA-512(password + fixedSalt) == runtime hash

passwordHandler 的 ssh.Context 参数被命名为 _，即用户名等 context 信息不参与此函数的认证判断；它只校验密码。源码使用的是固定 salt 的单次 SHA-512，而不是慢速 KDF 或标准 sha512crypt。salt 不是秘密，但硬编码和单次哈希会使获得 hash 的攻击者能够高效离线猜测口令。

passwordHandler 传入固定 salt 的源码位置

源码还表明 sshterminal 在认证成功时以 /bin/bash -i 提供交互会话，并检查是否请求 PTY；未请求 PTY 时会返回 No PTY requested.。虽然项目中定义了 sshHandler 与 runCommand，但 Server{ Handler: sshterminal } 实际注册的是 sshterminal，所以不应把 runCommand 当成本次已证实的执行路径。

离线恢复后门口令

程序实现的精确公式为：

1
SHA-512(password + salt) = runtime-hash

这与 Hashcat mode 1710 的 sha512($pass.$salt) 对应。输入应是一个 runtime-hash:salt 对，而非把源码默认 hash、runtime hash 和 salt 三者拼在一起：

1
2
hashcat -m 1710 -a 0 backdoor-salted.txt /usr/share/wordlists/rockyou.txt.gz
hashcat -m 1710 --show backdoor-salted.txt

本次字典审计成功恢复了一个后门密码（<redacted>）。这只证明该值能通过该后门的 PasswordHandler；不能据此推断它是 Linux 系统账户密码。

Hashcat mode 1710 成功恢复后门认证密码

PCAP 中取得的 /etc/shadow 另属一组 Linux 账户哈希，不能与后门 hash 混用。使用题目指定的 fasttrack 字典时，John 加载了 5 个账户哈希并恢复其中 4 个；这回答的是“有多少系统密码可被该字典破解”，不是后门认证口令的来源。

John 使用 fasttrack 对 shadow 条目审计：5 个加载、4 个恢复

验证 2222 后门与 user 阶段

将恢复出的后门密码用于 2222 端口后，服务端接受认证并进入 james 的家目录；目录中可见攻击者克隆的 ssh-backdoor 项目、host key 和构建文件。由 shell 提示符不足以证明身份，后续以读取 user flag 和本地文件权限作为补充证据。

成功连接 2222 后门，james 家目录中的 ssh-backdoor 文件

最终提权：当前实例中的 SUID Bash

james 家目录的 ls -la 显示了一个不同寻常的文件：

1
-rwsr-sr-x 1 root root ... .suid_bash

关键证据是 owner 为 root 且权限位中包含 s。这表示该 Bash 副本带有 root SUID；执行时可获得有效 UID 0。以保留特权模式启动后，whoami 返回 root，并成功读取 /root/root.txt。它构成可用于本地提权和持久化的高风险后门，而不是 sudo 密码爆破结果。

该文件位于攻击链关联用户 james 的家目录，且当前实例中与后门访问一同出现，因此与攻击遗留物一致；但现有 PCAP 截图没有捕获创建 .suid_bash 的命令，不能仅凭文件存在断言其创建者或创建时间。

发现 root-owned SUID Bash、获得 root shell 并读取 root flag

两个 Flag 均已取得。 入口是 PCAP 中恢复的 SSH 后门认证链；最终 root 来自当前实例中 root-owned SUID Bash 的实际执行。

SOC 视角：可检测的攻击痕迹

阶段网络或主机证据可支持的结论
初始访问POST /development/upload.php、payload.php、application/x-phpWeb 上传端点接收了 PHP 文件
命令控制到 192.168.170.145:4242 的 Netcat 反连流会话内容在捕获中明文可见
权限扩大su james、sudo -l、sudo cat /etc/shadow攻击者获得 james 并在当时读取 shadow
后门部署git clone ssh-backdoor、ssh-keygen、chmod +x、监听 2222新的伪装 SSH 服务被部署
持久化/最终提权root-owned .suid_bash 且带 SUID 位本地用户可借该文件获得有效 root 权限；创建者与创建时间仍待其他证据确认

本题最重要的取证习惯是将“PCAP 中曾发生的行为”和“重新部署靶机上实际验证的行为”分开写：历史流量给出攻击路径和配置线索；端口扫描、后门登录、文件权限与 whoami 则确认这些线索在当前实例中的实际影响。

总结与复盘

这次最有价值的不是单独获得一个 shell，而是把一份 PCAP 中的零散证据还原为可验证的攻击链：PHP 上传建立 www-data 反连 Shell，攻击者切换到 james 并读取 shadow，部署伪装 SSH 服务，最后在当前实例中通过 SUID Bash 获得 root。

复盘点本次得到的结论
从宽到窄分析流量先以 HTTP 请求和 POST 过滤流量，再检查 multipart 字段与文件内容，能避免在大量 ARP、DNS、mDNS 等噪声中直接手工翻包。
以完整会话而非单包归因上传请求本身只证明文件进入端点；将 payload 中的回连地址、4242/TCP stream 和 uid=33(www-data) 连起来，才形成初始访问的证据链。
分开看不同凭据james 的系统账户密码、/etc/shadow 中的账户哈希、SSH 后门的自定义认证密码不是同一类材料。一个凭据在某处成功，不等于可用于所有服务。
用源码决定哈希模式后门 hash 是 SHA-512(password + salt)，而不是无 salt 的 Raw SHA-512。运行命令中的 -a 还覆盖了源码默认 hash；只有源码、运行参数和 Hashcat 模式三者一致，离线审计结果才有意义。
权限结论需要运行证据看到 SUID 位只能提出提权假设；whoami=root 和成功读取 /root/root.txt 才证明该文件在当前实例中实际获得了 root。

本次过程中，multipart payload 的导出以及 sha512($pass.$salt) 对应 Hashcat mode 1710 的选择使用了明确指导。因此这些步骤应视为依据已知证据完成的复现验证。2222 后门连接和 SUID Bash root 验证保留实际操作与输出作为证据。

后续再遇到类似题目时，可以沿用下面的顺序：

1
2
3
4
5
6
确认样本完整性
→ 从协议和请求类型过滤噪声
→ 用 payload 中的 IOC 定位完整会话
→ 区分历史流量事实与当前实例验证
→ 读取源码还原认证/权限条件
→ 用最小化操作验证权限边界