Lesson 6 — Understanding Endpoint Alerts

Learning objectives

After completing this lesson, you should be able to investigate an endpoint alert using its evidence and surrounding context.

• Explain how Defender for Endpoint creates alerts.
• Interpret alert severity, category and status.
• Identify common evidence types.
• Review MITRE ATT&CK mappings and detection context.
• Pivot from an alert into the device timeline and Defender XDR incident.

The problem this solves

An alert is designed to attract attention, but it does not automatically prove that a compromise occurred.

Analysts need a consistent method for validating the alert, understanding the evidence and deciding what response is appropriate.

Telemetry first

Defender for Endpoint collects process, file, network, registry, logon and other endpoint activity.

Detection analytics evaluate that telemetry for suspicious patterns, known threats and abnormal behaviour.

Behaviour-based detection

Not every alert depends on a known malware signature.

Behaviour analytics can detect suspicious PowerShell, credential access, persistence, exploitation and living-off-the-land techniques.

Alert title

The title summarises what Defender detected.

Use it as an initial clue, but always review the evidence and surrounding activity before deciding what happened.

Alert description

The description explains why the activity may be suspicious and what behaviour triggered the detection.

Read the full description before moving into response actions.

Detection time

The alert timestamp helps anchor the investigation.

Use it to open the Device Timeline around the relevant period and inspect activity before and after the detection.

Affected device

The affected device identifies the endpoint involved in the alert.

Confirm the device name, risk, health, business importance and whether it appears in other incidents.

Affected user

The alert may identify the account associated with the activity.

User context can reveal whether the event involved an administrator, service account, standard user or compromised identity.

Alert severity

Severity helps prioritise investigation effort.

Common severity levels include informational, low, medium and high, but severity should never replace analyst judgement.

Do not rely on severity alone

A medium-severity alert on a domain controller may be more urgent than a high-severity alert on a test workstation.

Always combine alert severity with business importance, device risk and surrounding evidence.

Alert category

The category groups the detection by attack behaviour, such as execution, persistence, credential access or command and control.

This helps the analyst understand the likely objective of the activity.

MITRE ATT&CK mapping

Alerts may map to MITRE ATT&CK tactics and techniques.

Use these mappings to understand where the behaviour fits within a wider attack lifecycle.

Detection source

The detection source identifies which Defender capability or analytics engine generated the alert.

This context can help explain what telemetry and logic contributed to the detection.

Alert evidence

Evidence represents the entities and artefacts connected to the detection.

Common evidence includes processes, files, hashes, users, devices, IP addresses, URLs, domains and registry keys.

Process evidence

Process evidence may include the executable name, command line, parent process, user and file hash.

These details are often central to understanding attacker intent.

File evidence

File evidence may include the path, filename, hash, signer and reputation.

Check whether the file was downloaded, created by another process or observed on additional devices.

Network evidence

Network evidence may include remote IP addresses, domains, URLs and ports.

Correlate each connection with the process that initiated it and the time it occurred.

Registry evidence

Registry evidence can reveal persistence, configuration changes or security control modification.

Review the initiating process and whether the key or value is expected in the environment.

Entity relationships

Evidence becomes more useful when relationships are understood.

A process launched by an unusual parent, running as a privileged user and connecting to an unfamiliar domain is far more suspicious than any one item viewed alone.

Open the Device Timeline

The timeline provides the activity surrounding the alert.

Move backwards to find the cause and forwards to determine impact.

Review the parent process

The parent process often explains why the suspicious process started.

For example, PowerShell launched by an administrative tool may be expected, while PowerShell launched by a document application may require urgent investigation.

Review child processes

Child processes show what happened after execution.

Look for command shells, script engines, persistence tools, credential utilities or additional payloads.

Review the wider incident

The alert may belong to a Defender XDR incident containing related endpoint, identity, email or cloud alerts.

Do not close an endpoint alert without checking whether it contributes to a larger attack story.

Alert status

Status helps track the investigation lifecycle.

Common states include new, in progress and resolved, depending on the workflow and portal experience.

Assign ownership

Assigning an alert or incident makes responsibility clear.

Ownership helps prevent duplicate work and ensures important investigations are not left unattended.

Classification

After investigation, classify the activity according to the evidence.

The outcome may be true positive, false positive, expected activity or another organisation-defined result.

True positive

A true positive means the alert correctly identified malicious or unauthorised activity.

Containment, remediation and wider scoping may be required.

False positive

A false positive occurs when legitimate activity matches suspicious detection logic.

Expected administration, software deployment, security testing and approved scripts can all produce alerts.

Benign but suspicious

Some activity may be legitimate but still risky or unusual.

This can justify process changes, allow-list review, better documentation or tighter administrative controls.

Validate expected activity

Do not close an alert simply because an administrator says the action was expected.

Validate the user, device, time, command, change record and business purpose.

Advanced Hunting pivot

Use Advanced Hunting to determine whether the same process, hash, IP address, domain or user appears elsewhere.

This helps establish whether the alert is isolated or part of a broader campaign.

Containment decisions

If the evidence confirms active compromise, consider isolation, antivirus scanning, evidence collection or Live Response.

Response should match the confidence, impact and business importance of the device.

Common mistake

A common mistake is closing an alert after reading only the title.

The title is a summary; the evidence and timeline determine what actually happened.

Another common mistake

Do not assume that a legitimate Microsoft or Windows process is safe.

Attackers frequently abuse trusted binaries, scripts and administrative tools.

Best practices

• Read the full alert description.
• Review every evidence entity.
• Do not rely on severity alone.
• Open the Device Timeline.
• Check parent and child processes.
• Review the related Defender XDR incident.
• Validate activity before closing.

Agent Foskett takeaway

An alert is a signal that something deserves attention.

The investigation is the process of proving whether that activity was malicious, suspicious or legitimate by following the evidence and surrounding context.