Wireshark实战：识别中国菜刀、蚁剑、冰蝎、哥斯拉四类Webshell流量特征

1. 项目概述：为什么需要识别Webshell流量？

在安全运维和应急响应的日常工作中，Webshell的检测与处置是绕不开的核心议题。Webshell，这个被上传到Web服务器上的恶意脚本，就像一把插在服务器心脏上的“后门钥匙”。攻击者通过它，可以在不触发常规安全告警的情况下，远程执行命令、窃取数据、甚至作为跳板进行横向渗透。传统的基于文件特征码的杀毒软件，或者基于行为规则的HIDS（主机入侵检测系统），在面对日益“免杀化”、“混淆化”的Webshell时，常常力不从心。更棘手的是，攻击者一旦得手，其后续的远程控制流量，往往伪装在正常的HTTP/HTTPS协议中，如同水滴入海，难以分辨。

这时，网络流量分析的价值就凸显出来了。无论Webshell本身如何伪装，攻击者与它之间的“对话”——即网络流量——总会留下痕迹。Wireshark作为一款开源、强大且被广泛使用的网络协议分析工具，为我们提供了透视这些“对话”的显微镜。通过分析流量中的协议特征、载荷内容、交互模式，我们可以绕过文件层面的对抗，直接从通信行为上识别出异常。这不仅是应急响应中溯源分析的关键，也是构建纵深防御体系、完善检测规则（如用于Suricata、Snort等NIDS）的重要数据来源。

本指南将聚焦于实战中最常遇到的四款经典Webshell管理工具：中国菜刀、蚁剑、冰蝎和哥斯拉。它们各有特色，流量特征也迥然不同。掌握通过Wireshark快速识别它们的方法，意味着你能在安全事件发生时，更快地定位威胁、理解攻击者意图并采取遏制措施。这不仅仅是工具的使用教学，更是一种从网络层面思考安全问题的视角训练。

2. 核心思路：从混沌流量中提取特征指纹

面对海量的网络数据包，直接进行人工分析无异于大海捞针。我们的核心思路是“由面到点，由协议到载荷”，层层递进，逐步缩小可疑范围，最终定位到特征性的“指纹”。这个分析流程可以固化为一套可重复的方法论。

2.1 分析流程总览

一个高效的Webshell流量识别流程，通常遵循以下四个步骤：

1. 流量捕获与过滤：首先，我们需要在正确的网络位置（如Web服务器前端、核心交换机镜像口）捕获到完整的双向流量。然后，使用Wireshark的显示过滤器，快速聚焦到与疑似受害IP和Web服务端口（通常是80/443）相关的数据包，排除无关干扰。
2. 协议行为初筛：在HTTP/HTTPS流量中，初步观察其协议行为是否反常。例如，一个普通的网页浏览请求和Webshell的命令执行请求，在请求频率、数据包长度分布、交互模式上可能存在肉眼可见的差异。
3. 载荷深度解析：这是最关键的一步。我们需要深入查看HTTP请求的请求体（POST Data）和响应体。通过Wireshark的“追踪流”功能，重组应用层数据，并仔细观察其中是否包含可疑的关键字、编码模式（如Base64、十六进制）、序列化数据或特定工具的标识符。
4. 特征匹配与判定：将观察到的可疑特征，与已知的Webshell管理工具的特征库进行比对。这些特征包括但不限于：特定的URL参数名、Cookie字段、HTTP头部、载荷中的魔术字、加密前的固定字符串等。一旦匹配成功，即可做出判定。

这个流程的成功，依赖于对工具本身通信原理的理解。接下来，我们将深入这四款工具的通信机制，理解其流量特征的产生根源。

2.2 工具通信原理与特征根源

为什么不同工具的流量看起来不一样？根本在于它们的设计理念和实现方式。

• 中国菜刀：属于“上古神器”，设计简单直接。其流量通常是明文或经过简单的Base64/十六进制编码。它在请求中会通过固定的参数（如z0）传递经过编码的命令，响应也是直接的命令输出编码。特征非常明显，几乎“写在脸上”。
• 蚁剑：作为菜刀的现代化继承者，它采用了插件化架构和更多的编码器。默认情况下，其流量也包含特征明显的参数（如_0x...这种形式的参数名）和可识别的载荷结构。虽然支持自定义，但很多使用者会采用默认配置，从而暴露特征。
• 冰蝎：这是一款在流量隐蔽性上实现飞跃的工具。它的核心特征在于动态密钥协商和全程加密通信。客户端与Webshell首次连接时，会协商一个只有双方知道的密钥，后续所有指令和输出都使用此密钥进行AES等加密。因此，其流量在Wireshark中查看，通常是毫无规律、高熵的二进制数据，传统的关键字搜索完全失效。
• 哥斯拉：可以看作是冰蝎思路的进一步拓展和复杂化。它同样采用强加密通信，并且支持更多的加密算法和编码方式。此外，哥斯拉在HTTP头部、Cookie等处也做了更多的随机化和伪装，使得其流量更像正常的浏览器请求，隐蔽性极强。

