Skip to content

Advanced Defender Features

💡
Before you start

Python 3 and a terminal. Steps 1–4 run on Linux, macOS or Windows — nothing in them is Windows-specific.

🔴 Nothing malicious is created and nothing is executed. The sample files are inert text that the lab only ever reads. Do not substitute real malicious files.

Step 5 needs Windows, administrator rights, and Defender as the active antivirus. It is the only step that leaves the terminal, and it is reversible — the undo command is given with it.

Controlled Folder Access

Controlled Folder Access is a ransomware protection feature that prevents unauthorized applications from making changes to files in protected folders. When enabled, only applications on the allowed list can write to, modify, or delete files in designated directories.

This is one of the most effective defenses against ransomware. Even if malware manages to execute on your system, it cannot encrypt files in protected folders because the operating system blocks the write attempt at the kernel level.

Enabling Controlled Folder Access

1
Open Windows Security and navigate to Virus & threat protection.
2
Scroll down and click Manage ransomware protection.
3
Toggle Controlled folder access to On.

Via PowerShell (as Administrator):

# Enable Controlled Folder Access
Set-MpPreference -EnableControlledFolderAccess Enabled

# Check current status
Get-MpPreference | Select-Object EnableControlledFolderAccess

Managing Protected Folders

By default, Controlled Folder Access protects the Documents, Pictures, Videos, Music, Desktop, and Favorites folders. You can add additional folders:

# Add a custom protected folder
Add-MpPreference -ControlledFolderAccessProtectedFolders "D:\ImportantData"

# View all protected folders
Get-MpPreference | Select-Object -ExpandProperty ControlledFolderAccessProtectedFolders

Allowing Applications Through

Legitimate applications may be blocked from writing to protected folders. When this happens, you will receive a notification. To allow a specific application:

# Allow an application through Controlled Folder Access
Add-MpPreference -ControlledFolderAccessAllowedApplications "C:\Program Files\MyApp\myapp.exe"

# View allowed applications
Get-MpPreference | Select-Object -ExpandProperty ControlledFolderAccessAllowedApplications
!
Only allow applications you trust.

Every application you add to the allowed list can modify files in all protected folders. If that application is compromised, the protection is bypassed. Only add applications that genuinely need write access to your protected directories.

Exploit Protection

Exploit Protection applies mitigation techniques to individual applications and to the operating system as a whole. These mitigations make it significantly harder for attackers to exploit software vulnerabilities, even when patches are not yet available (zero-day attacks).

System-Level Settings

1
Open Windows Security and go to App & browser control.
2
Click Exploit protection settings at the bottom of the page.
3
The System settings tab shows global mitigations. Each one can be set to On, Off, or Use default.

Key system-level mitigations and what they do:

Control Flow Guard (CFG) Validates indirect call targets at runtime, preventing attackers from redirecting code execution to malicious locations.
Data Execution Prevention (DEP) Marks memory pages as non-executable, preventing code injection attacks from running shellcode in data regions.
Mandatory ASLR Forces address space layout randomization for all processes, making it harder for exploits to predict memory locations.
SEHOP Structured Exception Handler Overwrite Protection prevents attackers from hijacking exception handling chains.
Heap integrity validation Detects heap corruption that could be used for code execution exploits.

Per-Application Settings

The Program settings tab lets you apply or override mitigations for specific executables. This is useful when a system-level mitigation causes compatibility issues with certain software.

# Export current exploit protection settings to XML
Get-ProcessMitigation -RegistryConfigFilePath settings.xml

# Import exploit protection settings from XML
Set-ProcessMitigation -PolicyFilePath settings.xml

# View mitigations for a specific process
Get-ProcessMitigation -Name "chrome.exe"
i
Export your configuration.

After configuring exploit protection settings, export them to an XML file. This allows you to quickly restore your configuration after a Windows reinstall or apply the same settings across multiple machines.

Network Protection

Network Protection extends SmartScreen filtering to all outbound HTTP and HTTPS traffic on the system, not just web browsers. It blocks connections to domains known to host phishing scams, malware distribution, exploit kits, and command-and-control servers.

This is particularly valuable because many malware families communicate with remote servers after initial infection. Network Protection can cut off this communication even if the malware itself evades detection.

Enabling Network Protection

Network Protection is not enabled by default on consumer editions of Windows. You must enable it through PowerShell or Group Policy:

# Enable Network Protection (Block mode)
Set-MpPreference -EnableNetworkProtection Enabled

# Enable in Audit mode (logs events without blocking - good for testing)
Set-MpPreference -EnableNetworkProtection AuditMode

# Disable Network Protection
Set-MpPreference -EnableNetworkProtection Disabled

# Check current status
Get-MpPreference | Select-Object EnableNetworkProtection
Enabled (Block) Actively blocks connections to malicious domains. Users see a notification when a connection is blocked.
AuditMode Logs connections that would have been blocked but does not interrupt them. Use this to test before enforcing.
Disabled No network-level filtering. Only browser-based SmartScreen remains active.
i
Start with Audit Mode.

Enable Audit Mode first and monitor the Windows Event Log for a few days. Check Event Viewer > Applications and Services Logs > Microsoft > Windows > Windows Defender > Operational for Event ID 1125 (audit) and 1126 (block). If legitimate applications are being flagged, investigate before switching to Block mode.

Attack Surface Reduction Rules

Attack Surface Reduction (ASR) rules target specific behaviors commonly used by malware and exploits. Unlike traditional antivirus which looks for known malicious files, ASR rules block suspicious behaviors regardless of whether the file itself is recognized as malicious.

For example, an ASR rule can block Microsoft Office applications from creating child processes. Legitimate Office usage rarely requires this, but macro-based malware relies on it to execute payloads. The rule stops the behavior without needing to know about the specific malware variant.

Important ASR Rules

Block Office apps from creating child processes Prevents malicious macros from launching PowerShell, cmd, or other executables. GUID: d4f940ab-401b-4efc-aadc-ad5f3c50688a
Block Office apps from injecting code into other processes Stops Office applications from using code injection techniques to hide malicious activity. GUID: 75668c1f-73b5-4cf0-bb93-3ecf5cb7cc84
Block JavaScript or VBScript from launching downloaded content Prevents scripts from executing downloaded payloads, a common infection vector. GUID: d3e037e1-3eb8-44c8-a917-57927947596d
Block executable content from email and webmail Prevents execution of executable file types that arrive through email clients. GUID: be9ba2d9-53ea-4cdc-84e5-9b1eeee46550
Block credential stealing from LSASS Protects the Local Security Authority Subsystem Service from credential dumping tools. GUID: 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2

Enabling ASR Rules via PowerShell

# Enable a single ASR rule in Block mode
# Example: Block Office apps from creating child processes
Set-MpPreference -AttackSurfaceReductionRules_Ids d4f940ab-401b-4efc-aadc-ad5f3c50688a -AttackSurfaceReductionRules_Actions Enabled

# Enable in Audit mode (recommended first)
Set-MpPreference -AttackSurfaceReductionRules_Ids d4f940ab-401b-4efc-aadc-ad5f3c50688a -AttackSurfaceReductionRules_Actions AuditMode

# Enable multiple rules at once
Set-MpPreference -AttackSurfaceReductionRules_Ids `
    d4f940ab-401b-4efc-aadc-ad5f3c50688a, `
    75668c1f-73b5-4cf0-bb93-3ecf5cb7cc84, `
    d3e037e1-3eb8-44c8-a917-57927947596d `
    -AttackSurfaceReductionRules_Actions Enabled, Enabled, Enabled

# View current ASR rule status
Get-MpPreference | Select-Object AttackSurfaceReductionRules_Ids, AttackSurfaceReductionRules_Actions
!
Always test ASR rules in Audit mode first.

ASR rules can block legitimate software behaviors. Enable rules in AuditMode, monitor event logs for a week, and only switch to Enabled (Block) once you confirm no false positives affect your workflow. Check Event IDs 1121 (blocked) and 1122 (audited) in the Defender Operational log.

SmartScreen Configuration

Microsoft Defender SmartScreen protects against phishing websites, malicious downloads, and potentially unwanted applications. It works by checking URLs and file hashes against Microsoft's cloud-based reputation database.

SmartScreen for Microsoft Edge

