websocket 新型內存馬的應急響應

作者：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 發布，如需轉載請注明來源。本文地址：http://www.bjnorthway.com/1935/