文章总结： 本文分析了一种通过识别非TLS加密通信来缩小WebShell排查范围的方法。核心思路是排除法：先梳理企业私有加密业务，建立台账让业务部门认领，再集中调查无人认领的异常通信。该方法能有效降噪，但并非直接检测WebShell，存在误报和盲区。真正的排查需结合请求、应用、主机日志和时间线进行完整取证。建议安全团队将此法作为入口筛选器，并完善资产治理。 综合评分： 87 文章分类： 应急响应,安全运营,实战经验,WEB安全,安全建设

几千万条流量里捞 WebShell，这招好用，但别用错了

原创

messfree messfree

MessFreeSecurity

2026年8月26日 11:57 北京

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

先说结论：这套方法能用，思路也不错，但它干的不是“识别 WebShell”，而是“缩小排查范围”。

某厂商营销号原文讲了一个案例。某企业从几千万条流量里梳理出 137 个非 TLS 加密通信业务，找业务部门认领以后，还剩 11 个说不清用途。安全团队继续往下查，最后发现了一个魔改 WebShell。

137、11、1，这几个数字很抓眼球。不过案例没有提供原始流量、主机日志和样本，我们只能按原文口径理解，不能当成独立验证过的结果。

抛开产品宣传，这个案例里有一条很实用的思路：密文看不懂没关系，先把正常业务认出来。正常业务排掉以后，安全人员再集中精力查剩下的异常通信。

说白了，这是一种排除法。

TLS 为什么要单独拎出来

不少人第一次看到“非 TLS 加密通信”，会觉得这个说法有点绕。既然都加密了，为什么还要分 TLS 和非 TLS？

先把概念捋顺。

HTTPS 用的就是 TLS。浏览器访问 HTTPS 网站时，HTTP 请求和响应在 TLS 通道里传输。网络设备如果没有解密条件，通常只能看到通信双方、证书、连接时间、流量大小，看不到里面的 URL 参数和 Body 内容。

文章盯的是另一类流量：外面走普通 HTTP，Body 里却塞了一段业务自己加密的数据。

比如下面这个请求：

POST/api/syncHTTP/1.1
Content-Type: application/json

{"data":"8fa27bc91e..."}

URI 看得见，Header 看得见，状态码也看得见，唯独 data 里装了什么看不懂。里面可能是 AES，也可能是 XOR、RC4、自定义编码，甚至是一套只有开发人员知道的老协议。

很多企业都有这样的接口。网关对接、第三方通道、老 ERP、历史遗留系统，都可能在 HTTP Body 里再加一层密。加密 WebShell 也喜欢这么干，因为命令和回显一加密，传统流量特征就少了一大截。

那为什么不把 HTTPS 也一起查？因为 HTTPS 太多了。今天企业的大部分 Web 业务都在用 TLS，如果把所有 HTTPS 连接都塞进排查名单，等于什么也没筛。

非 TLS 私有加密的规模通常小得多，业务归属也更容易逐个确认，所以单独拿出来有意义。

137 个业务是怎么缩到 11 个的

设备没有必要先破解密文，可以先看一些外围特征，比如 Body 的信息熵、字符分布、编码形式、字段位置、长度变化，以及请求和响应是不是长期保持相似结构。

相似流量聚到一起，大致就能看出这里有多少类通信。接下来再找业务部门认领：这个接口是谁上的，用来做什么，谁负责维护，现在还在不在用。

有人认领、用途说得清、行为也稳定的，先放进正常基线。突然出现的、没人认领的、访问规律又奇怪的，留下来继续查。

原文提到的可疑业务有几个特点：一天只有几十次请求，部分来源带有恶意信誉，所有请求都返回 404，响应体长度还不固定。

这个组合确实可疑。

WebShell 完全可以故意返回 404，让访问看起来像打到了一个不存在的页面。命令执行结果经过加密以后放在响应体里，不同命令产生的结果不一样，响应长度也会跟着变。

但这里要踩一脚刹车。404 加变长响应，只能说明“值得查”，不能直接说明“已经抓到 WebShell”。正常业务一样可能返回 404，响应体里也可能带动态错误信息。

这套方法实际走的是下面这条路：

几千万条 HTTP 请求
→ 找出疑似私有加密的 Body
→ 按通信特征归类
→ 让业务部门认领
→ 留下新增和无人认领项
→ 按异常程度排序
→ 回到服务器上确认

前面几步都在做减法，最后一步才决定它到底是不是 WebShell。

这招最有用的地方，不在算法

不少人会把注意力放在“设备怎么识别加密流量”上。算法当然重要，但这个案例更值得借鉴的是资产治理。

很多企业知道自己有多少台服务器，却不知道有多少套私有加密接口。CMDB 里可能有 IP、端口、系统名称和负责人，就是没有“这个接口的 Body 为什么是一团密文”。

平时不梳理，演练时看到一段加密请求，安全人员就会卡住：这是业务流量，还是后门通信？问开发，开发说不清；翻台账，台账里没有；直接封，又怕影响业务。

