SigFlip

これは何ですか？

SigFlip は、オーセンティコード署名付き PE ファイル (exe、dll、sys など) を、既存のオーセンティコード署名に影響を与えたり壊したりしない方法でパッチ適用するためのツールです。言い換えれば、ファイルの署名、整合性チェック、または PE ファイルの機能を壊すことなく、データ (シェルコードなど) を埋め込むことで PE ファイルのチェックサムやハッシュを変更できます。

SigInject は、シェルコードを暗号化して PE ファイルの [WIN_CERTIFICATE] 証明書テーブルに注入します。暗号化キーは、基本的な BOF/C/C# ローダー (SigLoader) で使用するために出力されます。SigInject は変更を修正された PE ファイルに保存し、その署名と証明書の有効性をそのまま保持します。

SigLoader は、SigInject によって作成された修正された PE ファイルのパスと復号化キーをパラメータとして受け取り、埋め込まれたシェルコードを抽出して復号化し、任意のシェルコードインジェクションで使用するための基本的なローダーです。

SigFlip は、PE ハッシュが正常に変更されたかどうかを確認し、エンドポイントがこのような一般的な誤構成に対して強化されている場合には正常に終了してチェックします (「詳細」セクションを参照)。

注意: SigFlip、SigInject、SigLoader は BOF スクリプトと .NET アセンブリの両方で利用可能です。唯一の違いは、BOF ではなく .NET アーティファクトを使用する場合、SigInject 機能が SigFlip (-i) の一部として実装されていることです。

なぜ？

これは主に、永続化、ラテラルムーブメント、またはコードやコマンドの実行に使用でき、以下の点で役立ちます:

• アプリケーションホワイトリスティングバイパス: 署名を壊さずに PE ファイルのハッシュを変更する (例: msbuild.exe)。
• 特定の LOLBIN のハッシュに依存する悪意のあるコードやコマンド実行検出を使用する EDR のバイパス。
• 異なるハッシュを使用した署名付きドライバーのロード: 一般的な脆弱性のある署名付きドライバーを定義済みハッシュリストで監視している EDR を回避するのに役立つ可能性があります。
• 署名付き PE ファイルに暗号化されたシェルコードを埋め込み、好みのステージャー (sigloader) を使用して解析、復号化、ロード、実行する。
• エンドポイントセキュリティベンダーは多くの場合、署名付き PE ファイルを良性として分類する傾向があり、署名付き PE ファイルに未署名のコード (シェルコードなど) を埋め込むことで、検出やフラグ付けが少し難しくなります。
• 主にデフォルトの WinVerifyTrust に依存して署名検証を行うエンドポイントセキュリティベンダーのバイパス。
• OPSEC の向上と、signtool、sigcheck、Get-AuthenticodeSignature などの一般的な署名検証ユーティリティのみに依存して PE ファイルのオーセンティコード署名を検証する防御側への挑戦。

使用法と例:

コンパイルとビルド:

このプロジェクトではプリコンパイルされた BOF は提供されていません。Mingw-w64 を使用してコンパイルできます。.NET の場合は VS または csc.exe を使用して .NET プロジェクト (SigFlip、SigLoader) をコンパイルします。BOF の場合は以下の手順を確認してください。

• ➜ i686-w64-mingw32-gcc -c sigflip.c -o sigflip.x86.o
• ➜ x86_64-w64-mingw32-gcc -c sigflip.c -o sigflip.x64.o
• ➜ x86_64-w64-mingw32-gcc -c SigLoader/sigloader.c -o sigloader.x64.o
• ➜ i686-w64-mingw32-gcc -c SigLoader/sigloader.c -o sigloader.x86.o

すべてのオブジェクトファイルが sigflip.cna と同じディレクトリに配置されていることを確認し、sigflip.cna スクリプトを Cobalt Strike にロードします。

注意: プリコンパイルされた BOF は mingw-64 v8.0.0_3 でテストされ互換性があります。mingw-64 >= v9 を使用すると動作する可能性がありますが、アクティブなビーコンがクラッシュする可能性があります。詳細については https://github.com/med0x2e/SigFlip/issues/2 を確認してください。

Cobalt Strike:

1. Execute-Assembly

   • execute-assembly SigFlip.exe -h
   • execute-assembly SigLoader -h

