nvisosecurity/pycobalthoundpyCobaltHoundは、Cobalt StrikeとBloodhoundの間の深い統合を提供することを目的とした、Cobalt Strike用のAggressorスクリプト拡張です。
pyCobaltHound は Cobalt Strike 用の Aggressor スクリプト拡張であり、Cobalt Strike と BloodHound の深い統合を提供することを目的としています。
pyCobaltHound は、以下の方法でレッドチームオペレーターを支援します。
BloodHound データベースに問い合わせて発見する。これを実現するために、pyCobaltHound は一連の組み込みクエリを使用します。オペレーターは独自のクエリを追加/削除して、pyCobaltHound の監視機能を微調整することもできます。これにより、エンゲージメント中に特定のターゲット（ユーザー、ホストなど）に合わせて pyCobaltHound を柔軟に適応させることができます。
pyCobaltHound をインストールするには、このリポジトリをクローンしてください。含まれているサブモジュールも忘れずにクローンしてください！
以下のコマンドを使用できます。
git clone https://github.com/NVISOsecurity/pyCobaltHound.git --recurse-submodules以下の依存関係が正しくインストールされていることを確認してください。
PyCobalt は Cobalt Strike 用の Python API です。多くの Aggressor 関数を Python から直接使用できるようにします。
Python3+ がインストールされていることを確認してください。PyCobalt は macOS や Windows でも動作する可能性がありますが、Linux でのみ実際にテストしています。
PyCobalt Python ライブラリを使用する方法は 2 つあります。
pyCobaltHound はこのアプローチを採用しており、Python プログラム内で sys.path 変数を使用して検索パスを設定しています。PyCobalt Python ライブラリをインストールする。そのためには、python3 setup.py install を実行します。インストールされたライブラリを使用するように pycobalthound.py を変更する必要があります（リポジトリに含まれているものではなく）。PyCobalt プロジェクトが将来もメンテナンスされる保証はないことに注意してください。実際、最新のアップデートは Cobalt Strike 4.2 の変更に対応するためのものでした。ただし、pyCobaltHound は Cobalt Strike とそのオペレーターとのインターフェースに基本的な Aggressor 関数しか使用していないため、pyCobaltHound にとってこれは大きな問題ではありません。PyCobalt サブモジュールは、私たちがフォークしたものです。ただし、PyCobalt リポジトリを管理しているわけではありません。PyCobalt には、実行中の Python スクリプトを管理するための Script Console コマンドがいくつか付属しています。Aggressor スクリプトをリロードするときは、最初に明示的に Python スクリプトを停止する必要があります。そうしないと、何もせずに永遠に実行され続けます。pyCobaltHound の開発中、これが未定義の動作を引き起こす可能性があることに気付きました。
pyCobaltHound のリロードは次のように行えます。
aggressor> python-stop-all`
[pycobalt] Asking script to stop: /root/pycobalthound/pycobalthound.py
[pycobalt] Script process exited: /root/pycobalthound/pycobalthound.py
aggressor> reload example.cna`
[pycobalt] Executing script /root/pycobalthound/pycobalthound.py
PyCobalt を正しく動作させるには、1 つの Aggressor スクリプトでのみ PyCobalt を呼び出す必要があります。pyCobaltHound を他の PyCobalt を使用する Aggressor スクリプトと一緒に使用する場合は、この点に注意してください。私たちのアプローチは、PyCobalt ベースのツールごとに python() と include() の呼び出しを含む Aggressor スクリプトを用意することです。
notify2 は、Linux でデスクトップ通知を表示するためのパッケージです（現在はそうですが、過去形かもしれません）。後述するように、pyCobaltHound はオペレーターに通知するいくつかの方法をサポートしています。notify2 は Linux で D-Bus を介して通知デーモンに通知を送信するために使用されます。
これを有効にするには、次のコマンドで notify2 をインストールする必要があります。
pip install notify2
Cobalt Strike で pyCobaltHound を使用するには、pycobalthound.cna Aggressor スクリプトをクライアントにインポートするだけです。これが完了すると、Cobalt Strike のメニューバーに pyCobaltHound メニューが表示されるはずです。
pyCobaltHound の初期の目標は、Cobalt Strike の資格情報キャッシュ（View > Credentials）を新しいエントリについて監視することでした。これは、Cobalt Strike が資格情報ストアに変更があったときに発生させる on_credentials イベントに反応することで実現します。
このイベントが発生すると、pyCobaltHound は以下を実行します。
Cobalt Strike から受信したデータを解析して検証する。BloodHound データベースに存在するか確認する。BloodHound データベースに問い合わせる。これらはすべてメインの Cobalt Strike クライアントから非同期的に行われるため、UI がブロックされることはなく、pyCobaltHound がバックグラウンドで調査している間も作業を続けられます。
pyCobaltHound は、複数のチームサーバーを使用する際の問題を防ぐために、チームサーバーごとに別々のキャッシュを使用します。
特定のユーザー（または資格情報ストア全体）を再調査したい場合があります。これは、BloodHound データベースに新しいデータをアップロードした場合などに該当します。
pyCobaltHound は資格情報ストア内のすべてのエンティティを既に調査（したがってキャッシュ）しているはずなので、オペレーターの介入なしに新しいデータに対してそれらを評価することはありません。
オペレーターは、キャッシュされるエンティティを制御するために 2 つの方法を利用できます。
特定のエンティティ（または複数）をキャッシュから削除したい場合は、資格情報ビューア（View > Credentials）で行えます。対象を選択し、pyCobaltHound メニューエントリの下にある remove from cache オプションをクリックするだけです。
キャッシュからすべてのエンティティを削除したい場合は、pyCobaltHound のメインメニュー（Cobalt Strike > pyCobaltHound > Wipe cache）で行えます。これは、資格情報ストア全体を再評価したい場合に最も役立ちます。
ターゲットをキャッシュから削除した後、pyCobaltHound に資格情報ストアの内容を再調査するよう手動で促すことができます。これは上記と同じプロセスに従います。
pyCobaltHound には、既存のビーンセッションと対話する機能が含まれています。これはビーコンのコンテキストメニューにあります。これらのコマンドは、単一のビーコンまたは選択したビーコンに対して実行できることに注意してください。
この機能は、資格情報がまだ侵害されていないが、実質的に制御下にある（例えば、そのセッショントークンでビーコンが実行されている）ユーザーやコンピュータを扱う場合に特に便利です。
Mark as owned 機能（pyCobaltHound > Mark as owned）は、ビーコン（またはビーコンコレクション）を BloodHound データベースで所有済みとしてマークするために使用できます。
このダイアログでは、オペレーターに以下の情報を求めます。
pyCobaltHound は、ビーンセッションがローカル管理者、SYSTEM、または別のユーザーとしての高整合性セッションとして実行されている場合にのみ、コンピュータを所有済みとしてマークします。Investigate 機能（pyCobaltHound > Investigate）は、ビーコン（またはビーコンコレクション）に関連するユーザーとホストを調査するために使用できます。
このダイアログでは、オペレーターに以下の情報を求めます。
pyCobaltHound は、ビーンセッションがローカル管理者、SYSTEM、または別のユーザーとしての高整合性セッションとして実行されている場合にのみ、コンピュータを調査します。pyCobaltHound は、整合性レベルをチェックせずにすべてのエンティティを調査します。pyCobaltHound には、エンティティを自由に調査する機能が含まれています。これはメインメニュー（Cobalt Strike > pyCobaltHound > Investigate）にあります。
この機能は、資格情報が侵害されておらず、制御下にもないユーザーやコンピュータを扱う場合に特に便利です。
このダイアログでは、オペレーターに以下の情報を求めます。
pyCobaltHound の設定メニューは、Cobalt Strike > pyCobaltHound > Settings にあります。
pyCobaltHound は設定をディスクに保存します。pyCobaltHound がリロードされるたびに、設定ファイルの存在を確認し、見つかった場合は保存された設定を読み込みます。
pyCobaltHound はチームサーバーごとに設定ファイルを保存するため、異なるチームサーバーで異なる設定を持つことが可能です。
BloodHound データベースに認証するために、pyCobaltHound は以下の情報を必要とします。
注意: 設定を永続的に保存する（クライアント/ホストの再起動をまたいで保持する）ことを選択した場合、pyCobaltHound はこれらの資格情報をデシリアライズしてディスクに保存します。
前述のとおり、pyCobaltHound はキャッシュを使用して不要な作業を防ぎます。このキャッシュは設定で無効にできます。これは主に新しいクエリを開発する場合に便利で、キャッシュを常に管理/ワイプする必要がなくなります。
pyCobaltHound は、興味深いエンティティを特定した際にオペレーターに通知するためのいくつかの方法をサポートしています。これらの通知を無効にすることも可能です。
デフォルトでは、pyCobaltHound はデフォルトの Aggressor メッセージボックスを使用してオペレーターに通知します。このオプションはオペレーターのワークフローに影響を与える可能性があります。ただし、Cobalt Strike クライアントを実行できるすべてのプラットフォームでサポートされているため、デフォルトの方法となっています。
pyCobaltHound は、Linux でのデスクトップ通知表示もサポートしています。これは、オペレーターのワークフローを中断しないため、私たちが好むオプションです。
一部のワークフロー中、pyCobaltHound は HTML レポートを生成します。この設計選択は、多くのエンティティが調査された場合にオペレーターに巨大な通知が殺到するのを避けるために行われました。これらのレポートは reports フォルダに生成されます。レポート生成を無効にすることも可能です。
デフォルトでは、pyCobaltHound はすべてのクエリ関連設定に中央ファイルを使用して、チームサーバー間でクエリを同期します。つまり、あるチームサーバーで有効化、追加、削除されたクエリは、他のチームサーバーでも有効化、追加、削除されます。これは主に利便性のためのオプションであり、無効にすることもできます。これは、接続しているすべてのチームサーバーには適用されないエンゲージメント固有のクエリを実行している場合などに便利です。
クエリ同期が無効の場合、pyCobaltHound は固有のクエリファイルの存在を確認します。存在する場合は、それらを読み込んでワークフロー中に使用します。ファイルが存在しない場合は、作成して読み込みます。この設定はリロード後も維持されます。
クエリ同期が有効の場合、pyCobaltHound は固有のクエリファイルの存在を確認します。存在する場合、オペレーターに選択を促します。
オペレーターには以下の選択肢があります。
pyCobaltHound は固有のクエリファイルを単に削除します。すべてのカスタムクエリは失われます。pyCobaltHound は固有のクエリファイルを一般クエリファイルにマージしようとします。クエリをマージする前に、一般ファイルに同じ名前または同じ Cypher ステートメントを持つクエリがないか確認します。マージ競合が発生した場合、オペレーターはマージされなかったクエリを保持するかどうかを尋ねられます。それらは別のファイルに保存されます。その後、固有のクエリファイルは削除されます。pyCobaltHound は固有のクエリファイルをそのまま残します。すべてのカスタムクエリは保持され、クエリ同期が再び無効にされた場合に再度読み込まれます。pyCobaltHound は現在、以下の組み込みクエリをサポートしています。
pyCobaltHound が使用するさまざまなクエリの管理は、メインメニュー（Cobalt Strike > pyCobaltHound > Queries）から行えます。
Update queries ダイアログを使用すると、オペレーターは特定のクエリを有効/無効にできます。このダイアログを使用する際、オペレーターは最初に更新するクエリのタイプを尋ねられます。これは、このワークフロー中に正しいクエリを動的にレンダリング/読み込むためです。
最初のダイアログに回答すると、オペレーターにはそのタイプの利用可能なすべてのクエリのリストが表示されます。ここで、有効/無効にしたいクエリを選択できます。
クエリタイプオプションは、クエリタイプをワークフローの次の関数に渡すための醜い回避策であり、オペレーターにとっては気にする必要はありません。
Add query 機能を使用すると、オペレーターは独自のクエリを追加/削除して、pyCobaltHound の調査機能を微調整できます。これにより、エンゲージメント中に特定のターゲット（ユーザー、ホストなど）に合わせて pyCobaltHound を柔軟に適応させることができます。
このダイアログでは、オペレーターに以下の情報を求めます。
pyCobaltHound のワークフロー中のさまざまなメニューやレポートで使用されます。pyCobaltHound が実行する必要がある Cypher クエリ。オペレーターはクエリを自由に定義できます。唯一の要件は以下の通りです。
pyCobaltHound は、調査しているエンティティ名に基づいて以下の Cypher 文字列を動的に生成します。
WITH [account names here] AS samAccountNames UNWIND samAccountNames AS namesMATCH (x) WHERE x.name STARTS WITH names(x:User)）をお勧めします。pyCobaltHound は、クエリがユーザー名の重複のない集合を返すことを期待します。
RETURN DISTINCT (x.name) で終了させてください。pyCobaltHound がカスタムクエリに使用する見出し。これは pyCobaltHound のワークフロー中の通知やレポートで使用されます。
pyCobaltHound がこのクエリの結果数で置き換えます。Delete query ダイアログを使用すると、オペレーターは pyCobaltHound から特定のカスタムクエリを削除できます。このダイアログを使用する際、オペレーターは最初に削除するクエリのタイプを尋ねられます。これは、このワークフロー中に正しいクエリを動的にレンダリング/読み込むためです。
最初のダイアログに回答すると、オペレーターにはそのタイプの利用可能なすべてのクエリのリストが表示されます。ここで、削除したいクエリを選択できます。
クエリタイプオプションは、クエリタイプをワークフローの次の関数に渡すための醜い回避策であり、オペレーターにとっては気にする必要はありません。
pyCobaltHound は以下のものを使用/参考にしています。