理解这些原理差异，是我们能识别它们的前提。对于菜刀、蚁剑，我们主要进行“特征匹配”；对于冰蝎、哥斯拉，我们则需要进行“行为异常分析”和“加密流量识别”。

注意：本文讨论的特征是基于这些工具的常见默认配置或典型使用模式。高水平的攻击者会修改源代码、自定义编码器和通信协议，以规避检测。因此，流量分析不能作为唯一的检测手段，必须与日志分析、主机行为监控相结合。

3. 实战环境搭建与Wireshark准备

在开始分析之前，我们需要一个受控的实战环境。强烈建议在虚拟机或隔离的网络环境中进行以下操作，切勿在生产环境或非授权系统上尝试。

3.1 实验环境配置

1. 靶机：准备一台虚拟机，安装带有PHP/ASP/ASP.NET/JSP等一种或多种语言环境的Web服务器（如Apache + PHP， 或IIS）。这里以Apache + PHP为例。
2. Webshell准备：从安全研究渠道获取上述四款工具的典型Webshell服务端脚本。例如：
   • 菜刀：一个包含@eval($_POST[‘z0’]);的PHP文件。
   • 蚁剑：使用蚁剑生成器生成的默认编码的PHP Shell。
   • 冰蝎：使用冰蝎自带的服务器端脚本，如server.jsp。
   • 哥斯拉：使用哥斯拉生成的相应脚本。 将这些脚本上传到靶机的Web目录下，并记录访问地址。
3. 攻击机：另一台虚拟机，安装中国菜刀、蚁剑、冰蝎、哥斯拉的客户端。确保攻击机与靶机网络互通。
4. 监控点：这是关键。有两种方式捕获流量：
   • 在靶机上直接抓包：在靶机系统上安装Wireshark或使用tcpdump命令行工具，监听提供Web服务的网卡（如eth0）。
   • 在网络中镜像流量：更接近实战的场景。将靶机所在的网络端口流量镜像到运行Wireshark的监控机上。这需要在交换机上配置端口镜像（SPAN）。

3.2 Wireshark关键配置与过滤技巧

安装好Wireshark后，进行以下配置能让分析事半功倍：

1. 首选项设置：

   • 外观 -> 列：建议添加“Src Port (源端口)”和“Dst Port (目标端口)”列，方便快速查看通信双方。
   • 协议 -> HTTP：确保启用了“Reassemble HTTP bodies spanning multiple TCP segments”（重组跨TCP分片的HTTP主体），这对于查看完整的POST数据至关重要。

2. 核心显示过滤器： 捕获到海量数据包后，使用显示过滤器快速定位：

   • ip.addr == 192.168.1.100：只看与特定IP（假设靶机IP）相关的所有流量。
   • http：只显示HTTP协议流量。
   • tcp.port == 80：显示源或目的端口为80的TCP流量。
   • 组合过滤：ip.addr == 192.168.1.100 and tcp.port == 80可以精确定位到靶机的Web流量。
   • http.request.method == POST：只查看POST请求，因为Webshell命令执行大多通过POST传递。
   • tcp contains “eval”：在TCP载荷中搜索明文关键字“eval”（注意，这对加密流量无效）。这是一个简单但有时有效的初步筛查。

3. 关键功能：“追踪流”： 在任何一个HTTP请求或响应包上右键，选择“追踪流 -> TCP流”或“追踪流 -> HTTP流”。这个功能会将一次完整的TCP会话或HTTP事务的所有数据重组并显示在一个窗口里，并以ASCII或十六进制形式呈现。这是分析Webshell载荷最常用、最强大的功能，没有之一。窗口上方可以选择“整个会话”、“客户端到服务器”（请求）、“服务器到客户端”（响应），并可以切换显示格式（ASCII, 十六进制， C数组等）。对于加密流量，十六进制视图可能更有用。

4. 四款Webshell流量特征深度解析

现在，我们进入最核心的部分。假设我们已经捕获了一次完整的Webshell连接和操作流量，我们将逐一拆解它们的特征。

4.1 中国菜刀：特征明显的“古典派”

菜刀的流量几乎是最容易识别的。

特征一：固定的请求参数在Wireshark中追踪其TCP流，你会清晰地看到POST请求中有一个固定的参数名。对于PHP版本，通常是z0、z1、z2等。例如：

POST /shell.php HTTP/1.1 ... Content-Type: application/x-www-form-urlencoded z0=QGV2YWwoJF9QT1NUWyd6MSddKTs%3D&z1=ZWNobyAnSGVsbG8gQ2hpbmVzZSBDaG9wcGVyJzs%3D

这里z0的值是一段Base64编码（%3D是=的URL编码），解码后通常是@eval($_POST[‘z1’]);。而z1的值是另一段Base64，解码后是实际的PHP命令，如echo ‘Hello Chinese Chopper’;。

特征二：编码模式固定菜刀默认使用Base64编码，有时也会使用十六进制编码。在流量中，你会看到大量由A-Z, a-z, 0-9, +, /及填充符=组成的字符串，这是典型的Base64特征。即使参数名被修改，这种密集的、作为参数值的Base64串出现在POST请求中，也是极高的可疑信号。

特征三：响应内容特征服务器响应同样包含特征。成功执行命令后，响应体开头通常会有一个固定的“标识头”，后面跟着命令输出。这个标识头在菜刀的各个版本中可能不同，但通常是一个可打印字符的固定组合，用于客户端识别响应开始。在TCP流中，你可能会在返回的HTML源码前看到类似{phpinfo};或其它特定分隔符。

Wireshark快速识别法：

1. 过滤POST请求：http.request.method == POST
2. 在列表栏查看Info列，如果看到POST请求的URI路径可疑（如随机文件名）。
3. 选中该包，右键追踪流 -> TCP流。
4. 在ASCII视图中，直接搜索z0、z1、z2或base64样式的长字符串。几乎一眼可辨。

4.2 蚁剑：继承与演变

蚁剑的默认流量比菜刀稍隐蔽，但特征依然显著。

特征一：参数名特征蚁剑默认生成的Payload，其请求参数名具有明显的模式，通常以_0x开头，后面跟着一串十六进制数字，例如_0x5c8f、_0x3bf2等。这是其前端代码动态生成参数名时留下的特征。

POST /antsword.php HTTP/1.1 ... Content-Type: application/x-www-form-urlencoded _0x5c8f=Y21k&_0x3bf2=ZWNobyAnSGVsbG8gQW50U3dvcmQnOw%3D%3D

特征二：载荷结构特征即使参数名被自定义，其载荷内容也可能暴露。蚁剑的通信协议有固定的结构。在TCP流中，你可能会看到经过Base64编码的JSON数据。解码后，其结构类似：

{"action": "exec", "data": {"cmd": "whoami"}}

或者看到一些固定的键名，如iv、data（如果使用了加密插件），但默认的编码器下，结构相对固定。

特征三：Cookie或Header中的标识某些版本的蚁剑或特定配置下，会在HTTP请求的Cookie或User-Agent头部插入可识别的字符串，作为“密码”或标识。

Wireshark快速识别法：

1. 过滤POST请求到可疑路径。
2. 追踪TCP流，在ASCII视图中查找_0x开头的参数名。
3. 如果没有，查看整个请求体，寻找类似Base64编码的长字符串，尝试解码。如果解码后的字符串包含action、cmd、path等JSON键名，嫌疑很大。
4. 检查HTTP头部的Cookie和User-Agent字段，寻找异常值。

4.3 冰蝎：加密流量的挑战者

冰蝎的流量分析是真正的挑战，因为你看不到任何明文的可读内容。

特征一：首次请求的“握手”特征这是识别冰蝎最关键的一步。客户端首次连接Webshell时，会发送一个特殊的GET或POST请求，用于密钥协商。这个请求的URL可能带有特定参数，或者其响应体是固定的、用于计算密钥的“密钥因子”。在Wireshark中，你需要找到这个“第一次”请求。它的响应内容长度固定且较短（如16字节、32字节），内容看起来是随机二进制数据。这与其他正常的网页请求截然不同。

特征二：后续流量的高熵与固定长度密钥协商成功后，所有后续请求和响应都变为加密状态。在Wireshark中观察这些数据包：