2. BOF

   • Cobalt Strike で使用する場合、SigFlip.cna スクリプトをロードすると、SigFlip と SigInject の 2 つの新しいコマンドが登録されます。以下のように使用します。
     • SigFlip: 署名や証明書の有効性を壊さずに PE ファイル (DLL、EXE、SYS、OCX など) のハッシュを変更します:
       • SigFlip "<PE\_FILE\_PATH>" "<OUTPUT\_PE\_FILE\_PATH (拡張子付き)>"
     • SigInject: シェルコードを暗号化して PE ファイルの [WIN_CERTIFICATE] 証明書テーブルに注入します。暗号化キーは基本的な C/C# ローダーで使用するために出力され、署名と証明書の有効性をそのまま保持します:
       • SigInject "<PE\_FILE\_PATH> <OUTPUT\_PE\_FILE\_PATH (拡張子付き)>" "<SHELLCODE\_FILE>"
     • SigLoader: SigInject によって作成された PE ファイルから暗号化されたシェルコードをロードし、Early Bird queueuserapc を使用して犠牲プロセスにシェルコードを生成/注入します。シェルコードインジェクションロジックはカスタマイズするか、任意の他のコードインジェクション手法に置き換えることができます:
       • SigLoader <PE_FILE_PATH_WITH_SH> <DECRYPTION_KEY> <SPAWNTO_PROCESS_PATH> <PARENT_PROCESS_ID>

3. 例

   • BOF:

     • msbuild.exe にランダムデータを注入 (別名 msbuild.exe のビット反転):
       • SigFlip "C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe" "C:\lolbins\modified-msbuild.exe"
     • kernel32.dll にシェルコードを注入 (引数の順序が異なり、復号化キーを必ずメモしてください):

---

詳細:

これは、APT#10 が複数のキャンペーンや侵入セットで使用した既知の手法です。

オーセンティコードデジタル署名とは？

Authenticode は、Authenticode で署名されたソフトウェアの発行元を特定する Microsoft のコード署名技術です。Authenticode はまた、署名および公開されてからソフトウェアが改ざんされていないことも検証します。

どのように機能するか？

Microsoft は主に、PE バイナリの整合性と発行元を検証するために Authenticode 署名形式に依存しています。Authenticode Portable Executable 形式の仕様によると、Authenticode 署名は Windows PE ファイルに「埋め込む」ことができ、その場所はオプショナルヘッダーデータディレクトリの証明書テーブルエントリで指定されます。Authenticode を使用して Windows PE ファイルに署名する場合、ファイルの Authenticode ハッシュ値を計算するアルゴリズムは特定の PE フィールドを除外します。署名をファイルに埋め込む場合、署名プロセスはファイルのハッシュ値に影響を与えることなく、これらのフィールドを変更できます。これらのフィールドは次のとおりです: チェックサム、証明書テーブル RVA、証明書テーブルサイズ、および属性証明書テーブル。属性証明書テーブルには、PE ファイルの ハッシュ値、ソフトウェア発行元の秘密鍵で作成された 署名、およびソフトウェア発行元の署名鍵を法人にバインドする X.509 v3 証明書 を含む PKCS #7 SignedData 構造が含まれています。

簡単に言うと、オーセンティコードハッシュ計算から除外されるフィールドにデータを変更または埋め込むことができ、オーセンティコード署名やファイル整合性チェックを壊す心配はありません。

このような除外フィールドの詳細:

• 証明書テーブル RVA とサイズ: 署名付き PE ファイルのオプショナルヘッダー構造には、セキュリティディレクトリ IMAGE_DIRECTORY_ENTRY_SECURITY エントリを含むデータディレクトリの配列が含まれており、これには RVA と Size の 2 つのフィールドがあります。
  • RVA: 属性証明書テーブルへのファイルオフセット (メモリオフセットではありません)。
  • Size: 属性証明書テーブルのサイズ。
• 属性証明書テーブル: 署名と証明書をカプセル化するデータ構造 WIN_CERTIFICATE で、以下のフィールドがあります:
  • dwLength: 証明書テーブルのサイズ。
  • wRevision: WIN_CERTIFICATE の「リビジョン」。
  • wCertificateType: カプセル化された証明書データの種類。
  • bCertificate: 実際の証明書データ。WIN_CERT_TYPE_PKCS_SIGNED_DATA の場合、これは前述の PKCS#7 SignedData 構造 (PE ハッシュ値、署名、x.509 証明書を含む) です。これがまさに SigFlip がランダムデータまたはシェルコードを埋め込む場所です。

