冰蝎3.0 Beta 2今天发布，和v2.1相比，最重要的变化就是“去除动态密钥协商机制，采用预共享密钥，全程无明文交互，密钥格式为md5("admin")[0:16]；”。

没有了秘钥交换过程，在冰蝎v2.1中的明显的流量特征“返回内容必定是16位的密钥”（返回包检测规则：^[a-fA-F0-9]{16}$）消失，给流量检测带来了更大的困难。

以php版本的shell为例，默认的秘钥为“e45e329feb5d925b”，通过md5("rebeyond")[0:16]得到，其中“rebeyond”是冰蝎3.0的默认密码。

抓包分析冰蝎3.0流量，连接后门的第一个post包已经是加密流量：

第一个包主要作用是进行秘钥key的验证，根据AES加密算法和预共享key，对抓到的加密请求进行解密：

再对AES解密后的base64编码内容进行解码，获得解密后的post数据：

如果服务端返回$content变量"93b5ca86-1a0a-48a6-8929-00528b33cedf"经过加密后的值，则认为key验证通过，进行后续流程，之后的通信全程加密。



由于key是攻击者预置，无法像2.0版本那样通过返回包获取，所以对加密流量无法解密，需要定位到冰蝎webshell后门才能获得。而冰蝎v3.0版本的webshell免杀也做了加强，webdir和d盾对冰蝎3.0自带的5个webshell后门的检出率都只有20%：

从流量侧进行检测的难度很大，网上有大佬还是能够根据包的长度特征、content-type、ua等方式找出一些特征，但在真实的业务环境中的检测效果还有待检测。



换个思路，流量层的检测能力也是有上限的，特别是对于加密的流量，单靠流量层的安全设备是不够的，按照纵深防御的理念，可以尝试从应用层、系统层的角度进行检测。以RASP应用层检测方案为例，目前OpenRASP技术仍然可以很好的检测到冰蝎3.0的攻击行为，防守方可以尝试。

 ![](upload/attach/202008/902647_PR9JND458JRGUZW.png)





祝大伙好运。

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课