本篇将总结常见webshell（菜刀、蚁剑、冰蝎、哥斯拉）的流量分析以及流量特征，在下一篇文章中将给出冰蝎和哥斯拉的misc流量分析题目解题过程。

百度百科的定义：webshell就是以asp、php、jsp或者cgi等网页文件形式存在的一种代码执行环境，也可以将其称做为一种网页后门。黑客在入侵了一个网站后，通常会将asp或php后门文件与网站服务器WEB目录下正常的网页文件混在一起，然后就可以使用浏览器来访问asp或者php后门，得到一个命令执行环境，以达到控制网站服务器的目的。

通俗来讲，Webshell是黑客经常使用的一种恶意脚本，其目的是获得对服务器的执行操作权限，比如执行系统命令、窃取用户数据、删除web页面、修改主页等，其危害不言而喻。黑客通常利用常见的漏洞，如SQL注入、远程文件包含(RFI)、FTP，甚至使用跨站点脚本攻击(XSS)等方式作为社会工程攻击的一部分，最终达到控制网站服务器的目的。

虽然菜刀是比较老的webshell管理工具，而且现在用的也非常少，但还是需要了解一下它的流量特征。

图中为菜刀连接时产生的流量

首先，菜刀会伪造 X-Forwarded-For 头，且每一次利用菜刀与webshell建立连接，X-Forwarded-For 都会变化

将这段 post 请求先进行 url 解码

发现请求执行了 base64_decode 函数对 z0 进行 base64 后，经过 eval 函数执行命令，base64 解密 z0

这部分就是传输的 payload，首先关闭报错和 magic_quotes，接下来去获取主机的信息

这一段 QGluaV9zZXQoImRpc3BsYXlfZXJyb3JzIiwiMCIpO0BzZXRfdGltZV9saW1pdCgwKTs 将其base64解码，为@ini_set("display_errors","0");@set_time_limit(0); 流量特征明显，可以用插件做混淆处理

蚁剑同样是一款webshell管理工具，它的优点有许多，功能比菜刀还完善。与冰蝎不同的是，蚁剑没有单独的蚁剑木马，它采用的是跟中国菜刀一样原始的一句话木马。

蚁剑官方Github下载地址：AntSwordProject ，蚁剑安装不再赘述。

现在让我们来看看蚁剑是如何与服务器端通信的，在蚁剑中可以设置代理，这样我们就可以使用burpsuite进行抓包观察通信过程了。

数据包头“cmd”是木马的连接密码。可以看到中国蚁剑默认状态下的通信数据包仅仅做了URL编码处理，与明文无异，想过WAF基本上不可能。

众所周知，蚁剑所有脚本的源代码（php/asp/aspx等）均来自菜刀，所以流量特征也和菜刀差不多，过WAF基本不用想了。所以有了编码器和解码器，进行流量混淆可绕过WAF，并且编码器和解码器可以自定义，使用nodejs 编写即可，类似于插件很容易上手，先简单说明下编码器和解码器的作用。

可以看到一个对发送加密，一个对返回加解密，这样才能达到完美过WAF的目的。但是蚁剑自带的编码器其实过WAF还是比较勉强的，因为它的webshell脚本是最原始的一句话，如

根据上面提到的编码器作用，可以知道，服务端得进行解码才能正常接收，那像这种一句话是没法解码的（观察一下冰蝎马，发现冰蝎马中包含了加解密函数，因此可以直接解码，而蚁剑只有这一个一句话，没有函数服务端是一定不会加解密的），所以实际上是将解码函数一同发送到服务端，那几个解码函数是没法加密的，这就是一个很明显的特征。（关于这点有疑问的师傅，可以考虑一下密码学中的密钥分配，在分配密钥前是无法对传输密钥加密的，也就是明文传输，原理类似。）

Base 64编码

这里使用 base 64 编码器举例，通过流量分析可以看到，将原本传输的代码做了 base 64 编码，然后调用eval对前面的参数进行解码还原：

上面因为只选择了编码器为base 64，未选择解码器，所以可以看到服务器相应包是明文传输的。下面看看编码器和解码器都选择 base 64编码的情况：

1、默认的 user-agent 请求头是 antsword xxx（可修改）

