1. 项目概述为什么需要识别Webshell流量在安全运维和应急响应的日常工作中Webshell的检测与处置是绕不开的核心议题。Webshell这个被上传到Web服务器上的恶意脚本就像一把插在服务器心脏上的“后门钥匙”。攻击者通过它可以在不触发常规安全告警的情况下远程执行命令、窃取数据、甚至作为跳板进行横向渗透。传统的基于文件特征码的杀毒软件或者基于行为规则的HIDS主机入侵检测系统在面对日益“免杀化”、“混淆化”的Webshell时常常力不从心。更棘手的是攻击者一旦得手其后续的远程控制流量往往伪装在正常的HTTP/HTTPS协议中如同水滴入海难以分辨。这时网络流量分析的价值就凸显出来了。无论Webshell本身如何伪装攻击者与它之间的“对话”——即网络流量——总会留下痕迹。Wireshark作为一款开源、强大且被广泛使用的网络协议分析工具为我们提供了透视这些“对话”的显微镜。通过分析流量中的协议特征、载荷内容、交互模式我们可以绕过文件层面的对抗直接从通信行为上识别出异常。这不仅是应急响应中溯源分析的关键也是构建纵深防御体系、完善检测规则如用于Suricata、Snort等NIDS的重要数据来源。本指南将聚焦于实战中最常遇到的四款经典Webshell管理工具中国菜刀、蚁剑、冰蝎和哥斯拉。它们各有特色流量特征也迥然不同。掌握通过Wireshark快速识别它们的方法意味着你能在安全事件发生时更快地定位威胁、理解攻击者意图并采取遏制措施。这不仅仅是工具的使用教学更是一种从网络层面思考安全问题的视角训练。2. 核心思路从混沌流量中提取特征指纹面对海量的网络数据包直接进行人工分析无异于大海捞针。我们的核心思路是“由面到点由协议到载荷”层层递进逐步缩小可疑范围最终定位到特征性的“指纹”。这个分析流程可以固化为一套可重复的方法论。2.1 分析流程总览一个高效的Webshell流量识别流程通常遵循以下四个步骤流量捕获与过滤首先我们需要在正确的网络位置如Web服务器前端、核心交换机镜像口捕获到完整的双向流量。然后使用Wireshark的显示过滤器快速聚焦到与疑似受害IP和Web服务端口通常是80/443相关的数据包排除无关干扰。协议行为初筛在HTTP/HTTPS流量中初步观察其协议行为是否反常。例如一个普通的网页浏览请求和Webshell的命令执行请求在请求频率、数据包长度分布、交互模式上可能存在肉眼可见的差异。载荷深度解析这是最关键的一步。我们需要深入查看HTTP请求的请求体POST Data和响应体。通过Wireshark的“追踪流”功能重组应用层数据并仔细观察其中是否包含可疑的关键字、编码模式如Base64、十六进制、序列化数据或特定工具的标识符。特征匹配与判定将观察到的可疑特征与已知的Webshell管理工具的特征库进行比对。这些特征包括但不限于特定的URL参数名、Cookie字段、HTTP头部、载荷中的魔术字、加密前的固定字符串等。一旦匹配成功即可做出判定。这个流程的成功依赖于对工具本身通信原理的理解。接下来我们将深入这四款工具的通信机制理解其流量特征的产生根源。2.2 工具通信原理与特征根源为什么不同工具的流量看起来不一样根本在于它们的设计理念和实现方式。中国菜刀属于“上古神器”设计简单直接。其流量通常是明文或经过简单的Base64/十六进制编码。它在请求中会通过固定的参数如z0传递经过编码的命令响应也是直接的命令输出编码。特征非常明显几乎“写在脸上”。蚁剑作为菜刀的现代化继承者它采用了插件化架构和更多的编码器。默认情况下其流量也包含特征明显的参数如_0x...这种形式的参数名和可识别的载荷结构。虽然支持自定义但很多使用者会采用默认配置从而暴露特征。冰蝎这是一款在流量隐蔽性上实现飞跃的工具。它的核心特征在于动态密钥协商和全程加密通信。客户端与Webshell首次连接时会协商一个只有双方知道的密钥后续所有指令和输出都使用此密钥进行AES等加密。因此其流量在Wireshark中查看通常是毫无规律、高熵的二进制数据传统的关键字搜索完全失效。哥斯拉可以看作是冰蝎思路的进一步拓展和复杂化。它同样采用强加密通信并且支持更多的加密算法和编码方式。此外哥斯拉在HTTP头部、Cookie等处也做了更多的随机化和伪装使得其流量更像正常的浏览器请求隐蔽性极强。理解这些原理差异是我们能识别它们的前提。对于菜刀、蚁剑我们主要进行“特征匹配”对于冰蝎、哥斯拉我们则需要进行“行为异常分析”和“加密流量识别”。注意本文讨论的特征是基于这些工具的常见默认配置或典型使用模式。高水平的攻击者会修改源代码、自定义编码器和通信协议以规避检测。因此流量分析不能作为唯一的检测手段必须与日志分析、主机行为监控相结合。3. 实战环境搭建与Wireshark准备在开始分析之前我们需要一个受控的实战环境。强烈建议在虚拟机或隔离的网络环境中进行以下操作切勿在生产环境或非授权系统上尝试。3.1 实验环境配置靶机准备一台虚拟机安装带有PHP/ASP/ASP.NET/JSP等一种或多种语言环境的Web服务器如Apache PHP 或IIS。这里以Apache PHP为例。Webshell准备从安全研究渠道获取上述四款工具的典型Webshell服务端脚本。例如菜刀一个包含eval($_POST[‘z0’]);的PHP文件。蚁剑使用蚁剑生成器生成的默认编码的PHP Shell。冰蝎使用冰蝎自带的服务器端脚本如server.jsp。哥斯拉使用哥斯拉生成的相应脚本。 将这些脚本上传到靶机的Web目录下并记录访问地址。攻击机另一台虚拟机安装中国菜刀、蚁剑、冰蝎、哥斯拉的客户端。确保攻击机与靶机网络互通。监控点这是关键。有两种方式捕获流量在靶机上直接抓包在靶机系统上安装Wireshark或使用tcpdump命令行工具监听提供Web服务的网卡如eth0。在网络中镜像流量更接近实战的场景。将靶机所在的网络端口流量镜像到运行Wireshark的监控机上。这需要在交换机上配置端口镜像SPAN。3.2 Wireshark关键配置与过滤技巧安装好Wireshark后进行以下配置能让分析事半功倍首选项设置外观 - 列建议添加“Src Port (源端口)”和“Dst Port (目标端口)”列方便快速查看通信双方。协议 - HTTP确保启用了“Reassemble HTTP bodies spanning multiple TCP segments”重组跨TCP分片的HTTP主体这对于查看完整的POST数据至关重要。核心显示过滤器 捕获到海量数据包后使用显示过滤器快速定位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”注意这对加密流量无效。这是一个简单但有时有效的初步筛查。关键功能“追踪流” 在任何一个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 z0QGV2YWwoJF9QT1NUWyd6MSddKTs%3Dz1ZWNobyAnSGVsbG8gQ2hpbmVzZSBDaG9wcGVyJzs%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快速识别法过滤POST请求http.request.method POST在列表栏查看Info列如果看到POST请求的URI路径可疑如随机文件名。选中该包右键追踪流 - TCP流。在ASCII视图中直接搜索z0、z1、z2或base64样式的长字符串。几乎一眼可辨。4.2 蚁剑继承与演变蚁剑的默认流量比菜刀稍隐蔽但特征依然显著。特征一参数名特征蚁剑默认生成的Payload其请求参数名具有明显的模式通常以_0x开头后面跟着一串十六进制数字例如_0x5c8f、_0x3bf2等。这是其前端代码动态生成参数名时留下的特征。POST /antsword.php HTTP/1.1 ... Content-Type: application/x-www-form-urlencoded _0x5c8fY21k_0x3bf2ZWNobyAnSGVsbG8gQW50U3dvcmQnOw%3D%3D特征二载荷结构特征即使参数名被自定义其载荷内容也可能暴露。蚁剑的通信协议有固定的结构。在TCP流中你可能会看到经过Base64编码的JSON数据。解码后其结构类似{action: exec, data: {cmd: whoami}}或者看到一些固定的键名如iv、data如果使用了加密插件但默认的编码器下结构相对固定。特征三Cookie或Header中的标识某些版本的蚁剑或特定配置下会在HTTP请求的Cookie或User-Agent头部插入可识别的字符串作为“密码”或标识。Wireshark快速识别法过滤POST请求到可疑路径。追踪TCP流在ASCII视图中查找_0x开头的参数名。如果没有查看整个请求体寻找类似Base64编码的长字符串尝试解码。如果解码后的字符串包含action、cmd、path等JSON键名嫌疑很大。检查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快速识别法行为分析法寻找“孤立的”加密会话找到一个与Web服务器IP的TCP会话其流量模式为1个简短的HTTP请求/响应可能是密钥协商紧接着一系列Content-Length较大且数值规整的POST请求和响应。检查响应内容选中一个后续的POST请求的响应包追踪TCP流。如果响应体全部是乱码且长度可能是16的倍数嫌疑激增。对比基线对比同一Web服务器上其他正常页面的访问流量。正常页面如首页、登录页的请求响应内容通常是HTML、JSON等可读文本或格式数据。一个访问/admin.jsp假设却返回完全加密二进制数据的连接极不正常。辅助判断虽然内容加密但URL路径可能具有Webshell特征如非常规的、随机字符串命名的.jsp、.php文件。4.4 哥斯拉集大成的“隐身者”哥斯拉继承了冰蝎的加密通信思想并做了更多伪装。特征一动态的HTTP头部哥斯拉可以随机生成每次请求的HTTP头部包括User-Agent、Accept、Accept-Language等使其看起来更像来自不同浏览器或设备的请求规避基于固定Header的简单规则匹配。特征二Cookie中可能携带加密信息哥斯拉有时会将一些会话状态或校验信息加密后放在Cookie中传递而不是全部放在POST体内。这使得其流量在表面上更分散。特征三多阶段与多协议支持哥斯拉支持更多的加密算法和通信模式可能使用multipart/form-data格式上传文件其流量模式比冰蝎更多变。但其核心特征依然是通信主体内容无论是POST体还是部分Cookie值是加密的高熵数据。特征四连接保活与心跳哥斯拉的连接可能具有更长的时间周期和规律的心跳包以维持会话。在流量中可能表现为在长时间无操作后仍有定时的、小数据量的POST请求发生。Wireshark快速识别法 识别哥斯拉需要结合冰蝎的识别方法并更加关注行为异常和元数据特征。加密内容判断同冰蝎确认通信主体是否为不可读的加密数据。头部随机性分析观察来自同一源IP的多个请求其User-Agent等头部是否在频繁、无规律地变化正常用户会话通常保持相对稳定。URL与参数异常虽然内容加密但请求的URL路径、查询字符串如果有可能显得突兀。例如对一张图片的URL如.jpg发起大量POST请求这本身就很可疑。会话持续性观察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你需要进一步判断你仔细看这个TCP流的开头。发现第一个客户端请求是一个GET请求到那个php文件没有参数。服务器响应很短内容是6gB1fP...一段Base64样式的字符串但解码后也是乱码。这符合冰蝎的密钥协商特征。你查看后续POST请求的HTTP头部。User-Agent是Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36看起来正常。Cookie为空。你注意到所有POST请求的Content-Type都是application/x-www-form-urlencoded但载荷却是二进制。这有点矛盾正常该类型的POST体应该是键值对文本。你对比另一个正常用户登录的POST请求/wp-login.php其TCP流里清晰可见logadminpwd...这样的明文。基于以上首次特殊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流量方法是POSTURI包含.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与流量分析结果相互印证。问题3Wireshark过滤器似乎不起作用抓不到想要的包确认捕获位置确保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流量通常是“纯净”的只与一个动态脚本进行密集的、结构化的数据交换。培养这种对比的直觉能极大提升你的分析速度和准确度。
