websocket新型内存马的应急响应

前几天看到一个推送,websocket新型内存马。因其自身注册在Ws下面所以常规的内存检测脚本memshell scanner无法快速检出来。
项目地址:https://github.com/veo/wsMemShell
image-1658213128088
为了防止应急响应的时候翻车,我复现了一下ws内存马,并在本地环境上做了一套检测方案,能够有效的查找这款内存马。

内存马复现

这套内存马作者提供了wscmd.jsp的样例文件。通过查看这个jsp代码跟作者给出的方法,大概就是上传这个jsp,然后通过参数传入路径,便能在其传入的路径下注册一个内存马。
image-1658213145464
image-1658213152551
根据这个方法,在本地搭建了tomcat后放上恶意文件,然后传入地址参数,实现了内存马的操作
image-1658213164131
从流量上看没有任何的特征
image-1658213173853
不信邪的我又跑去喊同事搭建了远程环境上去测了一下,还真的是没法看,但是传输的协议的WS,又不是wss,我不是很理解这是为什么,希望有知道的师傅指教一下。
不能说毫无特征吧,只能说没啥可看。
image-1658213187676
image-1658213192409
看起来这个方法再跟上反序列化漏洞的方法,将会是今年hw一大杀器。

WS内存马检测手法

由于我本身目前工作都是蓝队应急方向的,所以这种大杀器在我这里就算不能流量设备检测出来,上机也得排出来。
既然是写在java内存里的,那么就能从内存里找到它。
java目录下打开java自带的jvm内存查看工具HSDB
java -cp sa-jdi.jar sun.jvm.hotspot.HSDB
image-1658213222941
根据注入的方法,可以看出来应该是在Endpoint注册的,根据作者提供的思路也应该是这样
image-1658213234251
image-1658213242657
从tomcat目录下jps找到tomcat的pid
image-1658213255376
根据pid打开
image-1658213273200
image-1658213277397
从HSDB的class browser里面找这个class
image-1658213291369
image-1658213302640
打开它,并找到它的类层次结构,可以很轻易的看到这个jsp生成的内存马
image-1658213314756
马上把它导出来丢到ida里面看看,确实可以锁定这个是内存马,干掉就行
image-1658213334952

反序列化实现

那么反序列化出来的内存马是不是这样的呢?找了@清水川崎 水子哥来帮忙写了一段shiro反序列化的ws内存马注入,做了环境复现
反序列化复现方法这里不说了,减少今年干活儿的次数
image-1658213353782
同样的手法去检测,可以看到也能很明显的快速定位到ws内存马的位置
image-1658213362293
image-1658213367388
image-1658213380051
那么此次检测应急方法到此结束,后续遇到ws内存马可以按照此类方法检测。

Q.E.D.


一名北漂的网安工程师,希望这次能好好工作,不被毕业吧…