加密业务台账补的就是这块空白。正常通信有了身份，后来冒出来的陌生通信自然更显眼。原本要翻几千万条请求，现在只需要盯住每天新增的几类通信，工作量完全不是一个级别。

所以这招适合做“入口筛选器”，帮安全团队决定先查谁，却不能代替后面的取证。

别急着高兴，盲区也很明显

先说误报。

Body 看不懂，不代表 Body 做了加密。压缩文件、图片上传、Protobuf 和其他二进制序列化数据，也可能表现出高熵和不可读。设备先找到的只能叫“疑似加密通信”，不能直接叫“恶意通信”。

再说业务认领。有人认领，不等于这个接口安全。

没人认领的接口可能只是历史遗留系统。有人认领的正常接口，也可能已经被攻击者借来传命令。白名单能降噪，但白名单从来不是免检证。

覆盖面更麻烦。

攻击者把通信放进 HTTPS、WebSocket、HTTP/2、DNS 或正常业务协议里，这套“非 TLS 加密梳理”就未必碰得到。攻击流量绕过镜像点，只出现在内网东西向链路上，边界设备看到的内容也不完整。

还有一类更麻烦的情况：WebShell 不回显，或者固定返回相同长度；后门只驻留在内存里，磁盘上没有文件；攻击者直接复用企业已有的加密接口。碰到这些情况，“低频、404、响应变长”都可能消失。

所以，加密业务梳理不是 WebShell 检测的终点，只是提供了一批更值得调查的对象。

正常的 WebShell 排查，到底怎么查

排查 WebShell，不能只盯文件，也不能只盯流量。比较稳的做法，是沿着攻击执行链往下追。

先看请求有没有进来。

流量和访问日志里重点找新 URI、异常 POST、文件上传后立即访问、静态资源路径接收动态参数、状态码和响应内容不匹配，以及低频但规律的访问。HTTPS 流量最好去反向代理、WAF、API 网关或服务端 TLS 终止点查解密后的日志，只看 TLS 外壳很难判断里面发生了什么。

再看应用有没有接住。

访问日志只能说明请求到了服务器。应用日志、上传记录、后台登录、插件安装和数据库操作，才能补上业务上下文。一次异常请求后面紧跟文件上传、配置修改或管理员操作，风险就要往上提。

接着看主机有没有执行。

这一层最关键。Web 服务进程如果拉起了 cmd、PowerShell、Shell、Python 或下载工具，证据强度远高于“Body 看起来像密文”。Web 根目录突然多出脚本、临时目录写入可执行文件、Web 进程读取应用凭据、服务器随后连接陌生地址，也都要追到底。

Java 内存马还得换个查法。磁盘扫描未必能找到文件，安全人员还要检查运行时里新注册的 Filter、Listener、Servlet、Agent 和异常模块，必要时分析进程内存。

最后把时间对上。

一条完整的时间线可能长这样：

10:01  可疑请求到达上传接口
10:01  Web 目录出现异常脚本
10:02  外部地址访问这个脚本
10:02  Web 服务进程启动命令解释器
10:03  子进程读取应用配置和凭据
10:04  服务器连接陌生外部地址

请求、文件、进程和外联落在同一个时间窗口，WebShell 是否执行、执行后做了什么，才有证据回答。

如果手里只有一段高熵 Body、一个 404 和一条恶意 IP 情报，最多只能报“疑似”。没有主机行为和日志闭环，直接写成“WebShell 攻击成功”，很容易把研判做过头。

台账怎么用，才不至于沦为表格

加密业务台账至少要记清几件事：谁访问谁，走哪个域名和 URI，什么时候第一次出现，平时多久调用一次，请求和响应有什么固定特征，业务用途是什么，负责人是谁，最后一次确认是什么时候。

台账不是建完就放着。新增通信出现以后，要尽快找人确认；业务下线以后，要及时移出基线；已经认领的接口如果访问来源、频率或报文结构突然变化，也要重新审核。

排查优先级可以这样理解：

• 新出现、没人认领，先加一分；
• 来源有恶意记录，再加一分；
• 低频访问，像人在手工操作，再加一分；
• 状态码固定，响应内容却一直变，再加一分；
• 目标还是一台对外服务器或高价值主机，优先往前排；
• 请求之后出现异常文件、子进程或外联，立刻进入主机调查。

前面几项负责找线索，最后一项开始接近事实。

找到异常流量，只是排查刚刚开始

从几千万条流量里整理私有加密业务，确实是一种聪明的办法。安全人员不必和每一种魔改算法硬碰硬，也不用在海量请求里盲目回捞。

但这招的作用要说准。先用台账降噪，再从流量里找入口；请求落到了哪段应用、起了什么进程、连了什么外部地址，还得靠应用和主机日志接着查。时间线对不上，结论就不能下死。

几千万条流量不是最难的问题。最难的是企业连正常业务都说不清，或者安全团队抓到一条异常请求，就把“可疑”写成“攻击成功”。

先把要查的对象从几千万条缩到十几条，再沿着请求、应用、进程和外联一路查到底。前半段是方法，后半段才是定性。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：MessFreeSecurity messfree messfree《几千万条流量里捞 WebShell，这招好用，但别用错了》