Inline-Execute-PE

免責事項:

このプロジェクトは複雑であり、仕組みを理解せずに適切にテストしないと、Beacon がクラッシュしてアクセスを失う可能性があります。

「設計上の考慮事項と解説」セクションまでのすべてのドキュメントを読むことを強くお勧めします。

はじめに

Inline-Execute-PE は、Beacon Object File（BOF）と、CobaltStrike 用の Aggressor スクリプトのスイートです。これにより、オペレーターはアンマネージド Windows 実行可能ファイルを Beacon メモリにロードして実行し、出力を取得して Beacon コンソールに表示できます。

これにより、オペレーターは多くのサードパーティ製ツール（Mimikatz、Dsquery、Sysinternals ツールなど）を、ディスクに書き込んだり、Donut のようなツールを使って位置独立コードに再フォーマットしたり、新しいプロセスを作成して実行したりする必要がなくなります。

これらの実行可能ファイルは Beacon メモリにマッピングされるため、ネットワーク経由で送信したり、新しいメモリを割り当てたり、毎回新しい conhost.exe プロセスを作成したりすることなく、繰り返し実行できます。

Beacon にロードされた実行可能ファイルは、CobaltStrike Team Server に接続されたすべての CobaltStrike クライアントがアクセスおよび実行できます。

Inline-Execute-PE は、x64 Beacon と、Mingw または Visual Studio でコンパイルされた x64 Windows C または C++ 実行可能ファイル用に設計されています。このプロジェクトは、x86 実行可能ファイルや、別の言語で記述された、または別のコンパイラでコンパイルされた x64 実行可能ファイルはサポートしていません。

セットアップ

リポジトリをクローンし、必要に応じて make を実行して BOF を再コンパイルします。

Inline-Execute-PE.cna を CobaltStrike クライアントにロードします。CobaltStrike が実行されているディレクトリがユーザーによって書き込み可能であることを確認してください。Inline-Execute-PE は、機能に必要なデータの可用性を確保するために、そこにテキストファイル（petable.txt）を作成します。

コマンド

Inline-Execute-PE は、BOF を実行する 3 つのターゲット向けコマンドと、プロジェクトのデータ構造を操作する 3 つの内部コマンドで構成されています。

ターゲット向け:

1. peload
2. perun
3. peunload

内部データ構造:

1. petable
2. peconfig
3. pebroadcast

peload

peload は Inline-Execute-PE の開始点です。このコマンドは、PE を Beacon メモリにロードするために使用されます。以下の主要なアクションを実行します:

1. 指定された PE をネットワーク経由で Beacon に送信するか、ターゲットマシン上のディスクから読み取る PE の名前を送信します。
2. Inline-Execute-PE がライフサイクル全体で必要とするさまざまなポインタとハンドルを保持する構造体を Beacon メモリに作成します。
3. Beacon にメモリを割り当て、RW 保護で PE を書き込みます。
4. ユーザー指定のキーを使用して、メモリ内の PE を XOR 暗号化します。
5. 別のメモリチャンクを割り当て、XOR 暗号化された PE をそこにコピーします。これは、後続の実行のために PE を「元に戻す」ことができるようにするために必要です。
6. Beacon の下に conhost.exe 子プロセスを生成し、stdin/stdout/stderr を初期化します。
7. stdout と stderr を匿名パイプにリダイレクトして、PE の出力をキャプチャできるようにします。

perun

perun は Inline-Execute-PE の 2 番目のステップです。以下の主要なアクションを実行します:

1. コマンドライン引数をネットワーク経由で Beacon に送信します。
2. メモリ内の PE を XOR 復号します。
3. PE のインポートアドレステーブル（IAT）を修正し、コマンドライン引数とプロセス終了に関連する特定の API をフックします。
4. PE のメモリ保護を RWX に変更します。
5. PE を自身のスレッドで実行します。
6. PE からの出力をキャプチャし、CobaltStrike に返します。
7. PE のメモリ保護を RW に戻します。
8. peload 時に作成された XOR コピーでメモリ内の PE を上書きします。

peunload

peunload は、オペレーターが PE を使い終えたとき、または別の PE をロードしたいときに、Beacon メモリから PE を削除するために呼び出されます。以下の主要なアクションを実行します:

1. peload 中に作成されたハンドルとファイルポインタを閉じます。
2. peload 中に作成された conhost.exe プロセスを終了します。
3. メモリ内の PE の両方のコピーをゼロで埋めてから解放します。
4. PE によって Beacon プロセスにロードされた DLL をアンロードしようとします（オプション）。

petable

petable は、現在 Beacon にロードされているすべての PE に関する情報を表示するために使用されます。

各 CobaltStrike クライアントは独自の petable を持っています。Inline-Execute-PE は、接続されているすべての CobaltStrike クライアント間でデータの同期を確保するために多大な努力を払っており、すべてのオペレーターが PE を使用できるようにしています。詳細については、「設計上の考慮事項と解説」を参照してください。

peconfig

peconfig は、Inline-Execute-PE の機能に関するオプションを構成するために使用されます。現在変更可能な 2 つのオプションは次のとおりです:

1. タイムアウト。これは、perun が PE の実行完了を待機する時間を指定し、その後終了します。これは、正しくない引数が PE に渡され、実行が戻らなくなったり完了しなくなったりする場合の安全策として存在します。この設定はデフォルトで 60 秒ですが、より長時間実行される PE に対応するために変更できます。
2. UnloadLibraries。このオプションは、peunload が PE によってロードされた DLL を Beacon プロセスから解放しようとするかどうかを制御します。デフォルトでは TRUE に設定されています。一部の PE では、Beacon プロセスから DLL をアンロードすると問題が発生し、Beacon がクラッシュする可能性があります。その場合、PE によってロードされたすべての DLL を Beacon プロセスに残しておく方がよいでしょう。これは、powershell.exe を使用する際に観察されています（おそらく、.Net CLR を Beacon プロセスにロードすることが原因です）。

