一、概述
此前，观成安全研究团队已发布多篇银狐木马分析报告，所涉样本的通信方式大多基于 TCP 自定义加密协议。而近期，我们注意到采用 UDP 自定义加密协议通信的银狐木马整体活跃度显著上升。深入分析发现，其通信机制与以往样本差异明显，不仅体现在先握手、后传输的两阶段通信模式上，密钥派生逻辑与数据包格式也均有较大调整。我们从通信交互流程、数据格式、加密算法等维度，对基于UDP的银狐木马通信机制进行全面剖析。
二、通信 机制分析
该类银狐变种使用UDP自定义加密协议进行通信，整体采用先握手、后传输的两阶段通信模式。由于原生UDP协议是一种"尽力而为"的传输协议，本身不提供数据包的送达确认或丢失重传机制，为实现可靠通信，该样本在应用层参考TCP的可靠性设计，自行构建了一套确认（ACK）与重传机制。 因此，在下文描述的交互流程中会出现类似TCP的确认包和超时重传逻辑。
交互流程上，双方通过四步握手交换Session ID，随后进入加密数据传输阶段；数据格式上，握手阶段为12字节固定结构，数据传输阶段为24字节头部加可变载荷；加密算法上，采用XOR动态密钥加密，即"一会话一密钥"。以下将对这三部分展开详细分析。
- 通信交互流程
该类银狐木马的通信交互流程如图1所示。
图 1 握手和数据传输阶段通信交互流程
第一阶段为握手阶段：
- 第一步，客户端向服务端发送握手请求。客户端生成自身的LocalID，由于此时是初次请求，对端标识未知，因此RemoteID字段置为0x00000000。若未收到服务端的响应，则进行重传，重传上限为10次。
- 第二步，服务端向客户端发送握手响应。服务端收到请求后生成自身的LocalID，首次响应中仅宣告该ID，RemoteID字段置为0x00000000，而重传时则将客户端的LocalID填入RemoteID进行回显。
- 第三步，客户端向服务端发送会话确认。该包中LocalID仍为客户端自身LocalID，RemoteID填入服务端LocalID进行回显，完成客户端侧的双向确认。该确认包连续发送3次，间隔10毫秒。
- 第四步，服务端向客户端发送握手确认。服务端收到会话确认后，LocalID为服务端自身LocalID，RemoteID填入客户端LocalID进行回显。至此，双方均完成对对方身份的确认，握手阶段正式结束，各自记录对端LocalID。
第二阶段为数据传输阶段：
- 第一条流，握手完成后，客户端首先向服务端发送载荷请求，服务端收到后回复 ACK 确认，随后下发相应的载荷数据。
- 第二条流，在握手完成后，客户端会主动发送包含主机信息的上线数据包。
- 后续交互中，服务端可根据需要继续下发控制指令，客户端按指令执行相应操作。
- 数据格式分析
- 握手阶段数据格式
握手阶段的数据包固定为12字节，由五个字段构成。起始2字节为Magic协议魔数，固定值为0x4FBB。随后为1字节的Flag1标志位（恒为0x01）和1字节的Flag2标志位，其中Flag2取值0x00表示请求或响应，0x01表示确认，用于区分握手子类型。最后8字节为会话标识，其中LocalID由发送方生成（客户端通过GetTickCount异或常量产生，服务端自行生成），RemoteID用于回显对端LocalID，初次请求时置为0，后续填入对端ID完成身份确认。
图 2 握手阶段数据格式
图 3 握手阶段流量数据
握手阶段的Session ID（即客户端生成的LocalID）生成逻辑如图4所示：将系统启动时间与常量0x5A3C7B1D进行异或运算，若运算结果为0则使用默认值0x12345678，否则直接作为Session ID。
图 4 Session ID 生成逻辑
数据传输阶段格式
数据传输阶段的数据包由24字节固定头部和可变载荷构成。头部前4字节为SessionID（即自身LocalID），用于标识会话。随后1字节为Type字段，用于区分包类型（详见下表）。接下来的字段依次为：1字节Flags、2字节Window（接收窗口），以及各4字节的Token、Seq和Ack，其中Token字段由发送端基于当前时间戳生成，用于标识DATA包，并在ACK包中原样回显，从而使发送端能够比对时间差，计算往返时延（RTT）及重传超时（RTO）。最后4字节为PayloadLen，取0时表示控制包，大于0时表示DATA包载荷长度。载荷位于头部之后，仅DATA包携带，承载实际通信数据。
表 1 Type字段 说明
|-----------|------------|--------------------|--------------------------|
| 值 | 名称 | 载荷 | 说明 |
| 0x51 | DATA | 有（PayloadLen > 0） | 承载实际通信数据 |
| 0x52 | ACK | 无（PayloadLen = 0） | 确认数据包接收成功 |
| 0x53 | SACK | 无（PayloadLen = 0） | 反馈已收分片状态及缺片区间，触发缺失分片重传 |
| 0x54 | NAK | 无（PayloadLen = 0） | 指示数据包接收失败（未收到或校验错误），请求重传 |
图 5 数据传输阶段数据格式、
图 6 数据传输阶段流量数据
数据传输阶段包类型的选择如下图所示。 
图 7 数据传输阶段包类型的选择
- 加密算法 分析
通信数据采用XOR动态密钥加密，每个会话独立使用一个密钥。加密载荷格式如下：前4字节为加密的长度字段，解密后获得后续实际数据长度；其后10字节为密钥派生种子，其中前4字节为随机生成的随机值，后6字节为固定常量，派生算法为 "keyi % key0 + key1"，将密钥种子逐字节代入得到最终密钥。从第15字节开始为密文数据。以上线包为例，解密后的明文为系统信息。
图 8 加密算法
以下为上线包数据解密示例，解密后可以看到银狐木马上线包常获取的几类信息，如主机名、用户名等。
图 9 上线包解密数据
三、检测
观成瞰云（ENS）-加密威胁智能检测系统能够对该类银狐木马进行有效检出。
图 10 观成瞰云（ENS）-加密威胁智能检测系统检测结果
四、总结
2026年以来，银狐木马的攻击活动持续高度活跃，观成安全研究团队捕获的变种样本量显著增长。在此背景下，本次分析的该类UDP变种进一步印证了该家族通信机制的持续演进：在长期沿用的TCP协议之外，新增了基于UDP的自定义加密通信方案，增加了通信协议的多样性；加密机制方面，固定密钥加密模式正逐步演化为基于随机数的动态密钥派生机制。上述变化表明，银狐木马的通信机制正朝着多协议化、载荷高随机化方向演进，给流量检测与分析带来挑战。观成安全研究团队将持续跟踪银狐木马家族的技术演进，不断加强观成瞰云（ENS）加密威胁智能检测系统的检测能力，为应对日益复杂的加密威胁提供可靠的技术保障。
五、附录
表 2 IOC信息
|------------|------------------------------------------------------------------|
| 类型 | 值 |
| SHA256 | 8d33791edb7a9744dba3df3b0b23435b495436a11aa72c7956599abbe56d1197 |
| IOC | 121.127.232.112 |