常见Webshell&重大漏洞的流量特征（附解密流量工具）-优快云博客

0x01 前言

攻防演练中，经常会看到一些加密的流量，又分不清楚是不是误报，本文总结了一些常见的流量特征，附流量解密工具。

0x02 正文

远控C2

cs流量特征：

1，基础特征：心跳包

2，请求特征：下发的指令，url路径，老版本固定的ua头

3，源码特征：checksum8 （92L 93L）

如果进行二开魔改后的cs，可提取样本

MSF流量特征：

1，端口号：msf默认使用4444端口作为反向连接端口

2，数据内容：msf数据包通常包含特定字符串:(“meterpreter”、"revshell"等)

webshell：

主要需要鉴别一些高危的函数，比如eval，assert

蚁剑：

特征：

请求中的User-Agent值是：antSword/*

也有可能是：Mozilla/5.0 (Windows NT ) AppleWebKit/ (KHTML, like Gecko) Chrome/* Safari/

请求中可以检测到的关键字：“eval””eVAL”

请求体存在@ini_set(“display_errors”, “0”);@set_time_limit(0);（开头可能是菜刀或者是蚁剑）

加密后的明显参数多数是_0x…=这种形式所以_0x开头的参数名，以及dirname、get_current_user函数的字眼（需要讲请求内容解密后判断），后面为加密数据的数据包可以鉴定为蚁剑的流量特征

在命令执行时有目录标记[S]、[E]、[R]、[D]、等，说明已经拿到shell了（在执行系统命令）

payload特征

php assert、eval关键字执行,

asp eval在jsp使用

Java 同时会带有base64编码解码等字符特征

菜刀：

老版本采用明文传输，非常好辨认新版本采用base64加密，检测思路就是分析流量包，发现大量的base64加密密文就需要注意

请求头中

User-Agent存在百度或者火狐

请求体中

会存在QGluaV9zZXQ攻击的开头部分后面的部分需要base64解码

z0(也会修改)跟随后面的payload的base64的数据。z0是菜刀的默认参数

eval也会替换成assert的方式（可能是拼接）

（“ass”.“ert”,…

固定的

QGluaV9zZXQoImRpc3BsYXlfZXJyb3JzIiwiMCIpO0BzZXRfdGltZV9saW1pdCgwKTtpZihQSFBfVkVSU0lPTjwnNS4zLjAnKXtAc2V0X21hZ2ljX3F1b3Rlc19ydW50aW1lKDApO307ZWNobygiWEBZIik7J

冰蝎：

冰蝎1：冰蝎1有一个密钥协商过程，这个过程是明文传输，并且有两次流量，用来校验冰蝎2：因为内置了很多的UA头，所以当某一个相同IP重复请求，但是UA头不一样的时候就需要注意了冰蝎3：因为省去了协商过程，所以流量上可以绕过很多，但是其他特征依旧保留，比如ua头冰蝎数据包总是伴随着大量的content-type：application什么什么，无论GET还是POST，请求的http中，content-type为application/octet-stream还有他们的accept之类的长度总是等长，正常的根据应用场景和不同文件，长度是不同的

冰蝎4：

1.UserAgent字段：

Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)  
Mozilla/5.0 (Windows; U; Windows NT 6.1; en\-US) AppleWebKit/533+ (KHTML, like Gecko) Element Browser/5.0  
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0)  
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.37 Edge/16.16299  
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0  
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36  
Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)  
Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; AS; rv:11.0) like Gecko  
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:39.0) Gecko/20100101 Firefox/39.0  
Mozilla/5.0 (Windows NT 5.1; rv:40.0) Gecko/20100101 Firefox/40.0  
Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36  
Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0) like Gecko  
Mozilla/7.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0; Xbox)

2.流量特征，Content-type: Application/x-www-form-urlencoded。

3.Cinnection字段：

Connection: Keep-Alive(冰蝎默认使用的长连接是为了避免频繁的握手造成的资源丢失)

4…Accept字段：

请求头中存在Accept: application/json, text/javascript, /; q=0.01

也有可能Accept: text/html,image/gif, image/jpeg, *; q=.2, /; q=.2

Content-Type: application/octet-stream ******q=0.8

5..端口

冰蝎与webshell建立连接的同时，javaw也与目的主机建立tcp连接，每次连接使用本地端口在49700左右，每连接一次，每建立一次新的连接，端口就依次增加。

检测思路

可以对符合该范围内的端口告警。

5.PHP webshell 中存在固定代码

流量特征

$post\=Decrypt(file\_get\_contents(“php://input”));  
eval($post);

检测思路

content字段中，将eval($post)作为流量特征纳入。

检测思路

可以作为辅助的流量特征。

6**、固定的请求头和响应头**

流量特征

请求字节头：

dFAXQV1LORcHRQtLRlwMAhwFTAg/M

冰蝎3与冰蝎4的区别：

v3.0 和 v4.0 的区别很明显在于这里 $KaTeX parse error: Undefined control sequence: \[ at position 11: \_SESSION \̲[̲'k'\]=$ key ，v3.0 版本当中会把 key 作为 session 传入；接着判断 extension_loaded ，也就是判断服务端是否存在 openssl 拓展，如果不存在就用 base64 解码，然后使用 key 进行异或加密，这也是冰蝎 v4.0 版本当中的 xor_base64 加密方式；如果服务端能够加载 openssl 拓展，就使用 AES128 解密，这里对应冰蝎 v4.0 版本当中的 aes 加密方式。

哥斯拉：

1.强特征：cookie字段，最后一个Cookie的值出现;（尾值出现分号）

2.请求中的Accept头是

Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8

3.paylod特征：jsp会出现xc,pass字符和Java反射，base64加解码等特征，php，asp则为普通的一句话木马。

4.还有响应，哥斯拉会响应三次，而且我认为还有一个地方需要注意的就是webshell连接，所以一般会设置长时间连接，所以connection这里会是keep-alive

5.响应头中的Cache-Control头是

Cache-Control: no-store, no-cache, must-revalidate

Webshell的检测思路

静态检测

静态检测通过匹配特征码，特征值，危险函数函数来查找 webshell 的方法，只能查找已知的 webshell，并且误报率漏报率会比较高，但是如果规则完善，可以减低误报率，但是漏报率必定会有所提高。优点是快速方便，对已知的 webshell 查找准确率高，部署方便，一个脚本就能搞定。缺点漏报率、误报率高，无法查找 0day 型 webshell，而且容易被绕过

动态检测

Linux 下就是 nobody 用户起了 bash，Win 下就是 IIS User 启动 cmd，这些都是动态特征。再者如果黑客反向连接的话，那很更容易检测了，Agent 和 IDS 都可以抓现行。Webshell

总有一个 HTTP 请求，如果我在网络层监控 HTTP，并且检测到有人访问了一个从没访问过得文件，而且返回了 200，则很容易定位到 webshell，这便是 http 异常模型检测，就和检测文件变化一样，如果非管理员新增文件，则说明被人入侵了。缺点也很明显，黑客只要利用原文件就很轻易绕过了，并且部署代价高，网站时常更新的话规则也要不断添加。

日志检测

总有一个 HTTP 请求，如果我在网络层监控 HTTP，并且检测到有人访问了一个从没反问过得文件，而且返回了 200，则很容易定位到 webshell，这便是 http 异常模型检测，就和检测文件变化一样，如果非管理员新增文件，则说明被人入侵了。缺点也很明显，黑客只要利用原文件就很轻易绕过了，并且部署代价高，网站时常更新的话规则也要不断添加。

Webshell防范方法

防范的措施大概有三种：

第一种的思路是将专门存放上传文件的文件夹里面的脚本类型文件，解析成其他类型的文件，服务器不会以脚本类型来执行它。

第二种是匹配文件夹里的脚本类型文件，将其设置为无法读取及操作。

第三种是将文件上传到一个单独的文件夹，给一个二级的域名，然后不给这个虚拟站点解析脚本的权限，听说很多网站都用这种方式。

内存马的原理&判断和清除：

原理：

其原理是先由客户端发起一个web请求，中间件的各个独立的组件如Listener、Filter、Servlet等组件会在请求过程中做监听、判断、过滤等操作，内存马利用请求过程在内存中修改已有的组件或者动态注册一个新的组件，插入恶意的shellcode达到持久化的控制服务器。

判断方式：

先判断是通过什么方法注入的内存马，可以先查看 web 日志是否有可疑的 web 访问日志，如果是 filter 或者 listener 类型就会有大量 url 请求路径相同参数不同的，或者页面不存在但是返回 200 的，查看是否有类似哥斯拉、冰蝎相同的 url 请求，哥斯拉和冰蝎的内存马注入流量特征与普通 webshell 的流量特征基本吻合。通过查找返回 200 的 url 路径对比web 目录下是否真实存在文件，如不存在大概率为内存马。如在 web 日志中并未发现异常，可以排查是否为中间件漏洞导致代码执行注入内存马，排查中间件的 error.log 日志查看是否有可疑的报错，根据注入时间和方法根据业务使用的组件排查是否可能存在 java 代码执行漏洞以及是否存在过 webshell，排查框架漏洞，反序列化漏洞

清除方式：1.利用条件竞争把shell内容改写或者清除比较好用 2.重启服务 3.提前占用他的目录名

重大漏洞的流量特征&原理

fastjson流量特征：

fastjson原理：

在请求包里面中发送恶意的 json 格式 payload，漏洞在处理 json 对象的时候，没有对@type 字段进行过滤，从而导致攻击者可以传入恶意的 TemplatesImpl 类，而这个类有一个字段就是_bytecodes，有部分函数会根据这个_bytecodes 生成 java 实例，这就达到fastjson 通过字段传入一个类，再通过这个类被生成时执行构造函数

还有commit值为true

不出网打法：#目前公开已知的poc有两个：

org.apache.tomcat.dbcp.dbcp2.BasicDataSource  
com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl

#第一种利用方式需要一个特定的触发条件:解析JSON的时候需要使用Feature才能触发，参考如下代码：JSONObject.parseObject(sb.toString(), new Feature[] {Feature.SupportNonPublicField});#第二种利用方式: 则需要应用部署在Tomcat应用环境中，因为Tomcat应用环境自带tomcat-dbcp.jar 对于SpringBoot这种自带Tomcat可以直接以单个jar文件部署的需要在maven中配置tomcat- dbcp。

而且对于不同的Tomcat版本使用的poc也不同：Tomcat 8.0以后使用org.apache.tomcat.dbcp.dbcp2.BasicDataSource• Tomcat8.0以下使用 org.apache.tomcat.dbcp.dbcp.BasicDataSource

log4j流量特征：

原理：该漏洞主要是由于日志在打印时当遇到${后，以:号作为分割，将表达式内容分割成两部分，前面一部分prefix，后面部分作为key，然后通过prefix去找对应的lookup，通过对应的lookup实例调用lookup方法，最后将key作为参数带入执行，引发远程代码执行漏洞特征：${jndi：rmi

struts2：

struts2漏洞原理：

Struts2漏洞是由于攻击者可以利用Struts2系统中没有恰当的输入验证机制，导致攻击者可以构造恶意请求，从而绕过Struts2的控制机制，访问服务器上的敏感资源，造成数据泄露的可能性。流量特征：攻击者可以通过发送特殊的http请求，构造恶意请求，并在请求中添加非法参数或操作，以绕过Struts2的认证机制，造成数据泄露的可能性。

流量特征：遇到之后先进行url解码在查看总体含义

redis未授权：6379

原理：redis使用了默认配置，使端口绑定在了0.0.0.0:6379并且暴露在公网的话此时我们任意一台带有redis-cli的机器就可以直接访问，跳过登陆验证，从而可以写shell，写入shell的话使用config参数

thinkphp：

5.x通杀原理：路由url从Request::path()中获取，由于var_pathinfo的默认配置为s，我们可利用 $KaTeX parse error: Undefined control sequence: \[ at position 5: _GET\̲[̲'s'\]来传递路由信息，也可…$ _SERVER[‘pathinfo’]中的\替换为/。结合前面分析可得初步利用代码如下：index.php?s=index/\namespace\class/method正则没写好

weblogic：7001

基于 T3 协议的反序列化；基于 xml 解析时候造成的反序列化，还有ssrf，权限绕过等等，详情见下面文章

基于攻击流量和日志对Weblogic各类漏洞的分析思路-安全客 - 安全资讯平台

shiro：

利用过程：

1、检索RememberMe Cookie的值

2、Base64解码

3、AES解密（加密密钥硬编码）

4、进行反序列化操作（未过滤处理）

5、攻击者可以使用Shiro的默认密钥构造恶意序列化对象进行编码来伪造用户的Cookie，服务端反序列化时触发漏洞，从而执行命令

shiro漏洞原理：

Apache Shiro框架提供了记住我的功能（RememberMe），用户登录成功后会生成经过加密并编码的cookie。cookie的key为RememberMe，cookie的值是经过相关信息进行序列化，然后使用AES加密（对称），最后再使用Base64编码处理。服务端在接收cookie时：检索RememberMe Cookie的值 Base 64解码 AES解密（加密密钥硬编码）进行反序列化操作（未过滤处理）攻击者可以使用Shiro的默认密钥构造恶意序列化对象进行编码来伪造用户的Cookie，服务端反序列化时触发漏洞，从而执行命令。

shiro550与shiro721的区别：

1、这两个漏洞主要区别在于Shiro550使用已知密钥碰撞，只要有足够密钥库（条件较低），不需要Remember Cookie

2、Shiro721的ase加密的key基本猜不到，系统随机生成，可使用登录后rememberMe去爆破正确的key值，即利用有效的RememberMe Cookie作为Padding Oracle Attack的前缀，然后精心构造 RememberMe Cookie 值来实现反序列化漏洞攻击，难度高

流量特征：