java内存马分析-[Godzilla-FilterShell]

考虑到很多小伙伴还不懂java 内存马，所以我打算新开一个系列，完善分享体系

为了方便演示，我们通过Godzilla写入webshell，地址为:http://localhost:8080/jiaju_mall/webshell.jsp

加密模式为：AES_BASE64

一、什么是Filter

Filter 作为 servler-api 的三大件之一，顾名思义就是起到过滤作用:对web服务器管理的所有web资源,例如Jsp, Servlet, 静态图片文件或静态 html 文件等进行拦截，实现一些特殊的功能。例如权限访问控制、过滤敏感字符(例如sql注入、RCE会出现的危险字符串)

在内存马技术中，Filter类型也被广泛使用，优先级通常比较高，且实现的拦截路径比较特殊,例如: /favicon.ico

当然，实现的拦截路径和优先级，可以根据不同环境自定义设置

二、Arthas

排查的思路，通过Java Agent 遍历加载到内存中的class，进行分析

这篇文章使用 Arthas ，实战环境也经常用到

安装&使用：https://arthas.aliyun.com/doc/install-detail.html

命令文档：https://arthas.aliyun.com/doc/commands.html

需要注意，在使用 Arthas 的时候，要和 web 程序权限相同

三、哥斯拉 FilterShell 型分析

废话不多说，环境搭建：Tomcat，一个支持 jsp 的web站点

FilterShell 上传前，获取所有的Filter，这个站点中，只存在初始化用的 WebSocket

点击：addFilterShell 再次获取，得到：ValueInstantiators1697030134135

Arthas 查看存在的 Filter : mbean | grep "j2eeType=Filter"

可以发现：Godzilla 的 FilterShell 存在非常明显的特征 ⇒ 尾部时间戳   1697030134135   →    2023-10-11 21:15:34

接着，根据得到的 Filter 名称继续分析:

sc *.Filter | grep "ValueInstantiators" ⇒ 得到类全路径

再接着分析 sc -d org.apache.coyote.deser.ValueInstantiators

看到这里就非常清晰了，classloader 暴露了它为恶意对象

该类被 webshell.jsp 进行加载，webshell.jsp 再由 JasperLoader 进行加载

+-org.apache.jsp.webshell_jsp$X@17915e77+-org.apache.jasper.servlet.JasperLoader@4c9262a3

[  jsp 的本质是一个Servlet， Servlet-api 一般是由 WebappClassLoader 进行加载 ，若其classloader 不是 WebappClassLoader，则可能为恶意

JasperLoader 会被用于热加载更新文件，类似文件上传的webshell，classloader便会是 JasperLoader ]

为了进一步确定我们的猜想，对类 dump到本地反编译:

dump -d D:/webshell-dump org.apache.coyote.deser.ValueInstantiators

也可通过下述命令，在窗口查看

jad org.apache.coyote.deser.ValueInstantiators

拖拽class文件进 jd-gui 进行反编译:

Filter存在doFilter方法，为拦截器的核心方法之一，而执行 doFilter() 的时候，调用了 _jspService()

义眼丁真鉴定为:Vulnerablity

也存在自写的加密方法等

顺便说一句,FilterShell的名字在 addFilter() 方法时候进行了指定

四、整体的排查思路

1. filter 名字很特别

   内存马的Filter名一般比较特别，有shell或者随机数等关键字。这个特征稍弱，因为这取决于内存马的构造者的习惯，构造完全可以设置一个看起来很正常的名字。

2. filter 优先级是第一位

   为了确保内存马在各种环境下都可以访问，往往需要把filter匹配优先级调至最高，这在shiro反序列化中是刚需。但其他场景下就非必须，只能做一个可疑点。

3. 对比 web.xml 中没有filter配置

   内存马的Filter是动态注册的，所以在web.xml中肯定没有配置，这也是个可以的特征。但servlet 3.0引入了@WebFilter标签方便开发这动态注册Filter。这种情况也存在没有在web.xml中显式声明，这个特征可以作为较强的特征。

4. 特殊 classloader 加载

   我们都知道Filter也是class，也是必定有特定的classloader加载。一般来说，正常的Filter都是由中间件的WebappClassLoader加载的。反序列化漏洞喜欢利用TemplatesImpl和bcel执行任意代码。所以这些class往往就是以下这两个：

   这个特征是一个特别可疑的点了。当然了，有的内存马还是比较狡猾的，它会注入class到当前线程中，然后实例化注入内存马。这个时候内存马就有可能不是上面两个classloader。

   • com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl$TransletClassLoader

   • com.sun.org.apache.bcel.internal.util.ClassLoader

5. Filter 的 doFilter 方法中有恶意代码

   我们可以把内存中所有的Filter的class dump出来，使用gui等反编译工具分析看看，是否存在恶意代码，比如调用了如下可疑的方法：

   • java.lang.Runtime.getRuntime

   • defineClass

   • invoke

以上就是这个系列的第一篇文章，后续会逐步更新,感谢支持~

·

也存在自写的加密方法等

顺便说一句,FilterShell的名字在 addFilter() 方法时候进行了指定

四、整体的排查思路

1. filter 名字很特别

   内存马的Filter名一般比较特别，有shell或者随机数等关键字。这个特征稍弱，因为这取决于内存马的构造者的习惯，构造完全可以设置一个看起来很正常的名字。

2. filter 优先级是第一位

   为了确保内存马在各种环境下都可以访问，往往需要把filter匹配优先级调至最高，这在shiro反序列化中是刚需。但其他场景下就非必须，只能做一个可疑点。

3. 对比 web.xml 中没有filter配置

   内存马的Filter是动态注册的，所以在web.xml中肯定没有配置，这也是个可以的特征。但servlet 3.0引入了@WebFilter标签方便开发这动态注册Filter。这种情况也存在没有在web.xml中显式声明，这个特征可以作为较强的特征。

4. 特殊 classloader 加载

   我们都知道Filter也是class，也是必定有特定的classloader加载。一般来说，正常的Filter都是由中间件的WebappClassLoader加载的。反序列化漏洞喜欢利用TemplatesImpl和bcel执行任意代码。所以这些class往往就是以下这两个：

   这个特征是一个特别可疑的点了。当然了，有的内存马还是比较狡猾的，它会注入class到当前线程中，然后实例化注入内存马。这个时候内存马就有可能不是上面两个classloader。

   • com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl$TransletClassLoader

   • com.sun.org.apache.bcel.internal.util.ClassLoader

5. Filter 的 doFilter 方法中有恶意代码

   我们可以把内存中所有的Filter的class dump出来，使用gui等反编译工具分析看看，是否存在恶意代码，比如调用了如下可疑的方法：

   • java.lang.Runtime.getRuntime

   • defineClass

   • invoke

以上就是这个系列的第一篇文章，后续会逐步更新。

希望各位读者看完我们的文章以后自己去实践一下，只有学到脑子里的东西才是自己的，如果遇到困难，可以加本人微信（i_still_be_milu）与麋鹿师傅一起探讨，炼心之路，就在脚下，我们一起成长。

同时欢迎各位同仁关注麋鹿安全，我们的文章会第一时间发布在公众号平台，如果不想错过我们新鲜出炉的好文，那就请扫码关注我们的公众号！

(附上本人微信，欢迎各位同仁加我微信，和我探讨安全，同时欢迎同仁们的不吝指正)