cobaltstrike4.5版本破/解、去除checksum8特征、bypass BeaconEye、修复错误路径泄漏stage、增加totp双因子验证、修复CVE-2022-39197等
cobaltstrike4.5版本破解、去除checksum8特征、bypass BeaconEye、修复错误路径泄漏stage、增加totp双因子验证、增加用户名加密显示、修复4.5版本foreign派生错误的bug、客户端配置文件名字修改等
cobalt strike4.5破解
cobaltstrike4.5破解
[TOC]
此工具以及文章内容仅限于安全研究,用户承担因使用此工具以及文章内容而导致的所有法律和相关责任!作者不承担任何法律责任! 如您在使用本工具以及文章内容的过程中存在任何非法行为,您需自行承担相应后果,我们将不承担任何法律及连带责任,否则,请您不要安装并使用本工具。您的使用行为或者您以其他任何明示或者默示方式表示接受本协议的,即视为您已阅读并同意本协议的约束。在使用本工具进行安全研究时,您应确保该行为符合法律法规,并且已经取得了足够的授权。请勿对非授权目标使用。
是的,我又回来了,继续原cobaltstrike4.4_cdf:https://github.com/lovechoudoufu/about_cobaltstrike4.4_cdf 这次是4.5版本。之前的4.4被github给删了,估计过不了多久该项目也会被删除~。
建议加入小飞机群,后续其他更新及项目被删除后可从群内下载:

使用前请认真核对相应版本jar包hash。
证书认证流程(4.3为例):4.5版本最后稍有改动。
各个版本的官方解密key:
4.0 1be5be52c6255c33558e8a1cb667cb06
4.1 80e32a742060b884419ba0c171c9aa76
4.2 b20d487addd4713418f2d5a3ae02a7a0
4.3 3a4425490f389aeec312bdd758ad2b99
4.4 5e98194a01c6b48fa582a6a9fcbb92d6
cobaltstrike.auth认证密钥文件,rsa加密,解密内容:
4.3
-54, -2, -64, -45, //文件头
0, 77, //后续长度
1, -55, -61, 127, //证书时间限制29999999(永久)
0, 0, 0, 1, //watermark(水印)
43, //版本
16, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20,
16, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20,
16, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20,
16, 58, 68, 37, 73, 15, 56, -102, -18, -61, 18, -67, -41, 88, -83, 43, -103
每更新一个版本,对应的长度+17,key增加17位。
aggressor/Aggressor.class中License.checkLicenseGUI(new Authorization());开始license认证:

License.checkLicenseGUI中isValid、isPerpetual、isExpired、isAlmostExpired对授权是否有效、授权是否过期进行判断:

Authorization类中是cobaltstrike.auth文件的处理,读取文件内容,调用AuthCrypto().decrypt对内容进行处理:

AuthCrypto()中构造函数中调用load(),load()函数中对resources/authkey.pub进行md5判断,再获取了RSA的公钥:

decrypt()中调用_decrypt对cobaltstrike.auth文件内容用公钥进行RSA解密赋值给数组var2,再用DataParser做转换赋值给var3,readInt()方法获取var3的前四位进行文件头判断(-889274181为3.x版本;-889274157为4.x版本)。再从var3中readShort()获取两位作为长度赋值给var5,再var6 = var3.readBytes(var5)获取该长度内容赋值给var6并返回:

在Authorization类中得到的arrayOfByte2数组是去除前六位之后的内容,继续对arrayOfByte2数组进行处理,先获取四个数字赋值给i,再获取4个数字赋值给watermark,再获取一个数字赋值给b1,判断b1小于43,判断i是否等于29999999,在common/ListenerConfig中判断watermark为0时候会增加杀毒检测水印:


去除前6位后,再去除i、watermark、b1这9位,剩余的为4.0到4.3以来的key,为:16, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20结构:
byte b2 = dataParser.readByte(); //获取1位,即16
byte[] arrayOfByte3 = dataParser.readBytes(b2); //获取16位,为4.0的key
byte b3 = dataParser.readByte(); //获取1位,即16
byte[] arrayOfByte4 = dataParser.readBytes(b3); //获取16位,为4.1的key
byte b4 = dataParser.readByte(); //获取1位,即16
byte[] arrayOfByte5 = dataParser.readBytes(b4); //获取16位,为4.2的key
byte b5 = dataParser.readByte(); //获取1位,即16
byte[] arrayOfByte6 = dataParser.readBytes(b5); //获取16位,为4.3的key赋值给arrayOfByte6
在Authorization类中调用SleevedResource.Setup方法对arrayOfByte6进行处理。在SleevedResource中把key设定为AES、HmacSHA256解密的秘钥,在_readResource中的this.data.decrypt(arrayOfByte1);进行解密调用,解密的内容为/sleeve/中的dll文件:

在SleeveSecurity中设定AES、HmacSHA256解密的秘钥,使用传入的值计算一个长度为256的摘要,再取0-16作为AES的密钥,取16-32作为HmacSHA256的密钥

如果得不到对应的key,就无法对sleeve文件夹中的dll进行解密,连接服务端时候会提示[Sleeve] Bad HMAC的错误提示:

hmac解密部分可参考:Cobaltstrike 4破解之 我自己给我自己颁发license
所以完成破解的关键是对应cs版本的key。
根据官方描述,4.5版本新增license的安全性,的确如此,

所以我们需要解密下泄漏的auth文件,看看多了什么:

在4.5的key位置后面多了一串,多的这些是该版本新增的watermarkHash:

watermarkHash和beacon的生成有关,与sleeve文件夹中dll相关,没有他或者错误时无法上线。大概官方可以通过这个watermarkHash反溯到泄漏的源头吧。

注释掉其他代码,对AuthCrypto().decrypt进行RSA解密后赋值的参数写死:

byte[] var4 = {1, -55, -61, 127, 0, 1, -122, -96, 45, 16, 27, -27, -66, 82, -58, 37, 92, 51, 85, -114, -118, 28, -74, 103, -53, 6, 16, -128, -29, 42, 116, 32, 96, -72, -124, 65, -101, -96, -63, 113, -55, -86, 118, 16, -78, 13, 72, 122, -35, -44, 113, 52, 24, -14, -43, -93, -82, 2, -89, -96, 16, 58, 68, 37, 73, 15, 56, -102, -18, -61, 18, -67, -41, 88, -83, 43, -103, 16, 94, -104, 25, 74, 1, -58, -76, -113, -91, -126, -90, -87, -4, -69, -110, -42, 16, -13, -114, -77, -47, -93, 53, -78, 82, -75, -117, -62, -84, -34, -127, -75, 66, 0, 0, 0, 24, 66, 101, 117, 100, 116, 75, 103, 113, 110, 108, 109, 48, 82, 117, 118, 102, 43, 86, 89, 120, 117, 119, 61, 61};
Javaagent原理:https://www.cnblogs.com/rickiyang/p/11368932.html
破解工具可参考:https://github.com/Twi1ight/CSAgent
破解的核心还是需要cs对应版本的key
beacon/BeaconData中将shouldPad方法的值固定为false:

4.4新暗桩
(之前以4.3为例进行License认证分析,换成4.4后发现运行退出,存在新的暗桩)
相比之前的this.shouldPad的exit,又在common/Helper增加.class判断,注释即可:

在common/Starter中增加.class判断,注释即可:

在common/Starter2中增加.class判断,注释即可:

在beacon/CommandBuilder中增加.class判断:(这个暗桩还真狗,client和temserver连续连接4小时后无法执行命令,从没连接过这么久所以也没发现,ggg)