【テクニカル・上級編】 WindowsのPowerShell実行ポリシーの制限 – インフラ・ネットワーク & クラウドセキュリティ防御ガイド

PowerShellの「実行ポリシー」はセキュリティの銀の弾丸か？ ― 現場が陥る甘い幻想と真のハーデニング戦略

多くのエンジニアが「PowerShellの実行ポリシー（ExecutionPolicy）を AllSigned や Restricted に設定したから大丈夫だ」と胸をなでおろす姿を、私はこれまで何度も見てきた。しかし、断言しよう。その認識こそが、攻撃者にとって最も「美味しい」餌食である。

この記事を読んでいる諸君は、既にOSレベルのハーデニングの重要性は理解しているはずだ。だが、PowerShellを単なる「管理ツール」として捉えていては、高度なファイルレス攻撃（Living-off-the-Land: LotL）の前に防壁は崩れ去る。本稿では、PowerShellの実行ポリシーが持つ限界を紐解き、真に堅牢な攻撃耐性を構築するための「攻めの防御」を解説する。

—

1. 実行ポリシー（ExecutionPolicy）の脆弱な本質

まず、根本的な事実を突きつけたい。Set-ExecutionPolicy は、セキュリティ境界（Security Boundary）ではない。これはMicrosoft自身も公式に認めている通り、ユーザーが自身の環境設定を誤って変更することを防ぐための「コンプライアンス維持ツール」に過ぎない。

攻撃者が管理者権限を奪取した、あるいは脆弱性を突いてインメモリでコードを実行する場合、彼らは以下のコマンドでいとも簡単にこの制約をバイパスする。

# プロセススコープでポリシーを一時的に無効化し、任意のスクリプトを実行する
powershell.exe -ExecutionPolicy Bypass -File .\malicious.ps1

あるいは、powershell.exe -EncodedCommand を使い、Base64エンコードされた難読化ペイロードを直接メモリ上に展開された実行環境へと送り込む。実行ポリシーをいくら厳格に設定しても、プロセス実行時に引数を与えられれば、その制限は無力化されるのだ。

—

2. 実行ポリシーを超えた「真の要塞化」アーキテクチャ

真のアーキテクトであれば、ポリシーの設定だけで満足してはならない。我々が目指すべきは、「実行ポリシーに頼らない防御層」の構築だ。

A. Constrained Language Mode (CLM) の強制

PowerShellの制限において最も強力なのは「実行ポリシー」ではなく「言語モード」である。Constrained Language Mode を有効にすれば、Win32 APIの呼び出しや高度な.NETオブジェクトの操作が制限され、ファイルレス攻撃の多くを無効化できる。

Windows Defender Application Control (WDAC) や AppLocker を利用し、PowerShellの言語モードを強制的に制限せよ。

B. AMSI（Antimalware Scan Interface）の深い理解

攻撃者はメモリ上で難読化を解くため、ディスク上のファイルには何も残さない。ここで鍵となるのが AMSI だ。PowerShellはコードを実行する直前に、メモリ上の解読済みコードをAMSIへ引き渡す。

ここで重要なのは、「スクリプトブロックログ」の取得と監査である。

# スクリプトブロックログの有効化（GPO推奨設定）
# HKLM\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging
# EnableScriptBlockLogging = 1
# これを有効にすると、難読化されたスクリプトが「実行直前の解読済み状態」でイベントログ(Event ID: 4104)に残る。

ログを SIEM（SplunkやMicrosoft Sentinelなど）に集約し、EncodedCommand や IEX（Invoke-Expression）といった、攻撃者が好む特定のキーワードをトリガーにした自動検知・遮断フローを構築しておくことが、インシデントハンドリングの基本となる。

—

3. 実務で導入すべきガードレイル設定

サーバーOSのハーデニングにおいて、私が推奨する最低限の実装構成は以下の通りだ。

Script Block Loggingの強制: 前述の通り、4104 イベントログを全量取得する。
PowerShell v2の完全削除: レガシーな環境を狙う攻撃の踏み台となる v2.0 は、機能単位でアンインストールせよ。
AppLockerによる実行制御: パスベースではなく、発行者（Publisher）による署名検証を厳格に行う。

監査用スクリプトの例（簡易的実装）

システムの現状を監査し、不適切な設定がないかを確認するためのスニペットだ。

# 現在の言語モードと実行ポリシーを確認する監査スクリプト
$ExecutionContext.SessionState.LanguageMode | Out-File "audit_log.txt" -Append
Get-ExecutionPolicy -List | Out-File "audit_log.txt" -Append

# 悪意のあるコマンドの兆候を監査する（簡易的な正規表現マッチング）
$SuspiciousPatterns = @("IEX", "Invoke-Expression", "FromBase64String", "Net.WebClient")
foreach ($Pattern in $SuspiciousPatterns) {
    Write-Host "Checking for pattern: $Pattern" -ForegroundColor Yellow
    # 実際にはここでイベントログを解析するロジックを組む
}

—

4. 総括：技術的負債としての「設定ミス」を排除せよ

最高峰のホワイトハッカーを目指す諸君に伝えたいのは、技術的な設定には「終わりがない」ということだ。量子耐性暗号への移行が議論される現在、レガシーな PowerShell の実行ポリシーという小さな穴は、攻撃者にとっては侵入の入り口となる。

PowerShellを敵視するのではなく、「PowerShellがメモリ上で何をしているか」を可視化・監視し、不審な挙動をシステムコールレベルで遮断するアーキテクチャこそが、真のセキュリティ・ディフェンスである。

「設定したから大丈夫」という慢心こそが、CVE（脆弱性）以上に恐ろしい。常に「バイパスされる前提」で防御層を多重化し、ログによる証跡管理を徹底すること。それこそが、プロフェッショナルが辿り着くべき境地である。

諸君らの環境において、今日、どれだけの Event ID 4104 が発生し、そしてそれらが正しく集約されているか。一度、SIEMのダッシュボードを自らの目で確認してほしい。そこに、我々の仕事の真価が問われている。