Nemesis

マルウェアサンプルの中にjlaiveのフォークが転がっているのを眺めるのに飽きて、ランタイムで実際に分解してくれる公開ツールが何もなかったから作ったWindowsツールです。

要するに、ネイティブ層でCLRをフックし、リフレクティブなアセンブリロードを追跡し、メモリから直接PEを自動ダンプする.NETプロセスモニターです。また、ディスク上のオリジナルバイナリと比較してAMSIとETWの整合性をチェックし、clr.dllの文字列パッチや直接的なLoadFromBufferの使用といったバイパス手法を検出します。

サンプルはどこで見つける？ https://tria.ge をチェックするのをおすすめします（宣伝ではありません）。好きなサンプルをダウンロードして、ファミリーでフィルタリングできます。

なぜこの名前？

なぜnemesisという名前なのか、疑問に思うかもしれません。

それはこのツールの目的そのものを表しているからです。nemesisとは、相手にとって絶え間ない挑戦や破滅の原因となるものを意味し、それがこのプロジェクトの背後にある考えです。

ギリシャ神話では、nemesisは神聖な報復の精霊であり、傲慢になりすぎたり、自分は手が届かないと思い込んだ者に報いを与える存在でした。マルウェアが「FUD」だと自慢するのには、ちょっと露骨すぎる名前かもしれませんがね。

なぜ存在するのか

私はマルウェアアナリストです。この仕事（私にとっては趣味）を十分長く続けると、同じローダーチェーンを何度も何度も見るようになります。特にjlaive（crybatとも呼ばれる）が流行ってからは、スクリプトキディがこぞってフォークしています。

パターンは馬鹿みたいに単純ですが、対処するのは地獄のように面倒です：

something.bat  →  obfuscated powershell  →  csharp stub  →  your actual payload

ワードサラダのように見える.batをダブルクリックします。cmdがジャンクの壁とともにpowershellを起動します。powershellが.NETスタブを復号・展開します（aes、gzip、base64）。そのスタブがAMSI + ETWにパッチを当て、実際のexe/dllをメモリ内にリフレクティブにロードし、終わりです。有用な形でディスクに何かが触れることはありません。

それが気になっていました。この特定のチェーンと戦うための良い公開ツールは実際には存在しません。.NETペイロードが実際に実体化する場所をフックし、プロセスが自滅する前にダンプし、これらのスタブが必ず行うAMSI/ETWパッチを捕まえるものです。だからnemesisを作りました。

万能薬ではありません。あなたのサンドボックスを置き換えるものでもありません。しかし、テストボックス上で疑わしい.batに対して実行し、実際にアーティファクトを引き出せる、本物の何かを提供します。

実際に何をするのか

launcher (Launcher.exe)

• ターゲットをサスペンド状態で作成します（exe、bat、cmd、何でも）
• メインスレッドが実行される前にNemesis.dllをインジェクトします
• nemesisが準備完了を報告するのを待ちます
• 再開します。ターゲットがpowershellの子プロセスを生成する場合、launcherはそれらにもインジェクトできます

nemesis dll (Nemesis.dll)

• jlaiveスタイルのスタブが実際に到達するCLRロードパスをフックします：
  • nLoadImage
  • nLoadFile
  • AssemblyNative::LoadFromBuffer（パターンはnLoadImageから解決）
• リフレクティブPEがメモリ内に現れると → %TEMP%\Nemesis_dumpsへのダンプをキューに入れます
• ライブのamsi.dll / ntdll.dllエクスポートをディスク上のコピーと比較します（AmsiScanBuffer / EtwEventWriteに対する古典的なretパッチを検出）
• AMSIチェックは、CLRがロードされているときにCLRの.rdata文字列も調べます（一部のバイパスはそちらにパッチを当てます。これに関する優れたvxugの論文があります：2024-11-21 - New AMSI Bypss Technique Modifying CLRDLL in Memory.pdf）
• コンソール（色付き）+ %TEMP%\Nemesis.logにログを記録します。コンソールが、まあ変な感じになる問題を避けるためにENABLE_VIRTUAL_TERMINAL_PROCESSINGも持っています :D