2、蚁剑的正文内容用URL加密，解密后流量最中明显的特征为ini_set("display_errors","0");这段代码基本是所有WebShell客户端链接PHP类WebShell都有的一种代码，但是有的客户端会将这段编码或者加密，而蚁剑是明文，所以较好发现，同时蚁剑也有eval这种明显的特征。

蚁剑绕过特征流量

由于蚁剑中包含了很多加密、绕过插件，所以导致很多流量被加密后无法识别，但是蚁剑混淆加密后还有一个比较明显的特征，即为参数名大多以0x.....=这种形式（下划线可替换为其他）所以，以0x开头的参数名，后面为加密数据的数据包也可识别为蚁剑的流量特征。

1、编码器改造

上面已经提到，蚁剑在数据包中实际上是将解码函数一同发送到服务端，那几个解码函数是没法加密的，所以产生一个很明显的流量特征。

蚁剑也支持使用者自定义编码器和解码器，关于这一块的升级改造读者可参见博文：蚁剑改造过WAF系列，此处不展开叙述。

2、请求头修改

蚁剑默认的数据包里都携带了特别明显的请求头信息：User-Agent: antSword/v2.1。

我们需要将请求包中的 User-Agent 修改为正常的浏览器标识：

修改位置在蚁剑的本地源码文件夹中，对antSword\modules\request.js 文件修改USER_AGENT变量值。

在现实生活中，网络之间的通信大部分是加密过的，webshell也是如此，老牌的webshell管理工具——中国菜刀因为其攻击流量特征明显，容易被各类安全设备检测，实际场景用的越来越少，现在用的比较多的就是加密webshell。对于加密webshell，如果我们想通过流量分析得到具体信息，需要知道webshell所采用的加密方式以及密钥。

冰蝎就是一款使用AES 128位对称加密的加密webshell。

冰蝎Github官方下载地址：Behinder ，下载完成后在其server目录下能看到各种冰蝎马。

加密通信流程即：

1.首先客户端以Get形式发起带密码的请求（形如 http://192.168.43.11/dvwa/shell.php?pass=645 的请求）；2.服务端产生随机密钥（使用随机数MD5的高16位作为密钥），将密钥写入Session并将密钥返回客户端；3.客户端获取密钥后，将Poyload（待执行的攻击命令）用AES算法（或者XOR运算）加密，用POST形式发送请求；4.服务端收到请求，用Session中的密钥解密请求的Body部分，之后执行Payload，将直接结果返回到客户端。5.客户端获取服务端返回结果，回显到客户端UI界面上。

通常AES加密前会进行一次Base64编码。图片来自红蓝对抗——加密Webshell“冰蝎”攻防

我们来看看一次wireshark抓包冰蝎流量的过程：

细心的师傅可能会发现冰蝎在建立通信时发送了两次get请求，服务端先产生了一个密钥然后又更新了一次密钥，这是为了实现可以在webshell内添加任意内容 (比如gif89a子类的文件头或者其它标示字符) 冰蝎在初始化密钥时会对webshell进行两次访问,然后比较两次页面返回的差异,把两次请求都相同的字符记录一个位置,后续加密会用到这两个位置(beginIndex,endIndex)。具体可参考红蓝对抗——加密Webshell“冰蝎” 流量 100%识别

检测思路可以从流量、应用、主机三个层面入手。

（1）虽然冰蝎的通讯流量都是加密的，但是在第一步，冰蝎必须需要获得密钥，具体流量特征： 1、是一个get请求，url中带上参数?pass（参数名称可变）

对应的检测正则表达式：

由于该请求特征不明显，此正则会产生较多误报。

2、返回包状态码为200，返回内容必定是16位的密钥

对应的检测正则表达式：

返回包特征相对明显，针对这一特征可以在WebIDS、全流量检测等安全设备中对返回包制定相应的特征检测规则。

3、通过Shell交互过程中的HTTP请求特征来检测

冰蝎在发送HTTP请求时存在一些特征，例如其工具中内置了17个User-Agent头，在用户没有自定义的情况下会随机选择一个发送。但是这些User-Agent头大部分是一些老版本的浏览器或设备。

这个类型检测的优势是检测方式比较简单，但是在大流量的环境下很容易引起误报，一般使用多个特征相结合的方法来改善误报的情况，并且这部分的特征通常是一些弱特征，攻击者可以通过定制请求头、使用代理等方式修改冰蝎的请求包很轻易的来绕过这类的检测。

