InlineExecute-Assembly

InlineExecute-Assemblyは、Cobalt Strikeの従来のfork and run方式のexecute-assemblyモジュールの代替として、セキュリティ専門家がプロセス内で.NETアセンブリを実行できるようにする概念実証のBeacon Object File（BOF）です。InlineExecute-Assemblyは、エントリポイントが Main(string[] args) または Main() の任意のアセンブリを実行します。これにより、ほとんどの公開ツールを事前の修正なしに実行できるはずです。

BOFは、実行前にアセンブリに必要な共通言語ランタイム（CLR）（v2.0.50727またはv4.0.30319）を自動的に判断し、ほとんどの場合、問題が発生しても正常に終了します。また、BOFは、.NET実行前にオペレーターがいくつかの動作を指定できるフラグをサポートしています。メモリパッチによるAMSIの無効化、メモリパッチによるETWの無効化と復元、作成するCLR App Domain名のカスタマイズ、アセンブリのコンソール出力を名前付きパイプまたはメールスロットに作成してリダイレクトするかどうか、そしてデフォルトのエントリポイントMain(string[] args)をMain()に切り替えることができます。使用法、ユースケース、および可能な検出方法の詳細は、以下およびhttps://securityintelligence.com/posts/net-execution-inlineexecute-assembly/ にあります。

最後に、.NETアセンブリをビーコンインプラントと同じプロセス内で実行する利点は、Cobalt Strikeのexecute-assemblyモジュールのデフォルト動作（新しいプロセスを作成してCLR/.NETアセンブリをロード/インジェクトする）を回避できることです。ただし、他のOPSEC上の考慮事項も存在します。例えば、実行中のプロセスが通常CLRをロードするかどうか、実行する.NETアセンブリに既知のシグネチャがあるかどうかなどです。そのため、欠点は、例えばAMSIによって何かが検出されて強制終了された場合、ビーコンも強制終了されることです。

参考資料

このツールは、セキュリティコミュニティのメンバーがすでに公開している優れた研究、ツール、コードを利用できなければ存在しませんでした。ありがとうございます。最後に、以下のリストに漏れていると思われる方がいれば、お知らせください。必ず追加します。

• HostingCLR - ここ - CLR/アセンブリ実行ロジック
• Dotnet-Loader-Shellcode - （@modexpblog 著） - ここ - COMインターフェースを含む、Cで.NETを実行するための総合的な優れた研究 -> 真のMVP
• Donut - （@TheRealWover および @modexpblog 著） - ここ - COMインターフェースヘッダ
• Memory Patching AMSI Bypass - （@_RastaMouse 著） - ここ - AMSIメモリパッチの研究
• Metasploit-Execute-Assembly - （@b4rtik 著） - ここ - 修正されたAMSIパッチと.NETバージョン検出関数の使用
• ExecuteAssembly - （@med0x2e 著） - ここ - 修正されたアグレッサースクリプト
• Hiding Your .NET ETW - （@xpn 著） - ここ - 優れたETW研究
• ETW BOF - （@ajpc500 著） - ここ - 修正されたETWパッチ
• ExecuteAssembly_Mailslot - （@N4k3dTurtl3 著） - ここ - コンソールリダイレクトにメールスロットを使用する修正
• @freefirex2 - BOFの内部動作と落とし穴について親切に共有してくれました。

はじめに

1. inlineExecute-Assemblyフォルダとそのすべての内容を、Cobalt Strike GUIアプリケーションを介して接続する予定のシステムにコピーします。
2. inlineExecute-Assembly.cnaアグレッサースクリプトをロードします。
3. 最も基本的な実行には、inlineExecute-Assembly --dotnetassembly /path/to/assembly.exe を実行します（具体的なフラグ例については以下のユースケースを参照）。

自分でビルドする

srcディレクトリ内で、VS 2019用のx64 Native Toolsコマンドプロンプトを使用して以下のコマンドを実行します。

cl.exe /c inlineExecute-Assembly.c /GS- /FoinlineExecute-Assemblyx64.o

srcディレクトリ内で、VS 2019用のx86 Native Toolsコマンドプロンプトを使用して以下のコマンドを実行します。

cl.exe /c inlineExecute-Assembly.c /GS- /FoinlineExecute-Assemblyx86.o

フラグ

--dotnetassembly        アセンブリへのディレクトリパス **必須**
--assemblyargs          渡すアセンブリ引数
--appdomain             送信されるAppDomainのデフォルト名を変更（デフォルト値はtotesLegitで、含まれているアグレッサースクリプトで設定） *ドメインは常にアンロードされます*
--amsi                  メモリパッチによるAMSIの無効化を試行（成功した場合、プロセスの全期間にわたってAMSIが無効になります）
--etw                   メモリパッチによるETWの無効化を試行（成功した場合、元に戻さない限りプロセスの全期間にわたってETWが無効になります）
--revertetw             メモリパッチによるETWの無効化を試行し、その後元の状態に再パッチします
--pipe                  名前付きパイプのデフォルト名を変更（デフォルト値はtotesLegitで、含まれているアグレッサースクリプトで設定）
--mailslot              コンソール出力をリダイレクトするためにメールスロットを使用するように切り替えます。メールスロットのデフォルト名を変更（空白の場合はデフォルト値はtotesLegitで、含まれているアグレッサースクリプトで設定）
--main                  エントリポイントをMain()に変更（デフォルト値はMain(string[] args)）