• 内容不可读：追踪TCP流，无论是ASCII视图还是十六进制视图，都看不到任何可读的英文单词、命令或路径，全是乱码。
• 熵值高：数据看起来完全随机，没有明显的模式。
• 长度可能规整：由于使用AES等分组加密算法，密文长度往往是16字节（AES块大小）的整数倍。你可以观察连续多个POST请求的Content-Length，它们可能非常接近甚至是相同的值（因为执行不同命令的请求结构被填充到了相同长度）。

特征三：HTTP头部相对“干净”冰蝎的默认配置下，其HTTP头部（如User-Agent）会模仿得比较像正常浏览器，没有明显的工具特征。这增加了识别难度。

Wireshark快速识别法（行为分析法）：

1. 寻找“孤立的”加密会话：找到一个与Web服务器IP的TCP会话，其流量模式为：1个简短的HTTP请求/响应（可能是密钥协商），紧接着一系列Content-Length较大且数值规整的POST请求和响应。
2. 检查响应内容：选中一个后续的POST请求的响应包，追踪TCP流。如果响应体全部是乱码，且长度可能是16的倍数，嫌疑激增。
3. 对比基线：对比同一Web服务器上其他正常页面的访问流量。正常页面（如首页、登录页）的请求响应内容通常是HTML、JSON等可读文本或格式数据。一个访问/admin.jsp（假设）却返回完全加密二进制数据的连接，极不正常。
4. 辅助判断：虽然内容加密，但URL路径可能具有Webshell特征，如非常规的、随机字符串命名的.jsp、.php文件。

4.4 哥斯拉：集大成的“隐身者”

哥斯拉继承了冰蝎的加密通信思想，并做了更多伪装。

特征一：动态的HTTP头部哥斯拉可以随机生成每次请求的HTTP头部，包括User-Agent、Accept、Accept-Language等，使其看起来更像来自不同浏览器或设备的请求，规避基于固定Header的简单规则匹配。

特征二：Cookie中可能携带加密信息哥斯拉有时会将一些会话状态或校验信息加密后放在Cookie中传递，而不是全部放在POST体内。这使得其流量在表面上更分散。

特征三：多阶段与多协议支持哥斯拉支持更多的加密算法和通信模式，可能使用multipart/form-data格式上传文件，其流量模式比冰蝎更多变。但其核心特征依然是：通信主体内容（无论是POST体还是部分Cookie值）是加密的高熵数据。

特征四：连接保活与心跳哥斯拉的连接可能具有更长的时间周期和规律的心跳包，以维持会话。在流量中可能表现为，在长时间无操作后，仍有定时的、小数据量的POST请求发生。

Wireshark快速识别法： 识别哥斯拉需要结合冰蝎的识别方法，并更加关注行为异常和元数据特征。

1. 加密内容判断：同冰蝎，确认通信主体是否为不可读的加密数据。
2. 头部随机性分析：观察来自同一源IP的多个请求，其User-Agent等头部是否在频繁、无规律地变化（正常用户会话通常保持相对稳定）。
3. URL与参数异常：虽然内容加密，但请求的URL路径、查询字符串（如果有）可能显得突兀。例如，对一张图片的URL（如.jpg）发起大量POST请求，这本身就很可疑。
4. 会话持续性：观察TCP会话的持续时间、数据包数量。一个长时间存在、进行多次POST交互、但从未请求过任何静态资源（如CSS, JS, 图片）的会话，非常可疑。

5. 实战演练：从抓包到判定的完整过程

让我们模拟一个实战场景：监控报警显示内网一台Web服务器（192.168.56.101）存在异常外连行为。你被要求快速分析其流量，判断是否被植入Webshell。

步骤1：定位与过滤你在核心交换机上已经镜像了该服务器的流量，并保存为webserver.pcapng。用Wireshark打开。 首先，应用过滤器：ip.addr == 192.168.56.101 and tcp.port == 80。这能聚焦到该服务器所有的HTTP流量。

步骤2：协议行为初筛浏览过滤后的数据包列表。你注意到除了大量的GET /index.php、GET /static/logo.png等正常请求外，有一个TCP会话格外显眼：

• 它访问的路径是/wp-content/uploads/temp/下的一个随机名.php文件（假设网站是WordPress）。
• 该会话中，先是一个简短的GET请求（可能返回200 OK，但内容长度很短，比如50字节），紧接着是几十个POST请求到这个同一文件。
• 这些POST请求的Content-Length都在1000字节左右，非常稳定。
• 而服务器的响应Content-Length也很大（几百到几千字节），但请求和响应之间没有夹杂任何对图片、样式表等资源的请求。

