Microsoft Defender for Endpoint

Microsoft Defender for Endpoint Attack Surface Reduction Rules – SC-200 Study Guide

Purpose of This Lesson Attack Surface Reduction, commonly called ASR, is a Microsoft Defender for Endpoint capability used to reduce the number of ways an attacker can compromise a Windows device. For the SC-200 exam, this topic matters because Security Operations Analysts need to understand how endpoint prevention controls affect detection, investigation, alert triage, ransomware […]

Microsoft SC-200 Security Operations AnalystMicrosoft Defender for EndpointUpdated Jul 3, 2026
Study options
WatchAvailable
ListenPremium
ReadAvailable
ReviewComing later

Watch this lesson

Video and article share the same canonical lesson.

Study guide

Technical reference and lesson notes

Purpose of This Lesson

Attack Surface Reduction, commonly called ASR, is a Microsoft Defender for Endpoint capability used to reduce the number of ways an attacker can compromise a Windows device. For the SC-200 exam, this topic matters because Security Operations Analysts need to understand how endpoint prevention controls affect detection, investigation, alert triage, ransomware defense, and endpoint hardening.

ASR rules help prevent common attacker techniques such as malicious Office macro behavior, script abuse, credential theft from LSASS, suspicious child processes, ransomware-like behavior, and abuse of remote execution tools. Microsoft recommends enabling standard protection rules and testing other ASR rules in Audit mode before enforcing them in Block or Warn mode.

Key Concepts

What Is an Attack Surface?

An attack surface is the collection of possible ways an attacker can enter, exploit, or abuse a system. On an endpoint, this can include:

  • Email attachments
  • Office macros
  • Scripts
  • Browsers
  • USB devices
  • Vulnerable drivers
  • Remote management tools
  • Credential theft attempts
  • Web shells on servers
  • Ransomware behavior
  • Applications launching suspicious child processes

The goal of attack surface reduction is not just to detect malicious activity after compromise. The goal is to reduce the number of behaviors that attackers can abuse in the first place.

In Microsoft Defender for Endpoint, ASR rules focus on risky behaviors commonly used by malware and hands-on-keyboard attackers. Microsoft describes ASR rules as protections against attacks that use macros, scripts, and common injection techniques.

What Are ASR Rules?

Attack Surface Reduction rules are endpoint security controls in Microsoft Defender for Endpoint that block, warn, or audit specific behaviors. They are especially important on Windows endpoints because Windows receives the broadest ASR rule support compared to other operating systems.

Common ASR rule categories include:

  • Blocking Office applications from creating child processes
  • Blocking Office macros from calling Win32 APIs
  • Blocking executable content from email and webmail
  • Blocking JavaScript or VBScript from launching downloaded executables
  • Blocking credential stealing from LSASS
  • Blocking abuse of vulnerable signed drivers
  • Blocking persistence through WMI event subscriptions
  • Blocking process creation from PsExec and WMI commands
  • Blocking executable content from USB devices
  • Blocking Adobe Reader from creating child processes
  • Blocking web shell creation on servers
  • Enabling ransomware protection behavior
  • Enabling Controlled Folder Access

ASR rules are prevention-focused, but they also support SOC visibility because audit and block events can be reviewed in Defender reporting and Advanced Hunting. ASR events are available in the DeviceEvents table in Microsoft Defender XDR Advanced Hunting.

ASR Rule Modes: Off, Audit, Warn, and Block

ASR rules can generally be configured in several modes.

ModeMeaningSOC / Operations Use
OffThe rule is not enforced or audited.No protection or useful signal from that rule.
AuditDefender records what would have happened if the rule were enforced.Best for testing impact before enforcement.
WarnThe user is warned and may be able to bypass depending on configuration.Useful when you want friction without full blocking.
BlockThe behavior is prevented.Strongest protection, but requires testing to avoid business disruption.

For real environments, Audit mode is critical. It allows the SOC and endpoint team to understand which rules would fire before those rules start blocking users, applications, scripts, or business workflows. Microsoft specifically recommends testing non-standard ASR rules in Audit mode before moving them to Block or Warn mode.

