Attack Surface Reduction: Audit to Block with Intune

Problem

Most organisations have not implemented Attack Surface Reduction rules at all. Of those that have, a large portion deployed everything in audit mode and never moved further.

Audit mode with no follow-up is a false sense of security. The rules are watching, but nothing is blocked.

Audit mode is the right starting point. It is not a destination. If your ASR rules have been in audit mode for months and you have not acted on the data, you are getting none of the protection ASR was designed to deliver.

This post picks up where Attack Surface Reduction Rules: Configure with Intune left off. That post covers what ASR is and how to deploy it. This one focuses on reading the audit data, tuning for your environment, and moving to block mode with confidence.

---

Why This Matters

ASR rules target the specific behaviours malware relies on: Office macros spawning child processes, scripts launching executables, credential theft from LSASS. These are not theoretical threats. They are the techniques in active campaigns right now.

A rule in audit mode generates an event and does nothing. The malicious action completes.

The value of audit mode is entirely in whether you act on that data. If you are not reading the reports, you are not getting value from ASR at all.

---

The Workflow

The path from audit to block depends on whether a rule is noisy or quiet:

flowchart TD
    A[Deploy all rules<br/>in Audit mode] --> B[Collect data<br/>for 14 days]
    B --> C[Check XDR portal<br/>ASR rules report]
    C --> D[Run KQL overview<br/>in Advanced Hunting]
    D --> E{Rule generating<br/>noise?}
    E -->|No events| F[Safe to block]
    E -->|Has events| G[Identify process<br/>and path with KQL]
    G --> H[Add exclusion<br/>in Intune]
    H --> F
    F --> I[Create block<br/>policy in Intune]
    I --> J[Monitor XDR<br/>Detections tab - 48h]
    J --> K{Unexpected<br/>block events?}
    K -->|No| L[Roll out to<br/>full device scope]
    K -->|Yes| G

Work through rules in batches. Do not try to block everything at once.

Start with the rules that generate no or very few audit events: those are safe to block immediately. Save the noisy ones for after you have added exclusions.

---

Implementation

Step 1: Deploy All Rules in Audit Mode

In Microsoft Intune, go to Endpoint Security > Attack Surface Reduction > Create Policy.

Select:

• Platform: Windows
• Profile: Attack Surface Reduction Rules

Set every rule to Audit. Scope the policy to a pilot group first: IT staff or a representative cross-section of your business. Give it two weeks minimum before drawing conclusions.

The rules that matter most for most environments:

Rule	Why it matters
Block Office apps from creating child processes	Macro-based phishing
Block credential stealing from LSASS	Pass-the-hash, Mimikatz
Block JavaScript/VBScript from launching executables	Script-based droppers
Block execution of potentially obfuscated scripts	PowerShell-based attacks
Block abuse of exploited vulnerable signed drivers	Kernel-level attacks
Block executable content from email and webmail	Malicious attachments

---

If you plan to deploy ASR rules to Windows Server make sure to check further documentation as limitations apply to specific version, such as Windows server 2012R2 & Windows Server 2016

Step 2: Read the ASR Audit Data

In the Microsoft XDR portal

Go to Reports > Endpoints > Attack surface reduction rules in the Microsoft Defender portal. This is the dedicated ASR dashboard for all your devices.

The report has three tabs worth using:

• Detections: Timeline of audit and block events per rule. Drill into any rule to see affected devices, files, and the processes that triggered it. Use the time range filter to scope to your audit window (14 or 30 days).
• Configuration: Shows the current rule state (not configured, audit, block, warn) across all onboarded devices. Use this to confirm your Intune policy has applied where you expect it before drawing conclusions from detection data.
• Add exclusions: Surfaces the most commonly triggered file and process paths across your devices and lets you generate exclusion entries directly from the portal. Useful as a starting point, but always validate suggestions against your own context before applying.

Tip: Change the ‘Rules’ filter from ‘Standard protection’ to ‘All’ for more rule visibility. After flipping a rule to block, use the Detections tab to compare the period before and after. A rise in block events with no sound from the end-user or support is strong evidence the rule is working cleanly and your exclusions are correct. Custom detections could align here well.

In Intune

Go to Endpoint Security > Attack Surface Reduction > your policy > Device status. Cross-reference with the MDE portal to understand whether detections are clustered on specific device groups or roles.

Using Advanced Hunting (KQL)

The MDE portal reports are useful for an overview. For precise tuning, use Advanced Hunting. The DeviceEvents table contains all ASR audit and block events.

If you are new to KQL, see Introduction to KQL before diving in.

DeviceEvents
| where Timestamp > ago(14d)
| where ActionType startswith "Asr"
| extend
    InitiatingProcess = InitiatingProcessFileName,
    EventMode = iff(ActionType endswith "Audited", "Audit", "Block")
| summarize
    EventCount = count(),
    AffectedDevices = dcount(DeviceName),
    Processes = make_set(InitiatingProcess, 10)
    by ActionType, EventMode
| sort by EventCount desc

This gives you a per-rule breakdown across all onboarded devices. startswith "Asr" catches all ASR events in a single filter. EventMode derives audit or block from the Audited or Blocked suffix on ActionType. dcount(DeviceName) shows the blast radius: a rule firing 200 times on 2 devices is very different from 200 times across 80 devices. make_set on the initiating process surfaces the top offenders without returning every raw row.

To drill into a specific noisy rule:

DeviceEvents
| where Timestamp > ago(14d)
| where ActionType == "AsrOfficeChildProcessAudited"
| project
    Timestamp,
    DeviceName,
    InitiatingProcessFileName,
    InitiatingProcessFolderPath,
    FileName,
    FolderPath,
    InitiatingProcessCommandLine
| sort by Timestamp desc

Replace AsrOfficeChildProcessAudited with the ActionType value from the first query for the rule you are investigating. ASR ActionType values follow the pattern Asr<RuleName>Audited or Asr<RuleName>Blocked. InitiatingProcessCommandLine is particularly useful for distinguishing legitimate LOB application behaviour from something suspicious that happens to match the same rule. InitiatingProcessFolderPath and FolderPath give you the exact paths you need to write a precise exclusion.

---

Step 3: Add Exclusions

ASR exclusions in Intune are path-based. You can exclude a specific file, folder, or process from all ASR rules. Keep exclusions as narrow as possible.

Common legitimate sources of ASR audit noise:

• Line of business applications that spawn child processes from Office macros (field automation tools, report generators)
• IT management tools that manipulate LSASS for credential sync
• Build or deployment scripts that match obfuscated script patterns

For each exclusion, document the business justification. An undocumented exclusion is a debt you will pay back later during an incident.

Tip: If a rule fires on more than 10 unique processes with no obvious pattern, the rule may not be suitable for block mode in your environment yet. Keep it in audit, investigate the source applications, and revisit in 30 days.

---

Step 4: Move Tuned Rules to Block Mode

Once a rule generates only known-good audit events that you have exclusioned, flip it to Block in your Intune policy.

Do not touch the original audit policy. Create a second policy targeting the same group with the tuned rules set to block.

Intune merges policies: where both policies define the same rule, the more restrictive setting wins. Block overrides audit.

This approach lets you roll back a specific rule to audit without disturbing the others. Delete the block-mode entry for that rule from the second policy and audit takes effect again immediately.

Tip: After flipping a rule to block, watch the MDE portal for the next 48 hours. Block events for processes you have not seen before during audit may indicate the pilot group did not surface all real-world usage patterns.

---

Recommended Starter Set for Organisations New to ASR

If your organisation has never run ASR and you want to know which rules to block first, start with these. They have the lowest rate of legitimate application interference and the highest impact against common attack techniques:

Rule	Risk of false positive	Impact
Block executable content from email and webmail	Low	High: stops attachment-based delivery
Block JavaScript/VBScript from launching executables	Low	High: breaks most script-based droppers
Block execution of potentially obfuscated scripts	Low-Medium	High: catches PowerShell-based loaders
Block credential stealing from LSASS	Medium	Critical: stops Mimikatz-style attacks
Block Office communication application from creating child processes	Low	Medium: targets Teams/Outlook phishing

Avoid blocking Block Office apps from creating child processes early. It is high impact but also the most common source of application noise. Run it in audit, read the data, then decide to block.

---

Tips

• Enable Cloud Protection Level: High Plus alongside your ASR block policies. In Intune, go to Endpoint Security > Antivirus > Create Policy, select the Microsoft Defender Antivirus profile, and set Cloud protection level to High Plus. This tells Defender to submit more suspicious samples to the cloud for deeper analysis and block them aggressively before execution.

  The result is extra EDR alerts in the Microsoft Defender portal that surface threats ASR rules alone would not show. These alerts appear in Advanced Hunting under AlertInfo and AlertEvidence and will show up in your incident queue alongside ASR block events. For more details on per-rule alert and notification behaviour, see the ASR rules reference.

• Use device groups to stage block mode rollout. Block on IT staff first, then extend to a broader pilot, then all devices. Staged rollout limits the blast radius of a misconfigured exclusion.
• Name your policies clearly: ASR - Audit - All Rules and ASR - Block - All rules makes it obvious at a glance which policies are protective and which are monitoring.
• Revisit audit-mode rules every 30 days. A rule generating zero events for 30 days on a representative device group is ready to block.

---

Summary

Audit mode gives you visibility. Block mode gives you protection. The gap between them is tuning, and tuning requires reading the data.

Your next steps:

1. If you have not deployed ASR yet, start with all rules in audit mode scoped to a pilot group
2. Run the Advanced Hunting queries above after 14 days and identify which rules have zero or minimal noise
3. Add exclusions for known-good processes triggering noisy rules
4. Create a second Intune policy to flip the tuned rules to block mode
5. Expand the block policy to all devices once validated on the pilot group

Stay safe 👾