octoberfest7/dropspawn_bofDLL Application Directory Hijackingを使用してBeaconsを生成するCobaltStrike BOF
DropSpawn は、比較的知られていない DLL ハイジャック手法を介して追加のビーコンを生成するために使用される CobaltStrike BOF です。x86-x86、x64-x64、x86-x64（またはその逆）で動作します。プロセスインジェクションの代替として使用します。
Windows 実行可能ファイルは DLL 検索順序に従います（絶対パスが指定されていない DLL を読み込もうとするとき）：
DLL ハイジャックは通常、次のいずれかの条件を必要とします：
A. ユーザーが、実際の DLL が存在するフォルダよりも高い検索順序を持つフォルダに書き込み権限を持っていること
または
B. 問題の DLL がシステム上にどこにも存在せず、その場合、ユーザーの %PATH% 変数内のユーザー書き込み可能なフォルダ（%USERPROFILE%\appdata\local\microsoft\windowsapps など）に配置できること
これらの要件により、C:\Windows\System32 に存在する実行可能ファイルに対する DLL ハイジャックは不可能になります。なぜなら、これらの実行可能ファイルが読み込む DLL のほとんども System32 に存在するからです。System32 の実行可能ファイルをユーザー書き込み可能な場所にコピーしてそこで実行することは可能ですが、これは OPSEC 上安全ではありません。System32 のバイナリが別の場所から実行されていることは容易に識別できるためです。
DropSpawn は、System32 の実行可能ファイル（およびその他のユーザー書き込み不可フォルダにあるもの）を使用した DLL ハイジャックを、「アプリケーションが読み込まれるディレクトリ」を任意のユーザー指定のものに偽装することで可能にします。
公開版の DropSpawn は非公開版と若干異なります。非公開版は独自のペイロードジェネレーターを利用しており、オペレーターにとってよりシームレスな体験を提供します。公開版は、ユーザーがそれぞれ独自の方法で DLL ハイジャック互換ペイロードを生成することを想定して、若干変更されています。Python3 スクリプトとデモ DLL のソースコードが含まれており、ユーザーが DropSpawn を統合して武器化する際の支援を目的としています。
絶対パスを指定せずに DLL を読み込もうとするターゲット実行可能ファイルを特定します。これを行うには、exe をユーザー書き込み可能なディレクトリにコピーし、Procmon で監視しながら実行します。この例では、通常 C:\Windows\System32\WerFault.exe にある WerFault.exe を使用します。
上の例では、cryptsp.dll、wer.dll、dbghelp.dll、bcrypt.dll はすべて実行可能な候補です。これらは WerFault 内で絶対パスが指定されていないため、WerFault はまずアプリケーションディレクトリからそれらを読み込もうとし、その後 DLL 検索順序の残りにフォールバックします。通常は WerFault のアプリケーションディレクトリが System32 であるため、これは問題になりません。
ターゲットシステムからハイジャック可能な DLL の 1 つをダウンロードします。
これは、そのエクスポートを抽出し、ペイロード DLL に含めるために必要です。DropSpawn を使用する予定の同じマシンからハイジャック可能な DLL を取得することが重要です。なぜなら、DLL は Windows のバージョンによって異なるからです。また、x86 ビーコンを実行していて DropSpawn を使用して x64 ビーコンを生成したい場合は、'C:\windows\system32...' ではなく 'C:\windows\sysnative...' を指定して、実際の DLL の x64 バージョンをダウンロードしてください。
generate_dll.py を実行し、ダウンロードした DLL と希望するペイロードアーキテクチャを渡します。generate_dll.py はこのスクリプトの修正版です。指定された DLL を解析し、DLL のエクスポートを含む .def ファイルを作成し、MingW を呼び出してデモペイロード DLL をコンパイルします。生成されたプロセスが偽装された DLL 内の実際の関数を呼び出そうとすると、ペイロード DLL は System32 にある実際の DLL に呼び出しを転送し、ホストプロセスがクラッシュしないようにします。
生成されたペイロード DLL を使用して dropspawn を呼び出します。
dropspawn <payload DLL> <x86|x64> <program to spawn> [writable target folder] [parent]
payload DLL - 生成された DLL ペイロードへの絶対パス。
architecture - 生成するプロセスのアーキテクチャ。
program to spawn - 生成するプロセスの名前またはパス。このプロセスが System32（または syswow64）にある場合は、名前のみを指定できます。それ以外の場合は、絶対パスを指定します。また、プロセスにコマンドライン引数を指定することもできます。パスにスペースが含まれる場合、または引数を使用する場合は、全体を引用符で囲んでください。
writable target folder - オプション。空白のままにすると、dropspawn はビーコンの現在のディレクトリを使用しようとします。パスにスペースがある場合は引用符を使用してください。
parent - オプション。新しく生成されたプロセスで PPID 偽装に使用するプロセスの名前。異なる特権レベルの複数の実行中のインスタンスを持つプロセス（例：svchost.exe）を指定した場合、dropspawn は PPID 偽装に使用できるものを特定しようとします。
例：dropspawn /root/gitlab/DropSpawn_BOF/dist/dbgcore.dll x64 "WerFault.exe -u -p 4352 -s 160" C:\users\user\appdata\local\temp explorer.exe
これにより、ペイロード DLL 'dbgcore.dll' がディスク上の 'c:\users\user\appdata\local\temp\dbgcore.dll' に配置され、コマンドライン引数 '-u -p 4352 -s 160' を持つ x64 WerFault.exe プロセスが、親プロセスとして explorer.exe を使用して生成されます。
クリーンアップは簡単です。ディスクに配置されるペイロード DLL に自己削除関数を含めることで、新しいプロセスが生成されて DLL を読み込むとすぐに削除されます。これは大きな変化です。通常、DLL を読み込んだプロセスが実行中である限り、DLL はディスク上でロックされたままになるためです。自己削除技術が何らかの理由で失敗した場合（またはプロセスの生成に失敗した場合）、DropSpawn はディスクからペイロード DLL を削除しようとし、いずれの場合も操作の結果をユーザーに通知します。
プロセスインジェクションは通常、リモートプロセスのオープン -> リモートメモリの割り当て -> リモートメモリへの書き込み -> リモートメモリの実行というチェーンに従い、最初に既存のプロセスを使用する代わりに新しいプロセスを生成するオプションがあります。DropSpawn は新しいプロセスを作成するだけです。新しく生成されたプロセスがシェルコードの割り当て、書き込み、実行を担当するため、リモートプロセスインジェクションに一般的に関連する IOC の多くを回避できます。
この手法はもちろん、DLL ペイロードの品質に依存します。しかし、Windows がどのように見ているかを確認してみましょう（次のセクションでは、プライベートバージョンの DropSpawn を使用し、ビーコンを生成しています）。
イベントビューアーに関しては、すべてが正常に見えます：
MDE では、ほとんど確認できるものはありません。
dropspawn の実行：
MDE ログ：
PPID 偽装あり：
PPID 偽装なし：
どちらの場合でも、元のビーコンプロセス（これも werfault）が dbgcore.dll をディスクに配置し、新しい WerFault.exe プロセスを作成し、新しく生成されたプロセスが dbgcore.dll を読み込み、その後名前を変更（削除）しているのがわかります。重要なのは、DLL ハイジャックに伴うことの多い dbgcore.dll に対する追加の精査がないことです。これは、頻繁にハイジャックされる場所に書き込んでいるわけではなく、WerFault.exe（または選択したプロセス）が WmiPrvSE.exe などと同様に DLL ハイジャックと関連付けられていないためです。
興味深いことに、PPID 偽装を使用してこれを行う方が、使用しない場合よりもほぼ可視性が高くなります。ただし、これはセキュリティ製品によって異なる場合があります。
前述のとおり、ユーザーは DropSpawn を使用する予定のターゲットマシンから実際の DLL をダウンロードすることが不可欠です。間違ったバージョンの DLL を使用すると、存在しない関数を呼び出そうとした場合に生成されたプロセスがクラッシュする可能性があります。
DropSpawn は System32 以外の実行可能ファイルでも使用できます。ただし、プロセスが本来のアプリケーションディレクトリから追加の DLL を読み込もうとすると問題が発生する可能性があることに注意してください。アプリケーションディレクトリを別の場所に偽装しているため、本来のアプリケーションディレクトリが DLL 検索順序で到達可能でない場合、プロセスは重要な DLL を見つけられずクラッシュするか、起動に失敗します。本番環境で使用する前に、必ず開発マシンで潜在的なハイジャックをテストしてください！
この研究は、プロセスが最終的な DLL 検索順序をどのように組み立てるか（実行可能ファイルが異なるディレクトリに存在するため、実行時に決定する必要があり、カレントディレクトリが検索パスの一部であるなど）を調査している中で生まれました。私の調査により、このフォーラム投稿にたどり着きました。これが、この手法の中心となる 2 つの重要な未公開 API の起源です。
これらは既にリンクされていますが、ローダーロックを回避するためのこの投稿、DLL プロキシ用の .def ファイルを生成するためのこのスクリプト、および実行中の実行可能ファイルの自己削除を可能にするこの研究は、DropSpawn に適した効果的な武器化された DLL ペイロードを生成するために不可欠です。
私が初めてこの手法を Twitter で公開したとき、数人の他の人々が会話に参加し、POC を公開しました。SecurityAndStuff はこちらを公開しました、一方 Snovvcrash はこちらに彼のものを公開しています。