pebroadcast

pebroadcast は、クライアントの petable の内容を、接続されている他のすべての CobaltStrike クライアントに手動でブロードキャストするために使用できます。

その他のすべての CobaltStrike クライアントは、ブロードキャストされたデータで petable を更新します。これが必要になることはほとんどありませんが、念のため機能として存在します。

使用方法

peload を使用して PE を Beacon メモリにロードします。

または、ターゲットマシン上に新しいプロセスを作成せずに使用したい PE がある場合は、パスと --local スイッチを指定します。

perun を呼び出し、ロードされた PE に任意の引数を渡します。

引数内の二重引用符は、バックスラッシュでエスケープする必要があります。

アンロード時に DLL の解放に問題が発生する PE を特定した場合は、peconfig を使用して unloadlibraries を false に設定します。

PE の使用が完了したら、peunload を呼び出して Beacon からクリーンアップします。

これで、別の PE を Beacon にロードできるようになります。

perun のタイムアウト

PE に渡すコマンドライン引数には注意が必要です。一部の PE は間違った引数を与えるとすぐにクラッシュしますが、他の PE は無限に実行され、プロセスはまだ実行中であっても Beacon がコールバックしなくなることがあります。

これは、引数リストの最後に 'exit' を指定しない場合の Mimikatz.exe で確認できます。

...

Inline-Execute-PE は、指定されたタイムアウト値に達すると、実行中の PE のスレッドを終了します。これにより、Beacon が通常の通信を再開できるようになります（perun BOF の実行が完了するまで Beacon はコールバックしません）。この Beacon で通常の CobaltStrike コマンドや他の BOF を引き続き使用することはできますが、Inline-Execute-PE は無効になります。この方法で実行中の PE が終了すると、Beacon プロセスの stdout と stderr が壊れ、後続の PE が適切に機能しないようです。

PE は Beacon メモリからアンロードすることは可能です（また、そうすべきです）。ただし、petable を表示すると、この Beacon にそれ以上 PE をロードできなくなることが示されます。

Inline-Execute-PE で実行する PE をテストし、perun にコマンドライン引数を渡す際には注意を払うことが必須です。許容度の高い PE もあれば、そうでないものもあります。

ヒント、コツ、および観察事項

以下は、テストと開発中に行った、ユーザーが Beacon にロードしたいと思われる特定の PE に関する観察事項であり、順不同です。

1. Powershell.exe で peunload を使用すると、UnloadLibraries が TRUE の場合、通常 Beacon がクラッシュします。これは、Powershell.exe が CLR をロードすることに関係していると考えられます。
2. Cmd.exe は、最初の引数として '/c' を使用しないと Beacon がクラッシュします。例: 'perun /c cd' は問題ありませんが、'perun cd' は問題があります。
3. Mimikatz.exe は、ロード、使用、アンロードを行い、その後再びロードすると、最初の peunload で UnloadLibraries が TRUE だった場合、Beacon がクラッシュします。
4. 一部の PE は、終了時にヘルプメニューを表示するようにプログラムされています。これらの出力は表示されません。なぜなら、ExitProcess や exit() などの呼び出しはフックされ、ExitThread にリダイレクトされるため、PE が Beacon プロセスを終了させることがないからです。
5. 一部の PE は、使用が終了してもメモリを適切に解放せず、プロセスが終了するときに解放されることに依存しています。PE は Beacon プロセス内で実行されるため（したがって、PE が終了してもプロセスは終了しません）、より多くの PE がロードされて実行されるにつれて Beacon が肥大化する傾向があります。Process Explorer などを使用してテスト中にこれを観察し、運用中に注意してください。
6. Sysinternals の Psexec は機能しないようです。実行はされますが、リモートマシンへのハンドルが無効であるというエラーが表示されます。実際には、psexec のようなものを使用したい場合は、CobaltStrike の SOCKS プロキシとアタックボックス版の psexec を使用する方がおそらく適切です。
7. Inline-Execute-PE で使用するために新しい Beacon を生成することはおそらく悪い考えではありません。特に、さまざまな PE がフレームワーク内でどのように相互作用し機能するかの感触をつかんでいる間はそうです。2 つは 1 つ、1 つは無しです。
8. 新しいプロセスを作成するテレメトリなしで LOLBIN を使用したい場合は、peload で --local スイッチを使用し、ターゲットシステム上のディスクから読み取ります。これは、バージョンの問題を回避するのにも役立ちます。

IOC と AV/EDR

Inline-Execute-PE に関連する IOC には、以下が含まれますが、これらに限定されません:

1. VirtualAlloc を使用したメモリの割り当て
2. 割り当てられたメモリの保護を RW と RWX の間で変更する
3. 子 conhost.exe プロセスの作成
4. マッピングされた PE に必要な DLL のロード
5. 実際の PE によって実行されるすべてのアクション。例: LSASS に触れる Mimikatz

AV/EDR

開発中に EDR に対する完全なバッテリーテストは行いませんでした。怠慢とテスト環境の不足が理由の一部です。ただし、最新パッチの Windows Defender（私の経験ではかなり優れた AV 製品です）に対してテストしました。

Mimikatz.exe はおそらく、Inline-Execute-PE で使用する候補として最も疑わしくよく知られた PE です。Inline-Execute-PE を使用した Mimikatz の実行を Windows Defender が検出できるかどうかは、Beacon が実行されているプロセスに依存することがわかりました。