安全研究

malware-traffic

2026年05月28日10分钟

TCP/IP 四层协议

做流量嘛，总是绕不过去这四层的，但这里就不讲理论了，直接从wireshark里来看

一个http包最普通的协议分级

image.png

从上到下依次是

  • 总览（包含数据包的基本信息）
  • 物理层（source与dist的MAC）
  • 网络层（source与dist的IP）
  • 传输层（source与dist的PORT, TCP负载，当然如果是UDP的话就是UDP负载）
  • 应用层（这是分析重点，可以看到各种奇奇怪怪的协议负载）

在做恶意流量的分析时其实主要就是在分析应用层的流量（要是没有应用层，只是TCP裸流的话那估摸着就是C2的回连流量，这就得喊逆向师傅干活了），因此学习过程的重点也就是去学习各种应用层的协议，像TCP这边有http,smb,nbns,ssh,smtp,telnet之类的，UDP那边就是dns,rtp,wireguard这些

那么要关注的就是协议所开放的端口，还有在wireshark中他们各个字段的含义

除此之外就是经验上的东西了

恶意流量的常见形式

外层：漏洞+持久化

  • web端漏洞
  • CVE

就是很众所周知的一点，那些开源项目时不时就会爆一些CVE出来，然后呢，有些洞他的流量特征是很明显的，比如说奥

  • CVE-2025-55449 伪造JWT加恶意插件包上传实现RCE
  • CVE-2026-24061 载荷开头有一段很明显的USER -f username
  • OWASP

这里但就题目来说，比较常见也比较简单的就是文件上传传一个webshell上来，少见一点的会有shiro的反序列化之类的，但最终目的都是为了实现RCE，当然偶尔也会有SQL 注入的，但这个大部分是为了脱库，通过SQL注入实现RCE的也有，就是很少见了

  • 持久化(webshell/C2上传)

其实很好理解这一步，黑客嘛肯定不会打一次就走，那么就需要上个🐎来持续控制嘛

  • 蚁剑

明文传payload第一人，特征可以说相当明显，连接密码（图中是1）后面直接跟着明文payload

image.png

要注意的是，蚁剑命令执行会进行一次base64编码，并在编码开头塞两个随机字符，因此解码的时候要把这俩删掉

  • 冰蝎

冰蝎很经典了（beyond），流量通常会使用AES进行加密

冰蝎的流量中一般可以看到攻击者上传的源码（java的话可能会是字节码，要进行一次反编译）

image.png

从源码中可以拿到加密流量的key

  • 哥斯拉

和冰蝎有点类似，同样能在流量中看到源码，但是哥斯拉可能还会套一层异或，并且处理加密流量的密钥外还会由和蚁剑类似的，供攻击者连接的密码

image.png

至于解密嘛，希潭的工具箱一把梭就是了

  • VSHELL

这个特征就很明显啦，一条长包一条短包交替出现的，然后dump下内存拿到salt和vkey后进行AES解密就好

  • Cobalt Strike
  • checksum8算法特征，即URI在经过checksum8计算后，64位后门的结果是93，32位则是92，举个小栗子

237

来看这里的FJwV，校验和的计算结果就是93

image.png

  • 没有魔改的CS还会出现诸如/en_US/all.js /submit.php?id=xxx 之类的奇奇怪怪富有特征的URI

image.png

内层：横向移动

拿到凭据之后攻击者肯定不会只待在一台机器上嘛，横向移动就是他们在内网里到处跑的过程。这里按凭据类型分两条线来讲：基于NTLM哈希的PTH和基于Kerberos票据的PTT，再补充几种常见的横向移动手法的流量特征

P-T-H（Pass-the-Hash）

NTLMv2 认证流程回顾

具体细节可以回头看果子面包那一片，这里不细说啦

  • NTLMSSP_NEGOTIATE（客户端→服务端）：客户端发起协商，告知自身支持的NTLM版本和安全特性
  • NTLMSSP_CHALLENGE（服务端→客户端）：服务端返回一个随机的Challenge（8字节）
  • NTLMSSP_AUTH（客户端→服务端）：客户端用密码哈希对Challenge进行加密，生成Response发回服务端验证

