云栈社区»论坛 › 技术文档「 Note & Doc 」 › 流量分析实战：TCP握手/挥手、Webshell特征与漏洞流量识别技战法 ...

3710 积分	1 好友	502 主题

发消息

流量分析实战：TCP握手/挥手、Webshell特征与漏洞流量识别技战法

发表于 2026-2-10 19:01:16 | 查看: 32| 回复: 0

网络流量分析是安全响应、攻击溯源与红蓝对抗的核心能力。本文基于真实抓包数据与协议解析逻辑，系统梳理六类高频分析场景：从基础连接行为（TCP三次握手/四次挥手）到高级攻击特征（端口扫描、暴力破解），再到典型恶意工具通信模式（蚁剑、冰蝎、哥斯拉）及高危漏洞流量指纹（Shiro 550、PwnKit、Dify任意文件读取）。所有结论均源自可复现的Wireshark过滤规则与字段级验证，拒绝模糊经验，强调证据链闭环。

一、攻击溯源检测法：从IP占比到请求-响应方向判定

在海量流量中快速定位攻击主体，需分两步走：先识别“主角IP”，再确认其角色（攻击者 or 受害者）。

主动攻击模型下的双IP聚焦

通过Wireshark的 Statistics > IPv4 Statistics > All Addresses 功能，对IPv4地址按 Count 字段降序排列，可直观发现流量主导者。例如下表中，两个IP异常突出：

IPv4 Address	Count	Percent	Rate (ms)	Burst Rate	Burst Start
192.168.8.30	8149	96.16%	3.2500	26.569	—
192.168.8.11	986	83.31%	3.2500	26.569	—

二者占比远超其余IP（第三名仅10.08%），构成典型的1V1主动攻击模型——即单一攻击源（192.168.8.11）持续向单一目标（192.168.8.30）发起请求。

进一步过滤HTTP流量，观察请求-响应流向：

No.	Time	Source	Destination	Protocol	Length	Info
2168	2025-05-14 08:23:43.445203	192.168.8.11	192.168.8.30	HTTP	72	GET / HTTP/1.0
2179	2025-05-14 08:23:43.460572	192.168.8.30	192.168.8.11	HTTP	84	HTTP/1.1 400 Bad Request
2180	2025-05-14 08:23:43.460572	192.168.8.30	192.168.8.11	HTTP	1321	HTTP/1.1 200 OK (text/html)

箭头向右（Source → Destination）为请求，向左为响应。可见：

所有GET请求均由 192.168.8.11 发起，指向 192.168.8.30
192.168.8.30 均返回HTTP响应（含200/400状态码）

因此，192.168.8.30 是被攻击的服务器（受害者），192.168.8.11 是攻击者。该结论符合Web服务“客户端请求→服务端响应”的基本模型。

被动感染模型下的单边流量特征

当流量分布极度倾斜（如某IP占比近100%，其余IP总和不足5%），需警惕被动感染场景：

Topic / Item	Count	Average	Min Val	Max Val	Rate (ms)	Percent	Burst Rate	Burst Start
10.12.3.66	55270	0.0271	100.00%	6.6300	1663.857	—	—	—
91.207.181.106	10683	0.0052	19.33%	1.4000	1899.388	—	—	—

此时 10.12.3.66 占据全部流量的100%，而其他IP均为其通信对端。若进一步过滤其流量：

当该IP大量出现在 Source 列 → 攻击者（主动发包）
当该IP大量出现在 Destination 列 → 受害者（被动接收）

典型被动感染案例：用户访问挂马网页（如含Flash漏洞页面），浏览器自动向C2服务器回连，此时受害主机IP在Source列高频出现，但目的IP为境外C2地址。

二、端口嗅探分析法：从TCP标志位到扫描工具指纹

端口扫描是渗透测试前置动作，其流量具备强可识别性，核心依据两类特征：TCP协议行为与应用层指纹。

TCP三次握手：建立连接的原子操作

TCP连接建立必须完成三次交互，无应用层数据，仅靠SYN/ACK标志位驱动：

第一次握手（SYN）：客户端向服务器发送SYN包，序列号Seq=0，表示“我要建立连接”

Source Port: 57965
Destination Port: 9505
[TCP Segment Len: 0]
Sequence number: 0 (relative sequence number)
Flags: 0x0002 (SYN)
Window size value: 64240

第二次握手（SYN/ACK）：服务器回复SYN+ACK，确认号Ack=1（即客户端Seq+1），表示“同意连接，并告知你我的初始序列号”
```
Source Port: 9505
Destination Port: 57965
Acknowledgment number: 1 (relative ack number)
Flags: 0x012 (SYN, ACK)
```
第三次握手（ACK）：客户端发送ACK，确认号Ack=1，表示“收到你的确认，连接已建立”
```
Flags: 0x010 (ACK)
Sequence Number: 1 (relative sequence number)
Acknowledgment Number: 1 (relative ack number)
```

✅ 关键识别点：三次握手包均无Payload（Length=0或极小），且SYN标志位仅在首次出现，后续置0。

TCP四次挥手：关闭连接的状态机

连接终止需四步，体现双向关闭语义：

第一次挥手（FIN）：客户端发送FIN，Seq=8496，表示“我无数据发送，准备关闭”
第二次挥手（ACK）：服务器回复ACK，Ack=8497，表示“已收到关闭请求”
第三次挥手（FIN）：服务器发送FIN，Seq=428，表示“我也无数据，正式关闭”
第四次挥手（ACK）：客户端回复ACK，Ack=429，表示“确认关闭”

Frame 59: 54 bytes on wire (432 bits), 54 bytes captured (432 bits)
Transmission Control Protocol, Src Port: 80, Dst Port: 54737, Seq: 8496, Ack: 428, Len: 0
Flags: 0x01 (FIN, ACK)

✅ 关键识别点：FIN/ACK包常伴随Len=0，且四次交互中Seq/Ack数值严格递增，形成闭环。

扫描工具指纹：User-Agent与行为模式

不同扫描器在HTTP请求头或TCP载荷中留下独特痕迹：

扫描器	User-Agent关键词	测试路径/参数	Payload特征	行为模式
AWVS	Acunetix、WVS	`/admin`、Cookie注入	随机字符串测试	高频扫描敏感目录
AppScan	AppScan、IBM	`/cgi-bin/`、随机参数	参数名含`AppScan_`	模拟用户登录流程
Nessus	Nessus、Tenable	非HTTP端口探测	原始协议包	系统/网络层漏洞探测
SQLMap	`sqlmap`（可能隐藏）	`/phpmyadmin`	`AND 1=1`、`SLEEP(5)`	专注SQL注入、逐参数测试

此外，vSphere API探测流量具有明确SOAP结构：

