Agent Foskett Academy • Lesson 114 • Incident Response Workflow Series

Incident Response Workflow: Malware Infection in Microsoft Defender XDR.

The alert fired just after 9:00 AM.

Microsoft Defender had quarantined a suspicious file, and the user said the computer had been running slowly all morning.

But Agent Foskett knew the malware name was only one clue.

The real investigation was to find how the malware arrived, what it executed, whether persistence was created, what it contacted, and whether the infection had spread beyond the first device.

Agent Foskett Academy lesson investigating malware infections in Microsoft Defender XDR
Lesson overview

Learn how to investigate a malware infection by correlating Microsoft Defender XDR endpoint, process, file, network, alert and identity telemetry into a complete incident response workflow.

Identify the affected device and first alert
Trace process, file and network activity
Check persistence and lateral movement
Contain, remediate and confirm recovery

Why malware investigations matter

A malware alert may tell you what Defender detected, but incident response requires understanding the entire chain of activity before, during and after execution.
The alert is only the starting pointA quarantined file does not automatically prove the incident is over. Defenders still need to confirm execution, persistence, network activity and scope.
Endpoint context explains behaviourDeviceProcessEvents, DeviceFileEvents and DeviceNetworkEvents show what happened on the affected endpoint and what the malware may have touched.
Scope determines responseA single infected device can become a wider incident if credentials were harvested, files were copied or lateral movement occurred.

The malware infection response workflow

Agent Foskett follows the evidence from first detection to containment and recovery.
1. Review the alertIdentify the affected device, user, malware family, first seen time, severity and whether Defender remediated the detection.
2. Reconstruct process executionUse process telemetry to find parent processes, child processes, command lines, PowerShell, scripts and LOLBin activity.
3. Investigate file activityReview downloaded files, dropped payloads, archive extraction, suspicious file creation and file modifications.
4. Analyse network connectionsLook for command-and-control traffic, suspicious domains, unusual remote IPs and attempted downloads.
5. Check persistence and spreadSearch for scheduled tasks, services, registry run keys, startup folders and signs of lateral movement.
6. Contain and validate recoveryIsolate devices, block indicators, remove malware, reset affected credentials and confirm no further evidence exists.

Step 1 — Locate malware-related alerts

Start with the Defender alert so the investigation has a clear device, user, timestamp and detection context.
step-1-locate-malware-alerts.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
let TimeFrame = 7d;
AlertInfo
| where Timestamp > ago(TimeFrame)
| where Title has_any ("malware", "trojan", "ransom", "virus", "suspicious", "backdoor")
| project Timestamp,
          AlertId,
          Title,
          Severity,
          Category,
          ServiceSource,
          DetectionSource
| order by Timestamp desc

Step 2 — Review alert evidence

AlertEvidence helps identify affected devices, users, files, processes and related entities connected to the malware alert.
step-2-review-alert-evidence.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
let TimeFrame = 7d;
AlertEvidence
| where Timestamp > ago(TimeFrame)
| where EntityType in~ ("Machine", "File", "Process", "User", "Ip")
| project Timestamp,
          AlertId,
          EntityType,
          EvidenceRole,
          DeviceName,
          AccountName,
          FileName,
          SHA256,
          ProcessCommandLine,
          RemoteIP
| order by Timestamp desc

Step 3 — Investigate suspicious process execution

Process execution shows whether malware launched scripts, spawned child processes or used legitimate tools to continue activity.
step-3-investigate-process-execution.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
let TimeFrame = 7d;
let DeviceToInvestigate = "DEVICE01";
DeviceProcessEvents
| where Timestamp > ago(TimeFrame)
| where DeviceName =~ DeviceToInvestigate
| where FileName in~ ("powershell.exe", "cmd.exe", "wscript.exe", "cscript.exe", "mshta.exe", "rundll32.exe", "regsvr32.exe")
   or ProcessCommandLine has_any ("-enc", "downloadstring", "invoke-webrequest", "frombase64string", "http", "temp")
