This SOP handles Defender for Endpoint (MDE) alerts firing on suspicious process execution, malware detection, or behavioural anomalies. The primary job is a fast FP/TP verdict — most EDR alerts in a mature environment are FPs from legitimate IT tooling. The process tree tells you within 5 minutes which it is.
Target: FP/TP verdict within 15 min. If TP confirmed, device isolated within 5 min of that verdict. Fleet scope KQL run within 10 min of isolation.
◈ Table of Contents
📋
PHASE 00 — QUICK REFERENCE
METADATA| SOP ID | SOP-03 |
| Owner | T1 SOC Analyst (initial triage) · T2 if TP confirmed |
| Trigger | Defender for Endpoint alert · Sentinel EDR rule · MDE severity Medium/High/Critical |
| Time Targets | FP/TP verdict: < 15 min · Device isolation (if TP): < 5 min after verdict · Fleet scope: < 10 min after isolation |
| Escalate To | T2/IR Lead if LSASS dump confirmed, lateral movement found, or >1 device affected |
| Critical Rule | DO NOT REBOOT the affected device before collecting investigation package — memory forensics is lost |
| Tools Required | security.microsoft.com · Microsoft Sentinel · MDE Live Response (if licensed) |
🔍
PHASE 01 — ALERT CONTEXT
TARGET: < 5 MIN01
Read the Alert — Device, User, Detection Source
T1 ACTION
◈ Steps
- 1Navigate:
security.microsoft.com → Incidents & alerts → Alerts → [alert]. Click to open full alert page. - 2Record: Alert title, Severity (Informational/Low/Medium/High/Critical), Category (Malware, Suspicious Activity, etc.), Detection source (MDAV = AV signature, EDR = behavioral, MDO = email-borne), Device name, User account, First activity timestamp.
- 3Check: Is this alert correlated to an existing Incident? If yes (Part of incident: [link]), open the Incident — it may have context from related alerts that changes your triage path. Escalate correlated multi-alert incidents to T2.
- 4Check the device:
security.microsoft.com → Devices → [device name]. Note Risk level (High = this device has had prior unresolved issues), Exposure level, OS version, Last seen. If Last seen > 24h ago, device may be offline — incident package collection won't work.
🌲
PHASE 02 — PROCESS TREE + KQL
TARGET: < 10 MIN02
Map the Process Chain + Check Network Callbacks
KQL REQUIRED
◈ Steps
- 1In the alert page: scroll to the Process tree section. Map GrandParent → Parent → Child. Write it down: e.g.
winword.exe → cmd.exe → powershell.exe -EncodedCommand. - 2For each process in the chain, check in Defender: Signed? (unsigned PE = suspicious) · Hash reputation (click the process → hash → Defender TI lookup) · Command line (is there base64, -enc, -nop, bypass, hidden?).
- 3Run KQL to get the full suspicious process list on that device from the alert time window:
KQL — SUSPICIOUS PROCESS EXECUTION ON TARGET DEVICE
// Replace DEVICE_NAME and adjust time window to match alert first activity
DeviceProcessEvents
| where DeviceName =~ "DEVICE_NAME"
| where Timestamp >= ago(2h)
| where ProcessCommandLine has_any (
"powershell", "cmd", "wscript", "cscript", "mshta",
"certutil", "regsvr32", "rundll32", "cmstp", "msiexec",
"bitsadmin", "odbcconf", "regasm", "installutil")
| project Timestamp, AccountName, InitiatingProcessFileName,
InitiatingProcessCommandLine, FileName, ProcessCommandLine,
FolderPath, SHA256
| order by Timestamp desc
- 4Run KQL to check outbound network connections from the suspicious process — C2 callback is a definitive TP indicator:
KQL — NETWORK CALLBACKS FROM SUSPICIOUS PROCESS
DeviceNetworkEvents
| where DeviceName =~ "DEVICE_NAME"
| where Timestamp >= ago(2h)
| where InitiatingProcessFileName in~ (
"powershell.exe", "cmd.exe", "mshta.exe",
"wscript.exe", "regsvr32.exe", "rundll32.exe")
| where RemoteIPType != "Private" // exclude internal IPs
| where ActionType in ("ConnectionSuccess", "HttpConnectionInspected")
| project Timestamp, InitiatingProcessFileName, RemoteIP,
RemotePort, RemoteUrl, InitiatingProcessCommandLine
| order by Timestamp desc
⚖️
PHASE 03 — FP vs TP VERDICT
DECISION GATE03
Apply FP / TP Verdict Framework
DECISION POINT
◈ Strong TP Indicators (any one = treat as TP)
- !Encoded PowerShell in command line:
-EncodedCommand,-enc, long base64 string,bypass,-nop,-hidden - !LOLBin chain: Office app → cmd/wscript/mshta → PowerShell → regsvr32/rundll32
- !Unsigned PE executing from
%TEMP%,%AppData%, orC:\Users\Public\ - !Network callback from PowerShell/cmd/mshta to an external IP on ports 443/80/4444/8080
- !LSASS access: process opening
lsass.exehandle, or command line withsekurlsa,logonpasswords,dcsync,procdump - !Scheduled task / registry run key creation for persistence pointing to a dropped executable
◈ Strong FP Indicators (all must be true = FP)
- ✓Binary is signed by Microsoft or known software vendor
- ✓Hash has clean reputation in Defender TI (File page shows "Good" or "Unknown" with no detections)
- ✓Parent process is a known IT deployment tool (SCCM, PDQ Deploy, Chocolatey, Windows Update)
- ✓No outbound network connection from the suspicious process
- ✓Activity matches scheduled maintenance window or known software install
If you're not certain — treat it as TP. A wrong FP call on a real infection costs far more than a false isolation of a legitimate device.
🔒
PHASE 04 — ISOLATE + COLLECT EVIDENCE
IF TP CONFIRMED04
Defender Device Isolation + Investigation Package
DEFENDER ACTION
◈ Steps
- 1DO NOT REBOOT the device. Communicate to the user/IT: leave the device powered on, do not close any windows, do not log out.
- 2Isolate:
security.microsoft.com → Devices → [device name] → … (three dots menu) → Isolate device. Select Full isolation. Enter your incident ticket number in the comment. Confirm. - 3Wait 1–2 min. Refresh device page. Verify status shows Isolated. If still showing Connected after 3 min, check if MDE agent is reporting — the device may be offline.
- 4Collect investigation package:
Devices → [device] → … → Collect investigation package. This bundles autoruns, process list, network connections, event logs, prefetch, memory strings into a ZIP. Download when available (usually 5–10 min). - 5If MDE Live Response is licensed:
Devices → [device] → … → Initiate Live Response session. In the session, run:processes(active processes),connections(active network connections),dir C:\Users\[user]\AppData\Roaming\,dir C:\Users\[user]\AppData\Local\Temp\.
KQL — CREDENTIAL DUMPING CHECK (LSASS ACCESS)
DeviceProcessEvents
| where DeviceName =~ "DEVICE_NAME"
| where Timestamp >= ago(4h)
| where FileName in~ ("mimikatz.exe", "procdump.exe", "ProcDump64.exe")
or ProcessCommandLine has_any (
"lsass", "sekurlsa", "logonpasswords",
"dcsync", "wce", "fgdump")
| project Timestamp, AccountName, FileName, ProcessCommandLine
- 6If LSASS dump confirmed: escalate to T2 and IR Lead immediately. Every password the user typed on that device should be treated as compromised. Trigger SOP-04 for the user account.
🔭
PHASE 05 — FLEET SCOPE CHECK
DETERMINE BLAST RADIUS05
Find the Same Hash / Process Across All Devices
KQL REQUIRED
◈ Steps
- 1Run KQL to check if the malicious file hash exists on any other device in the fleet:
KQL — SAME HASH ACROSS FLEET
// Replace SHA256 with hash from the alert or investigation package
DeviceFileEvents
| where Timestamp >= ago(48h)
| where SHA256 =~ "PASTE_HASH_HERE"
| summarize
DeviceCount = dcount(DeviceName),
Devices = make_set(DeviceName),
FirstSeen = min(Timestamp)
by FileName, SHA256
- 2Run KQL to check for lateral movement — did the affected user's account log into other devices during or after the compromise window?
KQL — USER LOGON TO OTHER DEVICES (LATERAL MOVEMENT CHECK)
// Replace AFFECTED_USER with the account name from the alert
DeviceLogonEvents
| where Timestamp >= ago(6h)
| where AccountName =~ "AFFECTED_USER"
| where DeviceName != "COMPROMISED_DEVICE"
| where LogonType in (3, 10) // Network (3) and Remote Interactive (10)
| summarize LogonCount = count(), LatestLogon = max(Timestamp)
by AccountName, DeviceName, RemoteIP
| order by LogonCount desc
- 3If DeviceCount > 1 or lateral movement found: escalate to T2 immediately. Isolate ALL devices in the returned list. Declare an Incident in Defender.
✅
PHASE 06 — REMEDIATE & CLOSE
FINAL STEPS06
Clean, Restore, or Re-image + Ticket Close
CLOSE
◈ Steps
- 1If FP confirmed: un-isolate device (
Devices → [device] → Release from isolation). Add the binary hash to Defender allow list if it's a legitimate tool triggering FPs. Close ticket as False Positive. - 2If TP + no LSASS/lateral movement: run AV remediation from Defender (
Devices → [device] → Run antivirus scan). After scan completes, check Defender recommendations. Un-isolate only after Remediated status confirmed. - 3If TP + LSASS dump or lateral movement confirmed: re-image the device. Do not trust AV remediation alone. Work with IT to provision a clean rebuild from gold image. Restore user data from backup only.
- 4Check the user's Entra ID account for credential compromise indicators (SOP-04 steps). Even if LSASS dump is not confirmed, attacker may have used a keylogger.
- 5Document: alert title, process chain, verdict (TP/FP), IOCs (hash, C2 IP/domain), device name, scope (single device or multi), remediation action, user notification sent.
Closure Checklist
- FP/TP verdict recorded with supporting evidence (process chain + network check)
- Device isolated (if TP) and investigation package collected
- Fleet scope KQL run — scope documented (single vs multi-device)
- LSASS/credential dump check completed
- Device remediated (AV scan) or re-image initiated
- User Entra account checked for compromise
For ransomware-level malware (mass file encryption, shadow copy deletion) escalate immediately to SOP-05. For confirmed credential theft escalate to SOP-04. Full SOP library at cyberhawkthreatintel.com/sops
◈ Stay Connected
Follow CyberHawk Threat Intel for threat intelligence, deployment guides and hands-on SOC tooling content.
"They can't exploit you if you are the Exploit."