PTH 的流量特征

PTH的核心思路就是攻击者已经拿到了目标用户的NTLM哈希（通常是NTLMv2的NTProofStr + Response），跳过密码直接进行认证。在流量中的表现就是：

  • 缺少正常的NTLMSSP_NEGOTIATE阶段，或者NEGOTIATE包极小（因为攻击者直接构造了AUTH包）
  • NTLMSSP_AUTH包中的NTResponse长度异常，正常认证的Response长度通常在160-240字节左右，而PTH构造的Response可能偏短或偏长
  • 时间间隔异常，正常用户输入密码再认证会有几秒的延迟，而PTH是自动化完成的，NEGOTIATE到AUTH的间隔可能只有几十毫秒
  • SMB2 Session Setup请求频率异常，短时间内对多个目标发起SMB认证

果子面包那题就是典型的PTH，通过NTLMv2爆破拿到密码后解密WinRM流量，再进一步横向

P-T-T（Pass-the-Ticket）

Kerberos 认证流程回顾

在正常的Kerberos认证链路下，用户会先请求TGT(AS-REQ/AS-REP)，接着请求服务票据(TGS-REQ/TGS-REP)，最后才是访问服务(AP-REQ)

PTT 的流量特征

在PTT攻击中，攻击者往往已经窃取了TGT（比如通过mimikatz的kerberos::ptt或者Rubeus的ptt命令注入票据），因此在流量中会看到以下异常：

  • 缺少AS-REQ/AS-REP，攻击者直接从TGS-REQ开始，因为他已经有了TGT不需要再向KDC申请
  • TGS-REQ中没有前置的AS交换，直接出现TGS-REQ请求某个SPN的服务票据
  • AP-REQ中Ticket的加密类型可能异常，正常用户使用AES256，而注入的票据可能是RC4加密（取决于票据来源）
  • cname字段可能与当前登录用户不一致，因为注入的是其他用户的票据

一个简单的判断方法：如果在Kerberos流量中直接看到TGS-REQ而没有前面的AS-REQ/AS-REP，基本就是PTT了

SMB 横向手法

除了凭据层面的PTH和PTT，攻击者拿到凭据后还需要通过具体的协议来执行远程操作。下面讲几种常见的基于SMB的横向手法

PSExec

PSExec是最经典的横向移动工具了，原理是通过SMB连接到目标的ADMIN$共享，上传一个服务二进制文件，然后通过RPC（svcctl服务控制管理器）注册并启动这个服务

流量特征：

  • SMB2 Tree Connect到\\目标\ADMIN$共享
  • SMB2 Create上传文件（通常是一个.exe或者.dll）
  • DCERPC绑定到svcctl服务（UUID: 367abb81-9844-35f1-ad32-98f038001003）
  • svcctl::CreateServiceW创建服务
  • svcctl::StartServiceW启动服务
  • 命名管道PSEXESVC的创建与通信

WMIExec

WMIExec通过WMI（Windows Management Instrumentation）服务进行远程命令执行，走的是DCERPC协议，相对于PSExec来说更隐蔽一些

流量特征：

  • SMB2 Tree Connect到\\目标\IPC$共享
  • DCERPC绑定到IWbemServices接口
  • 调用IWbemServices::ExecMethod执行命令
  • 命名管道\\.\PIPE\winreg或\\.\PIPE\svcctl的创建

DCOM 横向移动

DCOM（Distributed COM）也是一种横向移动方式，攻击者通过DCOM接口远程实例化对象来执行命令。比较常用的是MMC20.Application和ShellWindows

流量特征：

  • SMB2 Tree Connect到\\目标\IPC$
  • DCERPC绑定到MMC20.Application的IDispatch接口
  • 调用Document::ExecuteShellCommand执行命令
  • 流量中可以看到cmd.exe、powershell.exe等命令字符串

怎么区分这几种手法

说实话，在实际分析中区分这几种手法并不难，主要看DCERPC绑定的UUID和命名管道名称就行了：

  • 看到svcctl + PSEXESVC → PSExec
  • 看到IWbemServices → WMIExec
  • 看到IDispatch + ExecuteShellCommand → DCOM