1
Open Windows Security and go to App & browser control.
2
Click Reputation-based protection settings.
3
Configure each SmartScreen option according to your needs.
Check apps and files Checks downloaded files and applications against the SmartScreen database before they run. Recommended: On.
SmartScreen for Microsoft Edge Warns about malicious websites and downloads within the Edge browser. Recommended: On.
Phishing protection Warns when you enter credentials on suspected phishing sites or reuse passwords. Recommended: On (Windows 11 22H2+).
Potentially unwanted app blocking Blocks applications with poor reputation that may include adware, bundleware, or other unwanted software. Recommended: On (both Block downloads and Block apps).
SmartScreen for Microsoft Store Checks content accessed by Microsoft Store apps. Recommended: On.

SmartScreen for Other Browsers

SmartScreen for Microsoft Edge is built in, but other browsers have their own protective systems. Google Chrome and Brave use Google Safe Browsing, and Firefox uses a combination of Google Safe Browsing and its own threat lists. The "Check apps and files" setting in Windows Security still applies system-wide to downloaded executables regardless of which browser downloaded them.

PowerShell Defender Management

PowerShell provides comprehensive access to every Defender setting. This is essential for automation, scripting consistent configurations across machines, and accessing settings not exposed in the Windows Security graphical interface.

Essential PowerShell Commands

# View complete Defender configuration
Get-MpPreference

# View current threat status and statistics
Get-MpComputerStatus

# View detected threats
Get-MpThreat

# View threat detection history
Get-MpThreatDetection

# Remove an active threat (by ThreatID from Get-MpThreat)
Remove-MpThreat

Configuring Protection Levels

# Set cloud protection level (0=Default, 1=Moderate, 2=High, 4=High+, 6=Zero tolerance)
Set-MpPreference -CloudBlockLevel 2

# Set cloud check timeout (seconds to wait for cloud verdict)
Set-MpPreference -CloudExtendedTimeout 50

# Enable Potentially Unwanted Application protection
Set-MpPreference -PUAProtection Enabled

# Enable behavior monitoring
Set-MpPreference -DisableBehaviorMonitoring $false

# Enable scanning of all downloaded files and attachments
Set-MpPreference -DisableIOAVProtection $false

Creating a Security Audit Script

The following script checks the status of all major Defender features and reports any that are not configured optimally:

# Defender Security Audit Script
$status = Get-MpComputerStatus
$prefs = Get-MpPreference

Write-Host "=== Windows Defender Security Audit ===" -ForegroundColor Cyan
Write-Host ""

# Core protection
$checks = @(
    @{ Name = "Antivirus Enabled"; Value = $status.AntivirusEnabled; Expected = $true },
    @{ Name = "Real-time Protection"; Value = $status.RealTimeProtectionEnabled; Expected = $true },
    @{ Name = "Behavior Monitoring"; Value = -not $prefs.DisableBehaviorMonitoring; Expected = $true },
    @{ Name = "IOAV Protection"; Value = -not $prefs.DisableIOAVProtection; Expected = $true },
    @{ Name = "Network Protection"; Value = ($prefs.EnableNetworkProtection -eq 1); Expected = $true },
    @{ Name = "PUA Protection"; Value = ($prefs.PUAProtection -eq 1); Expected = $true },
    @{ Name = "Controlled Folder Access"; Value = ($prefs.EnableControlledFolderAccess -eq 1); Expected = $true }
)

foreach ($check in $checks) {
    $icon = if ($check.Value -eq $check.Expected) { "[OK]" } else { "[!!]" }
    $color = if ($check.Value -eq $check.Expected) { "Green" } else { "Red" }
    Write-Host "$icon $($check.Name): $($check.Value)" -ForegroundColor $color
}

# Signature age
$sigAge = (Get-Date) - $status.AntivirusSignatureLastUpdated
Write-Host ""
if ($sigAge.TotalHours -gt 48) {
    Write-Host "[!!] Signatures are $([math]::Round($sigAge.TotalHours)) hours old" -ForegroundColor Red
} else {
    Write-Host "[OK] Signatures updated $([math]::Round($sigAge.TotalHours)) hours ago" -ForegroundColor Green
}
i
Save this as a scheduled script.

Save the audit script as defender-audit.ps1 and schedule it to run weekly via Task Scheduler. Redirect output to a log file so you can review your security posture over time and catch any settings that have been changed unexpectedly.

Now Do It Yourself: Enable a Rule Without Breaking Someone's Work

Attack Surface Reduction is the most powerful thing on this page and the most commonly abandoned. It is rarely abandoned because it fails to catch attacks — it is abandoned because it caught something legitimate on the first day. In fifteen minutes you can watch that happen, and then watch the mode that prevents it.

You need Python 3. Nothing malicious is created and nothing is executed — the sample files are inert text that is only ever read. Steps 1–4 were run to produce every output below; step 5 is Windows and is marked where it could not be.

1
Make a folder that looks like a real workplace

Go: a terminal — Linux, macOS, or PowerShell on Windows. mkdir asrlab then cd asrlab.

Do: save this as files.sh and run it with sh files.sh. It creates four harmless text files standing in for what an Attack Surface Reduction rule inspects — two that look malicious, one that is legitimate IT work, and one ordinary note:

mkdir -p sample_files && cd sample_files
printf 'Set objShell = CreateObject("WScript.Shell")\nobjShell.Run "powershell -enc SQBFAFgA"\n' > invoice_macro.doc.vbs
printf 'Sub AutoOpen()\n  CreateObject("WScript.Shell").Run "cmd /c echo hi"\nEnd Sub\n' > quarterly_report.docm
printf 'Set objShell = CreateObject("WScript.Shell")\nobjShell.Run "\\\\fileserver\\deploy\\install.bat"\n' > it_deploy_script.vbs
printf 'Dear team,\nPlease find the quarterly numbers attached.\n' > covering_note.txt
ls -1

You should see: four files:

covering_note.txt
invoice_macro.doc.vbs
it_deploy_script.vbs
quarterly_report.docm

None of these does anything — they are text. Nothing runs them.

Look at it_deploy_script.vbs in particular. It launches a shell, exactly like the malicious pair, because that is genuinely its job. Remember it.

If not: on Windows PowerShell, sh is unavailable — create sample_files and the four files in Notepad instead, with Save as type set to All Files so nothing gains a hidden .txt.

2
Write one ASR rule and switch it straight on

Go: the same folder.

Do: save this as asr.py. It models a single ASR rule — block files that launch a shell — with the two modes Defender offers:

import sys, pathlib

# One Attack Surface Reduction rule, modelled: "block Office-style files from
# launching a shell". Real ASR rules watch process behaviour; the shape is the same.
RULE = "ASR: file launches a shell process"
TRIGGER = b"CreateObject(\"WScript.Shell\")"

mode = sys.argv[1] if len(sys.argv) > 1 else "audit"
if mode not in ("audit", "block"):
    sys.exit("usage: asr.py [audit|block]")

blocked = flagged = allowed = 0
for path in sorted(pathlib.Path("sample_files").iterdir()):
    hit = TRIGGER in path.read_bytes()
    if hit and mode == "block":
        print(f"  BLOCKED  {path.name:<26} {RULE}")
        blocked += 1
    elif hit:
        print(f"  WOULD BLOCK  {path.name:<22} {RULE}")
        flagged += 1
    else:
        print(f"  allowed  {path.name:<26}")
        allowed += 1

print()
if mode == "block":
    print(f"mode=block  {blocked} file(s) stopped, {allowed} allowed. Users feel this immediately.")
else:
    print(f"mode=audit  {flagged} file(s) WOULD have been stopped, {allowed} allowed. Nothing broke.")

Run it the way most people first enable ASR, in enforcing mode:

python3 asr.py block

You should see: three files stopped:

  allowed  covering_note.txt         
  BLOCKED  invoice_macro.doc.vbs      ASR: file launches a shell process
  BLOCKED  it_deploy_script.vbs       ASR: file launches a shell process
  BLOCKED  quarterly_report.docm      ASR: file launches a shell process

mode=block  3 file(s) stopped, 1 allowed. Users feel this immediately.

Two of those three were the point of the rule. The third was your deployment script, and it stopped working the moment the rule went on — with no warning and no list of what it would affect.

If not: FileNotFoundError: 'sample_files' means step 1 did not run — check the folder exists with ls.

3
Run the identical rule without breaking anything

Go: the same folder.

Do: switch the mode. Nothing else changes — same rule, same files:

python3 asr.py audit

You should see: the same three detections, and every file still working:

  allowed  covering_note.txt         
  WOULD BLOCK  invoice_macro.doc.vbs  ASR: file launches a shell process
  WOULD BLOCK  it_deploy_script.vbs   ASR: file launches a shell process
  WOULD BLOCK  quarterly_report.docm  ASR: file launches a shell process

mode=audit  3 file(s) WOULD have been stopped, 1 allowed. Nothing broke.

🔴 Audit mode gave you the same information at none of the cost. You now know your deployment script would break before anyone is standing at your desk about it — so you can exclude it, or change it, and then enforce.

This is the difference between ASR being useful and ASR being switched off in week two. Almost every organisation that abandons a security control abandons it because it was enforced before it was measured.

If not: if the output is identical to step 2, you passed block again — the argument is the mode, and with none it defaults to audit.

4
Decide what the exception should be

Go: the audit output.

Do: you have one legitimate detection. Consider the two ways to resolve it: exclude that file from the rule, or change the script so it no longer launches a shell.

You should see: no command — this step is the judgement the tooling cannot make for you.

An exclusion is faster and permanent, and it is a hole: anything placed at that path is exempt from then on, which is precisely why attackers look for exclusion lists. Fixing the script is slower and removes the exception entirely.

The honest rule of thumb: exclude a specific file, never a folder, and write down why — because in a year nobody will remember, and an exclusion nobody can explain never gets removed.

If not: if you cannot tell which detection is the legitimate one, that is the real finding: you cannot safely enforce a rule over files you do not recognise. Audit for longer.

5
Do it on real Defender, in audit first

Go: a Windows PowerShell window opened as Administrator.

Do: put one real ASR rule into audit mode — this GUID is Microsoft's “block Office applications from creating child processes”:

Add-MpPreference -AttackSurfaceReductionRules_Ids D4F940AB-401B-4EFC-AADC-AD5F3C50688A -AttackSurfaceReductionRules_Actions AuditMode

You should see: no output on success. Detections then appear in Event Viewer under Applications and Services Logs → Microsoft → Windows → Windows Defender → Operational, and nothing is blocked.

Not re-run for this page — PowerShell is Windows-only and this page was written on Linux. The cmdlet and GUID are from Microsoft's published ASR rule list. Steps 1–4 were run.

Leave it in audit for a week or two of ordinary work, read what it caught, then change AuditMode to Enabled once you recognise every detection. Enabling it directly is the same as running step 2 first — and you have now seen what that costs.

If not: Add-MpPreference is not recognized means Command Prompt rather than PowerShell, or a third-party antivirus has displaced Defender. To undo the rule entirely: Remove-MpPreference -AttackSurfaceReductionRules_Ids D4F940AB-401B-4EFC-AADC-AD5F3C50688A.

🎉
Check yourself before moving on

A colleague enables three ASR rules in Block mode on Friday afternoon. On Monday, two teams cannot work and the rules are switched off before lunch. Nothing was misconfigured. What went wrong? Answer: The rules were enforced before anyone measured what they would catch. Audit mode would have produced exactly the same list of detections with nothing broken, and the two legitimate cases could have been excluded or fixed first. The rules were probably correct — the deployment was not.

Now do it without the page: pick one ASR rule from Microsoft's list, put it in audit mode on your own machine, and read the Defender Operational log a week later. If you can explain every detection it produced, you are ready to enforce that rule — and if you cannot, you have just learned something you could not have read.

Summary

In this tutorial, you learned how to configure advanced Defender features:

  • Controlled Folder Access to protect against ransomware encrypting your files
  • Exploit Protection mitigations to harden the OS and individual applications
  • Network Protection to block malicious domain connections system-wide
  • Attack Surface Reduction rules to prevent common malware behaviors
  • SmartScreen configuration for reputation-based protection
  • PowerShell commands for comprehensive Defender management and auditing
+
Excellent work!

With these advanced features enabled, your Windows system has multiple layers of protection beyond basic antivirus scanning. Next, explore the Windows Firewall tutorials to learn how to control network access to and from your computer.