DSCourier BOF

これは、Dylan Davis 氏と Matthew Schramm 氏による DSCourier プロジェクトの BOF 実装です。WinGet の COM インターフェースを使用して、Microsoft によって署名され信頼されたプロセス内で任意の PowerShell コードを実行します。両氏の詳細な研究ブログは こちら でご覧いただけます。

私が公開しているほとんどのプロジェクトとは異なり、これは運用可能なツールではなく、むしろ概念実証（POC）です。このBOFを容易に展開可能にすることを妨げるいくつかの問題を発見したため、これ以上追求しないことにしました。コードはほぼすべてClaudeによって生成されました。いくつかの未解決の問題が残っており、以下で議論します。

使用法

任意のPowerShellコードを dist/rev.yml ファイルに配置してください。デフォルトでは、元のリポジトリにあるシンプルなPowerShellリバースシェルが含まれています。それを使用する場合は、既存の例内のIPを目的のIPに置き換えてください。

PowerShellリバースシェルを使用した例：

動作原理と制限事項

特に順序はありませんが、このツールに関するいくつかの問題/制限事項を以下に示します。

1. COM呼び出しを成功させるには、Microsoft.Management.Configuration.winmd ファイルがCOM呼び出しを行う実行ファイルと同じディレクトリに存在している必要があります。これは、例えば通常ユーザーに書き込み権限がない hollowed-out system32 プロセスから Beacon を実行する場合に直ちに問題となります。これを回避するために、ファイルは代わりに %APPDATA%\temp にドロップされ、winmdファイルパスを取得する WinTypes!RoGetMetaDataFile 関数をインラインフックでフックして、一時パスの場所を提供できるようにしています。これにより、winmdファイルの読み取り/COM呼び出しが成功するようになりますが、VirtualProtect呼び出しが行われ、DLLメモリが上書きされるため、IOCが作成されます。
2. #1に続き、BOF実行後、Beaconプロセスが終了するまでwinmdファイルがディスク上でロックされます。この問題を解決するために、現在よく知られている自己削除機能を追加するなど少し試しましたが、ファイルはディスク上でロックされたままでした。おそらくこれを回避/解決する方法を考案できるかもしれませんが、それは他の誰かに任せることにします。
3. 元の研究で述べられているように、これはWinGet内のpwshリソースを使用するため、conhost.exeプロセスがConfigurationRemotingServer.exeの子プロセスとして生成されます。Claudeは、pwshを呼び出す代わりにカスタムバイナリモジュールをリソースとしてロードすることが可能であり、それによってconhostの問題が解決される可能性があると示唆しましたが、これには追加のファイルをディスクにドロップする必要があり、私はそれを動作させることができませんでした。不可能かもしれません。もし可能であれば、ConfigurationRemotingServer.exeによってロードされ、渡されたシェルコード/パラメータなどを実行できる汎用的な.NET DLLをディスクにドロップする道が開かれます。
4. このBOFは、必要なCOMインターフェースのAsyncバージョンを実装しています。Syncバージョンを使用すると、ConfigurationRemotingServer.exeプロセスが完了するまでBeaconがハングし/コールバックしなくなります。シンプルなリバースシェルの例では、シェルが強制終了されるまでBeaconは再びチェックインしなくなります。Asyncインターフェースに切り替えることでこの問題は回避されますが、いくつかのタイミング問題が発生します。特定の呼び出しの間に遅延を入れるために、実際に機能するハードコードされた3秒のスリープがありますが、もちろんこれは適切な実装方法ではありません。
5. COMインターフェースの定義は、GitHubからwinget-cliの.msixbundleをダウンロードし、それを展開し、.msixを展開し、.winmdファイルを見つけることで取得しました。次にwinmdidl.exeを使用してIDLファイルを抽出しました。その後midlrt.exeを使用してIDLをヘッダー/.cファイルに変換し、それをClaudeで解析して必要な定義のみを含むようにしました。依然としてコードは混乱した状態です。このMicrosoftリンクがこのプロセスをより理解するのに役立つでしょう。
6. コードは概して混乱しています。なぜなら、これはPOC段階を超えていないからです。
7. winget configure --enable コマンドは、BOFが成功する前にターゲットマシンで少なくとも1回実行されている必要があります。この理由を追跡したところ、ConfigurationremotingServer.exeを含むDotNetディレクトリは、コマンドが実行され/バイナリがダウンロードされるまで存在しないためであることがわかりました。これらのファイルは C:\Program files\WindowsApps... に存在するため、低権限ユーザーが書き込むことができないため、BOFでこれらのファイルを自分でディスクにドロップして動作させることもできません。
8. 調査しましたが、私の知る限り、これらはDCOMインターフェースではなく、単なるCOMです。したがって、これは他のマシンへの横移動のための実行可能なプリミティブではありません。
9. #7のため、これは私の意見では優れた/信頼性の高い初期アクセス方法にはなりません。WinGetが無効化されているマシン（元のブログ記事参照）に侵入した場合、またはconfigure --enableコマンドが実行されていない場合、完全に停止します。ポストエクスプロイテーション目的では価値があるかもしれませんが、コードを生成/実行する固定プロセスであり、pwshであるためAMSIが影響するという制約があります。

コンパイル

このツールは、通常のBOF API宣言（例：bofdefs.h ファイル）を使用せずに記述されています。Matt Ehrnschwender 氏によるこの ブログ記事 で概説されているように、objcopy を使用して DLL$API 形式の適切なシンボルをコンパイル後にBOFにパッチすることが可能です。

私はこのプロセスを自動化するBOFPatcherというツールを作成しました。これにより、ユーザーは煩わしいAPI宣言を気にせずに、通常のC言語としてBOFを記述できます。

このツールは、私の BOF Development and Tradecraft コースを購入した方にご利用いただけます。

BOFPatcherツールはこのリポジトリに含まれていませんが、このツールのMakefileはobjcopyを呼び出し、適切なシンボル置換を含む imports_dscourier64.txt ファイルを渡すことで、BOFを使用可能にしています。

謝辞

1. Dylan氏とMatt氏の素晴らしい成果に感謝します。さらなる活躍を期待しています！
2. このコードのほとんどを生成してくれたClaudeに感謝します。