4.header中的Content-Type

默认在header中的Content-type字段，在一般情况下的GET形式访问是没有该字段的，只有POST形式的访问才会有。但”冰蝎”不论是GET形式还是POST形式的访问均包含此字段。此处露出了较大破绽，而且该字段的大小写有点问题，所以基于这个规则基本可以秒杀。

（2）我们已经知道冰蝎建立通信时会发送两个连续的GET请求了，那么Waf可以对一个ip连续访问2次的数据包进行截取，比对相同字符，比对之后，截取两次不同的数据，如果剩下的是16位的key，就可以证明这两个数据包就是冰蝎发出的，第三个数据包通过 0x02,0x03 中的一些bug，可以100%的匹配到冰蝎流量,不会误报

1、什么是OpenRASP？

随着Web应用攻击手段变得复杂，基于请求特征的防护手段，已经不能满足企业安全防护需求。Gartner在2014年提出了应用自我保护技术（RASP）的概念，即将防护引擎嵌入到应用内部，不再依赖外部防护设备。OpenRASP是该技术的开源实现，可以在不依赖请求特征的情况下，准确的识别代码注入、反序列化等应用异常，很好的弥补了传统设备防护滞后的问题。更多细节，请参考[《OpenRASP 最佳实践》](https://rasp.baidu.com/download/OpenRASP Internals.pdf?from=header)

2、RASP 技术和现有方案主要区别 首先，RASP 几乎没有误报情况。边界设备基于请求特征检测攻击，通常无法得知攻击是否成功。对于扫描器的踩点行为、nday 扫描，一般会产生大量报警。RASP 运行在应用内部，失败的攻击不会触发检测逻辑，所以每条攻击都是成功的报警。

其次，RASP 可以发现更多攻击。以SQL注入为例，边界设备只能看到请求信息。RASP 不但能够看到请求信息，还能看到完整的SQL语句，并进行关联。如果SQL注入让服务器产生了语法错误或者其他异常，RASP引擎也能够识别和处理。

最后，RASP 可以对抗未知漏洞。发生攻击时，边界防护设备无法掌握应用下一步的动向。RASP技术可以识别出异常的程序逻辑，比如反序列化漏洞导致的命令执行，因此可以对抗未知漏洞。

（1）定期对服务器进行webshell文件扫描查杀 这里用D盾、河马和OpenRASP团队开发的下一代WebShell检测引擎webdir+进行测试，检测结果都比较一般。

（2）Linux audit日志检测

虽然冰蝎通讯流量是加密的，但落到主机侧，还是会调用系统命令，所以可以在主机审计日志层面定制检测规则，监控冰蝎对系统命令的调用。Linux审计系统提供了一种跟踪系统上与安全相关的信息的方法。基于预先配置的规则，审核生成日志条目以记录尽可能多的关于系统上发生的事件信息，参考《另类WebShell监测机制–基于auditd》思路。

以root身份执行如下命令，可实现对执行系统命令这一个SYSCALL行为的监控审计。

上述命令在系统审计规则中增加了一条监控调用命令执行监控规则，并且定义规则名为rule01_exec_command。

在冰蝎中执行命令whoami，在Linux审计日志中发现记录：

type=SYSCALL：日志规则“rule01_exec_command”被触发，uid=33的用户，通过父进程ppid=597，调用/usr/bin/bash，执行了命令sh，进程pid=8380。

type=SYSCALL和type=EXECVE都能看到执行的程序名称和参数。

type=CWD则说明了，命令执行所在的目录cwd=”/var/www/html”。

一般cwd在web目下的，又执行了系统命令，则这个行为是比较可疑的。

当然基于审计日志的检测思路也存在一定问题，包括：合理配置auditd的运行参数，准确评估审计功能对系统性能的影响；如何主动识别Web进程和Web目录信息；如何实时收集操作系统进程和进程PID等信息；如何关联分析Web访问日志； Windows平台是否有同样的检测机制等等。

在上面的介绍中，我们了解到冰蝎建立通信时会进行明文传输密钥，这使得它可以被检测到。在密码学中，我们知道密码可分为对称密码和非对称密码（公钥密码），其中对称密码包括DES、AES等等，但是对称密码始终绕不过去的难题是密钥的分配，从而才引申出了公钥密码。

对于冰蝎密钥分配的问题，冰蝎作者采用将密钥”写死“，也就是在上传的shell文件中将密钥确定为一个固定的值，这样在以后通信时，不必再分配AES密钥，因为密钥已经提前确定好了，这样直接通信即可。

我们俩看一下新旧版本流量包的对比

不难看出新版本冰蝎客户端直接进行通信，也就是直接使用密钥加密密文了。而老版本还要使用GET请求服务器。

在前面我们介绍的2.0和3.0都是使用AES 128位加密，到了4.0版本，加密方式不再是单一的AES，多出来了几种用户可选加密方式，甚至可以自定义。

选用加密方式后直接通信即可。

网上看了很多文章，发现大多数师傅都说冰蝎通信过程可以分为两个部分：密钥协商和加密传输。但是根据前面我们所介绍的就可以知道，冰蝎3和冰蝎4就不再需要密钥交换了，因为密钥已经提前确定好了，如果大家手上有冰蝎流量的话可以分析一下，会发现无论如何也找不到密钥交换过程。

那么对于这种情况我们要如何进行破解呢，上文我们曾提到，如果要获取具体信息，就需要知道加密方式和密钥。在密码学中，对于密钥的破解其实从未停止过，而其中最为”笨拙“但却经常出奇效的方法就是暴力破解，即穷举法，这也是我们破解冰蝎流量的方法。关于破解冰蝎3和冰蝎4的文章我会放在下一篇介绍，接下来我们继续分析webshell的流量。

这是本篇介绍的最后一个webshell管理工具。

哥斯拉是继冰蝎之后出现的又一款webshell管理工具，与冰蝎类似，哥斯拉也采用了加密流量通信来躲避WAF等安全设备的检测。其特点有：

哥斯拉默认的webshell生成支持JAVA、C#以及PHP三种类型，其中JAVA支持生成jsp以及jspx两种后缀webshell，C#支持aspx、asmx、ashx后缀，PHP就支持php后缀webshell（PHP环境可能支持解析很多后缀类型的文件，如php3、php5、phtml、pht，但是语法都是兼容的）。

先看JAVA的，主要原理和冰蝎的差不多。关键在于加密、类加载和反射，可以提取关键操作的代码作为静态检测的特征，如：AES加/解密：javax.crypto.Cipher.getInstance(“AES”)类加载：ClassLoader反射：Class.forName

C#的webshell核心在于使用Assembly来动态解析执行已编译的DLL二进制文件，以及流量加密。使用Assembly的特征为System.Reflection.Assembly，实现加/解密：System.Security.Cryptography.RijndaelManaged()

PHP没有沿用AES加密的流量，而是通过异或实现自定义的加密，并且直接使用eval函数进行代码执行。

具体过程可参考【原创】哥斯拉Godzilla加密流量分析，这里仅给出结论。

哥斯拉发送的第一个POST请求中，请求数据的加密过程为：将原始数据（即src\shells\payloads\php\assets\payload.php文件）与shell密钥（本例中为test1234）md5值的前16位（本例中为16d7a4fca7442dda）按位异或，再依次经过base64编码和URL编码，得到编码数据，最终以pass=编码数据的形式作为POST报文请求体，POST到服务器。解密过程与加密过程正好相反：从pass=编码数据中提取编码数据，依次经过URL解码和base64解码，再与shell密钥（本例中为test1234）md5值的前16位（本例中为16d7a4fca7442dda）按位异或即可得到原始请求数据。

哥斯发送的第2个POST请求实际上是通过调用evalFunc((String)null, "test", parameter)函数向服务器POST了原始数据为methodName=test的加密包，如果服务器返回值（解密后）为ok，则说明shell测试连接成功。

第3个请求数据和服务器响应数据和第2个请求完全一致，不再赘述。

通过Burp抓包分析，在Godzilla中进入shell的时候，类似Shell Setting过程中测试连接的过程，一共发送了3个POST请求，其中前两个请求和测试连接中发送的请求和接收到的响应完全一致。

第1个请求：请求报文发送大量数据（实际内容为Payload），返回报文为空

第2个：请求报文发送很少数据（实际内容为测试连接命令test），返回少量数据（即ok）

第3个请求：请求报文为获取服务器基础信息的命令getBasicsInfo，返回服务器基础信息

1.请求包解密，CyberChef 配方

2.返回包解密，CyberChef 配方

自己先手动删掉前16和后16的字符串

哥斯拉客户端使用JAVA语言编写，在默认的情况下，如果不修改User-Agent，User-Agent会类似于Java/1.8.0_121（具体什么版本取决于JDK环境版本）。但是哥斯拉支持自定义HTTP头部，这个默认特征是可以很容易去除的。

Accept为text/html, image/gif, image/jpeg, *; q=.2, /; q=.2对这个默认特征应该很熟悉了，之前冰蝎也出现过同样的Accept。为什么会这么巧合出现两个工具都会出现这个特征呢，其实这个也是JDK引入的一个特征，并不是作者自定义的Accept（参考：https://bugs.openjdk.java.net/browse/JDK-8177439）。同样的这个默认特征也可以通过自定义头部去除，只能作为默认情况下的辅助检测特征。

哥斯拉的作者应该还没有意识到，在请求包的Cookie中有一个非常致命的特征，最后的分号。标准的HTTP请求中最后一个Cookie的值是不应该出现;的，这个可以作为现阶段的一个辅助识别特征。后面如果作者意识到这个问题的话应该会发布新版本修复这个问题。

因为无法准确识别加密的请求体，所以只能采用比较宽泛的匹配条件去匹配请求体特征，宽泛的匹配思路其实就是基于区别大部分正常的数据包，加密数据包自身体现的特征。这种宽泛的匹配在一些情况下可能会带来误报，因此有时候难以作为一种非常有效的检测手法。

哥斯拉支持对加密的数据进行base64编码以及原始的加密raw两种形式的通讯数据，对于请求体的检测也要考虑两种情况。

首先看一下base64编码的数据包，对于这种数据包唯一的识别方法就是识别流量中的base64编码。当然不能仅仅去识别数据包中存在base64编码就拦截，因为很多应用正常的参数也会采用base64编码加密。哥斯拉在进行初始化时会产生一个比较大的数据包，后面进行命令执行等操作时产生的base64数据包会比较比较小。在长度上做一个匹配条件在一定程度上也可以降低误报率。

对于原始加密raw请求体，没想到比较好的方法，目前只想到到了匹配较多的不可见字符的思路。同样的，这种检测方法也会产生误报，像一些对传输安全要求比较高的金融机构，不少应用也会实现一些加密的通讯流量。需要注意的是，在匹配不可见字符时，需要排除文件上传，也就是multipart/form-data数据包，因为文件上传的流量也会包含大量的不可见字符。

和请求体一样，请求响应体也分两个格式，base64编码的和原始加密raw数据。如果请求体采用base64编码，响应体返回的也是base64编码的数据。在使用base64编码时，响应体会出现一个很明显的固定特征。这个特征是客户端和服务端编写的时候引入的。

从代码可以看到会把一个32位的md5字符串按照一半拆分，分别放在base64编码的数据的前后两部分。整个响应包的结构体征为：md5前十六位+base64+md5后十六位。

从响应数据包可以明显看到这个特征，检测时匹配这个特征可以达到比较高的检出率，同时也只可以结合前面的一些弱特征进行检查，进一步提高检出率。因为md5的字符集范围在只落在0123456789ABCDEF范围内，因此很容易去匹配，正则匹配类似于(?i:[0-9A-F]{16})[\w+/]{4,}=?=?(?i:[0-9A-F]{16})。需要注意的是md5需要同时匹配字母大小写两种情况，因为在JAVA版webshell响应中为大写字母，在PHP版中为小写字母。

编写对应检测规则，在ModSecurity上测试成功拦截。

但是比较遗憾的是对于原始加密数据的raw形式响应包并没有比较好的检测思路，只能和请求体检测一样，匹配不可见字符。

参考链接：

红蓝对抗——加密Webshell“冰蝎”攻防

红蓝对抗——加密Webshell“冰蝎” 流量 100%识别

冰蝎v2.0.1流量分析

渗透测试-流量加密之冰蝎&蚁剑

冰蝎的前世今生：3.0新版本下的一些防护思考

Shell管理工具流量分析-上（菜刀、蚁剑、冰蝎2.0流量分析）&入侵检测、应急响应资料整理

哥斯拉流量特征以及检测思路

【原创】哥斯拉Godzilla加密流量分析

2022某世赛选拔流量分析（jsp哥斯拉流量）