7.4 EDR and Automated Investigation Configuration

75 minutes · Module 7

EDR and Automated Investigation Configuration

By the end of this subsection, you will know how to configure EDR in block mode, set the correct automated investigation level, and create custom indicators that operationalize your investigation findings.

EDR in block mode

Standard EDR detects and alerts. EDR in block mode goes further — it automatically quarantines malicious files and terminates malicious processes without waiting for analyst approval. This is separate from ASR rules (which prevent behaviors before execution) and from AIR (which investigates and remediates alert chains).

When to enable: Organizations with mature SOC processes, confidence in Defender detection accuracy, and tolerance for occasional false-positive remediation.

When to keep disabled: Critical infrastructure (manufacturing, medical devices, trading systems) where an automated file quarantine could cause operational disruption. In these environments, false-positive risk outweighs speed benefit.

Automated Investigation and Response (AIR)

When Defender raises an alert, AIR automatically investigates: identifying scope, related entities, impacted files, and affected devices. The automation level determines whether AIR takes remediation actions or waits for human approval.

Level	Behavior	Best for	Risk
No automated response	Alerts only, no investigation	Not recommended	Wastes analyst time on every alert
Semi — require approval for all	AIR investigates, proposes actions, waits for approval	Most organizations (default choice)	None — human reviews every action
Semi — require approval for non-temp folders	Auto-remediates in temp/downloads, waits for system folders	Moderate maturity, after 90+ days on full semi	Low — temp folders rarely contain critical files
Full automation	AIR investigates and remediates without human approval	High-volume environments, mature SOC, 90+ days of data	False positive auto-remediation

Start with semi-auto, upgrade with data

Semi-auto (require approval for all) is the correct default. Run it for 90+ days. Track the false positive rate. If every remediation recommendation is approved and no false positives occur, consider advancing to the next level. Do not skip to full automation on day one — you do not have the data to justify the risk.

Custom indicators — operationalize investigation findings

Custom indicators tell Defender to alert on, block, or allow specific files, IPs, URLs, and certificates across all onboarded devices. This is how investigation findings become automated protection.

Indicator type	Example from Module 13	Action	Scope
IP address	203.0.113.45 (attacker token replay IP)	Alert and block	All devices — any connection attempt generates alert
URL/domain	northgate-voicemail.com (phishing domain)	Alert and block	All devices — DNS request blocked
URL pattern	/auth/[a-f0-9]{32}/login (kit URL path)	Alert and block	All devices — catches the kit across new domains
File hash	SHA-256 of malware sample	Alert and block	All devices — file quarantined on detection
Certificate	Code signing cert used by attacker tool	Alert and block	All devices — signed executables using this cert blocked

1
2
3
4
5
6
7
8
// Find connections to your blocked indicators in the last 7 days
DeviceNetworkEvents
| where TimeGenerated > ago(7d)
| where RemoteUrl has_any ("northgate-voicemail.com", "northgate-docs.com")
    or RemoteIP == "203.0.113.45"
| project TimeGenerated, DeviceName, RemoteUrl, RemoteIP, RemotePort,
    InitiatingProcessFileName, ActionType
| sort by TimeGenerated desc

Expected Output — After Indicator Deployment

TimeGenerated	DeviceName	RemoteUrl	ActionType	InitiatingProcess
14:22	DESKTOP-NGE042	northgate-voicemail.com	ConnectionBlocked	chrome.exe

What to look for: ConnectionBlocked confirms the indicator is working — the user attempted to visit the phishing domain (possibly from a cached email) and Defender blocked the connection. Without the indicator, this connection would have succeeded and potentially led to a second compromise. Every investigation should produce indicators. Investigations that do not produce operational defenses are incomplete.

Live Response

Live response opens a remote command-line shell to a device from the Defender portal. No RDP, no VPN, no network line-of-sight required — the session routes through the Defender cloud service.

Key capabilities:

Command	What it does	When to use
`processes`	List all running processes with PID, name, path	Identify suspicious processes during active investigation
`connections`	List active network connections	Find C2 connections, data exfiltration channels
`fileinfo [path]`	Get file metadata, hash, and digital signature	Verify a suspicious file before collection
`getfile [path]`	Download file from device to investigation portal	Collect malware samples, evidence files
`run [script]`	Execute a pre-uploaded PowerShell script	Run forensic collection scripts, evidence gathering
`remediate file [path]`	Quarantine a specific file	Remove malware or attacker tools

Restrict live response to Tier 2+ analysts

Live response executes commands directly on production devices. A mistyped remediate command on the wrong file path can delete critical system files. A run command with an incorrect script can crash a service. Restrict the "Advanced live response" permission to experienced analysts. Tier 1 analysts investigate via the device timeline (subsection 7.5) and escalate when live response is needed.

Check your understanding

1. After the Module 13 AiTM investigation, you have 5 phishing domains and 1 attacker IP. What should you do with them in Defender?

Create custom indicators: alert-and-block for all 5 domains and the attacker IP. Any device that attempts to connect generates an alert and is blocked. This turns investigation IOCs into automated protection across your entire fleet.

Email the IOCs to the team

Add them to a spreadsheet

Custom indicators close the loop from investigation to prevention. Every investigation should produce indicators. Sharing IOCs by email or spreadsheet is a communication step, not a defense step. Deploy them as indicators for automated, fleet-wide protection.

2. Semi-auto AIR has run for 30 days with 0 false positives. Should you switch to full automation?

Yes — zero FPs proves safety

Never — always require human approval

Not yet — 30 days is too short. Low-frequency false positives may not appear in this window. Wait 90+ days and assess whether your environment can tolerate automated remediation of a rare FP.

Sample size matters. 30 days may not include the rare edge case that causes a damaging false positive. 90 days across varying threat activity gives much higher confidence.

← 7.3 Attack Surface Reduction (ASR) Rules 7.5 The Device Investigation Page →