POST /sdk HTTP/1.1
Connection: close
User-Agent: Mozilla/5.0 (compatible; Nmap Scripting Engine; https://nmap.org/book/nse.html)
Host: BigBoss:443
Accept: */*
Content-Length: 441

<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema" xmlns:xsd="http://www.w3.org/2001/XMLSchema-instance" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Header>
    <operationID>soap.Header</operationID>
    <Body>RetrieveServiceContent soap:Body>
      <RetrieveServiceContent xmlns="urn:internalvim25">
        <this xsi:type="ManagedObjectReference" type="vim.ServiceInstance">
          <value>ServiceInstance</value>
        </this>
      </RetrieveServiceContent>
    </Body>
  </soap:Header>
</soap:Envelope>

SYN半连接扫描：隐蔽端口探测

黑客常用tcp.flags.syn == 1 and tcp.flags.ack == 0过滤出纯SYN包，实现不建立完整连接的端口探测：

No.  Time                        Source         Destination    Protocol  Length  Info
258  0.108062                    192.168.177.155  192.168.177.145  TCP       60      42642 → 132 [SYN] Seq=0 Win=1024 Len=0 MSS=1460
259  0.108062                    192.168.177.155  192.168.177.145  TCP       60      42642 → 133 [SYN] Seq=0 Win=1024 Len=0 MSS=1460

若目标端口关闭，服务器会返回RST/ACK包；若开放，则返回SYN/ACK。据此可推断：

过滤 tcp.flags.syn == 1 and tcp.flags.ack == 1 → 服务器开放端口的响应包
过滤 tcp.flags.reset == 1 → 关闭端口的拒绝响应

三、暴力破解分析法：从HTTP POST频率到响应长度差异

暴力破解本质是高频、低成功率的认证尝试，其流量在时间密度与响应特征上高度异于正常业务。

时间维度：秒级密集请求

筛选http.request.method == POST并限定IP后，可见攻击者在5秒内发起数十次登录请求：

No.	Time	Source	Destination	Protocol	Length	Info
9403	39.361209	59.191.245.66	192.168.10.5	HTTP	730	POST /OA/login.php?login HTTP/1.1
9413	39.367357	59.191.245.66	192.168.10.5	HTTP	730	POST /OA/login.php?login HTTP/1.1
...	...	...	...	...	...	...
9593	39.472800	59.191.245.66	192.168.10.5	HTTP	730	POST /OA/login.php?login HTTP/1.1

同一IP在39.36–39.47秒（约0.11秒间隔）内连续发送19个相同路径的POST请求，属典型暴力破解行为。

响应维度：长度突变指示成功

破解成功时，服务端响应内容显著增长（如返回管理后台HTML），而失败响应通常较短（JSON错误提示或302跳转）：

失败响应长度：Length=730（固定登录表单）
成功响应长度：Length=1321（含完整HTML页面）

通过对比Length字段，可快速定位疑似成功请求，避免人工逐条检查响应体。

四、认证身份识别分析法：从User-Agent到Kerberos票据流转

协议层信息是识别设备类型、操作系统与认证机制的关键入口。

User-Agent解析：精准定位终端环境

HTTP请求头中的User-Agent字段直接暴露客户端环境：

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36

其中Windows NT 10.0对应Windows 10系统（NT版本映射关系如下）：

NT 5.1: Windows XP
NT 6.0: Windows Vista
NT 6.1: Windows 7
NT 6.2: Windows 8
NT 6.3: Windows 8.1
NT 10.0: Windows 10

此信息可用于判断攻击源是否来自企业内网（如统一部署Win10）、或识别爬虫/自动化工具（UA含Nmap Scripting Engine）。

Kerberos认证：三阶段票据交换

Kerberos认证通过KDC（密钥分发中心）实现三方可信，流量分为三个阶段：

AS Exchange（获取TGT）
Client向AS发送KRB_AS_REQ，携带pA-ENC-TIMESTAMP（客户端Hash加密的时间戳）。AS验证后返回KRB_AS_REP，含：
- ticket：由krbtgt Hash加密的TGT票据（含PAC、Client SID等）
- enc-part：由Client Hash加密的Session Key
TGS Exchange（获取ST）
Client用Session Key加密authenticator（含时间戳），连同TGT发送至TGS。TGS解密TGT验证后，返回KRB_TGS_REP，含：
- ticket(TGS)：由目标Server Hash加密的ST票据
- enc-part：由Session Key加密的新Session Key
Client/Server Exchange（访问服务）
Client用ST中的Session Key加密authenticator，发送KRB_AP_REQ至Server。Server解密后校验PAC权限，返回KRB_AP_REP。

🔍 抓包验证点：KRB_AS_REQ中pA-ENC-TIMESTAMP字段存在即表明Kerberos认证启动；KRB_TGS_REP中ticket字段长度>100字节且含PAC标识，为典型域渗透特征。

SMB打印机共享：协议协商与NTLM认证

SMB流量始于TCP三次握手，随后经历三阶段：

协议协商（Negotiate Protocol）
客户端发送支持的SMB版本列表（如SMB 2.0/2.1/3.0），服务端选择最高兼容版本并返回Negotiate Protocol Response。
会话建立（Session Setup）
客户端发起NTLMSSP_NEGOTIATE请求，服务端返回8字节NTLM Server Challenge（如3dfaefbce47bc2db）。
认证响应（NTLM Authentication）
客户端用密码Hash + Challenge生成response（如6142a67953e5b519cb3c95d7f2f7520b630acbab2a8978de）发送。服务端校验后返回：
- STATUS_SUCCESS：认证成功
- STATUS_LOGON_FAILURE：认证失败

五、一句话木马解析：从明文到多层加密的通信特征

Webshell是攻击持久化的关键载体，其通信模式随WAF演进而不断变形，但核心特征始终可溯。

蚁剑（AntSword）：多编码绕过策略

蚁剑默认使用antSword/v2.1作为User-Agent，请求体经多层编码：

明文模式：

POST /shell.php HTTP/1.1
User-Agent: antSword/v2.1
Content-Length: 52

=@ini_set("display_errors", "0");@set_time_limit(0);

Base64模式：
request_body为QGluaV9zZXQoImRpc3BsYXlfZXJyb3JzIiwgIjAiKTtAc2V0X3RpbWVfbGltaXQoMCk7
CHR模式：
request_body为cHr(64).ChR(105)...（ASCII码拼接）

✅ 共同特征：User-Agent含antSword/，Content-Length固定为52（明文）或64（Base64），响应体含随机字符串包裹的执行结果。

冰蝎（Behinder）：AES动态密钥加密

冰蝎2.x采用服务端动态生成16字节AES密钥，通信分两阶段：

密钥协商（GET请求）：

GET /shell.php?pass=xxx HTTP/1.1
Accept: application/xhtm1+xml,application/xml,application/signed-exchange

服务端返回密钥（如a1b2c3d4e5f67890）至响应体。

加密传输（POST请求）：
```
POST /shell.php HTTP/1.1
Connection: Keep-Alive
Content-Length: 16
Accept: application/xhtm1+xml,application/xml,application/signed-exchange

[16字节AES密文]
```
Content-Length: 16是冰蝎2.x最稳定特征；3.x取消动态密钥，改用固定MD5前16位，Content-Type: application/octet-stream成为JSP版强特征。

哥斯拉（Godzilla）：XOR+Base64双层加密

哥斯拉PHP版采用XOR（密钥为用户密码MD5前16位）+ Base64 + URL编码三层处理：

请求体格式：pass=evalContent&key=XXXXXXXX
evalContent：预编译模板经XOR/Base64/URL编码后的密文
key=XXXXXXXX：实际执行命令的密文（同算法加密）

响应体为Base64解码后的原始输出，无额外包装。

六、常见漏洞解析：从Shiro Cookie到PwnKit本地提权

漏洞利用流量具备高度结构化特征，是威胁狩猎的黄金指标。

Shiro反序列化（CVE-2016-4437）

Apache Shiro默认使用硬编码AES密钥解密rememberMe Cookie，导致反序列化漏洞：

登录失败响应：必含Set-Cookie: rememberMe=deleteMe
登录成功且勾选RememberMe：Set-Cookie同时含rememberMe=deleteMe与rememberMe=[长Base64]
命令执行流量：rememberMe值极长（>2000字符），响应体含$符号（Linux命令提示符）或>（Windows提示符）

Set-Cookie: rememberMe=VGVzdFJlbWVtYmVyTWU7...

该Base64解码后为AES密文，再经AES解密得到Java反序列化字节流。

PwnKit本地提权（CVE-2021-4034）

该漏洞利用pkexec程序对空参数处理缺陷，攻击者通过构造特殊环境变量触发堆溢出。流量侧特征为：

攻击者上传linpeas.sh等提权脚本（HTTP POST上传）
执行./linpeas.sh后输出中包含PwnKit字样
最终调用pkexec提权时，进程树显示pkexec子进程以root权限运行

Dify任意文件读取

Dify默认配置中，PostgreSQL与Redis密码为difyai123456，攻击者可直连数据库获取敏感信息：

数据库表upload_files中key字段存储绝对路径（如/app/storage/uploads/xxx.txt）
构造知识库上传请求，重放时将key替换为/etc/passwd等路径，响应体即返回目标文件内容

附件：Wireshark常用过滤速查表

场景	过滤表达式	说明
TCP SYN扫描	`tcp.flags.syn == 1 and tcp.flags.ack == 0`	识别端口扫描发起方
TCP开放端口响应	`tcp.flags.syn == 1 and tcp.flags.ack == 1`	识别服务器开放端口
HTTP POST暴力破解	`http.request.method == "POST" && ip.addr == 59.191.245.66`	锁定特定IP的登录请求
Kerberos认证	`kerberos`	快速定位Kerberos协议流量
SMB协议	`smb2`	过滤SMB 2.x及以上版本流量
DNS查询	`dns.qry.name contains "google"`	搜索特定域名DNS请求

参考资料

[1] 流量常见分析技战法详解, 微信公众号：mp.weixin.qq.com/s/ZOWynRbwVkCQsejFWjnLTQ

版权声明：本文由云栈社区整理发布，版权归原作者所有。

上一篇：藏在电路板里的美学：丰田、华为、荣耀等产品拆解揭秘
下一篇：AI Agent Skill 进阶指南：从机制解析到TRAE实战，解锁稳定可靠执行

Wireshark, TCP协议, Webshell, Shiro反序列化, PwnKit