冰蠍動態二進位加密WebShell特徵分析

• 2019 年 10 月 6 日
• 筆記

概述

冰蠍一款新型加密網站管理客戶端，在實際的滲透測試過程中有非常不錯的效果，能繞過目前市場上的大部分WAF、探針設備。本文將通過在虛擬環境中使用冰蠍，通過wireshark抓取冰蠍通訊流量，結合平時在授權滲透中使用冰蠍馬經驗分析並總結特徵。

版本介紹

目前冰蠍已經迭代6個版本下載地址，從最初的v1.0版本到目前最新的版本v2.0.1，其中v1.0版本可以從此處下載到。

冰蠍最初的版本對於環境的要求較為苛刻，僅支援部分環境，絕大部分環境中都無法連接成功，目前最新版本可使用範圍有了較大的提升，PHP 5-PHP 7全版本支援，Java最低支援至1.6，.NET最低支援至2.0。

冰蠍最初版本User-Agent頭為客戶端JDK版本，v1.1開始新增隨機UserAgent支援，每次會話會從17種常見UserAgent中隨機選取。

由於冰蠍在通訊過程中使用AES加密，Java和.Net默認支援AES加密，php環境中需要開啟openssl擴展，v2.0更新以後，PHP環境加密方式根據伺服器端支援情況動態選擇，不再依賴openssl，使得冰蠍有了更大的發揮空間。

JSP冰蠍馬，此處不作冰蠍馬分析。

PHP冰蠍馬

通訊流量分析

在本地搭建環境抓取冰蠍流量來進行簡單的特徵分析，主要測試冰蠍最初版本和最新版本，v1.0和v2.0.1，提取通訊關鍵特徵。

服務端虛擬機win7、客戶端本地主機win10、Tomcat8，客戶端服務端Java環境均為1.8。

V1.0版本冰蠍連接

抓取到的通訊流量如下：

從Wireshark中抓到的數據包中可以看出，冰蠍與傳統的管理工具一樣，操作請求均為POST。從流量包中可以清楚看到請求頭中攜帶的User-Agent: Java/1.8.0_181為客戶端Java環境的版本且會隨著客戶端的Java環境而變化，Content-Type: application/octet-stream表示以二進位流傳輸數據，響應體的數據被加密，無法看出響應的內容是什麼，Content-Type: application/octet-stream代表二進位流也不能作為判定的依據，暫時無法提取的有效的特徵，但是注意到冰蠍在建立之前會有一個GET請求，咱們在最新版本中看一下會不會有這個GET請求。

V2.0.1版本冰蠍連接

冰蠍v2.0.1連接成功，抓取到流量包如下：

我們通過查看POST數據包發現除上述提到冰蠍增加了隨機的User-Agent和v1.0並無其它本質上的區別。

但是我們注意到依然會有GET請求，冰蠍檢測的難點在於在通訊過程中數據通過加密傳輸，難以提取特徵，下面我們比較一下兩個版本之間在連接過程中發起的GET請求。

V1.0請求包詳情如下：

V2.0.1請求包詳情如下：

通過比較發現，冰蠍在連接之前會發送一個GET請求，服務端如果正常會響應一個16位的字元串。其實冰蠍每一次連接請求都會向服務端發送一次GET請求獲取16位的密鑰，這16位的字元串就是密鑰，在客戶端和服務端的通訊過程中使用密鑰進行加密以達到免殺的目的，因此只要我們能在流量中發現這樣特徵的流量，便可以發現隱藏在流量中的冰蠍webshell。

冰蠍特徵總結

檢測請求方式：Request.method= GET

檢測請求資源：Request.url= /[w.]*.[a-zA-Z]{3,4}?w{0,20}=d{0,10}

檢測服務端響應（僅16位密鑰）：Response.body.startwith =w{16}

上述正則僅供參考，實際過程中需要防止規則被繞過，例如：shell的名字、後綴（可能利用解析漏洞等）、密碼的長度等等。本次僅從v1.0和v2.0.1中去分析，實際在目前的版本中都存在獲取密鑰這個請求，由於篇幅有限，只舉例說明了這個兩個版本。

文末總結

與檢測傳統的網站管理工具不同的，中國菜刀、中國蟻劍、c刀等都從POST請求中去提取特徵，而冰蠍在通訊過程中使用加密傳輸無法獲取明文，因此，利用冰蠍在和服務端通訊過程中會獲取密鑰的特性去檢測也許會是一種可行的方法。

參考鏈接

基於流量側檢測冰蠍webshell交互通訊(點擊底部閱讀原文查看)

*本文作者：lowliness，轉載請註明來自FreeBuf.COM