説明:

ExecuteAssemblyはCSのexecute-assemblyの代替であり、C/C++で構築されています。ホスト（spawnto）プロセスに読み込まれたCLRモジュール/AppDomainManagerの再利用、ローダー/.NETアセンブリのPE DOSヘッダーの隠蔽、.NET関連モジュールのリンク解除、ETW+AMSIのバイパス、NT静的システムコール（x64）によるEDRフックの回避、superfasthashハッシュアルゴリズムを使用したAPIの動的解決によるインポートの隠蔽により、.NETアセンブリを読み込み/インジェクションするために使用できます。

TLDR（機能）:

PEBデータ構造からのCLR関連モジュールのリンク解除。（確認にはPHではなくMSの"ListDLLs"ユーティリティを使用）
.NETアセンブリおよびリフレクティブDLLのヘッダー隠蔽（MZバイト、e_lfanew、DOSヘッダー、リッチテキスト、PEヘッダー）
EDRフックをバイパスするための静的ハードコードされたシステムコールの使用（現時点ではx64のみ対応、WinXPからWin10 19042まで）
CLR "AppDomain/AppDomainManager"の列挙と再利用（ICLRMetaHost->EnumerateLoadedRuntimes）。spawnto/ホストプロセスを既知のWindows .NETプロセスに設定するだけ。
APIに対応するハッシュ（SuperFastHash）を使用したWIN32 APIの動的解決（PEB）
.NETアセンブリ読み込み前のAMSIおよびETWのパッチ適用
読み込み/使用するCLRバージョンを特定するための.NETアセンブリバイトの解析とスキャン
ETWバイパスにGetProcAddress/LoadLibrary/GetModuleHandleを使用しない
v4 COM APIとリフレクティブDLLインジェクションを使用したCLRホスティング

使い方:

x64（syscalls）: このバージョンは主に静的システムコールを使用してEDRフックをバイパスします。このバージョンを使用してDLLのx64版のみをビルドできます（現時点ではx64のみ対応）。
x86|x64（PEB）: PEBモジュールのEAPテーブルを走査し、superfasthashハッシュを介してAPIを解決することで、実行時に必要なAPIアドレスを動的に取得します。ただし、kernel32.dllまたはntdll.dllに配置されたEDRフックは考慮しません。このバージョンを使用してx86とx64の両方のDLLをビルドするか、x86 DLLのみをビルドし、x64（syscalls）バージョンを使用してx64 DLLをビルドすることで、一般的なEDRフックに対応できます。
必要なDLLをVS2017および/またはWindows SDK 10.0.17134.0（または互換性のあるSDKバージョン）を使用してビルドします。
gzipがインストールされ、以下のアーティファクトが同じフォルダに配置されていることを確認し、アグレッサースクリプト「ExecuteAssembly.cna」を読み込むだけです。
- ExecuteAssembly.cna
- ExecuteAssembly-x64.dll
- ExecuteAssembly-x86.dll
- CLI オプション:
  
  --dotnetassembly: 読み込み/インジェクションする.NETアセンブリ。
  
  --assemblyargs: .NETアセンブリの引数。
  
  --unlink-modules: CLR/MsCoree関連DLLなどの.NET関連モジュールをPEBデータ構造からリンク解除します。
  
  --stomp-headers: .NETアセンブリとリフレクティブDLLのPE DOSヘッダーを隠蔽します。
  
  --etw: Windowsのイベントトレーシング（ETW）をバイパスします。
  
  --amsi: AMSIをバイパスします。
  
  --spawnto: spawntoプロセスを選択します。デフォルトで実行時にCLRを読み込む.NETバイナリのリスト：
        - PresentationHost.exe
        - stordiag.exe
        - ScriptRunner.exe
        - caitstatic.exe
        - Microsoft.Uev.SyncController.exe
        - TsWpfWrp.exe
        - UevAgentPolicyGenerator.exe
        - UevAppMonitor.exe
        - FileHistory.exe
        - UevTemplateBaselineGenerator.exe
        - UevTemplateConfigItemGenerator.exe
spawnto-list.txtをチェックして、デフォルトでCLRを読み込む他のMSバイナリを確認し、spawntoとして設定する良い候補にしてください。（既知のLOLBinsは避けるべきですが、開発者のマシンでは問題ない場合があります）

例:

ExecuteAssembly --dotnetassembly /tmp/Seatbelt.exe --assemblyargs LogonSessions --unlink-modules --stomp-headers --amsi --etw --spawnto PresentationHost.exe
ExecuteAssembly --amsi --etw --unlink-modules --stomp-headers --dotnetassembly /tmp/ghostpack/SharPersist.exe --assemblyargs -t reg -c "C:\Windows\SysWow64\mshta.exe C:\Users\admin\Downloads\Test2.hta" -k logonscript -m add --spawnto FileHistory.exe
ExecuteAssembly --unlink-modules --stomp-headers --dotnetassembly /tmp/ghostpack/SharPersist.exe --assemblyargs -t reg -k "logonscript" -v "C:\Windows\SysWow64\mshta.exe C:\Users\admin\Downloads\Test.hta" -m remove --spawnto FileHistory.exe
ExecuteAssembly --unlink-modules --amsi --dotnetassembly /tmp/ghostpack/SharpWMI.exe --assemblyargs action=query computername=localhost query="select * from win32_service" --spawnto FileHistory.exe
ExecuteAssembly --amsi --etw --dotnetassembly /tmp/ghostpack/SharpWMI.exe --assemblyargs action=query query="select * from win32_process" --spawnto PresentationHost.exe

C2 サポート:

主にCobalt Strikeで作成およびテストされましたが、他のC2フレームワーク（MSFなど）でも使用できます。リフレクティブDLLのDLLMAINは、ペイロードを次の形式（「.」なし）でパラメータ（lpReserved）として期待していることに注意してください。

AMSI_FLAG|ETW_FLAG|STOMPHEADERS_FLAG|UNLINKMODULES_FLAG|LL_FLAG.LENGTH_FLAG.B64_ENCODED_COMPRESSED_PAYLOAD [スペース区切りの引数]
- AMSI_FLAG: 0|1（0または1のいずれか）
- ETW_FLAG: 0|1
- STOMPHEADERS_FLAG: 0|1
- UNLINKMODULES_FLAG: 0|1
- LENGTH_FLAG: .NETアセンブリのサイズ（バイト単位）
- LL_FLAG: length_of(LENGTH_FLAG)（ここは気にしないでください。見なかったことにしても構いません）
- B64_ENCODED_COMPRESSED_PAYLOAD: Gzip圧縮されBase64エンコードされた.NETアセンブリ。
- [スペース区切りの引数]: .NETアセンブリの引数

テストノート:

Cobalt Strike 4.xで、マリアブルプロファイルなしでテスト済み。
Cobalt Strike 4.xで、以下のマリアブルプロファイルを使用してテスト済み（userwx、startrwxなどの複数のメモリ回避オプション設定）;
- https://github.com/threatexpress/malleable-c2/blob/master/jquery-c2.4.0.profile

TODO:

RFLLの代替、BOF + 名前付きパイプの可能性（長時間実行タスクについては未確定）
x86の静的システムコール対応。
バグ修正と、見落としていたダングリングポインタやメモリリークのクリーンアップ :p

既知の問題:

SharpHound v2およびv3のサポート（v2は問題なく動作していましたが、何が変わったか確認が必要です）。
.NETアセンブリのサイズ制限（1MB未満）

人気

ExecuteAssembly

説明: