websocket 新型内存马的应急响应
source link: https://paper.seebug.org/1935/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
作者：flamingo
原文链接：https://mp.weixin.qq.com/s/T3UfA1plrlG-e9lgfB4whg
前几天看到一个推送，websocket新型内存马。因其自身注册在Ws下面所以常规的内存检测脚本memshell scanner无法快速检出来。
项目地址：https://github.com/veo/wsMemShell
为了防止应急响应的时候翻车，我复现了一下ws内存马，并在本地环境上做了一套检测方案，能够有效的查找这款内存马。
内存马复现
这套内存马作者提供了wscmd.jsp的样例文件。通过查看这个jsp代码跟作者给出的方法，大概就是上传这个jsp，然后通过参数传入路径，便能在其传入的路径下注册一个内存马。
根据这个方法，在本地搭建了tomcat后放上恶意文件，然后传入地址参数，实现了内存马的操作
从流量上看没有任何的特征
不信邪的我又跑去喊同事搭建了远程环境上去测了一下，还真的是没法看，但是传输的协议的WS，又不是wss，我不是很理解这是为什么，希望有知道的师傅指教一下。
不能说毫无特征吧，只能说没啥可看。
看起来这个方法再跟上反序列化漏洞的方法，将会是今年hw一大杀器。
WS内存马检测手法
由于我本身目前工作都是蓝队应急方向的，所以这种大杀器在我这里就算不能流量设备检测出来，上机也得排出来。
既然是写在java内存里的，那么就能从内存里找到它。
java目录下打开java自带的jvm内存查看工具HSDB
java -cp sa-jdi.jar sun.jvm.hotspot.HSDB
根据注入的方法，可以看出来应该是在Endpoint注册的，根据作者提供的思路也应该是这样
从tomcat目录下jps找到tomcat的pid
根据pid打开
从HSDB的class browser里面找这个class
打开它，并找到它的类层次结构，可以很轻易的看到这个jsp生成的内存马
马上把它导出来丢到ida里面看看，确实可以锁定这个是内存马，干掉就行
反序列化实现
那么反序列化出来的内存马是不是这样的呢？找了@清水川崎 水子哥来帮忙写了一段shiro反序列化的ws内存马注入，做了环境复现
反序列化复现方法这里不说了，减少今年干活儿的次数
同样的手法去检测，可以看到也能很明显的快速定位到ws内存马的位置
那么此次检测应急方法到此结束，后续遇到ws内存马可以按照此类方法检测。
本文由 Seebug Paper 发布，如需转载请注明来源。本文地址：https://paper.seebug.org/1935/
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK