CobaltStrike 4.5 バージョンのクラック、checksum8特徴の除去、BeaconEyeのバイパス、エラーパスによるstage漏洩の修正、TOTP二要素認証の追加、CVE-2022-39197などの修正
cobaltstrike4.5 版のクラック、checksum8 特徴の除去、BeaconEye のバイパス、エラーパスによる stage 漏洩の修正、TOTP 二段階認証の追加、ユーザー名の暗号化表示の追加、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 によって削除されましたが、このプロジェクトも間もなく削除されるでしょう~。
Telegram グループへの参加をお勧めします。今後の他のアップデートやプロジェクトが削除された場合、グループ内からダウンロードできます:

使用前に、対応するバージョンの jar パッケージのハッシュをよく確認してください。
証明書認証フロー(4.3を例とする): 4.5 バージョンでは最後に少し変更あり。
各バージョンの公式復号キー:
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 され、キーが 17 バイト増えます。
aggressor/Aggressor.class 内の License.checkLicenseGUI(new Authorization()); からライセンス認証が始まります:

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 までのキーであり、以下の構造です: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 のキー
byte b3 = dataParser.readByte(); // 1 バイト取得、すなわち 16
byte[] arrayOfByte4 = dataParser.readBytes(b3); // 16 バイト取得、4.1 のキー
byte b4 = dataParser.readByte(); // 1 バイト取得、すなわち 16
byte[] arrayOfByte5 = dataParser.readBytes(b4); // 16 バイト取得、4.2 のキー
byte b5 = dataParser.readByte(); // 1 バイト取得、すなわち 16
byte[] arrayOfByte6 = dataParser.readBytes(b5); // 16 バイト取得、4.3 のキーを arrayOfByte6 に代入
Authorization クラス内で SleevedResource.Setup メソッドを呼び出して arrayOfByte6 を処理します。SleevedResource ではキーを AES、HmacSHA256 復号の秘密鍵として設定し、_readResource 内の this.data.decrypt(arrayOfByte1); で復号を呼び出し、復号される内容は /sleeve/ 内の dll ファイルです:

SleeveSecurity では AES、HmacSHA256 復号の秘密鍵を設定し、渡された値を使用して長さ 256 のダイジェストを計算し、0-16 を AES の鍵、16-32 を HmacSHA256 の鍵として使用します

対応するキーを取得できない場合、sleeve フォルダ内の dll を復号できず、サーバーに接続する際に [Sleeve] Bad HMAC のエラーメッセージが表示されます:

hmac の復号部分については、Cobaltstrike 4 クラック ~自分でライセンスを発行する~ を参照してください。
したがって、クラックを成功させる鍵は、対応する cs バージョンのキーです。
公式の説明によると、4.5 版ではライセンスのセキュリティが強化されています。確かにその通りです。

そこで、漏洩した auth ファイルを復号して、何が追加されたか確認する必要があります:

4.5 のキーの位置の後ろにさらに文字列が追加されています。これが、このバージョンで追加された 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 対応バージョンのキーが必要です。
beacon/BeaconData 内の shouldPad メソッドの戻り値を false に固定します: