Microsoft Defender for Endpoint Settings, Device Groups, Indicators, and Detection Tests – SC-200 Study Guide

Study guide

Technical reference and lesson notes

Purpose of This Lesson

This lesson introduces the major configuration areas inside Microsoft Defender for Endpoint as managed from the Microsoft Defender portal. The focus is not on mastering every setting individually, but on understanding where endpoint security settings live, what they control, and how they support security operations.

For the SC-200: Microsoft Security Operations Analyst exam, this topic matters because Defender for Endpoint is one of the core Microsoft security products used for endpoint detection, investigation, response, and vulnerability of the core Microsoft security products used for endpoint detection, investigation, response, and vulnerability visibility. A SOC analyst needs to understand how endpoint alerts are generated, how devices are grouped, how indicators are used, how alert notifications work, and how Defender for Endpoint integrates with other Microsoft security tools such as Microsoft Intune, Microsoft Purview, Microsoft Defender for Cloud Apps, and SIEM platforms.

This lesson also demonstrates how to run a built-in Defender for Endpoint detection test using PowerShell, then review the resulting alert, incident, device, user, evidence, and MITRE ATT&CK mapping.

Key Concepts

Microsoft Defender for Endpoint in the Microsoft Defender Portal

Microsoft Defender for Endpoint settings are managed from the Microsoft Defender portal.

A typical navigation path is:

portal.microsoft.com → Security → Settings → Endpoints

From the Endpoints settings area, administrators can configure endpoint-specific options such as:

Advanced endpoint settings
Licenses
Email notifications
Role-based access control
Device groups
SIEM integration
Alert suppression
Indicators
Enforcement scope
Onboarding
Offboarding

For SC-200, the important point is that Defender for Endpoint is not just an antivirus console. It is an endpoint security platform used for alerting, investigation, response, device inventory, vulnerability visibility, and integration with broader Microsoft security operations.

Advanced Settings in Defender for Endpoint

The Advanced settings area contains tenant-wide or endpoint-wide options that influence how Defender for Endpoint behaves.

Examples include:

Incident correlation behavior
File allow/block features
Defender for Cloud Apps integration
Web content filtering
Sharing endpoint alerts with Microsoft Purview
Authenticated telemetry
Microsoft Intune connection
Preview features

These settings affect how alerts are enriched, how endpoints are managed, and how Defender for Endpoint integrates with the rest of the Microsoft security ecosystem.

Restrict Correlation to Scoped Device Groups

One setting discussed is the ability to restrict incident correlation within scoped device groups.

When enabled, alerts are correlated into separate incidents based on the device group scope. This matters in environments where different teams manage different device populations.

For example:

A corporate security team may manage all endpoints.
A regional IT team may only manage devices in a specific office.
A managed service provider may support multiple customers or business units.
A highly regulated business unit may need separate incident boundaries.

In a SOC workflow, this can help separate incidents by ownership or operational scope. However, it can also create fragmented visibility if configured poorly.

Allow or Block a File

Defender for Endpoint can allow or block files using file indicators. This feature depends on Microsoft Defender Antivirus and cloud-based protection being enabled.

This is important because blocking a file is an endpoint response action. It can be useful when a known malicious file hash is identified during an investigation.

Example use case:

A SOC analyst confirms that a malicious executable is present on one endpoint. The analyst can use an indicator to block that file from running across managed devices, assuming the proper Defender features are enabled.

Microsoft Defender for Cloud Apps Integration

Defender for Endpoint can integrate with Microsoft Defender for Cloud Apps. This connection helps bridge endpoint activity with cloud application activity.

This matters when investigating scenarios involving:

Suspicious browser activity
Shadow IT usage
Risky cloud application access
Data movement from endpoints to cloud services
Session or app governance scenarios

For the exam, remember that Defender for Endpoint focuses on endpoint activity, while Defender for Cloud Apps focuses on SaaS and cloud app usage. Integration improves investigation context.

Web Content Filtering

Web content filtering can be used to block access to certain categories of websites.

From a security operations perspective, this can help reduce exposure to risky web categories, malicious destinations, or policy-violating sites.

This is not the same as investigating an alert. It is a preventive control that can reduce risk before an alert occurs.

Sharing Endpoint Alerts with Microsoft Purview

The transcript references sharing endpoint alerts with Microsoft’s compliance center, which is now associated with Microsoft Purview.

This matters because some endpoint security events may also be relevant to compliance, insider risk, data loss prevention, or audit workflows.

For SC-200, understand the distinction:

Microsoft Defender XDR / Defender for Endpoint: security detection and response
Microsoft Purview: compliance, data governance, eDiscovery, insider risk, audit, and DLP

There is overlap in real investigations, but the tools serve different primary purposes.

Authenticated Telemetry

Telemetry is the data Defender for Endpoint collects from endpoints to support detection, investigation, and threat analytics.

Authenticated telemetry helps Microsoft and the tenant trust the source of endpoint security data.

In plain English, telemetry is the security signal coming from devices. Without telemetry, the SOC has limited visibility.

Microsoft Intune Connection

The Microsoft Intune connection allows Defender for Endpoint and Intune to work together.

This matters because Intune is Microsoft’s endpoint management platform for mobile device management and mobile application management.

Common integration benefits include:

Device compliance decisions
Security baseline enforcement
Endpoint security policy deployment
Conditional Access signals
Defender-driven device risk reporting
Security configuration management

For SC-200, Intune is usually the endpoint management tool, while Defender for Endpoint is the endpoint detection and response tool.

Preview Features

Preview features allow an organization to test new Microsoft Defender capabilities before they become generally available.

In production environments, preview features should be handled carefully. They may be useful for testing, but organizations should consider change control, supportability, and operational impact.

Licensing in Defender for Endpoint

The Licenses area shows which Defender for Endpoint licenses are active.

The transcript references Defender for Endpoint Plan 1 and notes that some capabilities, such as the full vulnerability management dashboard, require Defender for Endpoint Plan 2.

Defender for Endpoint Plan 1 vs Plan 2

At a high level:

Plan 1 provides foundational endpoint protection capabilities.
Plan 2 provides more advanced endpoint detection, response, investigation, and vulnerability management capabilities.

For the lesson, the important distinction is that Plan 1 may show endpoint alerts and device-level information, but Plan 2 exposes richer vulnerability management and investigation features.

In an exam scenario, if a question asks for advanced EDR, automated investigation, or more complete vulnerability management visibility, Plan 2 is usually the stronger fit.

Email Notifications and Alert Rules

Defender for Endpoint supports email notifications for alerts.

An administrator can create notification rules that define:

Rule name
Notification settings
Whether to include the organization name
Whether to include an organization-specific portal link
Whether to include device information
Which devices the rule applies to
Alert severity threshold
Recipients

Why Alert Notifications Matter

Email notifications are useful when a SOC or IT team needs immediate awareness of endpoint alerts.

However, notifications must be tuned carefully. Too many notifications can cause alert fatigue, while too few notifications can delay response.

A reasonable approach is to notify on medium, high, or critical severity alerts depending on the organization’s size, staffing model, and monitoring process.

SOC Consideration

Email notifications should not be the only incident response workflow. In a mature SOC, alerts should flow into a centralized queue, case management system, SIEM, SOAR process, or ticketing platform.

Email is useful for awareness, but it is not ideal for long-term tracking, evidence handling, escalation, or metrics.

Role-Based Access Control in Defender for Endpoint

The Permissions section allows administrators to manage Defender for Endpoint roles.

Role-based access control, or RBAC, controls what users can see and do in the portal.

The lesson shows the ability to enable Defender for Endpoint-specific roles and assign users or groups to those roles.

Defender for Endpoint Administrator

One built-in role mentioned is Microsoft Defender for Endpoint Administrator.

This role has broad permissions over Defender for Endpoint. It should be assigned carefully because endpoint security permissions can be powerful.

Custom Roles

Custom roles allow organizations to grant only the permissions needed for a specific job function.

For example:

Tier 1 SOC analysts may need read-only access to alerts and devices.
Tier 2 analysts may need investigation and response capabilities.
Endpoint engineers may need device management and configuration permissions.
Security administrators may need full control.

SC-200 Relevance

For the exam, remember that RBAC supports least privilege.

If a scenario asks how to give analysts access without granting excessive permissions, the correct answer is usually to use built-in or custom roles rather than making everyone a global administrator.

Device Groups in Defender for Endpoint

Device groups allow administrators to organize endpoints based on conditions.

The transcript demonstrates creating a group based on device name, such as devices that start with a specific prefix like NYC.

Device group conditions can include attributes such as:

Device name
Domain
Azure tag
Operating system
Other device properties

A preview option can show matching devices before the group is finalized.

Why Device Groups Matter

Device groups help organize endpoint security operations.

They can be used for:

Scoping analyst access
Separating devices by location
Separating servers from workstations
Separating production from test systems
Applying different security operations workflows
Supporting incident correlation boundaries
Delegating responsibilities to specific teams

Example

A company has workstations named by location:

NYC-CL-001
NYC-CL-002
CHI-CL-001
LON-CL-001

A device group could target devices where the name starts with NYC. This would allow a team to focus on New York client machines.

SOC Analyst Perspective

Device groups are helpful during triage because they provide context. An alert on a domain controller, executive laptop, kiosk, or test workstation should not always be treated the same way.

Device group context helps answer questions such as:

What business unit owns the device?
Is this endpoint high value?
Which team should remediate it?
Is the device part of a scoped incident boundary?
Should this alert be escalated immediately?

SIEM Integration

The transcript describes SIEM as a centralized log management and security monitoring platform.

SIEM stands for Security Information and Event Management.

Common SIEM platforms include products like Splunk and Microsoft Sentinel.

In Microsoft environments, Microsoft Sentinel is Microsoft’s cloud-native SIEM and SOAR platform.

Defender for Endpoint and SIEM

Defender for Endpoint can integrate with SIEM platforms so that endpoint alerts and security events can be centralized with other data sources.

This is important because endpoint data is only one part of an investigation.

A complete investigation may require data from:

Endpoints
Identity providers
Firewalls
Email systems
Cloud workloads
SaaS applications
DNS logs
Proxy logs
VPN logs
Servers
Network devices

Defender XDR vs SIEM

Defender XDR correlates signals across Microsoft Defender products. A SIEM centralizes and analyzes security data across many sources, including Microsoft and non-Microsoft systems.

For SC-200, do not assume Defender for Endpoint replaces Sentinel. They solve related but different problems.

Alert Suppression Rules

Alert suppression rules can reduce noise by suppressing alerts that are known, expected, or low-value in a specific environment.

Why Suppression Exists

Not every alert requires action. Some alerts may be caused by:

Approved administrative tools
Internal scripts
Vulnerability scanners
Security testing
Software deployment tools
Known lab activity
False positives

Alert suppression can help reduce analyst fatigue.

Caution

Suppression rules must be used carefully. Suppressing too broadly can hide real attacks.

A poor suppression rule might silence a detection across all devices when it should only apply to a specific test machine, tool, or maintenance window.

SOC Best Practice

Before suppressing an alert, document:

Why the alert is being suppressed
Who approved it
Which devices or users are in scope
Whether the suppression is temporary or permanent
How the detection will be monitored in another way
When the suppression should be reviewed

Indicators in Defender for Endpoint

Indicators allow Defender for Endpoint to detect, alert on, allow, or block specific items.

The transcript mentions several indicator types:

File hashes
IP addresses
Domain names
URLs
Digital certificates

Indicators are important in threat response because they allow analysts to operationalize known indicators of compromise, also called IOCs.

File Hash Indicators

A file hash is a unique fingerprint generated from a file’s binary content.

If two files have the same binary content, they should produce the same hash, even if the filename changes.

This allows Defender for Endpoint to detect or block a known file based on its content rather than its name.

Example

A malicious file named invoice.exe is discovered. The attacker later renames it to update.exe.

If the binary content is unchanged, the hash remains the same. A file hash indicator can still identify it.

SOC Use Case

A SOC analyst confirms a malicious file hash from one infected endpoint. The analyst can add the hash as an indicator to block or alert on that file across the organization.

IP Address Indicators

IP indicators can be used to detect or block traffic involving known suspicious or malicious IP addresses.

Use cases include:

Command-and-control infrastructure
Malware download servers
Known attacker infrastructure
Suspicious remote access endpoints
Phishing infrastructure

Caution

IP addresses can change frequently. Cloud providers, CDNs, VPN providers, and shared hosting platforms can make IP-based blocking noisy or risky.

Blocking an IP can also impact legitimate business traffic if not validated.

Domain and URL Indicators

Domain and URL indicators can be used to detect or block access to known malicious web destinations.

Examples include:

Phishing domains
Malware download URLs
Credential harvesting sites
Suspicious redirectors
Known malicious infrastructure

Domain vs URL

A domain indicator applies broadly to a domain, such as:

malicious-example.com

A URL indicator applies to a more specific path, such as:

https://malicious-example.com/download/payload.exe

URL indicators can be more precise, while domain indicators can be broader.

Certificate Indicators

Digital certificate indicators can be used when malicious or suspicious software is signed with a known certificate.

This can be useful when tracking malware families or attacker tooling that uses the same signing certificate.

Enforcement Scope and Microsoft Intune

The Enforcement scope setting allows security settings in Intune to be enforced by Defender for Endpoint.

This reflects the integration between endpoint security management and endpoint detection.

Why This Matters

Organizations often use Intune to deploy endpoint security policies. Defender for Endpoint can provide security intelligence, risk signals, and enforcement integration.

This matters in scenarios involving:

Security baselines
Antivirus settings
Attack surface reduction rules
Endpoint detection and response settings
Device compliance
Conditional Access decisions

For SC-200, remember that Defender for Endpoint detects and responds to endpoint threats, while Intune manages endpoint configuration and policy deployment.

Onboarding Devices to Defender for Endpoint

The Onboarding section provides methods for connecting devices to Defender for Endpoint.

Onboarding is required before Defender for Endpoint can collect telemetry from a device and provide endpoint detection and response visibility.

Common onboarding methods may include:

Local script
Group Policy
Microsoft Intune
Microsoft Configuration Manager
VDI onboarding packages
Defender for Cloud integrations for servers

The transcript specifically shows the onboarding area because it contains a built-in detection test script.

SOC Impact

If a device is not onboarded, the SOC may not receive Defender for Endpoint telemetry from that system.

That means:

Endpoint alerts may not be generated.
Device timeline data may not be available.
Automated investigation may not run.
Response actions may not be available.
Vulnerability visibility may be limited or missing.

Offboarding Devices from Defender for Endpoint

The Offboarding section provides a way to remove devices from Defender for Endpoint.

Offboarding may be needed when:

A device is retired
A lab machine is removed
A device is transferred out of scope
A tenant migration occurs
A server or workstation is decommissioned

Caution

Offboarding removes Defender for Endpoint visibility and response capability for that endpoint. In production, this should be handled through change control or an approved operational process.

Running a Defender for Endpoint Detection Test

The lesson demonstrates running a built-in detection test from the Defender for Endpoint onboarding area.

The workflow is:

Go to the Microsoft Defender portal.
Open Settings.
Go to Endpoints.
Open Onboarding.
Locate the detection test script.
Copy the PowerShell command.
Run PowerShell or Terminal as administrator.
Paste and execute the command.
Wait for Defender for Endpoint to process the signal.
Review the generated alert and incident.

Why Microsoft Provides a Detection Test

The test helps confirm that the endpoint is onboarded correctly and that Defender for Endpoint can generate alerts.

This is useful after onboarding a new device or validating a lab environment.

Timing Consideration

The alert may not appear instantly. There can be processing delay between running the test and seeing the alert in the portal.

This is important in real operations. Security portals often have ingestion, enrichment, and correlation delays.

Reviewing the Detection Test Alert

After the detection test runs, the endpoint can show an active alert and incident.

The transcript demonstrates reviewing the alert from the device view.

The investigation includes:

Device details
Active alerts
Related incident
Alert details
Incident graph
Assets involved
User involved
Evidence and response
PowerShell command line
MITRE ATT&CK mapping

Incidents and Alerts

The test generates an alert for a suspicious PowerShell command line. That alert is associated with an incident.

Alert

An alert is a detection generated from suspicious or malicious activity.

Example:

A suspicious PowerShell command was run on a device.

Incident

An incident is a container that groups related alerts, entities, and evidence.

Example:

An incident may include a PowerShell alert, a suspicious file alert, and a network connection alert involving the same device and user.

SC-200 Exam Point

Do not confuse alerts and incidents.

Alerts are individual detections.
Incidents are grouped investigations that may contain multiple alerts and entities.

A SOC analyst usually triages incidents rather than treating every alert as a completely separate case.

Incident Graph and Visual Investigation

The Defender portal can provide a visual graph showing relationships between entities.

This may include:

Device
User
Process
File
IP address
Domain
Mailbox
Cloud app
Other related entities

The transcript notes that the graph can help show whether a script contacted other machines.

Why This Matters

Security investigations are relationship-driven. Analysts need to understand what interacted with what.

A graph can help answer:

Which device was affected?
Which user ran the command?
Did the activity touch other devices?
Was there network communication?
Was a file created or executed?
Was email or cloud app activity involved?
Is this isolated or part of a broader attack?

Assets Tab

The Assets tab shows entities involved in the incident.

This can include:

Devices
Users
Mailboxes
Apps
Other resources

For the test scenario, the main asset is the endpoint where the PowerShell command ran.

In real incidents, the assets tab helps determine scope and impact.

Evidence and Response

The Evidence and response section shows relevant artifacts associated with the alert or incident.

For the suspicious PowerShell test, evidence may include:

PowerShell process
Command line
Device
User context
Related process details

This section matters because analysts should not respond blindly. Evidence helps validate whether the alert is true positive, benign, expected, or false positive.

Response Actions

Depending on licensing, permissions, and device state, Defender for Endpoint may support response actions such as:

Isolate device
Collect investigation package
Run antivirus scan
Restrict app execution
Stop and quarantine file
Initiate automated investigation
Add indicators
Take action on files or processes

The transcript does not walk through response actions in depth, but the evidence and response area is where analysts begin connecting detection details to possible remediation.

MITRE ATT&CK Mapping

The alert summary includes MITRE ATT&CK tactic and technique context.

MITRE ATT&CK is a knowledge base of adversary tactics, techniques, and procedures.

In this lesson, the suspicious PowerShell behavior maps to a known type of attacker behavior.

Why MITRE ATT&CK Matters

MITRE ATT&CK helps analysts understand what stage of an attack a behavior may represent.

Examples of tactics include:

Initial Access
Execution
Persistence
Privilege Escalation
Defense Evasion
Credential Access
Discovery
Lateral Movement
Command and Control
Exfiltration
Impact

PowerShell abuse is commonly associated with execution, defense evasion, discovery, or post-exploitation activity depending on the command.

SC-200 Exam Point

MITRE ATT&CK is used to classify attacker behavior and improve investigation context. It does not replace evidence review.

Vulnerability Visibility in Defender for Endpoint

The transcript references vulnerability management in Defender for Endpoint.

A key point is the licensing difference:

Defender for Endpoint Plan 1 may provide limited device-level visibility.
Defender for Endpoint Plan 2 provides access to richer vulnerability management dashboards.

Vulnerability Management Dashboard

With the appropriate licensing, the vulnerability management dashboard can show vulnerabilities across devices in the organization.

This helps security teams identify:

Exposed devices
Missing security updates
Vulnerable software
Weak configurations
Prioritized remediation recommendations

Plan 1 Limitation

With Plan 1, vulnerability information may still be visible in some device-specific areas, but the centralized vulnerability dashboard experience is limited compared to Plan 2.

SOC Analyst Perspective

Vulnerability management is not only a patching function. It supports threat-informed defense.

If an alert involves a device with known critical vulnerabilities, that changes the investigation priority and remediation plan.

Microsoft Security Operations Context

How This Fits into a Real SOC Workflow

This lesson maps directly to several SOC responsibilities:

Configure endpoint security visibility.
Ensure devices are onboarded.
Validate alert generation.
Triage endpoint alerts.
Review incident evidence.
Identify affected users and devices.
Determine scope.
Use indicators to block known threats.
Integrate endpoint alerts with SIEM workflows.
Tune noisy alerts through suppression rules.
Use device groups and RBAC to control access and scope.
Improve future detection and response.

Triage Workflow Example

A realistic SOC workflow for the suspicious PowerShell alert would look like this:

Open the incident in the Microsoft Defender portal.
Review severity, title, affected device, and user.
Confirm whether the alert is a test, expected admin activity, or suspicious behavior.
Review the PowerShell command line.
Check whether the command launched child processes.
Review the device timeline for surrounding activity.
Check whether the device contacted external IPs or internal systems.
Review related entities in the incident graph.
Determine whether the activity is isolated or part of a larger incident.
If suspicious, contain the device or escalate to endpoint/security engineering.
Add indicators if a malicious file, URL, domain, certificate, or IP is confirmed.
Document findings and update detection logic or suppression rules as needed.

Determining Scope and Impact

A SOC analyst should use Defender for Endpoint to answer scope questions such as:

Which device generated the alert?
Which user was logged on?
Was PowerShell launched by a legitimate process?
Did the command download or execute a payload?
Did the device communicate with other devices?
Were additional alerts generated?
Is the same file hash seen elsewhere?
Are other devices in the same device group affected?
Is this a one-off test or part of broader attacker behavior?

Containment and Remediation Considerations

Possible response actions depend on the evidence.

Examples:

Situation	Possible Response
Known test script	Close as benign or test activity
Suspicious but not confirmed	Continue investigation and collect more evidence
Confirmed malicious file	Block file hash and remediate endpoint
Lateral movement suspected	Isolate device and escalate
Malicious domain or URL identified	Add indicator and block access
Compromised user suspected	Coordinate with identity team for password reset, session revocation, and MFA review
Widespread activity	Escalate to incident response team and activate major incident process

Documentation and Escalation

A good SOC note should include:

Alert name
Incident ID or case reference
Device name
User account
Time of activity
Command line or relevant evidence
Alert severity
Related entities
Scope assessment
Actions taken
Whether the activity was confirmed malicious, benign, or inconclusive
Recommended next steps

Escalation should happen when the analyst cannot safely contain the threat, when the impact is unclear, or when another team owns the affected system, identity, email, cloud resource, or business application.

Exam-Relevant Takeaways

For SC-200, remember the following:

Defender for Endpoint settings are found under Settings → Endpoints in the Microsoft Defender portal.
Defender for Endpoint supports endpoint detection, investigation, response, device inventory, and vulnerability visibility.
Device groups can scope devices by properties such as name, domain, operating system, or tags.
RBAC controls what analysts and administrators can access or modify.
Alert notifications can be configured by severity, device scope, and recipients.
Indicators can be created for file hashes, IP addresses, domains, URLs, and certificates.
File hash indicators identify files by binary content, not filename.
SIEM integration allows endpoint alerts to be centralized with broader security data.
Microsoft Sentinel is Microsoft’s cloud-native SIEM and SOAR platform.
Alert suppression reduces noise but must be scoped carefully.
Onboarding is required before Defender for Endpoint can collect endpoint telemetry.
Offboarding removes Defender for Endpoint visibility from a device.
The onboarding detection test can validate that alerts are being generated.
Alerts are individual detections.
Incidents group related alerts, entities, and evidence.
MITRE ATT&CK mapping helps classify attacker behavior.
Defender for Endpoint Plan 2 provides richer vulnerability management and advanced EDR capabilities than Plan 1.
Intune is used for endpoint management and policy enforcement; Defender for Endpoint is used for endpoint security detection and response.

Tool / Feature Decision Guide

Scenario	Best Microsoft Security Tool or Feature	Why
Review endpoint alerts and incidents	Microsoft Defender for Endpoint / Microsoft Defender portal	Provides endpoint alerting, incident investigation, evidence, and response actions
Organize devices by location, OS, or naming convention	Defender for Endpoint device groups	Helps scope access, incident correlation, and operational ownership
Assign limited permissions to SOC analysts	Defender for Endpoint RBAC	Supports least privilege and role-based access
Notify a team when medium or high severity endpoint alerts occur	Defender for Endpoint email notification rules	Sends alert notifications based on defined criteria
Block a known malicious file across endpoints	Defender for Endpoint file hash indicator	Identifies the file by hash even if renamed
Detect or block known malicious IPs, domains, or URLs	Defender for Endpoint indicators	Operationalizes known indicators of compromise
Reduce repeated false positive alerts	Alert suppression rules	Suppresses known noisy alerts when carefully scoped
Validate that a device is onboarded and generating alerts	Defender for Endpoint detection test	Confirms endpoint telemetry and alert generation
Enforce endpoint security policies through device management	Microsoft Intune integration	Intune manages device configuration and security policies
Centralize endpoint alerts with logs from other systems	SIEM integration / Microsoft Sentinel	SIEM provides broader cross-source detection and investigation
Investigate whether PowerShell activity contacted other systems	Defender incident graph and device timeline	Shows relationships between users, devices, processes, and network activity
Review organization-wide vulnerability exposure	Defender Vulnerability Management / Defender for Endpoint Plan 2	Provides broader vulnerability dashboards and prioritization
Remove a retired endpoint from Defender monitoring	Defender for Endpoint offboarding	Removes the device from Defender for Endpoint management and telemetry

KQL Notes

This lesson does not directly cover KQL.

However, the concepts are related to KQL because Defender and Sentinel investigations often require querying endpoint, identity, and security event data.

In Microsoft Sentinel or Microsoft Defender Advanced Hunting, KQL can be used to search for suspicious PowerShell activity.

Simple Example: Suspicious PowerShell Command Search

DeviceProcessEvents
| where FileName =~ "powershell.exe"
| where ProcessCommandLine has_any ("-enc", "Invoke-WebRequest", "DownloadString", "IEX")
| project Timestamp, DeviceName, InitiatingProcessAccountName, FileName, ProcessCommandLine
| order by Timestamp desc

Query Logic

KQL Element	Purpose
`DeviceProcessEvents`	Searches endpoint process execution events
`where FileName =~ "powershell.exe"`	Filters for PowerShell process executions
`has_any`	Looks for suspicious strings commonly seen in PowerShell abuse
`project`	Selects the most useful columns for investigation
`order by Timestamp desc`	Shows newest events first

How This Helps an Investigation

This type of query helps analysts identify PowerShell commands that may involve encoded commands, web downloads, or in-memory execution.

For SC-200, you do not need to memorize this exact query from the lesson. The exam is more likely to test whether you understand when KQL is used for hunting or investigation, which table type is relevant, and how filtering reduces noise.

Common Exam Traps

Confusing Defender XDR with Microsoft Sentinel

Defender XDR correlates alerts across Microsoft Defender products.

Microsoft Sentinel is a SIEM and SOAR platform that collects and analyzes data from Microsoft and non-Microsoft sources.

If the scenario requires centralized log ingestion across many platforms, Sentinel is likely the answer.

If the scenario is specifically about endpoint alerts, device timelines, endpoint evidence, or endpoint response actions, Defender for Endpoint is likely the answer.

Confusing Alerts with Incidents

An alert is a single detection.

An incident is a grouped investigation containing related alerts, assets, entities, and evidence.

In Microsoft security operations, analysts usually investigate incidents because incidents provide broader context.

Choosing Suppression Too Quickly

Alert suppression can reduce noise, but it can also hide real attacks.

If an alert is not understood, investigate first. Suppress only after confirming the activity is expected and after scoping the suppression carefully.

Thinking File Name Equals File Identity

A malicious file can be renamed. A hash identifies the file by content.

For known malicious files, file hash indicators are stronger than filename-based assumptions.

Forgetting Licensing Differences

Some Defender for Endpoint capabilities depend on licensing.

If an exam question mentions advanced EDR, automated investigation, or full vulnerability dashboards, pay attention to whether Plan 2 or Defender Vulnerability Management is required.

Assuming Alerts Appear Instantly

Detection and portal visibility can take time.

In real environments, ingestion and correlation delays are normal. Do not assume a detection test failed just because the alert did not appear immediately.

Using the Wrong Tool for Endpoint Policy

Defender for Endpoint detects and responds to endpoint threats.

Intune manages endpoint configuration and policy enforcement.

They integrate, but they are not the same tool.

Real-World SOC Analyst Notes

Alert Fatigue

Email notifications and endpoint alerts must be tuned carefully. If every medium alert generates an email to a large group, analysts may start ignoring notifications.

Better workflows use queue-based triage, severity-based escalation, ticketing integration, and documented playbooks.

False Positives

PowerShell alerts are common in enterprise environments. Administrators, deployment tools, monitoring agents, and security scanners may all use PowerShell.

The analyst’s job is to determine whether the PowerShell activity is expected, authorized, and properly scoped.

Important review points include:

Who ran the command?
What device ran it?
What parent process launched it?
What command line was used?
Did it download content?
Did it execute encoded or obfuscated commands?
Did it connect to external infrastructure?
Did it touch other systems?

Evidence Preservation

Before taking disruptive response actions, preserve enough evidence to support the investigation.

Useful evidence may include:

Command line
Process tree
File hash
User context
Device timeline
Network connections
Related alerts
Screenshots or exported case details
Investigation package if supported

Escalation Paths

Endpoint alerts may require coordination with several teams:

Finding	Possible Escalation Team
Suspicious endpoint process	Endpoint/security engineering
Compromised user account	Identity/IAM team
Malicious email origin	Messaging/security team
Cloud app abuse	Cloud security or SaaS admin team
Vulnerable server	Infrastructure or server team
Business-critical system impacted	Application owner or incident commander

Automation Safety

Blocking indicators can be powerful. A bad block can disrupt business operations.

Before blocking a hash, domain, URL, IP, or certificate, validate:

Is the indicator truly malicious?
Is it used by legitimate business systems?
How broad is the scope?
Is the block temporary or permanent?
Who approved the action?
How will the action be reversed if needed?

Change Control and Tenant-Wide Impact

Some Defender for Endpoint settings affect the entire tenant. Others affect scoped device groups.

Changes involving alert suppression, device grouping, indicators, Intune enforcement, or preview features should be handled carefully in production.

Data Retention and Cost Considerations

Defender for Endpoint retains endpoint security data according to product capabilities and licensing.

When sending Defender data to Microsoft Sentinel or another SIEM, ingestion and retention can affect cost.

For real-world operations, teams should decide which data is needed for detection, investigation, compliance, and long-term retention.

Quick Reference Summary

Defender for Endpoint settings are managed under Settings → Endpoints.
Onboarding connects devices to Defender for Endpoint telemetry.
Offboarding removes devices from Defender for Endpoint monitoring.
Device groups organize endpoints and can scope access or incident correlation.
RBAC supports least privilege for analysts and administrators.
Email notification rules alert recipients based on severity and scope.
Indicators can target file hashes, IPs, domains, URLs, and certificates.
File hashes identify file content, not filenames.
SIEM integration centralizes endpoint alerts with broader log data.
Microsoft Sentinel is Microsoft’s SIEM/SOAR platform.
Alert suppression reduces noise but must be used carefully.
Defender for Endpoint integrates with Intune for endpoint security management.
A built-in detection test can validate onboarding and alert generation.
Alerts are individual detections; incidents group related alerts and entities.
MITRE ATT&CK mapping helps classify attacker behavior.
Defender for Endpoint Plan 2 provides richer vulnerability and EDR capabilities than Plan 1.