ユースケース

.NETアセンブリを実行

構文

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe

ユースケース

引数付きで.NETアセンブリを実行

構文

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --assemblyargs AntiVirus AppLocker

ユースケース

引数付きで.NETアセンブリを実行し、AMSIを無効化

構文

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --assemblyargs AntiVirus AppLocker --amsi

ユースケース

引数付きで.NETアセンブリを実行し、ETWを無効化

構文

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --assemblyargs AntiVirus AppLocker --etw

ユースケース

引数付きで.NETアセンブリを実行し、デフォルトの名前付きパイプの代わりにメールスロットで出力をリダイレクト

構文

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --mailslot

ユースケース

引数付きで.NETアセンブリを実行し、アグレッサースクリプトで設定されたデフォルトの名前付きパイプ名を変更

構文

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --pipe forRealLegit

ユースケース

.NETアセンブリを実行し、アグレッサースクリプトで設定されたデフォルトのアプリケーションドメインを変更

構文

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --appdomain forRealLegit

ユースケース

デフォルトのMain(string[] args)の代わりにMain()エントリポイントで.NETアセンブリを実行

構文

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/simpleMain.exe --main

ユースケース

全力で実行

構文

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --assemblyargs AntiVirus AppLocker --amsi --etw --appdomain forRealLegit --mailslot forRealLegit

注意事項

1. 可能な限り安定させるよう努めましたが、クラッシュせずビーコンが死なないという保証はありません。fork and runのように何か問題が発生してもビーコンが生き残るという追加の利点はありません。これがBOFのトレードオフです。とはいえ、ツールで適切に動作するかどうかを事前にアセンブリをテストすることの重要性はいくら強調してもしすぎることはありません。
2. BOFはプロセス内で実行され、実行中はビーコンを引き継ぐため、長時間実行されるアセンブリに使用する前にこれを考慮する必要があります。結果が返ってくるまでに長い時間がかかるものを実行する場合、結果が返ってきてアセンブリの実行が完了するまで、ビーコンはさらにコマンドを実行するためにアクティブになりません。また、これはsleep設定に従いません。例えば、sleepが10分に設定されていてBOFを実行した場合、BOFの実行が完了するとすぐに結果が返ってきます。
3. PEをメモリにロードするツール（例：SafetyKatz）に修正を加えない限り、これらはほとんどの場合ビーコンを強制終了します。これらのツールの多くは、終了前に犠牲プロセスからコンソール出力を送信できるため、execute assemblyで正常に動作します。プロセス内BOF経由で終了すると、プロセスが強制終了され、ビーコンも強制終了されます。これらは動作するように修正可能ですが、OPSECに優しくない他のものがプロセスにロードされ、削除されない可能性があるため、この種のアセンブリはexecute assembly経由で実行することをお勧めします。
4. アセンブリがEnvironment.Exitを使用している場合、プロセスとビーコンを強制終了するため、削除する必要があります。
5. 名前付きパイプとメールスロットは一意である必要があります。データが返ってこず、ビーコンがまだ生きている場合、問題はおそらく別の名前付きパイプまたはメールスロット名を選択する必要があることです。

検出

使用できる検出および軽減戦略：

1. AMSIおよびETWのメモリパッチを実行する際にPAGE_EXECUTE_READWRITEを使用します。これは意図的に行われており、PAGE_EXECUTE_READWRITEのメモリ保護を持つメモリ範囲を持つプログラムはほとんどないため、危険信号となるはずです。
2. 作成される名前付きパイプのデフォルト名はtotesLegitです。これは意図的に行われており、シグネチャ検出を使用してこれをフラグ付けできます。
3. 作成されるメールスロットのデフォルト名はtotesLegitです。これは意図的に行われており、シグネチャ検出を使用してこれをフラグ付けできます。
4. ロードされるAppDomainのデフォルト名はtotesLegitです。これは意図的に行われており、シグネチャ検出を使用してこれをフラグ付けできます。
5. .NETの悪意ある使用を検出するための優れたヒント（@bohops著）ここ、（F-Secure著）ここ、およびここ
6. .NET CLRが疑わしいプロセス（CLRがロードされるべきではないアンマネージドプロセスなど）にロードされていないか確認する。
7. イベントトレース ここ
8. 他の既知のCobalt Strike BeaconのIOCやC2の出力/通信のIOCを探す。