Standard Protection Rules vs Other ASR Rules

Microsoft groups some ASR rules as standard protection rules. These are the rules Microsoft generally expects organizations to enable with minimal end-user impact while they evaluate the rest of the ASR rule set.

The standard protection rules include protections such as:

  • Blocking abuse of exploited vulnerable signed drivers
  • Blocking credential stealing from the Windows Local Security Authority Subsystem Service, or LSASS
  • Blocking persistence through WMI event subscriptions

The exam-relevant point is this: standard protection rules are usually safer to enable earlier, while other ASR rules should normally be piloted, audited, and reviewed before broad enforcement.

Where ASR Rules Are Configured

ASR rules can be managed through Microsoft endpoint security policy workflows. In modern Microsoft environments, this often involves:

  • Microsoft Defender portal
  • Microsoft Intune endpoint security policies
  • Defender for Endpoint security settings management
  • Group Policy
  • PowerShell
  • Configuration Manager

In the portal workflow shown in the lesson, the policy is created under endpoint security policy settings for Windows devices. Microsoft Intune endpoint security policies can configure attack surface reduction settings for managed devices when Microsoft Defender Antivirus is in use.

A typical policy workflow looks like this:

  1. Go to the Microsoft Defender / security portal.
  2. Navigate to endpoint security policy configuration.
  3. Create a new Windows endpoint security policy.
  4. Select the Attack Surface Reduction Rules profile.
  5. Configure each ASR rule as Off, Audit, Warn, or Block.
  6. Add exclusions only when justified.
  7. Assign the policy to a device group.
  8. Save and allow time for policy sync.
  9. Review ASR events and reports.
  10. Move carefully from Audit to Warn or Block after validation.

Windows, macOS, and Linux Considerations

ASR rules are primarily a Windows endpoint protection capability. Other operating systems may support different Microsoft Defender for Endpoint settings, but the exact same ASR rule templates are not necessarily available across Windows, macOS, and Linux.

For SC-200, remember that when the scenario involves ASR rules such as blocking Office child processes, macro abuse, LSASS credential theft, WMI persistence, or executable content from email, the expected workload is usually Windows endpoints protected by Microsoft Defender for Endpoint.

Important ASR Rule Examples

Block Office Applications from Creating Child Processes

This rule helps prevent Office applications like Word, Excel, PowerPoint, and Outlook from launching suspicious child processes. Attackers frequently abuse Office documents to spawn PowerShell, cmd.exe, wscript.exe, or other tools.

SOC relevance:

  • Useful against phishing attachments and malicious documents.
  • Helps stop macro-based initial access.
  • Can generate alerts or hunting events if Office tries to spawn suspicious processes.

Exam angle:

  • If the scenario involves malicious Office documents launching scripts or command shells, think Defender for Endpoint ASR.

Block Win32 API Calls from Office Macros

This rule targets more advanced macro abuse. A malicious macro may call Windows APIs to download payloads, manipulate memory, or interact with the OS in suspicious ways.

SOC relevance:

  • Reduces risk from macro malware.
  • Supports email-to-endpoint investigation workflows.
  • Can connect Defender for Office 365 phishing detection with Defender for Endpoint device behavior.

Block Executable Content from Email Client and Webmail

This rule helps stop executable payloads launched from email or webmail.

SOC relevance:

  • Useful when phishing is a major initial access vector.
  • Helps reduce malware execution from user-downloaded attachments.
  • Works alongside Defender for Office 365, but it is enforced at the endpoint behavior layer.

Block JavaScript or VBScript from Launching Downloaded Executables

Attackers often use scripts as a first-stage downloader. This ASR rule helps prevent script files from launching downloaded payloads.

SOC relevance:

  • Useful against phishing, drive-by downloads, and script-based malware.
  • Helps reduce initial execution opportunities.

Block Credential Stealing from LSASS

LSASS stores sensitive authentication material. Attackers often attempt to dump LSASS memory to extract credentials.

SOC relevance:

  • Strong defensive control against credential theft.
  • Relevant to lateral movement and privilege escalation investigations.
  • Pairs well with identity investigation in Microsoft Defender XDR.

Exam angle:

  • If the scenario involves credential theft from a Windows endpoint, Defender for Endpoint ASR is highly relevant.

Block Persistence Through WMI Event Subscriptions

WMI can be abused for persistence. An attacker may create event subscriptions that execute malicious commands when certain system events occur.

SOC relevance:

  • Helps prevent stealthy persistence.
  • Useful in post-compromise hardening.
  • Relevant to MITRE ATT&CK persistence techniques.

Block Process Creation from PsExec and WMI Commands

PsExec and WMI are legitimate administrative tools, but attackers also abuse them for lateral movement and remote execution.

SOC relevance:

  • Useful in ransomware containment strategies.
  • May impact legitimate admin workflows.
  • Should be tested before broad enforcement.

Real-world gotcha:

  • Blocking PsExec or WMI process creation without testing can disrupt IT operations, scripts, remote management, or software deployment.

Block Abuse of Exploited Vulnerable Signed Drivers

Attackers sometimes abuse legitimately signed but vulnerable drivers. This rule helps block known abused vulnerable drivers.

SOC relevance:

  • Protects against kernel-level abuse and bring-your-own-vulnerable-driver techniques.
  • Important for endpoint hardening.

Block Web Shell Creation for Servers

Web shells are commonly used after exploiting internet-facing servers. This ASR rule helps reduce the ability to create web shells on servers.

SOC relevance:

  • Especially important for Windows servers hosting web applications.
  • Can support investigation of suspected web server compromise.
  • Useful after exploitation attempts against IIS or other web workloads.

Controlled Folder Access

Controlled Folder Access protects specified folders by preventing untrusted applications from modifying or deleting files. This is commonly associated with ransomware protection.

Important components:

  • Protected folders
  • Allowed applications
  • Audit, block, or off behavior
  • Exclusions for trusted apps or paths

SOC relevance:

  • Helps limit ransomware impact.
  • Requires careful testing to avoid blocking legitimate business applications.
  • Allowed app configuration should be tightly controlled.

ASR Exclusions

ASR exclusions allow administrators to exclude certain files, folders, or paths from ASR enforcement. Microsoft supports global ASR exclusions and per-rule exclusions.

Use exclusions carefully.

Good reasons for an exclusion:

  • A trusted business application is blocked after testing.
  • The app is validated, signed, documented, and required.
  • The exclusion is scoped as narrowly as possible.

Bad reasons for an exclusion:

  • Users complain before investigation.
  • The exclusion is broad, such as an entire user profile or downloads folder.
  • The organization wants to bypass testing.
  • The exclusion is not documented or reviewed.

ASR Reporting

After ASR policies are assigned and devices sync, events can be reviewed in Defender reporting. Microsoft provides an Attack surface reduction rules report in the Microsoft Defender portal that shows detections, device configuration status, and exclusion management.

For analysts, this reporting helps answer:

  • Which ASR rules are firing?
  • Which devices are affected?
  • Which applications would have been blocked?
  • Are there false positives?
  • Which rules are safe to move from Audit to Warn or Block?
  • Are exclusions being overused?
  • Are high-risk behaviors happening repeatedly?

Microsoft Security Operations Context

ASR rules fit into the SOC as both preventive controls and investigation signals.

Triage Workflow

When an ASR-related detection appears, an analyst should determine:

  1. Which rule fired?
  2. Was the rule in Audit, Warn, or Block mode?
  3. Which device was involved?
  4. Which user was logged in?
  5. What file, process, script, or parent process triggered the rule?
  6. Was the activity expected business behavior?
  7. Did the behavior connect to an email, download, USB device, or remote execution tool?
  8. Are other devices showing the same behavior?
  9. Is containment required?
  10. Should the rule be moved toward enforcement?

Investigation Workflow

A SOC analyst may investigate ASR activity by pivoting through:

  • Device timeline
  • Advanced Hunting
  • File entity page
  • User entity page
  • Alert evidence
  • Process tree
  • Email investigation in Defender for Office 365
  • Identity signals in Defender for Identity
  • Related incidents in Microsoft Defender XDR
  • Sentinel incidents if Defender data is connected to Sentinel

Scope and Impact

ASR audit events help determine potential impact before enforcement. For example:

  • If only one non-critical app triggers an ASR rule, enforcement may be low risk.
  • If hundreds of endpoints trigger a rule because of a business-critical app, the rule needs staged testing or a controlled exclusion.
  • If the rule triggers from Office spawning PowerShell on multiple devices, that may indicate phishing or malware activity.

Containment and Remediation

Depending on the finding, response actions may include:

  • Isolate the device in Defender for Endpoint.
  • Collect an investigation package.
  • Quarantine or block a file.
  • Submit the file for analysis.
  • Disable a compromised account.
  • Remove malicious persistence.
  • Block indicators.
  • Create or tune an ASR policy.
  • Add a narrowly scoped exclusion only after validation.
  • Escalate to endpoint engineering, identity, email security, or server teams.

Improving Future Detection

ASR audit data can be used to improve security posture by:

  • Moving tested rules from Audit to Block.
  • Creating exclusions for verified business processes.
  • Identifying risky legacy applications.
  • Creating Defender XDR hunting queries.
  • Creating Sentinel analytics rules if ASR data is ingested.
  • Updating incident response playbooks.
  • Building dashboards for rule adoption and enforcement.

Exam-Relevant Takeaways

  • ASR rules are a Microsoft Defender for Endpoint capability used to reduce risky endpoint behaviors.
  • ASR is mainly associated with Windows endpoint protection.
  • Use Audit mode before enforcement to understand business impact.
  • Use Block mode when you are ready to prevent the behavior.
  • Use Warn mode when users should receive a warning before proceeding.
  • Use exclusions carefully and narrowly.
  • ASR events can be reviewed in Defender reports and Advanced Hunting.
  • ASR events appear in the DeviceEvents table in Microsoft Defender XDR Advanced Hunting.
  • Controlled Folder Access is related to ransomware protection.
  • Standard protection rules are generally safer to enable earlier than more disruptive rules.
  • For endpoint behavior prevention, choose Microsoft Defender for Endpoint, not Sentinel.
  • For centralized SIEM correlation across many data sources, choose Microsoft Sentinel.
  • For policy deployment to managed endpoints, expect Intune endpoint security policies or Defender security settings management.
  • For investigation, pivot from rule event to device, user, process, file, and related incident.

Tool / Feature Decision Guide

ScenarioBest Microsoft Security Tool or FeatureWhy
Block Office from launching PowerShell or cmd.exeMicrosoft Defender for Endpoint ASR ruleASR controls risky endpoint behavior.
Test whether a rule would break business appsASR Audit modeAudit mode records what would have happened without blocking users.
Prevent ransomware from modifying user documentsControlled Folder AccessProtects specified folders from untrusted applications.
Review which ASR rules are triggeringMicrosoft Defender portal ASR rules reportShows detections, configuration status, and exclusion information.
Hunt for ASR events across devicesMicrosoft Defender XDR Advanced HuntingASR events are available in the DeviceEvents table.
Centrally correlate ASR events with firewall, identity, and cloud logsMicrosoft SentinelSentinel is the SIEM/SOAR platform for multi-source correlation.
Deploy ASR policy to managed Windows devicesIntune endpoint security policyIntune can manage endpoint security settings for Defender Antivirus-protected devices.
Allow a trusted business app blocked by ASRASR exclusionExclusions should be narrow, validated, and documented.
Investigate credential theft behavior on a deviceDefender for Endpoint device timeline and ASR eventsLSASS-related ASR rules can help detect or prevent credential theft attempts.
Investigate phishing email that led to endpoint executionDefender for Office 365 + Defender for EndpointEmail investigation shows delivery; endpoint investigation shows execution behavior.
Build a dashboard of ASR activityDefender reporting or Sentinel workbookDefender gives native ASR reporting; Sentinel workbooks help if data is ingested into Sentinel.
Automatically respond to Sentinel incidents created from endpoint dataSentinel automation rule or playbookAutomation rules manage incident automation; playbooks run Logic Apps workflows.

KQL Notes

The transcript does not focus heavily on KQL, but ASR activity can be investigated using Advanced Hunting in Microsoft Defender XDR. Microsoft documents ASR rule events in the DeviceEvents table.

Example: Find ASR Events

DeviceEvents
| where ActionType contains "Asr"
| project Timestamp, DeviceName, ActionType, FileName, FolderPath,
          InitiatingProcessFileName, InitiatingProcessCommandLine,
          AccountName, ReportId
| order by Timestamp desc

What This Query Does

  • DeviceEvents
    Searches endpoint event data in Microsoft Defender XDR.
  • where ActionType contains "Asr"
    Filters for ASR-related events. Exact action names can vary by rule and event type.
  • project
    Selects the most useful columns for triage.
  • order by Timestamp desc
    Shows the newest activity first.

Example: Summarize ASR Activity by Rule Type

DeviceEvents
| where ActionType contains "Asr"
| summarize EventCount = count(), Devices = dcount(DeviceId) by ActionType
| order by EventCount desc

What This Query Does

This query helps identify which ASR rules are firing most often. It is useful during an audit phase because it can show which rules may need more testing before enforcement.

Example: Identify Devices with Repeated ASR Events

DeviceEvents
| where ActionType contains "Asr"
| summarize EventCount = count() by DeviceName, ActionType
| where EventCount > 10
| order by EventCount desc

Investigation Value

This helps find devices repeatedly triggering the same ASR rule. That could indicate:

  • A legitimate app that needs review
  • A misconfigured script
  • A user repeatedly opening malicious content
  • Malware attempting the same behavior multiple times
  • A rule that needs phased deployment or exception handling

Common Exam Traps

Trap 1: Confusing Defender for Endpoint with Sentinel

ASR rules are a Defender for Endpoint endpoint protection feature. Microsoft Sentinel can ingest and correlate security data, but Sentinel is not where ASR rules are primarily enforced.

Trap 2: Blocking Everything Immediately

For exam scenarios involving production users, the safest answer is often to deploy ASR rules in Audit mode first, review impact, then move to enforcement.

Trap 3: Confusing Alerts and Incidents

An ASR event may contribute to an alert or incident, but an alert is a detection and an incident is a grouped investigation container. Defender XDR can correlate multiple alerts into incidents.

Trap 4: Using Broad Exclusions

Broad exclusions weaken protection. If an answer choice excludes large paths like C:\Users\*\Downloads, that is usually risky unless the question specifically justifies it.

Trap 5: Forgetting Business Impact

Some ASR rules can affect legitimate admin tools, Office automation, scripts, or legacy applications. Audit mode and pilot groups reduce the risk of production disruption.

Trap 6: Choosing Email Security for Endpoint Behavior

Defender for Office 365 helps with phishing and malicious email investigation, but ASR enforcement happens on the endpoint through Defender for Endpoint.

Trap 7: Assuming macOS and Linux Have the Same ASR Options

ASR rule coverage is strongest on Windows. Other operating systems may support different Defender settings, but not necessarily the same Windows ASR rule set.

Trap 8: Treating Controlled Folder Access as a Backup

Controlled Folder Access can reduce ransomware impact, but it is not a replacement for backup, disaster recovery, or incident response.

Real-World SOC Analyst Notes

Alert Fatigue

ASR audit data can be noisy during rollout. Analysts should avoid treating every audit event as an incident. Instead, look for patterns:

  • Same rule across many devices
  • Same suspicious parent process
  • Office spawning script interpreters
  • Repeated LSASS access attempts
  • WMI or PsExec behavior outside approved admin systems
  • Activity tied to phishing campaigns

False Positives

False positives are common when deploying prevention controls. Some business applications legitimately use scripts, child processes, or automation. The key is to validate before excluding.

A good false positive review should document:

  • Device name
  • User
  • Rule triggered
  • Process path
  • Command line
  • Business justification
  • Vendor or application owner
  • Risk of allowing the behavior
  • Approved exclusion scope
  • Change record or ticket reference

Evidence Preservation

Before remediating a suspicious endpoint, collect enough evidence to understand what happened. Useful evidence includes:

  • Device timeline
  • Process tree
  • File hash
  • Command line
  • User context
  • Email source if phishing-related
  • Related alerts
  • Network connections
  • Persistence mechanisms
  • Screenshot or export of ASR report details

Escalation Paths

ASR findings may require escalation to different teams:

FindingEscalation Team
Business app blockedEndpoint engineering / application owner
Office macro malwareEmail security and endpoint security
LSASS credential theft attemptIdentity / Active Directory / incident response
WMI persistenceEndpoint security / IR team
Web shell creationServer / web application / cloud team
Ransomware-like behaviorIncident response / infrastructure / backup team
Excessive exclusionsSecurity governance / endpoint architecture

Automation Safety

Do not automatically isolate devices or disable accounts for every ASR audit event. Automation should consider severity, confidence, rule type, asset criticality, and correlation with other evidence.

Good automation candidates:

  • High-confidence ASR block tied to known malware
  • Multiple suspicious ASR events on the same device
  • ASR event plus Defender alert plus malicious file hash
  • ASR event plus risky sign-in or identity alert

Bad automation candidates:

  • Single audit event from a known business app
  • Activity from a known admin tool during a maintenance window
  • Broad response actions without validation

Change Control

Moving ASR rules from Audit to Block should be treated like a production security change. A mature rollout includes:

  1. Pilot group
  2. Audit period
  3. Review of triggered events
  4. Business app validation
  5. Exclusion review
  6. Help desk communication
  7. Change approval
  8. Phased deployment
  9. Post-change monitoring

Cost Considerations

ASR reporting in Defender does not have the same ingestion-cost model as Microsoft Sentinel. However, if Defender data is connected to Sentinel, ingestion and retention choices can affect cost. For SC-200, remember that Sentinel is powerful for correlation and SIEM use cases, but data ingestion volume matters.

Quick Reference Summary

  • ASR stands for Attack Surface Reduction.
  • ASR rules reduce risky endpoint behaviors attackers commonly abuse.
  • ASR is part of Microsoft Defender for Endpoint.
  • Use Audit mode to test rule impact before enforcement.
  • Use Block mode to prevent behavior.
  • Use Warn mode when user warning is appropriate.
  • Standard protection rules are generally safer to enable earlier.
  • ASR exclusions should be narrow and justified.
  • Controlled Folder Access helps protect folders from untrusted app changes.
  • ASR events can be reviewed in Defender reports and Advanced Hunting.
  • In Advanced Hunting, ASR activity can be investigated in DeviceEvents.
  • For endpoint prevention, choose Defender for Endpoint.
  • For SIEM correlation and automation across many sources, choose Sentinel.
  • For deployment, think Intune endpoint security policy or Defender security settings management.
  • For SOC triage, pivot from ASR event to device, user, process, file, and related alerts.

Flashcards

Q: What does ASR stand for?
A: Attack Surface Reduction.

Q: Which Microsoft security product provides ASR rules?
A: Microsoft Defender for Endpoint.

Q: What is the purpose of ASR rules?
A: To reduce risky endpoint behaviors that attackers commonly abuse, such as malicious scripts, Office child processes, credential theft, and ransomware-like activity.

Q: What ASR mode should usually be used before enforcing rules broadly?
A: Audit mode.

Q: What does ASR Audit mode do?
A: It records what would have happened if the rule were enforced, without blocking the activity.