これらを踏まえて、SigFlip は以下の処理を行います:

1. システム構成を確認
2. PE ファイルのロードと PE ファイル署名の検証、Sha1 ハッシュの計算
3. "e_lfanew" オフセットを取得 (PE FILE HEADER -> IMAGE_NT_HEADERS を指す)
4. IMAGE_NT_HEADERS から IMAGE_OPTIONAL_HEADER を取得
5. IMAGE_OPTIONAL_HEADER から IMAGE_DATA_DIRECTORY を取得
6. IMAGE_DIRECTORY_ENTRY_SECURITY フィールドを取得し、属性証明書テーブル (WIN_CERTIFICATE) の RVA と SIZE を取得
7. 証明書テーブルに任意の追加バイト (ランダム/シェルコード) をパディングして PE ファイル blob にパッチ適用
8. オプショナルヘッダー -> IMAGE_DIRECTORY_ENTRY_SECURITY データディレクトリの Size を更新
9. WIN_CERTIFICATE (証明書テーブル) の dwLength を更新
10. 新しい PE チェックサムを生成して更新 (OPT ヘッダーチェックサム)
11. 新しいサイズの最終的な PE を保存
12. 修正された PE ファイルの署名を検証

最初のステップは、システムがオーセンティコード署名付き PE ファイルへのパディングやシェルコード注入を許可するように誤構成されているかどうかを確認するために重要です。そのため、以下の健全性チェックが実行されます:

1. MS13-098 修正プログラム (KB2893294) がインストールされていないことを確認します。インストールされていてもレジストリキーが適切に設定されていない場合があり、パッチが無効になる可能性があることに注意してください。
2. レジストリキーを確認
   1. X86:
      • レジストリキー "HKLM:\Software\Microsoft\Cryptography\Wintrust\Config" が存在しないことを確認
        • -> 存在する場合は、"EnableCertPaddingCheck" レジストリ値が存在しないことを確認
   2. X64:
      • レジストリキー "HKLM:\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config" が存在しないことを確認
        • -> 存在する場合は、"EnableCertPaddingCheck" レジストリ値が存在しないことを確認

修正された PE が自身のアドレス空間や他のプロセスのアドレス空間にモジュールとしてロードされた場合、注入されたデータを読み取れないのはなぜですか？

Windows ローダーは証明書データをプロセスアドレス空間にロードしません。そのため、シェルコードなどのデータを抽出して使用するにはカスタムローダー (例: SigLoader) が必要です。これは、IMAGE_DIRECTORY_ENTRY_SECURITY データディレクトリエントリの RVA が通常のメモリオフセットではなくファイルオフセットである理由も説明しています。

検出/防止:

• https://docs.microsoft.com/en-us/security-updates/SecurityAdvisories/2014/2915720?redirectedfrom=MSDN
• パッチがインストールされ、適切なレジストリキーが設定されると、システムの再起動は不要で、Cryptographic Services を再起動するだけで済みます。Applocker サービスも暗号化サービスに依存しているため再起動されます。(@p0w3rsh3ll)
• Adrien による Yara ルール; https://twitter.com/Int2e_/status/1330975808941330432

参考文献

• https://docs.microsoft.com/en-us/security-updates/SecurityBulletins/2013/ms13-098?redirectedfrom=MSDN
• https://docs.microsoft.com/en-us/security-updates/SecurityAdvisories/2014/2915720?redirectedfrom=MSDN
• http://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/authenticode_pe.docx
• https://msrc-blog.microsoft.com/2013/12/10/ms13-098-update-to-enhance-the-security-of-authenticode/
• https://www.specterops.io/assets/resources/SpecterOps_Subverting_Trust_in_Windows.pdf
• https://p0w3rsh3ll.wordpress.com/2014/05/24/testing-ms13-098-certificate-padding-check/
• http://jsac.jpcert.or.jp/archive/2021/pdf/JSAC2021_202_niwa-yanagishita_en.pdf