IntuneとMicrosoft Defenderで攻撃面縮小（ASR）を実現する手順と検証方法

Microsoft Defender for Endpoint（MDE）の「攻撃面の減少（ASR：Attack Surface Reduction）ルール」を、Intune から配信して動作を確かめました。この記事では、ASR ルールの前提条件と動作モードを整理したうえで、Intune でのポリシー作成、Office マクロを使ったブロックの確認、イベントログと Defender ポータルでの記録の見方までを順に説明します。

ASR ルールは、マルウェアがよく使う「入り口」になる動作を止める機能です。設定は Intune の画面から行えますが、業務アプリを止めてしまうこともあるので、展開の進め方と除外のしかたも合わせて押さえておきます。

攻撃面の減少（ASR）とは

攻撃面の減少は、攻撃者が入り込める場所（攻撃面）を減らす考え方です。家にたとえると、扉や窓は侵入口になります。使わない扉を閉じたり、鍵を強くしたりすれば、侵入されにくくなります。ASR ルールは、これと同じことを Windows 上のソフトウェアの動作に対して行います。

ASR ルールが止める動作の例は次のとおりです。

• ファイルをダウンロードしたり実行したりしようとする実行ファイルやスクリプトの起動
• 難読化されたスクリプトや、その他の疑わしいスクリプトの実行
• Office アプリなどからの子プロセスの作成や、他のプロセスへのコードの挿入

これらは正規のアプリが行うこともありますが、マルウェアがよく使う動作でもあります。そのため、いきなり全部を止めるのではなく、影響を確かめながら有効にしていきます。

攻撃面の減少に含まれる機能

攻撃面の減少は1つの機能の名前ではなく、Defender for Endpoint の複数の保護機能をまとめた呼び方です。この記事で扱うのは、このうちの「攻撃面の減少ルール（ASR ルール）」です。

前提条件：ここを満たさないと ASR ルールは動かない

ASR ルールは Microsoft Defender ウイルス対策（MDAV）の機能です。そのため、MDAV がきちんと動いていることが前提になります。展開の前に次の項目を確認します。

必須の要件

対応する OS

ASR ルールそのものは、MDAV を含むすべてのエディションの Windows で使えます（Windows 11 Home でも、PowerShell でローカルに設定できます）。Defender for Endpoint で一元管理（Intune からの配信、レポート、アラート）できるのは次の OS です。

• Windows 10 以降の Pro・Enterprise エディション
• Windows Server 2012 R2 以降（2012 R2・2016 は、最新の統合ソリューション パッケージでオンボードしたもの）
• Azure Local（旧 Azure Stack HCI）バージョン 23H2 以降

ルールごとに対応するバージョンは違います。たとえば「すべての Office アプリケーションによる子プロセスの作成をブロックする」は Windows 10 1709 以降、「WMI イベント サブスクリプションを介して永続性をブロックする」は Windows 10 1903 以降です。使うルールの対応状況は、ルールのリファレンスで確認します。

ライセンス

ASR ルールを使うだけなら、Microsoft 365 E5 は必須ではありません。ただし、管理と監視の機能は使うライセンスで変わります。

Microsoft は、監視・分析やレポートの機能を活用するために、E5 またはそれに相当するライセンスを推奨しています。

ASR ルールの動作モード

ASR ルールは、ルールごとに次のどれかのモードで動かします。PowerShell や CSP で設定するときは、右の数値（コード）を使います。

まずは標準保護ルールの3つから

ASR ルールは全部で19あります（2026年10月時点）。Microsoft は、このうち次の3つを「標準保護ルール」として、大がかりなテストなしにブロック モードで有効にすることを推奨しています。利用者への影響がほとんどなく、保護の効果が大きいためです。

ただし例外があります。Configuration Manager でデバイスを管理している場合、Configuration Manager のクライアントは WMI に大きく依存しているので、WMI のルールは監査モードで十分にテストしてから有効にします。また、LSA 保護を有効にしているデバイスでは、資格情報の盗用のルールは同じ保護になるので不要です。

Defender ポータルの ASR ルールのレポートも、既定では標準保護ルールに絞り込んで表示されます。

展開の全体の流れ

ASR ルールは「設定して終わり」ではありません。業務への影響を確かめながら、段階的に広げていきます。Microsoft の展開ガイドの流れを図にすると次のようになります。

最初は小さなグループ（リング1）で、すべてのルールを監査モードにして、日常の業務でどのルールが反応するかを調べます。業務アプリが引っかかったら除外を追加し、問題がなくなったルールからブロック モードに切り替えます。そのあと、リング2、リング3 と対象を広げます。