Flashcards

Q: Where are Defender for Endpoint settings configured in the Microsoft Defender portal?
A: Under Settings → Endpoints.

Q: What is the purpose of onboarding a device to Defender for Endpoint?
A: Onboarding connects the device to Defender for Endpoint so it can send telemetry, generate alerts, and support investigation and response.

Q: What is the difference between an alert and an incident?
A: An alert is an individual detection. An incident groups related alerts, entities, and evidence into a broader investigation.

Q: What are Defender for Endpoint device groups used for?
A: They organize devices and can help scope access, incident correlation, and operational ownership.

Q: What does a file hash indicator identify?
A: It identifies a file based on its binary content, even if the file is renamed.

Q: Why should alert suppression rules be used carefully?
A: Overly broad suppression can hide real attacks and reduce security visibility.

Q: Which Microsoft product is used for endpoint management and security policy deployment?
A: Microsoft Intune.

Q: Which Microsoft product is used for endpoint detection and response?
A: Microsoft Defender for Endpoint.

Q: What is Microsoft Sentinel?
A: Microsoft’s cloud-native SIEM and SOAR platform.

Q: Why would Defender for Endpoint integrate with a SIEM?
A: To centralize endpoint alerts with logs and alerts from other security sources.

Q: What does MITRE ATT&CK mapping provide in an alert?
A: It maps the detected behavior to known adversary tactics and techniques.

Q: Why might Defender for Endpoint Plan 2 be needed?
A: Plan 2 provides richer EDR, investigation, and vulnerability management capabilities than Plan 1.

Q: What is the purpose of the Defender for Endpoint detection test script?
A: It validates that an onboarded endpoint can generate Defender for Endpoint alerts.

Q: What type of indicator would you use to block a known malicious website?
A: A domain or URL indicator.

Q: What should an analyst review when investigating suspicious PowerShell activity?
A: The command line, user, device, parent process, child processes, network connections, and related alerts.

Practice Questions

Question 1:

A SOC analyst needs to confirm that a newly onboarded endpoint is successfully generating Defender for Endpoint alerts. What should the analyst do?

A. Create a Microsoft Sentinel workbook
B. Run the Defender for Endpoint detection test from the onboarding section
C. Create a Microsoft Purview compliance alert
D. Offboard and re-onboard the device immediately

Correct Answer:
B. Run the Defender for Endpoint detection test from the onboarding section

Explanation:
The Defender for Endpoint onboarding area includes a detection test that can be run on a device to validate alert generation. This is useful after onboarding a device or validating a lab setup.

Question 2:

An administrator wants to organize endpoints by naming convention so that devices beginning with NYC are grouped together. Which Defender for Endpoint feature should be used?

A. Alert suppression
B. Device groups
C. Microsoft Purview audit
D. Microsoft Sentinel watchlists

Correct Answer:
B. Device groups

Explanation:
Device groups can organize endpoints based on conditions such as device name, domain, tags, or operating system. A naming convention such as NYC can be used as a condition.

Question 3:

A malicious file was discovered on one endpoint. The attacker renamed the file on another endpoint, but the binary content is unchanged. Which indicator type is most useful for detecting or blocking the file?

A. File hash
B. Device name
C. User principal name
D. Mailbox address

Correct Answer:
A. File hash

Explanation:
A file hash is generated from the file’s binary content. If the file is renamed but the content is unchanged, the hash remains the same.

Question 4:

A company wants to centralize Defender for Endpoint alerts with firewall logs, VPN logs, identity logs, and non-Microsoft security data. Which solution is the best fit?

A. Microsoft Purview
B. Microsoft Sentinel
C. Microsoft Intune Company Portal
D. Microsoft Entra Connect

Correct Answer:
B. Microsoft Sentinel

Explanation:
Microsoft Sentinel is Microsoft’s cloud-native SIEM and SOAR platform. It is used to centralize and analyze security data from Microsoft and non-Microsoft sources.

Question 5:

A SOC analyst sees a suspicious PowerShell alert in Defender for Endpoint. What should the analyst do first?

A. Immediately suppress all PowerShell alerts
B. Delete the user account
C. Review the alert evidence, command line, device, user, and related entities
D. Offboard the device from Defender for Endpoint

Correct Answer:
C. Review the alert evidence, command line, device, user, and related entities

Explanation:
The first step is investigation and validation. PowerShell can be used legitimately or maliciously, so the analyst should review evidence before taking disruptive action.