Windows Defender Application Control (WDAC) 完全実装ガイド：現代のマルウェアが最も嫌う「暗黙の拒否」の構築
こんにちは。現場のインシデントレスポンスやペネトレーションテストを渡り歩いてきた人間なら誰もが知っている真理がある。それは、「どれほど強固な境界防御を敷こうとも、エンドポイントで任意のコードが実行された瞬間、そのゲームの勝敗は決まる」ということだ。
ランサムウェアの亜種、Living off the Land (LotL) バイナリを用いたファイルレス攻撃、そして初期アクセスの足がかりとなる野良のペイロード。これらすべての攻撃ライフサイクルにおいて、侵入者の最終的な目的は常に同じ、「メモリ上での未承認バイナリの実行」に帰結する。
従来のアンチウイルス（AV）や、シグネチャマッチングに依存したEDRは、もはや後手に回らざるを得ない。攻撃者が未知の難読化やポリモーフィックな手法を用いて検知をすり抜ける時間を稼ぐ間、防御側は常にイタチごっこを強いられているからだ。
ここで私たちが選択すべき唯一にして最大の解答が、Windows Defender Application Control (WDAC) によるホワイトリスト方式の実行制御である。今回は、お座なりなセキュリティガイドラインの復唱ではなく、攻撃者のバイパス試行を完全に無効化し、エンタープライズ環境を要塞化するための実践的なアーキテクチャ設計と実装の勘所を深掘りする。
—
1. なぜ「ブラックリスト」ではなく「WDAC（ホワイトリスト）」なのか
現代のエンドポイントセキュリティにおいて、ブラックリスト方式（悪意あるものを検知して止める）はすでに破綻している。攻撃者は、正当なOSの管理ツール（powershell.exe, certutil.exe, wmic.exe 等）や、信頼された証明書でサインされたサードパーティ製バイナリを悪用する。これがいわゆる Living off the Land Binaries (LoLBins) だ。
WDACは、これらの一切の「不審な正当性」を無効化する。
ポリシーの根幹にあるのは、「明示的に許可されていないものは、すべて実行を拒否する（Default Deny）」という原則だ。カーネルモード（Ci.dll）のレイヤでコード整合性（Code Integrity）を強制するため、ユーザーモードの脆弱性を突いた権限昇格や、EDRエージェント自体のプロセス停止を試みるアグレッシブなマルウェアに対しても、強固な防御壁として機能する。
—
2. WDACポリシー構築の現実解：監査モードから強制モードへ
WDACの導入における最大の失敗は、最初から「強制モード（Enforce）」で適用し、業務アプリケーションや社内ニッチツールを破壊してヘルプデスクをパンクさせることだ。
鉄則は以下のステップを踏むこと。
1. ベースポリシーの生成（マイクロソフト推奨ブロックや基本テンプレートをベースにする）
2. 監査モード（Audit Mode）でのデプロイ（イベントログへの記録による影響測定）
3. イベントログの解析と補足ルールのマージ
4. 強制モード（Enforce Mode）への移行
実践：PowerShellによるベースポリシーの作成とカスタマイズ
以下のスクリプトは、標準の DefaultWindows テンプレートをベースに、監査モードで初期ポリシーを作成し、必要なオプション（ダイナミックコード生成の許可やブート時の厳格化など）を有効化する際の代表的なコマンドラインだ。
# 1. 作業用ディレクトリの作成
$PolicyPath = "C:\WDAC_Policies"
New-Item -ItemType Directory -Force -Path $PolicyPath
# 2. マイクロソフト推奨のベースポリシーをコピー
$TemplatePath = "$env:windir\schemas\CodeIntegrity\ExamplePolicies\DefaultWindows_Enforce.xml"
$BasePolicyXML = "$PolicyPath\Enterprise_Base_Policy.xml"
Copy-Item $TemplatePath -Destination $BasePolicyXML
# 3. ポリシーIDの付与とバージョン設定
Set-CIPolicyId -FilePath $BasePolicyXML
Set-CIPolicyVersion -FilePath $BasePolicyXML -Version "1.0.0.0"
# 4. オプションの有効化：
# - 許可されていないバイナリの実行時にイベントログへ記録（監査）
# - ユーザモードのコード整合性（UMCI）の強制
Set-RuleOption -FilePath $BasePolicyXML -Option 3 # 監査モードを有効にする場合は一時的に設定（後で削除）
Set-RuleOption -FilePath $BasePolicyXML -Option 0 # プレフィックスとサフィックスの厳格な一致
Set-RuleOption -FilePath $BasePolicyXML -Option 6 # アドバンスド・インストーラーのルール
Set-RuleOption -FilePath $BasePolicyXML -Option 9 # ダイナミックコードのメモリ実行をブロック（JIT対策）
Set-RuleOption -FilePath $BasePolicyXML -Option 12 # ブート時のカーネルデバッグの無効化
# 5. バイナリ形式（.cip）への変換
ConvertFrom-CIPolicy -XmlFilePath $BasePolicyXML -BinaryFilePath "$PolicyPath\SiPolicy.p7b"—
3. 署名者ルール（Signer Rules）とファイルハッシュの罠
WDACのポリシー設計で最も頭を悩ませるのが、「何を信頼の基準（Rule Level）にするか」という点だ。
- ファイルハッシュ（File Hash）: 最も厳格だが、アプリケーションのアップデート（パッチ適用）のたびにハッシュが変わるため、運用コストが破綻する。社内ニッチなスクリプト等を除き、ベースのOSや業務アプリには推奨されない。
- ファイルパス（File Path）:
C:\Program Files\などを許可する方式。一見楽だが、非特権ユーザーがそのディレクトリ内に書き込み権限（ACLの不備）を持っている場合、攻撃者に同名バイナリを置かれてバイパスされる（Path Interception Vulnerability）。 - 署名者ルール（Publisher / Signer）: コード署名証明書のCN（Common Name）やルート証明書、またはファイルパブリッシャーを信頼する方式。もっともスケーラブルかつセキュア。
署名者ルールの追加例（PowerShell）
特定のベンダ（例: Microsoft や自社開発の署名証明書）を信頼するルールをマージするには、既存のカタログやバイナリからルールを抽出し、ベースポリシーに統合する。
# 特定の署名入りファイルからルールを生成し、ベースポリシーにマージする
$TargetBinary = "C:\TrustedApp\my_enterprise_app.exe"
$NewRuleXML = "$PolicyPath\AppRule.xml"
# ファイルの署名情報に基づきパブリッシャー規則を生成
New-CIPolicyRule -Level Publisher -FilePath $TargetBinary -UserPE -OutFilePath $NewRuleXML
# ベースポリシーに生成したルールを統合（マージ）
Merge-CIPolicy -OutputPolicy $BasePolicyXML -PolicyPaths @($BasePolicyXML, $NewRuleXML)現場のセキュリティエンジニアとして強調しておきたいのは、「ファイルパブリッシャー規則（Publisher Rule）」を使用する際は、証明書の有効期限切れやサードパーティの証明書チェーンの信頼関係に細心の注意を払うことだ。安易に広範な証明書を信頼すると、サプライチェーン攻撃の踏み台にされる。
—
4. 攻撃者の視点：WDACバイパスと防御側のカウンター
最高峰の防御機構であっても、実装の不備やエッジケースを突いたバイパス手法は存在する。レッドチームや高度な攻撃者が好むWDAC回避の手口と、それに対するアーキテクチャ上のカウンターを知っておく必要がある。
1. 脆弱なドライバを用いたBYOVD（Bring Your Own Vulnerable Driver）攻撃
- 攻撃の仕組み: カーネルモードのコード整合性（KMCI）をバイパスするため、脆弱性が既知の古い正当なドライバ（管理者権限でロード可能）を読み込み、カーネルメモリを直接書き換えてWDACの enforcement を無効化する。
- 防御策: WDACのポリシーにおいて「HVCI（Hypervisor-protected Code Integrity）」および「Credential Guard」を完全に有効化し、VBS（Virtualization-based Security）の基盤上で実行させること。また、ASR（Attack Surface Reduction）ルールやドライバブロックリスト（Microsoft Vulnerable Driver Blocklist）を最新の状態に保ち、既知の脆弱なドライバのロードをハードウェアレベルで阻止する。
2. 信頼されたディレクトリのACL不備を突くサイドローディング
- 攻撃の仕組み: WDACポリシーで
C:\Program Files\配下が無条件で信頼されている場合、一般ユーザーに書き込み権限が誤設定されているフォルダが存在すると、そこに悪意あるDLLを配置して正規アプリに読み込ませる（DLLサイドローディング）。 - 防御策: WDACポリシーの構築と並行して、インフラ側のセキュリティ監査としてディレクトリのACL（アクセス制御リスト）を厳格に監査し、非特権ユーザーによる書き込み権限を排除する。
—
5. 運用自動化と監査のベストプラクティス
WDACは一度デプロイして終わりではない。新しいアプリケーションの導入、Windows UpdateによるOSコンポーネントの変更、サードパーティ製ツールのアップデートのたびに、ポリシーのライフサイクル管理が求められる。
1. Intune / グループポリシー（GPO）による強制配信:
バイナリ化されたポリシー（SiPolicy.p7b）を、Windows 10/11 向けのエンドポイント管理ソリューション経由でセキュアにプッシュする。
2. イベントログ（Event ID 3076, 3077, 3033 等）のSIEM連携:
監査モード時、あるいは強制モードでブロックが発生した際のイベントをリアルタイムで検知し、SOC（Security Operation Center）のダッシュボードに集約する。これにより、ユーザーからの「アプリが動かない」という問い合わせに対し、迅速にポリシー側で例外許可（または拒否の正当性確認）を下す体制を構築する。
結びにかえて
WDACによる実行制御は、決して「導入すればすべてのセキュリティインシデントが消え去る魔法の杖」ではない。しかし、攻撃者に対して「エンドポイントでのコード実行」という最大の金脈を塞ぐための、最も費用対効果が高く、かつ根本的な防壁であることは間違いない。
ブラックリストの限界に絶望し、シグネチャのイタチごっこに疲弊したエンジニアたちよ。今こそ「暗黙の拒否」という冷徹なロジックをインフラの根底に据え、サイバー犯罪者たちの侵入コストを跳ね上げよう。
コメント