ここからは、この流れのうち「ASR ルールを Intune で設定し、動作を確かめる」部分を実機で行います。

Intune で攻撃面の減少ルールを設定する

検証の構成

Intune に登録し、MDE にオンボードした Windows 11 のデバイス「Win11-3」に ASR ルールを適用します。ポリシーは「セキュリティ適用グループ」に割り当て、Win11-3 をこのグループのメンバーにしています。

MDE のオンボーディングは、Defender for Endpoint をIntuneからオンボーディングする を参照してください。

攻撃面の減少のポリシー作成を開く

Microsoft Intune 管理センター（https://intune.microsoft.com/）で、エンドポイント セキュリティ ›› 攻撃面の減少 を開き、「ポリシーの作成」をクリックします。

プラットフォームとプロファイルを選ぶ

プラットフォームとプロファイルを選び、「作成」をクリックします。

基本情報を入力する

ポリシーの名前を入力し、「次へ」をクリックします。今回は「ASRルールテスト」にしました。

構成設定で各ルールのモードを決める

「構成設定」には、「Adobe Reader による子プロセスの作成をブロックする」など、ルールが1つずつ並んでいます。ルールごとにモードを選びます。各ルールの詳細は 攻撃面の減少ルールの参照 で確認できます。

今回はテストなので、「すべての Office アプリケーションによる子プロセスの作成をブロックする」だけを「ブロック」にし、「次へ」をクリックします。

このルールの GUID は d4f940ab-401b-4efc-aadc-ad5f3c50688a です。対象の Office アプリは Word、Excel、PowerPoint、OneNote、Access です。

スコープ タグと割り当て

「スコープ タグ」は何も設定せず、「次へ」をクリックします。「割り当て」では「グループの追加」をクリックし、対象のグループを選びます。今回はあらかじめ「セキュリティ適用グループ」を作り、デバイス Win11-3 をメンバーにしています。

確認および作成

「確認および作成」で設定内容を確認し、「作成」をクリックします。

作成すると、攻撃面の減少のポリシー一覧に登録されます。

デバイスにポリシーが届いたかを確かめる

デバイスを同期する

ポリシーを早く反映させるため、デバイスを同期します。Intune 管理センターの デバイス ›› すべてのデバイス で Win11-3 を開き、「同期」をクリックして、確認のメッセージで「はい」をクリックします。

PowerShell で適用されたルールを確認する

ルールが実際に届いたかは、対象の PC の PowerShell で確認できます。管理者として PowerShell を起動し、次のコマンドを実行します。

Win11-3（管理者の PowerShell）

$p=Get-MpPreference;0..([math]::Min($p.AttackSurfaceReductionRules_Ids.Count,$p.AttackSurfaceReductionRules_Actions.Count)-1) | % {[pscustomobject]@{Id=$p.AttackSurfaceReductionRules_Ids[$_];Action=$p.AttackSurfaceReductionRules_Actions[$_]}} | Format-Table -AutoSize

出力の例は次のとおりです。Id 列がルールの GUID、Action 列がモードのコードです。

出力の例

Id                                       Action
--                                       ------
d4f940ab-401b-4efc-aadc-ad5f3c50688a          1
9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2          1
56a863a9-875e-4185-98a7-b882c64b5ce5          1

Action 列の値の意味は、モードのコードと同じです。

この例では、Office の子プロセスのルール（d4f940ab-…）に加えて、標準保護ルールの資格情報の盗用（9e6c4e1f-…）と脆弱な署名付きドライバー（56a863a9-…）もブロック（1）になっています。GUID とルールの対応は、ルールのリファレンスの GUID の一覧 で確認できます。

テスト用のマクロを用意する（ChatGPT で作成）

Office アプリから子プロセスを作るテスト用のマクロを、ChatGPT に作ってもらいました。プロンプトは次のとおりです。

出力されたマクロは次のとおりです。WScript.Shell オブジェクトの Run で PowerShell を起動し、echo Hello, World! を実行します。Word（WINWORD.EXE）から見ると、powershell.exe は子プロセスになります。

Word の VBA マクロ

Sub RunPowerShellCommand()
    Dim shell As Object
    Set shell = CreateObject("WScript.Shell")
    
    Dim command As String
    ' PowerShellコマンドを設定
    ' 例: PowerShellで "Hello, World!" を表示
    command = "powershell.exe -NoProfile -Command ""echo Hello, World!"""
    
    ' PowerShellコマンドを実行
    shell.Run command, 1, True ' 1 = アクティブウィンドウで実行, True = 実行が終わるまで待つ
