external_c2 フレームワーク

Cobalt Strike の External C2 仕様（仕様書）で説明されている仕様と併せて使用するための Python フレームワークです。

主な設計目標は、external c2 仕様を非常にモジュール化された実装とし、Cobalt Strike 用の C2 チャネルを簡単に実装できる十分な抽象化を提供することです。理想的には、ユーザーは transport モジュールと encoder モジュールを作成し、設定ファイルに値を記入するだけで、新しいチャネルを実装できます。

Dropbox トランスポート設定

開始する前に、いくつかの設定変更を行う必要があります。次のことを行ってください。

1. まだ作成していない場合は、Dropbox アカウントを作成します（https://www.dropbox.com/）
2. Dropbox アカウントのアクセストークンを生成します（https://www.iperiusbackup.net/en/create-dropbox-app-get-authentication-token/）
3. builds/client/dbox/dbox_client.py 内で、token を手順 2 で生成したものに変更します。
4. builds/server/utils/transports/transport_dbox.py でも、手順 3 と同じ変更を行います。
5. DLL をコンパイルします：cd builds/client/dbox && ./compile_dll.sh
6. Cobalt Strike Team Server を起動し、Cobalt Strike Client で接続します。
7. CS クライアントから start_externalc2.cna スクリプトを読み込みます。
8. このリポジトリをチームサーバーにコピーし、cd builds/server/ && ./dbox_server.py でサーバーを実行します。
9. 手順 6 の実行可能ファイルを対象ホストに配布して実行します。チームサーバーからの接続が確認できるはずです。

ビデオデモへのリンク: https://www.youtube.com/watch?v=nTRHSh_uCcA

アーキテクチャ

このプロジェクトは、次の 3 つの主要部分で構成されています。

• Builder（未実装）
• Client（クライアント）
• Server（サーバー）

Builder

Builder は、指定された設定に基づいてクライアントとサーバーのデプロイメントを動的に構築します。理想的には、クライアントは DLL や EXE などの単一のコンパイル済みファイルとして配布できることが望まれます。

Client

Client は基本的にエンドポイント上で実行されるペイロードであり、仕様書では third-party client と呼ばれます。クライアントのロジックは主に静的です。

1. transport を利用するために必要な準備を実行します
2. ステージャーを受け取ります
3. ステージャーを注入し、ビーコンへのハンドルを開きます
4. ビーコンからメタデータを取得します
5. transport を介してビーコンから C2 サーバーへメタデータを中継します
6. 新しいタスクがないか transport を監視します
7. 新しいタスクをビーコンに中継します
8. transport を介してビーコンからの応答を中継します
9. 手順 6〜8 を繰り返します。

トランスポートとエンコーディングの仕組みに必要な設定は、クライアントに静的にコピーされます。トランスポートとエンコーディングの仕組みの関数ロジックも、それぞれのモジュールから静的にコピーされます。

プロセスインジェクションのロジックは Builder によって決定されます。

Server

Server は、client と c2 server の間の通信を仲介するアプリケーションであり、仕様書では third-party Client Controller と呼ばれます。サーバーロジックは主に静的ですが、開発を支援するための verbose 出力とデバッグ出力をサポートしています。

1. 設定を解析します
2. 指定されたエンコーディングモジュールをインポートします
3. 指定されたトランスポートモジュールをインポートします
4. c2 サーバーへの接続を確立します
5. c2 サーバーからステージャーを要求します
6. encoder モジュールでステージャーをエンコードします
7. transport モジュールでステージャーを転送します
8. transport を介して受信したクライアントからのメタデータ応答を待ちます
9. encoder モジュールでメタデータをデコードします
10. メタデータを c2 サーバーへ中継します
11. c2 サーバーから新しいタスクを受け取ります
12. 新しいタスクをエンコードします
13. transport を介して新しいタスクをクライアントへ中継します
14. transport を介して受信したクライアントからの応答を待ちます
15. encoder モジュールで応答をデコードします
16. 応答を c2 サーバーへ中継します
17. 手順 11〜16 を繰り返します

サーバーがインポートする encoder モジュールと transport モジュールの決定は、config.py に保存されている値に基づいて行われます。

未使用の transport モジュールや encoder モジュールのインポートは実行されません。

Client とモジュールの共有機能

次の表は、encoding モジュールと transport モジュール、および client の間で共有される関数を示しています。共有関数は基本的にまったく同じコードです。

非常に重要な注意: client の sendData 関数と recvData 関数に送信するデータは生データ（raw data）である必要があります。一方、transport モジュールの sendData 関数と retrieveData 関数に送信するデータは、必要に応じてエンコードまたはデコード済みである必要があります。

Transport モジュール

Encoder モジュール

使い方

まず、使用する transport モジュールと encoding モジュールを決定します。次の例では、transport_gmail と encoder_b64url を使用します。

次に、server/config.py を自分のニーズに合わせて変更し、ENCODER_MODULE と TRANSPORT_MODULE が適切に設定され、目的のモジュールを指すようにします。

config.py のサンプル

EXTERNAL_C2_ADDR = "127.0.0.1"
EXTERNAL_C2_PORT = "2222"
C2_PIPE_NAME = "foobar"
C2_BLOCK_TIME = 100
C2_ARCH = "x86"
IDLE_TIME = 5
ENCODER_MODULE = "encoder_b64url"
TRANSPORT_MODULE = "transport_gmail"
verbose = False
debug = False

次に、選択した transport モジュールと encoder モジュールの設定セクションを変更します。

client/mechanism/$mechanism_client.py の設定セクションが、これまでに定義したすべての設定と一致することを確認してください。

サーバーを実行するマシン上で、次を実行します：

python server.py

より詳細な出力を得るには、次を実行します：

python server.py -v

より詳細な出力と、デバッグに役立つ追加出力を得るには、次を実行します：

python server.py -d

次に、対象エンドポイント上でクライアントを実行します。

すべてがうまくいけば、Cobalt Strike コンソール内に新しいビーコンが登録され、操作できるようになります。

FAQ

なぜこれを書いたのか？: この仕様の実装はあまり公開されておらず、公開されているものも、自分が慣れ親しんだ言語でなかったり、求めているモジュール性や抽象化を備えていなかったからです。

なぜ Python 2 なのか？: 私が怠惰だからです。そして、Python 2 では新しいトランスポートチャネルやエンコーディングチャネルを簡単に実装できます。

お前のコードはクソだ: それは質問ではありません。

新しい transport モジュールや encoder モジュールを提出できますか？: ぜひどうぞ！プルリクエストを送っていただければ、喜んでレビューします。

ロードマップ

• クライアントコンポーネントにも同様の抽象化とモジュール性を実装し、ビーコンペイロードのプロセスインジェクションのさまざまな方法や、ロードマップ上の他の機能をサポートする予定です。

• 現在、このプロジェクトには Builder 機能がありません。これはクライアントとサーバーのデプロイメントを動的に構築するために計画されているものですが、ロードマップに含まれています。