当然了，攻击者也可以用impacket的smbexec、atexec等变种，流量特征会有些许不同，但核心都是SMB + DCERPC的组合

附录

流量特征明显的一些CVE

CVE-2025-53770

漏洞的存在是因为PHP在设计时未能预见到Windows的Best-Fit字符编码转换特性，这使得攻击者可以通过构造特定的请求来绕过安全限制。

影响范围:

PHP 8.3 < 8.3.8
PHP 8.2 < 8.2.20
PHP 8.1 < 8.1.29

特征：

image.png

如图所示哈，URI中出现php-cgi以及php伪协议，同时请求体中出现恶意php_payload

CVE-2025-55449

该漏洞源于 AstrBot 使用了固定的 JWT 签名密钥，攻击者可利用该密钥伪造任意有效的 JWT 认证令牌，完全绕过身份验证机制。成功绕过认证后，攻击者可访问插件管理接口，通过上传恶意的 Python 插件文件实现远程代码执行。

影响范围:

AstrBot < 3.5.18

image.png

如图哇，伪造JWT并上传恶意插件压缩包

image.png

后续进行RCE

CVE-2025-29927

Next.js 中间件认证绕过漏洞，攻击者通过构造特殊的请求头x-middleware-subrequest可以绕过中间件的认证检查，直接访问受保护的路由

影响范围:

Next.js < 14.2.25、15.x < 15.2.3

特征：

这个漏洞的特征可以说是一眼就能看出来，在正常的HTTP请求头中会出现一个很不自然的自定义头

x-middleware-subrequest: middleware:middleware:middleware:middleware:middleware

注意看，这个middleware字段会重复5次以上，用冒号分隔。在wireshark中可以直接用这个筛选

http.header contains "x-middleware-subrequest"

基本上看到这个头就可以确认是这个洞了，因为正常业务不会有人发这种请求头

CVE-2025-24893

XWiki 的SolrSearch接口存在服务端模板注入（SSTI）漏洞，攻击者可以通过text参数注入Groovy模板代码实现RCE

影响范围:

XWiki 多个版本受影响

特征：

流量中可以看到请求/xwiki/bin/get/Main/SolrSearch这个REST API接口，参数中带有Groovy模板语法的双花括号标记

{{groovy}}...{{/groovy}}

或者

{{async async=false}}{{groovy}}...{{/groovy}}{{/async}}

在wireshark中筛选

http.request.uri contains "/SolrSearch" and http.request.uri contains "groovy"

双花括号{{是XWiki的模板语法标记，正常搜索请求中不会出现这种结构

CVE-2025-24071

Windows 在解压包含.library-ms文件的压缩包时，会自动触发SMB连接向攻击者泄露NTLM哈希，全程无需用户交互

影响范围:

Windows 全版本

特征：

这个洞的利用链很有意思，攻击者构造一个.rar或.zip压缩包，里面放一个.library-ms文件，文件中指向一个UNC路径（\\attacker\share）。当受害者在Windows上解压这个压缩包时，系统会自动尝试连接这个UNC路径，从而触发SMB认证，受害者的NTLMv2哈希就这样泄露了

在流量中的表现就是：

  • 解压操作后突然出现SMB2连接到一个外部IP
  • NTLMSSP_AUTH包中包含受害者的NTLMv2哈希
  • 整个过程没有任何用户点击操作
CVE-2025-24813

Apache Tomcat 反序列化漏洞，攻击者通过PUT方法上传恶意序列化数据，再通过JSESSIONID触发反序列化执行代码

影响范围:

Apache Tomcat 特定版本

特征：

攻击分两步，流量特征都很明显

第一步：HTTP PUT请求上传序列化数据，注意Content-Range头，请求体以Java序列化对象的魔数开头

ac ed 00 05

第二步：通过构造Cookie中的JSESSIONID触发反序列化

在wireshark中可以直接搜Java序列化魔数

frame contains "\xac\xed\x00\x05"

配合HTTP PUT方法使用基本就能确认了

暂无标签