zeoday/cobaltstrike4.5_cdf-1cobaltstrike4.5 버전 크랙, checksum8 특성 제거, BeaconEye 우회, 오류 경로로 인한 stage 유출 수정, totp 2단계 인증 추가, CVE-2022-39197 수정 등
cobaltstrike4.5 버전 크랙, checksum8 특성 제거, BeaconEye 우회, 오류 경로 stage 누출 수정, totp 2단계 인증 추가, 사용자 이름 암호화 표시 추가, 4.5 버전 foreign 파생 오류 버그 수정, 클라이언트 구성 파일 이름 변경 등
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의 앞 4바이트를 가져와 파일 헤더를 판별합니다(-889274181은 3.x 버전, -889274157은 4.x 버전). 그런 다음 var3에서 readShort()로 2바이트를 길이로 가져와 var5에 할당하고, var6 = var3.readBytes(var5)로 해당 길이만큼의 내용을 var6에 할당하여 반환합니다:
Authorization 클래스에서 얻은 arrayOfByte2 배열은 앞 6바이트를 제거한 내용입니다. 계속해서 arrayOfByte2 배열을 처리합니다. 먼저 4바이트를 가져와 i에 할당하고, 다시 4바이트를 가져와 watermark에 할당한 다음, 1바이트를 가져와 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과도 관련이 있습니다. 이것이 없거나 잘못되면 online 연결이 되지 않습니다. 아마도 공식에서는 이 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로 고정합니다: