Agent Foskett Academy • Defender for Endpoint • Module 4 • Lesson 19

Lesson 19 — Attack Surface Reduction Basics

Attack Surface Reduction rules help prevent risky software behaviours that attackers commonly abuse, including malicious Office activity, scripts, credential theft techniques and living-off-the-land execution.

ASR rules are part of Microsoft Defender Antivirus and can be configured in modes such as Audit, Warn and Block, depending on the rule and supported environment.

This lesson explains how ASR works, how to plan a controlled rollout, how to review audit data and how to avoid disrupting legitimate business activity.

ASR is prevention, not guesswork. Test broadly, review the evidence and enforce deliberately.

Start Lesson Back to Defender for Endpoint Academy

Agent Foskett Microsoft Defender for Endpoint Attack Surface Reduction Basics lesson

What you will learn

This lesson introduces the planning, testing and enforcement principles behind Microsoft Defender ASR rules.

What ASR rules prevent

Audit, Warn and Block modes

Safe deployment rings and exclusions

Monitoring and investigation workflow

Learning objectives

After completing this lesson, you should be able to plan and evaluate a basic ASR deployment.

Explain the purpose of Attack Surface Reduction rules.
Recognise common risky behaviours targeted by ASR.
Differentiate Audit, Warn and Block modes.
Plan a staged rollout using deployment rings.
Review events, exclusions and enforcement results.

The problem this solves

Many attacks rely on legitimate applications and built-in tools rather than an obviously malicious executable.

ASR rules reduce those opportunities by constraining behaviours such as Office child-process creation, script abuse, executable content from email and credential theft techniques.

What is Attack Surface Reduction?

Attack Surface Reduction is a collection of Microsoft Defender Antivirus rules designed to block or monitor risky software behaviour commonly used during malware and hands-on-keyboard attacks.

ASR does not wait for every file to be identified as malware. It can prevent an application or process from performing a dangerous behaviour even when the originating file appears legitimate.

Risky software behaviour │ ├── Office creates a child process ├── Script launches downloaded content ├── Process attempts credential theft ├── Email delivers executable content └── Trusted tool is abused │ ▼ ASR rule evaluates │ ├── Audit ├── Warn └── Block

Agent Foskett tip:

ASR focuses on behaviour. That makes it valuable against attacks that abuse trusted applications and built-in Windows tools.

Why ASR matters

Reduces opportunities for malware to execute.
Constrains common Office and script attack paths.
Limits abuse of trusted Windows components.
Helps protect credentials and sensitive processes.
Provides additional prevention beyond file reputation.

Layered endpoint protection

Defender Antivirus detects malicious content.
ASR restricts risky behaviour.
EDR records and detects suspicious activity.
Defender for Endpoint supports investigation and response.
Vulnerability management reduces exploitable weaknesses.

Examples of ASR rules

Analysts do not need to memorise every rule. The important skill is understanding which attack behaviour a rule is intended to reduce.

Example rule	Attack path it reduces
Block Office applications from creating child processes	Prevents Word, Excel and other Office applications from launching tools such as PowerShell or command interpreters.
Block Office applications from creating executable content	Reduces payload creation and staging from Office documents.
Block executable content from email client and webmail	Reduces execution of files delivered through common phishing channels.
Block Win32 API calls from Office macros	Restricts macros from calling Windows APIs that can support malicious behaviour.
Block credential stealing from LSASS	Helps prevent processes from accessing credential material in the Local Security Authority process.
Block process creations originating from PSExec and WMI commands	Reduces remote process creation techniques often used for lateral movement.

Audit mode

Audit mode records when a rule would have triggered without preventing the activity.

It helps security teams measure prevalence, identify business dependencies and understand potential disruption before enforcement.

Warn mode

Warn mode can present a user-facing warning for supported rules and scenarios while providing a less abrupt transition toward enforcement.

Support and user experience vary by rule, platform and management configuration, so deployment should be validated carefully.

Rule modes compared

Mode	What happens	Typical use
Audit	The behaviour is recorded but not prevented.	Initial testing, impact assessment and tuning.
Warn	The user may receive a warning and limited override experience where supported.	Controlled transition when the rule and platform support it.
Block	The targeted behaviour is prevented.	Production enforcement after validation.
Disabled or not configured	The rule does not enforce or audit the behaviour through that policy.	Rules not yet selected or intentionally excluded from the rollout.

Do all rules start in Audit?

Audit-first is a strong general approach for rules that can affect business applications.

Microsoft identifies standard protection rules that may be suitable for faster enablement, but organisations should still assess their own devices, workloads and risk tolerance.

Prerequisites matter

ASR rules depend on Microsoft Defender Antivirus and supported Windows configurations.

Cloud-delivered protection, platform health, licensing and management capabilities can affect reporting and enforcement, so validate the environment before rollout.

Recommended deployment approach

1. Inventory devices and critical applications 2. Confirm Defender Antivirus health and cloud protection 3. Select rules based on threat and business priorities 4. Deploy to a small test ring 5. Use Audit mode where appropriate 6. Review events and investigate false positives 7. Create narrowly scoped approved exclusions 8. Move a pilot group to Warn or Block 9. Expand through additional deployment rings 10. Monitor continuously after enforcement

Deployment principle:

Do not treat ASR as one organisation-wide switch. Treat each rule as a controlled security change with its own evidence, owner and rollout decision.

Deployment rings

Security or IT test devices.
Technical pilot users.
General business users.
High-risk or privileged users.
Critical servers and specialised devices.

Deployment methods

Microsoft Intune endpoint security policies.
Microsoft Defender security settings management where supported.
Group Policy.
Microsoft Configuration Manager.
PowerShell for controlled testing or local management.

Before moving to Block

Confirm the rule is reaching the intended devices.
Review audit events over a representative business period.
Identify affected applications, scripts and workflows.
Investigate whether triggered activity is legitimate or risky.
Engage application and business owners.
Test required exclusions with a narrow scope.
Document rollback and support procedures.
Obtain approval for the enforcement change.

Global exclusions

Global ASR exclusions can apply across multiple rules and therefore have broad impact.

They should be used sparingly because one excluded path or file can bypass protections provided by more than one rule.

Rule-specific exclusions

Rule-specific exclusions apply to an individual ASR rule where supported by the selected management method.

They are generally preferable when a business exception applies to one behaviour but should not weaken unrelated rules.

Exclusion governance

Control	Good practice
Business justification	Record why the exclusion is required and which workflow depends on it.
Scope	Use the narrowest path, file, device group and rule possible.
Owner	Assign an application or service owner responsible for future review.
Expiration	Set a review date and remove temporary exclusions when no longer required.
Validation	Confirm the exception fixes the business issue without creating an unnecessary bypass.

Where ASR activity appears

Microsoft Defender portal reports.
Device timeline events.
Alerts and incidents where applicable.
Advanced Hunting telemetry.
Local Microsoft Defender operational events.

What to investigate

The application that triggered the rule.
The initiating process and command line.
The user and device involved.
The file, script or destination involved.
Whether the activity is expected business behaviour.

ASR investigation workflow

ASR event appears │ ├── Confirm rule and configured mode ├── Identify device and user ├── Review initiating process and command line ├── Check file, signer, hash and prevalence ├── Review device timeline ├── Hunt for similar events across devices └── Decide: malicious, legitimate, misconfiguration or exception

Audit events are security data

An audit event is not merely a deployment warning.

It can reveal risky Office behaviour, scripts, remote execution or credential-access attempts that deserve investigation even before the rule moves to Block mode.

Blocked events still need review

A successful block may prevent one stage of an attack, but it does not explain how the file arrived or whether other techniques succeeded.

Review the full incident, device timeline and related identity activity before closing the case.

Example investigation

1. A user opens a malicious Word document 2. The document attempts to launch PowerShell 3. The Office child-process ASR rule blocks the action 4. Defender records the event and creates investigation context 5. The analyst reviews the document, process tree and command line 6. Advanced Hunting checks for the same file and behaviour elsewhere 7. Email telemetry identifies the original phishing message 8. The message and related payloads are removed 9. No successful payload execution is found 10. The incident is documented and the rule remains enforced

Agent Foskett investigation principle:

The block stopped the process. The investigation explains the attack.

ASR and legitimate software

Some line-of-business applications, macros, deployment tools and administrative scripts may use behaviours targeted by ASR.

That does not make the rule unsuitable. It means the dependency must be understood, redesigned where possible or handled through a controlled exception.

ASR is not a replacement

ASR complements Microsoft Defender Antivirus, EDR, application control, vulnerability management and user security controls.

No single ASR rule can prevent every attack technique or compensate for weak identity, patching and application governance.

Common mistakes

Mistake	Why it creates risk	Better practice
Enabling every rule in Block immediately	Legitimate business workflows may be interrupted without preparation.	Use staged testing, deployment rings and evidence-based enforcement.
Ignoring Audit events	Potential attacks and business dependencies remain unexplored.	Review audit telemetry and classify recurring activity.
Creating broad exclusions	Large paths or trusted locations can become protection gaps.	Use the narrowest rule-specific exception possible.
Never reviewing enforced rules	Changes in applications and attacker behaviour can reduce effectiveness.	Monitor trends, blocked events, exceptions and device coverage continuously.

Key takeaways

ASR rules constrain risky software behaviours commonly used by attackers.
ASR is a Microsoft Defender Antivirus prevention capability.
Audit mode helps measure impact before enforcement.
Warn and Block should be deployed according to rule support and business testing.
Use deployment rings and narrowly scoped exclusions.
Investigate both audit and blocked events in their wider incident context.

Related Agent Foskett resources

Continue developing endpoint prevention, investigation and response skills with these connected resources.

Lesson 18 — Antivirus Scan and Remediation Actions Lesson 17 — Collect Investigation Package Lesson 16 — Indicators Lesson 15 — Device Isolation Building a Device Timeline Investigating DeviceProcessEvents Hunting LOLBins Microsoft Security Services

Continue learning

Continue through Module 4 — Endpoint Hardening & Exposure Management, or return to the wider Defender for Endpoint Academy learning path.

⬅ Previous lesson

Lesson 18 — Antivirus Scan and Remediation Actions Review quick and full scans, remediation outcomes, Action center monitoring and post-scan validation.

🏠 Academy home

Defender for Endpoint Academy Continue through Module 4 — Endpoint Hardening & Exposure Management and the wider learning path.

📘 Next lesson

Lesson 20 — Threat and Vulnerability Management Identify vulnerable software, exposed devices, missing patches and security weaknesses using Microsoft Defender Vulnerability Management.

Microsoft Defender Attack Surface Reduction Rules

Microsoft Defender Attack Surface Reduction rules help prevent risky software behaviour involving Office applications, scripts, credential theft, executable content and commonly abused system tools.

Module 4 Endpoint Hardening — Attack Surface Reduction Basics Lesson 19

This Agent Foskett Defender for Endpoint Academy lesson explains Audit, Warn and Block modes, deployment rings, exclusions, monitoring and safe ASR enforcement.