Q: What ASR mode prevents the behavior from occurring?
A: Block mode.

Q: Why should ASR exclusions be used carefully?
A: Exclusions weaken protection and can create bypass paths if they are too broad.

Q: Which ASR-related feature helps protect user folders from ransomware-like modification?
A: Controlled Folder Access.

Q: Where can ASR activity be hunted in Microsoft Defender XDR?
A: In Advanced Hunting, using the DeviceEvents table.

Q: If Office launches PowerShell from a document, which Microsoft feature is most relevant?
A: A Defender for Endpoint ASR rule that blocks Office child process creation.

Q: If you need to correlate ASR events with firewall, identity, and cloud logs, which tool is best?
A: Microsoft Sentinel.

Q: Why are ASR rules important to a SOC analyst?
A: They provide both prevention and investigation signals for endpoint attack techniques.

Q: What is a common risk when enabling ASR Block mode too quickly?
A: Disrupting legitimate business applications, scripts, or administrative tools.

Q: What should an analyst review before moving an ASR rule from Audit to Block?
A: Triggered events, affected devices, process details, business impact, and required exclusions.

Q: What type of attack does blocking LSASS credential theft help prevent?
A: Credential dumping and credential theft from Windows endpoints.

Practice Questions

Question 1:

You are deploying Microsoft Defender for Endpoint ASR rules to a production Windows device group. The security team wants to understand which applications would be affected before blocking any behavior. What should you do first?

A. Configure all ASR rules in Block mode
B. Configure the rules in Audit mode and review the ASR report
C. Disable Defender Antivirus until testing is complete
D. Create broad exclusions for all business application folders

Correct Answer:
B. Configure the rules in Audit mode and review the ASR report

Explanation:
Audit mode allows the organization to see what would have been blocked without disrupting users. This is the safest first step before moving rules to Warn or Block.

Question 2:

A user opens a malicious Word document, and Microsoft Defender detects that Word attempted to launch PowerShell. Which security capability is most directly related to preventing this behavior?

A. Microsoft Sentinel workbook
B. Microsoft Defender for Endpoint Attack Surface Reduction rule
C. Microsoft Entra ID Conditional Access
D. Microsoft Defender for Cloud regulatory compliance dashboard

Correct Answer:
B. Microsoft Defender for Endpoint Attack Surface Reduction rule

Explanation:
ASR rules can block Office applications from creating child processes, which helps stop macro-based malware and phishing payload execution.

Question 3:

You need to investigate ASR rule activity across multiple endpoints using KQL. Which table should you query in Microsoft Defender XDR Advanced Hunting?

A. SigninLogs
B. EmailEvents
C. DeviceEvents
D. SecurityRecommendation

Correct Answer:
C. DeviceEvents

Explanation:
ASR rule events are available in the DeviceEvents table in Microsoft Defender XDR Advanced Hunting.

Question 4:

A business-critical application is blocked by an ASR rule after pilot testing. The application is validated as legitimate. What is the best next step?

A. Disable all ASR rules globally
B. Add a narrowly scoped ASR exclusion for the validated application
C. Remove Defender for Endpoint from the affected devices
D. Move all devices back to Audit mode permanently

Correct Answer:
B. Add a narrowly scoped ASR exclusion for the validated application

Explanation:
A narrowly scoped exclusion preserves the security value of ASR while allowing a verified business process to function.

Question 5:

Your organization wants to correlate ASR events with firewall logs, identity alerts, and cloud activity to create cross-domain incidents. Which Microsoft tool is best suited for this requirement?

A. Microsoft Sentinel
B. Controlled Folder Access
C. Local Group Policy Editor
D. Microsoft Word Trust Center

Correct Answer:
A. Microsoft Sentinel

Explanation:
Microsoft Sentinel is the SIEM/SOAR platform used to correlate data from multiple sources. Defender for Endpoint provides the endpoint ASR telemetry and enforcement, while Sentinel is used for broader correlation and automation.