这种“单一端点、密集POST、无资源加载”的模式，已经高度可疑。你右键点击第一个POST包，选择追踪流 -> TCP流。

步骤3：载荷深度解析TCP流窗口打开。你切换到ASCII视图。

• 情况A：你看到了明文的z0=...和Base64字符串。结论：高度疑似中国菜刀。
• 情况B：你看到了_0x5c8f=...之类的参数名。结论：高度疑似蚁剑。
• 情况C：你看到的请求体和响应体全是乱码，像‰PNG...开头但又不对，或者完全是不可读字符。你尝试在流里搜索eval、system、POST等关键字，一无所获。结论：流量被加密，疑似冰蝎或哥斯拉。

步骤4：特征匹配与最终判定针对情况C，你需要进一步判断：

1. 你仔细看这个TCP流的开头。发现第一个客户端请求是一个GET请求到那个php文件，没有参数。服务器响应很短，内容是6gB1fP...（一段Base64样式的字符串，但解码后也是乱码）。这符合冰蝎的密钥协商特征。
2. 你查看后续POST请求的HTTP头部。User-Agent是Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36，看起来正常。Cookie为空。
3. 你注意到所有POST请求的Content-Type都是application/x-www-form-urlencoded，但载荷却是二进制。这有点矛盾，正常该类型的POST体应该是键值对文本。
4. 你对比另一个正常用户登录的POST请求（/wp-login.php），其TCP流里清晰可见log=admin&pwd=...这样的明文。

基于以上：首次特殊GET请求、后续POST内容全加密、Content-Type与内容不符、与正常流量对比鲜明。最终判定：该流量符合冰蝎Webshell通信特征。

你可以将相关IP、端口、URL路径、以及这个特征（“与特定URI的TCP会话，首次为短响应GET，后续为固定长度加密POST”）记录下来，作为安全事件响应的证据，并可以此特征编写入侵检测系统的规则。

6. 进阶技巧与自动化识别思路

手动分析在应急时很有效，但无法应对海量流量。我们需要将其转化为自动化能力。

6.1 Wireshark显示过滤器与着色规则

你可以将上述特征保存为Wireshark的显示过滤器或着色规则，实现快速高亮。

• 菜刀过滤器：http.request.uri contains “.php” and http.request.method == “POST” and (tcp contains “z0=” or tcp contains “z1=”)
• 蚁剑过滤器：http.request.method == “POST” and http.request.uri matches “\\.(php|jsp|asp|aspx)$” and frame contains “_0x”（注意：frame contains可能性能较差，仅用于小流量分析）
• 冰蝎/哥斯拉（行为过滤）：这个更复杂，可以尝试过滤出那些响应内容长度较大但内容看似“非文本”的请求。一个粗略的思路是寻找Content-Type为text/html但内容非ASCII的响应。但这可能误报。更可靠的是在NIDS中实现。

你可以为这些过滤器设置不同的颜色（如菜刀标红，蚁剑标黄），这样在捕获流量时，可疑连接会立即突显出来。

6.2 编写Suricata/Snort规则

网络入侵检测系统（NIDS）如Suricata和Snort，可以实时分析流量。我们可以将特征提炼成规则。

• 菜刀规则示例（Suricata格式）：

  alert http any any -> $HOME_NET any (msg:"WEBSHELL Possible China Chopper Activity"; flow:established,to_server; http.method; content:"POST"; http.uri; content:".php"; fast_pattern; content:"z0="; http.client_body; depth:4; sid:1000001; rev:1;)

  这条规则检测：流向内网的HTTP流量，方法是POST，URI包含.php，并且客户端请求体中含有z0=字符串。

• 冰蝎规则（基于首次响应特征）： 这需要更精细的规则，可能需要对首次响应的长度和内容熵进行判断。一个简化的思路是检测对特定扩展名文件的请求，其响应长度非常短（如16-64字节）且紧接着有加密POST。这可能需要结合多个规则或使用Lua脚本实现更复杂的逻辑。

6.3 流量行为画像与机器学习

对于冰蝎、哥斯拉这种加密Webshell，传统特征匹配失效。此时需要采用流量行为分析（Network Traffic Analysis, NTA）。

