開門見山，不說廢話
判斷條件
是否符合通信的特征
請求加密的資料和回應包加密的型別一致
是否一直向同一個url路徑發送大量符合特征的請求，并且具有同樣加密的回應包
一 、蟻劍
特征為帶有以下的特殊欄位
第一個：@ini_set("display_errors","0");
第二個：eval
在編碼器和解碼器都是default的狀態下，是最容易看出來的一種情況
可以看到在下圖中，請求包和回傳包都是明文，也就是說一眼就能看出來是蟻劍的流量
實際上在antword中只要編碼器為default，那么請求包均為明文，
antword的編碼器共有以下幾種模式：default、base64、chr、chr16、rot12
在連接php的webshell時，不論編碼器處于那種模式，都會出現eval欄位
加密為base64：
加密為chr：
加密為chr16：
加密為rot13：
二、冰蝎
總結特征：
Accept: application/json, text/javascript, */*; q=0.01 #q=0.01
最新版本請求包沒有content-type，老版本Content-Type: application/octet-stream
回傳字串和請求字串都是加密，在擁有密鑰的情況下可以使用工具解密流量（當然加密也是一種特征）
加密為default_image的時候，具有png的請求頭，但是請求包中可能會出現java字樣的字符
如果是json加密就是
{
"id":"1",
"body":"{
"user":"加密的payload"
}"
}
加密為default_aes
header
Accept: application/json, text/javascript, */*; q=0.01
請求相應包都是AES加密
加密為default_image
?
?
加密為default_json
json結構
{
"id":"1",
"body":"{
"user":"payload"
}"
}
加密為aes_imagic
三、哥斯拉
探活資料包：
aes_base64: 請求包POST傳參pass，回應包為空
java_raw: 請求包POST傳參raw資料，Content-Type: application/octet-stream，探活資料包為空
cookie的最后面有個 ;
加密為JAVA_AES_BASE64
-
第一個通信包使用post請求發送pass引數探活，回應包為空
-
回應包前后有各拆分為一半的大寫32位MD5值
加密為JAVA_RAW
-
探活資料包，回應包為空，請求content-type為Content-Type: application/octet-stream
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/555189.html
標籤：其他
上一篇：漏洞復現 CVE-2023-0297( pyload遠程代碼執行漏洞 )
下一篇：返回列表