End Sub

動作を確認する

Win11-3 で Word を開き、表示 ›› マクロ から、作成したマクロを選んで「実行」をクリックします。

実行すると PowerShell は起動せず、Windows セキュリティのトースト通知でブロックされたことが表示されました。

Windows セキュリティ1操作がブロックされました管理者の設定により、このアクションは Windows セキュリティでブロックされました。ヘルプ デスクに問い合わせてください。

このときの動きを図にすると次のようになります。Word が powershell.exe を子プロセスとして起動しようとしたところを ASR ルールが止め、その記録がデバイスと Defender ポータルの両方に残ります。

イベントログで確認する

ブロックはデバイスのイベントログにも記録されます。イベント ビューアーで アプリケーションとサービス ログ ›› Microsoft ›› Windows ›› Windows Defender ›› Operational を開くと、イベント ID 1121 でブロックの記録が見つかりました。

1Microsoft Defender Exploit Guard が IT 管理者によって許可されていない操作をブロックしました。 詳細は IT 管理者に問い合わせてください。2        ID: D4F940AB-401B-4EFC-AADC-AD5F3C50688A        検出時刻: 2024-03-17T09:53:28.312Z        ユーザー: （伏せています）3        パス: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe        プロセス名: C:\Program Files\Microsoft Office\root\Office16\WINWORD.EXE        ターゲット コマンドライン: "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -NoProfile -Command "echo Hello, World!"        親コマンドライン: "C:\Program Files\Microsoft Office\Root\Office16\WINWORD.EXE" /n "C:\Users\（伏せています）\Desktop\テスト文章.docx" /o ""        関連ファイル: C:\Users\（伏せています）\Desktop\テスト文章.docx

ASR ルールに関係する主なイベント ID は次のとおりです。監査モードにした場合は、動作は止めずに 1122 が記録されます。

Defender ポータルで確認する

Microsoft Defender ポータル（https://security.microsoft.com/）で、レポート ›› エンドポイント ›› 攻撃面の減少ルール を開きます。レポートは https://security.microsoft.com/asr から直接開くこともできます。

「Detections」タブで、ブロックと監査の検出数と、検出の一覧を確認できます。既定では標準保護ルールだけが表示されるので、フィルターの「ルール」を「すべて」にしています。

一覧では、検出したファイル（powershell.exe）、起動元のアプリ（WINWORD.EXE）、反応したルール、デバイスを確認できます。誤検知を調べるときは、ここから対象のファイルとルールを特定します。

除外の設定：ブロックされて困るときの対処

ASR ルールが正規の業務アプリを止めてしまうことがあります。たとえば「Office の子プロセスのブロック」が、業務用のマクロから呼び出す社内アプリの起動を止める、といったケースです。このような場合は、除外を追加して、そのファイルやフォルダーを ASR ルールの評価から外します。

除外の種類

ルールごとの除外を使えば、「Office の子プロセスのブロックだけは特定のアプリを許可し、難読化スクリプトのブロックはそのまま有効にする」といった細かい制御ができます。

Intune での設定方法

1. エンドポイント セキュリティ ›› 攻撃面の減少 で、対象のポリシーを開いて構成設定を編集します。
2. 除外したいルールのモードを「監査」「ブロック」「警告」のどれかにすると、「ASR のみ規則ごとに除外」の項目が表示されます（図5 の項目）。
3. 除外するフォルダーのパス、またはファイルのパスとファイル名を入力します（例：C:\Program Files\MyApp\test1.exe）。CSV で取り込むこともできます。

MDAV の除外に従わないルール

次のルールは、MDAV のファイルとフォルダーの除外に従いません。これらのルールで除外したい場合は、ASR ルールの除外（ルールごと、または共通）を設定します。なお、MDAV のプロセスの除外には、すべてのルールが従います。

• Windows ローカル セキュリティ機関サブシステムからの資格情報の盗用をブロックする
• WMI イベント サブスクリプションを介して永続性をブロックする
• Adobe Reader による子プロセスの作成をブロックする
• Office アプリケーションによる実行可能コンテンツの作成をブロックする
• Office アプリケーションによる他のプロセスへのコード挿入をブロックする
• Office 通信アプリケーションによる子プロセスの作成をブロックする
• PSExec コマンドと WMI コマンドから発生するプロセスの作成をブロックする

現場でつまずきやすいポイント

運用でよく問い合わせがあるポイントをまとめます。

Q1. ポリシーを設定したのに動いている気配がない

次の順に確認します。