• 统计特征：计算一个HTTP会话的以下特征：POST请求数量占比、请求/响应数据包平均大小、请求间隔时间规律性、会话持续时间、上行/下行流量比等。Webshell会话的这些特征可能与正常API调用或网页浏览有显著差异。
• 熵值计算：计算请求体和响应体的信息熵。加密数据的熵值通常远高于未加密的文本或HTML。
• 机器学习模型：收集大量正常的Web流量和已知的Webshell流量作为训练集，提取上述行为特征和统计特征，训练分类模型（如随机森林、XGBoost）。模型可以学习到正常与异常流量的微妙差异，从而识别出新型或变种的加密Webshell。

在实际工作中，手动Wireshark分析是“最后一公里”的深度验证和取证，而自动化规则和NTA系统才是7x24小时守护网络的“哨兵”。两者结合，方能构建起有效的Webshell流量检测防线。

7. 常见问题与排查技巧实录

在实际分析中，你会遇到各种复杂情况。以下是一些常见问题及处理思路：

问题1：流量是HTTPS加密的，Wireshark看到的是TLS记录，怎么办？这是最大的挑战。要解密HTTPS流量，需要满足以下条件之一：

• 拥有服务器私钥：在Web服务器上配置Wireshark或tcpdump，将RSA私钥导入Wireshark（编辑 -> 首选项 -> Protocols -> TLS -> RSA keys list）。这样Wireshark可以解密所有到此服务器的TLS流量。（仅用于安全测试和内部排查，切勿泄露私钥！）
• 中间人解密（有条件）：在内网部署SSL/TLS解密代理，所有流量经过该代理解密后再转发。这需要部署专门的设备或软件，并处理好证书信任问题。
• 分析元数据：如果无法解密内容，只能分析元数据：TLS握手阶段使用的协议版本、密码套件（可能与客户端工具有关）、服务器证书信息（是否自签名、异常）、连接的时间规律、数据包长度和频率的异常模式等。这些信息价值有限。

问题2：攻击者使用了自定义编码或加密，特征不明显怎么办？

• 回归行为分析：放弃对载荷内容的直接解读，专注于会话行为异常。参考第6.3节的行为画像方法。
• 上下文关联：这个可疑连接发生前，是否有文件上传漏洞的利用流量？是否有登录爆破的流量？将Webshell连接与前期攻击入口点关联起来。
• 主机侧验证：流量分析存疑时，立即登录可疑服务器进行主机侧排查。检查Web目录下最近修改的文件、异常进程、网络连接（netstat -antp），与流量分析结果相互印证。

问题3：Wireshark过滤器似乎不起作用，抓不到想要的包？

• 确认捕获位置：确保Wireshark在正确的网卡上抓包。如果监控镜像口，确保交换机镜像配置正确。
• 检查过滤器语法：Wireshark显示过滤器语法严格。http和http.request不同；contains对大小写敏感。使用自动补全功能减少错误。
• 使用更宽泛的过滤器：如果ip.addr and tcp.port过滤后无结果，先尝试只使用ip.addr == x.x.x.x，看看是否有该IP的任何流量，确认流量是否真的被捕获。

问题4：如何区分冰蝎和哥斯拉的流量？在Wireshark层面，仅通过单次流量捕获很难100%区分。可以关注以下几点倾向性特征：

• 哥斯拉的头部伪装更彻底：观察连续请求中的User-Agent、Accept-Language等字段，如果变化多端且无规律，哥斯拉的可能性更大。
• 哥斯拉可能使用Cookie传递数据：检查Cookie字段，如果存在长且看起来随机的字符串，并随着请求变化，可能是哥斯拉。
• 工具指纹：如果能在客户端或服务器端获取样本，进行静态分析是更准确的方法。流量分析更多是用于发现和预警。

一个关键的排查技巧：对比分析法。在分析可疑流量时，永远不要孤立地看它。同时打开一个已知正常的、对同一网站的用户访问流量（例如，你手动访问一下网站首页和登录页面）。将两个TCP流窗口并排对比，观察它们在请求频率、数据包大小分布、载荷可读性、HTTP头部完整性、交互模式上的差异。这种差异往往比任何单一特征都更能说明问题。正常的用户流量是“杂乱”的（请求HTML、JS、CSS、图片，有重定向，有缓存请求），而Webshell流量通常是“纯净”的（只与一个动态脚本进行密集的、结构化的数据交换）。培养这种对比的直觉，能极大提升你的分析速度和准确度。