Your EDR Fired an Alert. Here Is What to Do in the Next 60 Minutes.

The first thing to look at is not the alert details: it is the alert category. EDR platforms classify detections into technique categories that tell you immediately how serious the situation is before you read a single process name.

Highest urgency (respond immediately, assume active threat):

• Credential access or credential dumping (T1003)
• Defense evasion via process injection or tampering (T1055, T1562)
• Lateral movement via remote services (T1021)
• Command and control with active outbound connection (T1071)
• Ransomware behavior or mass file modification

High urgency (investigate within 15 minutes):

• Persistence mechanism installed (T1053 scheduled task, T1547 registry run key)
• PowerShell or scripting host executing encoded or obfuscated commands (T1059)
• Living-off-the-land binary (LOLBIN) used suspiciously (certutil, mshta, regsvr32)
• Suspicious parent-child process relationship

Medium urgency (investigate within 60 minutes, false positive more likely):

• Network scan activity from a workstation
• Reconnaissance commands (whoami, net user, ipconfig with suspicious context)
• Generic malware detection with no active behavior observed

Classify the alert into one of these tiers in the first five minutes. This determines your investigation tempo for everything that follows.

Every major EDR platform provides a process tree view for the alerted event. Pull it immediately. This is the single most important data source for determining true positive vs. false positive.

What to read in the process tree:

Start from the top of the tree: the parent process: and work down.

• Parent process: What launched the process that triggered the alert? A Word document launching PowerShell is a red flag. A scheduled task launching PowerShell at 2 AM with a known script hash is likely legitimate. The parent context resolves most ambiguity.
• Command line: What was the full command line for the alerted process? An encoded base64 PowerShell command is suspicious. powershell.exe -File C:\Scripts\backup.ps1 with a known hash is probably your backup agent.
• Child processes: Did the suspicious process spawn children? A process that spawned cmd.exe, wscript.exe, or net.exe is behaving like malware. A process that spawned nothing after execution is lower risk.
• File writes: Did the process write any files? Where? An executable writing a new executable to %APPDATA% or %TEMP% is a stage-two dropper pattern.

What to check for network context:

Pull the network connections for the alerted endpoint over the past 30 minutes. Look for:

• Connections to IP addresses in unusual geographies for this endpoint
• Connections to known-bad infrastructure (your threat intel feed or your EDR's built-in enrichment)
• Long-duration connections (minutes or hours) to unfamiliar IPs: indicators of C2 beaconing
• DNS queries to dynamically generated domain names (high entropy, random-looking TLDs)

You now have the process tree, command line, parent process, and network connections. Answer these four questions to determine whether this is a true positive:

Question 1: Is the behavior expected from this host? A developer workstation running obfuscated PowerShell is expected. A receptionist's workstation doing the same thing at 11 PM is not. Endpoint role matters. Check what type of machine this is and who uses it.

Question 2: Does the hash match a known-good file? Most EDR platforms enrich alerts with file hash reputation data. If the alerted process has a hash that appears in VirusTotal with 0/70 detections and has been seen on millions of machines, it is almost certainly a legitimate application that triggered a noisy rule. If the hash is unique or has high detection rates, it is suspicious.

Question 3: Has this alert fired before on this host? A recurring alert that has been closed as a false positive 15 times is probably still a false positive. An alert that has never fired before on this host for this process is more likely genuine. Check alert history before concluding.

Question 4: Is there a corresponding suspicious event in another log source? An EDR alert corroborated by a firewall block for the same endpoint at the same timestamp is much more likely to be a true positive than an isolated EDR alert. Check your SIEM for events from the same host in the same time window.

If you cannot answer all four confidently by minute 35: Treat it as a true positive and contain. The cost of a false containment is a brief user disruption. The cost of missing a true positive is an uncontained breach.

If true positive:

Contain the endpoint immediately using your EDR's network isolation feature. This severs the endpoint's network connections while maintaining your EDR connectivity so you can continue investigating remotely. Do not have the user reboot or shut down.

Document the containment time, the reason for containment, and who authorized it. This timestamp starts your incident timeline.

Escalate according to your incident response runbook. If you do not have one, follow the escalation path: your manager, your IR firm or insurer, and the system owner in that order.

While escalation is in progress, continue pulling artifacts from the isolated endpoint: additional process tree nodes, any files the malicious process created, scheduled tasks modified, registry keys changed, and network connections it attempted.

If false positive:

Document what the process was, why it triggered the alert, and why it is legitimate. This documentation is your justification for creating a suppression rule.

Create a targeted suppression: suppress by file hash plus parent process plus command line pattern: never suppress by process name alone. A suppression for powershell.exe blocks all PowerShell detections. A suppression for powershell.exe with hash abc123 launched by Task Scheduler with command line backup.ps1 suppresses exactly one legitimate behavior.

Check whether this false positive is likely affecting other endpoints: if the same legitimate software runs across your fleet, the alert is firing everywhere. Address the suppression fleet-wide.

If uncertain after 60 minutes:

Contain and escalate. Uncertainty at the 60-minute mark means the alert is sufficiently ambiguous that you need more investigation time than a single analyst's triage window provides. Contain now, investigate at the right tempo with the right resources.