| project Timestamp,
          DeviceName,
          AccountName,
          InitiatingProcessFileName,
          FileName,
          ProcessCommandLine
| order by Timestamp asc

Step 4 — Review file creation and modification

Malware often creates payloads, scripts, temporary files or renamed executables before execution.
step-4-review-file-activity.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
let TimeFrame = 7d;
let DeviceToInvestigate = "DEVICE01";
DeviceFileEvents
| where Timestamp > ago(TimeFrame)
| where DeviceName =~ DeviceToInvestigate
| where FolderPath has_any ("\Downloads\", "\Temp\", "\AppData\", "\ProgramData\", "\Startup\")
   or FileName endswith ".exe"
   or FileName endswith ".dll"
   or FileName endswith ".ps1"
   or FileName endswith ".js"
   or FileName endswith ".vbs"
| project Timestamp,
          DeviceName,
          ActionType,
          FileName,
          FolderPath,
          SHA256,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine
| order by Timestamp asc

Step 5 — Analyse network activity

Network telemetry helps identify command-and-control activity, payload downloads and suspicious external communication.
step-5-analyse-network-activity.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
let TimeFrame = 7d;
let DeviceToInvestigate = "DEVICE01";
DeviceNetworkEvents
| where Timestamp > ago(TimeFrame)
| where DeviceName =~ DeviceToInvestigate
| where isnotempty(RemoteUrl) or isnotempty(RemoteIP)
| project Timestamp,
          DeviceName,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine,
          RemoteUrl,
          RemoteIP,
          RemotePort,
          ActionType
| order by Timestamp asc

Step 6 — Hunt for persistence indicators

Persistence checks determine whether the attacker or malware created a way to survive reboot or return later.
step-6-hunt-persistence-indicators.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
let TimeFrame = 7d;
let DeviceToInvestigate = "DEVICE01";
DeviceRegistryEvents
| where Timestamp > ago(TimeFrame)
| where DeviceName =~ DeviceToInvestigate
| where RegistryKey has_any ("Run", "RunOnce", "Winlogon", "Services", "Explorer\StartupApproved")
   or RegistryValueData has_any ("powershell", "cmd.exe", "wscript", "mshta", "rundll32")
| project Timestamp,
          DeviceName,
          ActionType,
          RegistryKey,
          RegistryValueName,
          RegistryValueData,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine
| order by Timestamp asc

Step 7 — Build the malware incident timeline

A combined timeline helps responders explain the incident, scope the impact and validate containment.
step-7-build-malware-timeline.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
let TimeFrame = 7d;
let DeviceToInvestigate = "DEVICE01";
let Processes =
    DeviceProcessEvents
    | where Timestamp > ago(TimeFrame)
    | where DeviceName =~ DeviceToInvestigate
    | project Timestamp, EventType="Process", DeviceName, Evidence=FileName, Detail=ProcessCommandLine;
let Files =
    DeviceFileEvents
    | where Timestamp > ago(TimeFrame)
    | where DeviceName =~ DeviceToInvestigate
    | project Timestamp, EventType="File", DeviceName, Evidence=FileName, Detail=FolderPath;
let Network =
    DeviceNetworkEvents
    | where Timestamp > ago(TimeFrame)
    | where DeviceName =~ DeviceToInvestigate
    | project Timestamp, EventType="Network", DeviceName, Evidence=RemoteUrl, Detail=strcat(RemoteIP, ":", RemotePort);
union Processes, Files, Network
| order by Timestamp asc

Malware investigation clues

Malware infections become clearer when multiple weak signals align across process, file and network telemetry.
Unexpected parent processA browser, Office process, archive tool or script host spawning PowerShell or cmd.exe may indicate execution from a phishing or drive-by event.
Suspicious file locationsPayloads commonly appear in Downloads, Temp, AppData, ProgramData or user-writable folders before execution.
External communicationMalware may contact unusual domains, newly seen IP addresses, non-standard ports or hosting providers shortly after execution.
Persistence creationScheduled tasks, services, registry run keys and startup folder changes can indicate the malware intends to survive reboot.
Credential exposureIf the infected device has interactive logons from privileged users, defenders should review credential theft and lateral movement risk.
Multiple affected devicesRepeated file hashes, command lines or network indicators across devices can turn a single alert into a wider incident.

False positives to consider

Not every suspicious-looking endpoint event is malicious. Validate business context before taking disruptive action.
Software deployment toolsRMM, Intune, SCCM and software deployment platforms may create processes, files and services that look unusual out of context.
Administrator scriptsIT teams often use PowerShell, cmd.exe, scheduled tasks and registry changes for legitimate maintenance.
Security toolsEDR, vulnerability scanners and backup agents may create high-volume file, process and network activity.
Application updatesBrowsers, collaboration tools and line-of-business applications may download and execute update components automatically.
Developer activityBuild tools, package managers and test frameworks can create scripts, executables and network connections.
Known enterprise pathsCompare suspicious file paths and command lines with known management tools before escalating.

Investigation checklist

Use this checklist before closing a malware infection incident.
Was the malware executed?Confirm whether the file was only detected, or whether it actually launched and spawned child processes.
How did it arrive?Review email, browser downloads, removable media, file shares and user activity around first execution.
What did it contact?Check remote URLs, IP addresses, ports and network timing after suspicious process activity.
Was persistence created?Search for scheduled tasks, services, registry run keys, startup entries and repeated execution.
What is the blast radius?Look for the same hash, filename, command line, domain, IP address or user activity across other devices.
Has recovery been validated?Confirm remediation, isolate if necessary, reset exposed accounts and re-run hunts after cleanup.

Related Agent Foskett Academy lessons

These lessons support malware infection investigations.
Hunting Playbook: PowerShell AbuseReview encoded commands, script execution and suspicious PowerShell behaviour.
Hunting Playbook: LOLBinsInvestigate legitimate Windows binaries being abused for execution and evasion.
Hunting Playbook: Persistence MechanismsFind scheduled tasks, services, registry run keys and other persistence techniques.
Hunting Playbook: RansomwareUnderstand how malware investigations can escalate into ransomware response.
Incident Response Workflow: Compromised User AccountCorrelate endpoint infections with suspicious identity and cloud activity.
Building Reusable Hunting QueriesTurn malware investigation logic into repeatable Defender XDR hunting workflows.

Coming next

The Incident Response Workflow series continues with ransomware incident response.
Lesson 115 — Incident Response Workflow: Ransomware IncidentNext, Agent Foskett investigates a ransomware incident from initial alert through encryption behaviour, lateral movement, containment, recovery and lessons learned.
Why this mattersMalware infection investigations teach defenders how to follow endpoint evidence. Ransomware response brings identity, endpoint, file activity, network behaviour and business impact together.

Final thought

A malware alert names the threat. The investigation explains the incident.
Agent Foskett mindsetDo not stop at quarantine. Ask how the file arrived, what executed, what changed, what communicated and whether the environment is still exposed.
Incident Response Workflow SeriesLesson 114 moves the Academy deeper into endpoint incident response and practical Microsoft Defender XDR investigation workflows.
Develop IT. Protect IT.GEMXIT PTY LTD | GEMXIT UK LTD

Incident Response Workflow Malware Infection in Microsoft Defender XDR

Agent Foskett Academy Lesson 114 teaches defenders how to investigate malware infections using Microsoft Defender XDR endpoint telemetry, process events, file activity, network connections, alert evidence and KQL hunting workflows.

Learn malware infection response with Microsoft Defender XDR and KQL

Malware infection investigations help Microsoft security analysts identify initial compromise, suspicious execution, dropped files, command-and-control traffic, persistence mechanisms and lateral movement.

Microsoft Defender XDR malware investigation tutorial

This lesson explains how to investigate malware alerts, affected devices, malicious files, suspicious process trees, endpoint telemetry and remediation steps using practical Microsoft security investigation workflows.