【検証】SYSTEM権限でも弾かれる！？Defenderフォルダアクセス制御とhosts書き込みの罠
※本記事には広告を含みます。
はじめに
社内のキッティングスクリプトや自動化バッチで c:\windows\system32\drivers\etc\hosts ファイルを更新しようとした際、「管理者権限」や「SYSTEM権限」で実行しているにもかかわらず、「アクセスが拒否されました」と弾かれて困った経験はないでしょうか。
私も過去に、GPOのスタートアップスクリプト（SYSTEMコンテキスト）でhostsファイルを一斉配布するジョブを組んだところ、最新のWindows 11端末でことごとく書き込み失敗のアラートが上がり、原因究明に丸一日追われた経験があります。
原因を突き詰めたところ、アクセス権（NTFS ACL）の問題ではなく、Microsoft Defenderの「コントロールされたフォルダーアクセス（Controlled Folder Access: CFA）」がバックグラウンドで厳重にブロックしていることが判明しました。
この記事では、SYSTEM権限プロセスすら遮断されるDefender CFAの内部挙動の実機検証ログと、ブロックされた際のイベント確認手順、そして安全に設定を更新するための現場の回避策を徹底解説します。
読み終えるころには、セキュリティを落とさずに安全にhostsファイルや保護フォルダを自動更新できるようになります。
この記事の要点
- Defenderの「コントロールされたフォルダーアクセス（CFA）」が有効な場合、管理者やSYSTEM権限であっても未許可アプリによるシステム領域変更は遮断される
- ブロックの証拠は、イベントログ（Microsoft-Windows-Windows Defender/Operational）の「イベントID 1123 / 1124」に記録される
- 本番反映前にPowerShellで「監査モード（AuditMode）」に設定して影響範囲を洗い出すのが鉄則である
| 項目 | 動作確認・検証環境 |
|---|---|
| 検証年月 | 2026年3月 |
| 対象OS | Windows 11 Enterprise / Pro 23H2・24H2 |
| 対象セキュリティ | Microsoft Defender ウイルス対策 / Defender for Endpoint (MDE) |
| 関連機能 | コントロールされたフォルダーアクセス（CFA / ランサムウェア保護） |
結論：CFAは特権アカウント（SYSTEM/Admin）の権限よりも上位でブロックする
結論からお伝えすると、Defenderの「コントロールされたフォルダーアクセス（CFA）」は、Windowsのユーザー権限モデル（NTFS ACL）とは独立したカーネルレベルの保護フィルターとして動作 します。
そのため、たとえOS上で最高権限を持つ「SYSTEMアカウント」や「ローカル管理者グループ（Administrators）」が実行するPowerShell、コマンドプロンプト、自作バッチであっても、「信頼されたアプリケーション」として許可リストに入っていなければ、保護フォルダへの書き込みは容赦なく拒否されます。
1. なぜSYSTEM権限でも弾かれるのか？
ランサムウェア攻撃の多くは、脆弱性を突いてSYSTEM権限や管理者権限を奪取した後にファイルの暗号化や改ざんを試みます。
CFAはこうした特権昇格後の攻撃を防ぐために設計されているため、「権限がSYSTEMだから通す」という例外を意図的に排除しています。プロセスを実行しているアカウントではなく、「その実行ファイル（バイナリ）が安全と認められているか」 のみが判定基準となります。
【実機検証】hostsファイル書き込み時のブロックログとイベントID
実際にWindows 11環境でCFAを有効化した状態で、PowerShell（管理者として実行）からhostsファイルへの書き込みを試行しました。
検証コマンドとエラー挙動
以下のコマンドを実行して、hostsファイルへの1行追記を試みました。
# 管理者権限のPowerShellでhostsへの追記を実行
Add-Content -Path "C:\Windows\System32\drivers\etc\hosts" -Value "192.168.1.50 testserver.corp.local"
実行結果は以下の通り、即座に例外エラーが発生します。
Add-Content : パス 'C:\Windows\System32\drivers\etc\hosts' へのアクセスが拒否されました。
発生場所 行:1 文字:1
+ Add-Content -Path "C:\Windows\System32\drivers\etc\hosts" -Value "192 ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : PermissionDenied: (C:\Windows\Syst...ivers\etc\hosts:String) [Add-Content], UnauthorizedAccessException
+ FullyQualifiedErrorId : GetContentWriterUnauthorizedAccessError,Microsoft.PowerShell.Commands.AddContentCommand
ブロックを検知するイベントログ（ID 1123）
このとき、イベントビューアーの以下のパスに明確な遮断ログが記録されます。
- ログの場所:
アプリケーションとサービス ログ > Microsoft > Windows > Windows Defender > Operational - イベントID:
1123（ブロック時）または1124（監査モード時）
イベントログの詳細には、以下のようにブロックされたアプリと対象パスが明記されます。
イベント ID: 1123
説明: コントロールされたフォルダー アクセスによって C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe による C:\Windows\System32\drivers\etc\hosts への変更がブロックされました。
自作のスクリプトや配布ツールが原因不明の書き込みエラーで失敗した場合は、まずこのイベントID 1123が出ていないかを確認するのが最速の切り分けルートです。
現場で使える3つの安全な回避策・運用ベストプラクティス
セキュリティ機能を完全にオフにしてしまうとランサムウェア対策が無力化されるため、以下のいずれかの手法で安全に回避・運用します。
回避策1：PowerShellで特定のスクリプト実行元を除外アプリに登録する
運用管理ツールや特定の実行ファイルを、CFAの許可リスト（AllowedApplications）に登録します。
# 特定の配布ツールやPowerShell実行モジュールをCFAの除外アプリに追加
Add-MpPreference -ControlledFolderAccessAllowedApplications "C:\CorpTools\DeployAgent.exe"
※powershell.exe 自体を除外登録してしまうと、悪意あるPowerShellスクリプトによる暗号化まで素通りしてしまうため、自社の独自ラッパーや特定エージェントバイナリのみを登録するのが鉄則です。
回避策2：導入・移行期は「監査モード（AuditMode）」でログだけ収集する
いきなり本番環境でCFAのブロックを強制すると、社内システムやインストーラーが広範囲で停止する恐れがあります。
事前に「監査モード」へ切り替えることで、書き込み自体は許可しつつ、将来ブロック対象となるアプリをイベントID 1124として可視化できます。
# CFAを監査モード（ログ記録のみで遮断しない）に設定
Set-MpPreference -EnableControlledFolderAccess AuditMode
# 設定状態を確認（0: 無効, 1: 有効/ブロック, 2: 監査モード）
Get-MpPreference | Select-Object EnableControlledFolderAccess
社内PCで数週間このモードで運用し、イベントログから誤検知（自社アプリ）を洗い出してから本番ブロックへ移行するのが安全な導入手順です。
回避策3：そもそもhosts配布をやめ、社内DNSや条件付きフォワーダーで解決する
インフラ運用としての根本的な見直しです。hostsファイルへのIP直書きは、CFAのブロック問題だけでなく、端末ごとの構成差異や更新漏れによる障害の温床になります。
- Active Directory DNSに内部ゾーンやAレコードを追加する
- クラウド環境（Azure Private DNS）と連携させる
- GPOによるhostsファイル直接編集は極力廃止する
よくある質問（FAQ）
Q: 一時的にCFAを完全に無効化するコマンドはありますか？
A: PowerShellから以下のコマンドで無効化できます。ただし、エンドポイント保護が無防備になるため、メンテナンス作業時の一時的な使用に留めてください。
Set-MpPreference -EnableControlledFolderAccess Disabled
なお、Microsoft Defender for Endpoint（MDE）配下で「改ざん防止（Tamper Protection）」が有効になっている端末では、ローカル管理者であってもこのコマンドは拒否されます。IntuneまたはMDEポータルからポリシーを変更する必要があります。
Q: CFAで保護されている既定のフォルダ一覧を確認するには？
A: 既定では System32\drivers のほか、ユーザープロファイルの「ドキュメント」「ピクチャ」「デスクトップ」などが自動保護されています。追加で保護されているカスタムフォルダは以下のコマンドで確認可能です。
Get-MpPreference | Select-Object -ExpandProperty ControlledFolderAccessProtectedFolders
まとめ
Microsoft Defenderの「コントロールされたフォルダーアクセス（CFA）」とシステムファイル編集のポイントは以下の通りです。
- CFAは SYSTEM権限や管理者権限のプロセスであっても未登録アプリを容赦なく遮断する
- 書き込み失敗時の原因究明は、Defender運用ログの イベントID 1123 / 1124 を真っ先に確認する
- 現場導入時は、いきなり有効化せず 監査モード（AuditMode）で影響調査 を行う
- hostsファイルの更新に依存せず、可能な限り 社内DNSによる一元管理 へ移行する
モダンなWindowsセキュリティの仕組みを正しく理解し、堅牢な運用と作業の自動化を両立させましょう。
関連記事
この記事で提供される情報は、一般的なガイダンスを目的としており、すべての環境やシステムでの動作を保証するものではありません。
OSのバージョンやリリースによっては、記載されている事が実行できない、または異なる結果をもたらす可能性があります。
また、会社所有のパソコン、スマホ、タブレットなどでは、ポリシーや権限によって実行できない場合があります。
この記事の情報を使用することによって生じる問題や結果について、筆者およびサイト管理者は責任を負いません。
すべての操作は自己責任で行ってください。
またお会いしましょう！
著者のおすすめ教材 ＆ note実践記事
PowerShell実務スクリプト50選
AD・Windows運用・障害対応をコマンド一発で自動化する現役SEの実務スクリプト集。
ググっても出ない実務テク20選
社内SE現場の地味で細かすぎる面倒作業を一撃で解消する実践テクニック集。