基本的に：batチェーンを実行させ、クリプターが実際にペイロードをロードする場所で捕まえ、途中で回避テクニックをログに記録します。

証拠：

ビルド

Visual Studio 2022+ と C++デスクトップ + MASM (x64) が必要です。

Nemesis.slnxを開き、Release | x64を選択して、ソリューションをビルドします。

実際のターゲットで実行

これが実際のユースケースです。疑わしいbatを指定して、何が出てくるか見てみましょう：

cd x64\Release
.\Launcher.exe "C:\path\to\suspicious.bat"

--以降の追加引数はターゲットに渡されます：

.\Launcher.exe myapp.exe -- --some-flag

カスタムDLLパス：

.\Launcher.exe --dll C:\path\Nemesis.dll myapp.exe

アーティファクト：

• ログ → %TEMP%\Nemesis.log
• ダンプされたPE → %TEMP%\Nemesis_dumps

nemesisができること / できないこと

できること：

• jlaiveスタイルのクリプター（bat → ps1 → csharpチェーン）向けのランタイム分析ヘルパー
• サンプルがあり、メモリ内ダンプ + AMSI/ETWテレメトリが欲しいときにラボVMで役立つ
• 他のアナリストが使用、拡張、文句を言うためにオープン

できないこと：

• EDRの代替
• すべてのフォークバリアントを捕まえる保証（難読化の変更、新しいバイパス、例えばパッチレスAMSI/ETW。現時点ではそれ用に作られていないため。将来的に変更する予定です もしかしたらこれはマネージド言語ツールキットになるかもしれません）

注意事項

• CLR asm detoursは現在x64のみ
• cmd.exeホストは多くの場合CLRを持たないため、nemesisはとにかくシグナルを出さず、launcherがハングすることはありません。実際の作業はpowershell/dotnetが現れたときに起こります
• リビルドがLNK1104で失敗する？ まだ何かがnemesis.dllをロードしています。ターゲットをkillしてリビルドしてください
• ビルド中のpwsh.exe vcpkgのノイズは無害です。無視してください

参考文献（jlaiveエコシステム）

何と戦っているのかを理解したいなら：

• Trend Micro on BatCloak / Jlaive — bat → ps1 → csharpのレイヤーケーキ
• Fortinet on ScrubCrypt — jlaiveの厄介な後継者。scrubcryptのちょっとした違いに興味があれば、それは.bat内でパイプ記号を使ってコマンドをパイプしていたことです。かなりうまく機能します...
• Unprotect.it — ScrubCrypt — テクニックの内訳
• https://github.com/backdoorskid/ClrAmsiScanPatcher - 前述の.NET文字列を見つけます。先ほども言ったように、あの.pdfファイルを読むことをおすすめします :)

免責事項

nemesisを使用することで、これに同意したものとみなされます。 これは現状のまま提供され、いかなる保証もありません — すべてのリスクはあなたが負います。

合法的かつ許可された使用（ラボVM、所有システム、明示的な許可）については、あなたが単独で責任を負います。法律で許容される最大限の範囲で、作者およびzypherion.techは、使用または誤用から生じるいかなる損害、損失、法的請求についても一切の責任を負いません。完全な条件についてはLICENSEを参照してください。

ライセンス

非商用 / 個人 / 研究 / 趣味での使用 → PolyForm Noncommercial 1.0.0

商用利用（販売、有償製品、SaaS、クライアントワークなど）→ 別途ライセンスが必要です。PolyForm Noncommercialはそれをカバーしていません。

商用ライセンスが必要な場合は連絡してください：

[[email protected] / @wd6g(discord) / telegram: @ZypherionTechnologies]

todo

ちょっとしたメモ。compilemethodを調べて修正する必要があります。現時点では、クリプターは通常それを使わないので、それほど必要ではありません... なぜなら彼らはasm.load(...)を使わなければならないからです また、rdata文字列をチェックする必要があることを思い出させます。残念ながらまだちゃんとテストしていません... 馬鹿げたコードでPRを送らないでください。n(Native)バックエンド、例えばnLoadImageを普通にフックすることはできません。レジスタを保存しなければならず、面倒です。だからasmを使っています。