1.1 Defender for Endpoint

60–90 minutes · Module 1 · Free

Defender for Endpoint is an endpoint detection and response (EDR) platform for Windows, macOS, Linux, iOS, and Android. It is not just antivirus. It is a full sensor platform that captures device telemetry, detects threats, enables investigation, and supports automated response. Think of it as the eyes on the device — everything happening on a workstation or server flows through Defender for Endpoint.

Figure 1.1: Defender for Endpoint components and the data tables they populate in Advanced Hunting.

Core components

Endpoint Sensor. A lightweight agent built into Windows 10/11 and Server 2016+. On macOS and Linux it is deployed as a separate package. The sensor captures process creation, network connections, file activity, registry changes, and more. This sensor is what populates the Device* tables in advanced hunting — the tables you will query in almost every investigation module.

Threat and Vulnerability Management (TVM). Continuous vulnerability assessment of every onboarded device. It identifies missing patches, insecure configurations, and software vulnerabilities without requiring a separate scanning tool. The output feeds into the DeviceTvmSoftwareVulnerabilities table and into the Exposure Management dashboard (covered in Module 12).

Attack Surface Reduction (ASR) Rules. Preventive controls that block specific high-risk behaviours: Office macro execution, credential stealing from LSASS, executable content from email attachments. These are not detections — they are active blocks configured as policies.

Why ASR rules matter

When properly tuned, ASR rules stop entire categories of attack before any investigation is needed. A rule blocking Office macros from creating child processes eliminates a huge portion of the malware delivery chain. Module 7 covers ASR rule configuration and tuning in detail.

Endpoint Detection and Response (EDR). The investigation engine. EDR captures a rolling 30-day device timeline showing every process, network connection, file event, and registry modification. This timeline is what analysts use to reconstruct what happened on a compromised device. When you need to know exactly which process ran cmd.exe /c whoami at 14:32 on a Tuesday, the device timeline is where you look.

Automated Investigation and Response (AIR). When an alert fires, AIR can automatically investigate the alert, determine scope, and take remediation actions — quarantine a file, isolate a device — subject to analyst approval or configured for full automation.

Device Isolation. A containment capability that cuts a device’s network access while maintaining the management channel to Defender. Used during active incidents to prevent lateral movement. You will use this in the ransomware pre-encryption scenario (Module 17).

Key data tables for investigation

DeviceProcessEvents — every process execution
DeviceNetworkEvents — every network connection
DeviceFileEvents — file creation, modification, deletion
DeviceRegistryEvents — registry changes
DeviceLogonEvents — local and remote logons
DeviceEvents — catch-all for other device activity
DeviceInfo — device inventory and properties

How it connects to the ecosystem

Alerts feed into the Defender XDR unified incident queue. Data tables are queryable in Defender XDR advanced hunting and in Sentinel via the M365 Defender connector. Device isolation can be triggered manually, via AIR, or via Sentinel playbooks. TVM findings feed into Exposure Management (Module 12).

Licensing

Tier	What you get	Included in
P1	Basic threat protection, ASR rules, manual response	M365 E3, Business Premium
P2	Full EDR, device timeline, advanced hunting, AIR, TVM	M365 E5 (or add-on)

Key takeaways

Defender for Endpoint is an EDR platform, not just antivirus — it captures a full device timeline for investigation
The Device* tables are the primary data source for endpoint investigation in KQL
ASR rules are preventive controls that block attack behaviours before detection is needed
Device isolation is a critical containment action during active incidents
P2 is required for the full investigation capabilities used in this course

Try it yourself

If you have access to a Defender XDR tenant, open Advanced Hunting and run this query. If not, think through what the output would look like before revealing the answer.

1
2
3
4
5
DeviceInfo
| where TimeGenerated > ago(1d)
| summarize arg_max(TimeGenerated, *) by DeviceId
| project DeviceName, OSPlatform, OnboardingStatus, RiskScore
| sort by RiskScore desc

This query returns the latest record for each device onboarded to Defender for Endpoint, showing the device name, operating system, onboarding status, and risk score — sorted by the highest risk devices first. In a real environment, you would use this as a starting point to identify devices that need attention. The arg_max function picks the most recent row per device, avoiding duplicates.

Check your understanding

1. What is the primary difference between ASR rules and EDR?

ASR rules detect threats; EDR prevents them

ASR rules prevent high-risk behaviours before execution; EDR detects and investigates threats after they occur

They are the same feature with different names

ASR rules are preventive — they block specific behaviours (like Office macros spawning child processes) before they execute. EDR is detective — it captures what happened on the device for investigation after the fact. Both are essential but serve different purposes.

2. Which data table would you query to find every process that executed on a specific device?

DeviceProcessEvents

DeviceNetworkEvents

DeviceEvents

DeviceProcessEvents captures every process execution — the process name, command line, parent process, user, and timestamp. This is the table you will query most when reconstructing what happened on a compromised device.

← 1.2 Defender for Office 365