1. MDAV がプライマリのウイルス対策として、アクティブ モードで動いているか（他社のウイルス対策を入れていないか）
2. リアルタイム保護とクラウド提供の保護が有効か
3. デバイスが MDE にオンボードされているか
4. Intune の同期が済んでいるか
5. PowerShell の Get-MpPreference で、ルールが届いているか、モードが監査になっていないか
6. グループ ポリシーで同じルールを設定して競合していないか
7. Office 系のルールの場合、Office が %ProgramFiles% 配下にインストールされているか

Q2. グループ ポリシーと Intune の両方で設定するとどうなるか

同じルールをグループ ポリシーと MDM（Intune）の両方で設定すると、既定ではグループ ポリシーの設定が優先されます。Policy CSP の MDMWinsOverGP を 1 にすると、MDM 側を優先できます。基本は、どちらか一方にそろえます。

Intune の中で複数のポリシーが同じデバイスに届く場合は、競合しない設定はまとめて（スーパーセットとして）適用され、競合する設定だけが適用されずに保留されます。

Q3. PSExec・WMI のルールと Configuration Manager

Configuration Manager のクライアントは WMI に大きく依存しています。Microsoft は、Configuration Manager を使っている場合、「PSExec コマンドと WMI コマンドから発生するプロセスの作成をブロックする」（GUID：d1e49aac-8f56-4280-b9ba-993a6d77406c）を、ほかの方法（Intune やグループ ポリシーなど）で有効にしないよう案内しています。このルールは Configuration Manager からは設定できないので、Configuration Manager の環境では、このルールは使わない前提で考えます。

Q4. 資格情報の盗用のルールで大量のイベントが出る

「Windows ローカル セキュリティ機関サブシステムからの資格情報の盗用をブロックする」は、もともと大量の監査イベントを出すルールです。必要のない権限で lsass.exe にアクセスするプロセス（svchost.exe や Chrome の更新など）が多いためです。このルールが止めるのは LSASS のメモリへのアクセスで、プロセスの実行そのものは止めません。

そのため、監査モードでの評価を省いてブロック モードで展開してよい、と公式ドキュメントでも案内されています（少数のデバイスから始めて広げることが推奨されています）。なお、LSA 保護を有効にしているデバイスでは、このルールは Defender ポータルで「適用不可」と表示されます。

Q5. 正規のアプリがブロックされた

自動更新ツールや、独自のパスにインストールされたアプリなど、正規のアプリが ASR ルールに止められることがあります。たとえば「Block use of copied or impersonated system tools」（コピーまたは偽装されたシステム ツールの使用のブロック）は、場所や動きがシステム ツールに似たアプリを止めることがあり、「ランサムウェアに対して高度な保護を使用する」は、まだ評判が確立していないファイルも止めます。

Defender ポータルのレポートで、止められたファイルとルールを確認し、影響を判断したうえで次のどれかで対応します。

1. ルールごとの除外に、対象のファイルのフルパスを追加する
2. 侵害インジケーター（IoC）で、ファイルや証明書を「許可」にする
3. ルールを監査モードに戻す（最後の手段）

ブロックを放っておくと、更新が止まって脆弱性が残ることもあります。止まったまま気づかない状態にならないよう、レポートを定期的に確認します。

Q6. Office を C:\Program Files 以外にインストールしている

前提条件で説明したとおり、一部の Office 系ルールは %ProgramFiles% または %ProgramFiles(x86)% 配下の Office にしか効きません。別のパス（例：D:\Apps\Office）にインストールしていると、ポリシーでは有効でも実際には適用されません。

対象のルールは次の3つです。

• すべての Office アプリケーションによる子プロセスの作成をブロックする
• Office 通信アプリケーションによる子プロセスの作成をブロックする
• Office アプリケーションによる他のプロセスへのコード挿入をブロックする

Q7. MDE Client Analyzer で詳しい情報を取りたい

誤検知や想定外の動きを Microsoft サポートに問い合わせるときは、MDE Client Analyzer で診断データを取ります。問題を再現するのと同じタイミングで、詳細モード（-v）で実行します。

コマンド プロンプト

MDEClientAnalyzer.cmd -v

MDAV の診断ファイルは、MpCmdRun.exe -GetFiles でも MpSupportFiles.cab として作れます。この中で特に役に立つのは次のファイルです。

まとめ

ASR ルールは強力な防御機能ですが、業務への影響を確かめながら段階的に展開することが大切です。この記事のポイントを表にまとめます。

これらの注意点を押さえて運用すれば、ASR ルールで組織の攻撃面を着実に減らせます。

関連記事：Defender for Endpoint をIntuneからオンボーディングする