Triage 5 Mock EDR Alerts — UprootSecurity Bootcamp

An EDR is only as useful as the decisions made when it fires. Most alerts are not clean "malware detected" events — they are behaviors that could be malicious or could be a developer doing something unusual but legitimate. Triage is the skill of looking at an alert, assessing severity, and deciding the right action: investigate, isolate, escalate, or tune. As a GRC Engineer you will not always be the first responder, but you must understand triage well enough to evaluate whether an organization's response process is sound and whether its alert decisions are defensible and documented.

For each of the five alerts below, choose the best triage decision. Every scenario has one best answer, and the explanation walks through the reasoning a good responder uses. Note throughout how each decision should leave a documented trail — that record is what proves the monitoring-and-response control actually operates.

The 2 a.m. 'possible ransomware' page

A quick triage frame

For each alert, ask three questions in order: (1) Is the behavior plausibly legitimate for this user/host? (2) What is the blast radius if it is real — what can the attacker reach from here? (3) What is the reversible-but-safe action — can I contain without breaking the business while I confirm? "Isolate the host" is almost always reversible; "wipe the laptop" is not. Bias toward containment you can undo.

Alert 1: Office document spawns PowerShell that downloads a payload

Quick check

An EDR alert fires on a finance employee's laptop: Microsoft Word spawned PowerShell with an encoded command that connected to an unfamiliar external IP and downloaded an executable. The employee is at their desk. What is the right immediate action?

Dismiss it — Office and PowerShell are both Microsoft tools, so this is normal

Isolate the host immediately, then investigate: this is a classic malicious macro / initial-access behavior chain, and containing the endpoint stops further download or lateral movement while you confirm

Email the employee and ask them to delete the file when they get a chance

Wait to see if more alerts fire before doing anything

Alert 2: Credential-dumping behavior on a domain controller

Quick check

An alert indicates a process on a Windows domain controller attempted to access LSASS memory in a way consistent with credential dumping (e.g., Mimikatz-style behavior). What is the appropriate response?

Low priority — domain controllers are internal, so this is not urgent

Treat as a high-severity incident: isolate/contain the DC per the IR plan, escalate immediately, and begin investigation — credential dumping on a DC can compromise the entire identity infrastructure

Tune the rule to stop alerting on LSASS access since it is noisy

Reboot the domain controller to clear any malicious process

Alert 3: Developer running a security tool — likely false positive

Quick check

An alert flags 'hacking tool / port scanner detected' on a security engineer's laptop. You confirm this engineer is on the internal red-team, the activity matches a scheduled authorized internal assessment, the tool is on the approved list, and the timing matches the engineer's calendar. What is the right disposition?

Isolate the laptop and open a major incident — a hacking tool was detected

Disposition as a false positive / authorized activity after verifying context, document the verification, and create a tuning exception (e.g., allow-list this tool for this user/group) to reduce future noise

Ignore it silently and move on without recording anything

Delete the security tool from the engineer’s machine

Alert 4: Mass file encryption in seconds — possible ransomware

Quick check

An EDR alert reports a single process on a file server rapidly renaming and rewriting thousands of files with a new extension within seconds. What is the priority action?

Wait for the backup job tonight and restore in the morning

Immediate containment: isolate the host and kill the process now to stop ongoing encryption, trigger the ransomware IR playbook, and preserve evidence — every second of delay means more files encrypted

Lower the alert severity because file servers handle lots of file changes normally

Restart the file server to interrupt the process

Alert 5: Low-confidence anomaly that needs investigation, not panic

Quick check

An alert flags an unusual but low-confidence event: a marketing employee's laptop made an outbound connection to a rarely-seen cloud domain at 2 a.m. There is no other suspicious behavior, no process-chain red flags, and the destination is unfamiliar but not on any threat-intel blocklist. What is the most proportionate response?

Immediately isolate the laptop and declare a major breach

Investigate before acting: review the process and connection context, check whether it is a legitimate app/update/sync or scheduled task, and only escalate to containment if evidence of malice emerges — documenting the finding either way

Dismiss it instantly since marketing laptops are low-value

Permanently block the domain for the entire company without checking what it is

What good triage looks like

Across these five, a few principles repeat — and they are exactly what you should look for when evaluating an organization's response process:

Severity drives speed. Credential dumping on a DC and active ransomware demand immediate containment; a lone low-confidence anomaly demands investigation first. Matching urgency to blast radius is the core skill.
Prefer reversible containment. Host isolation and targeted process-kill stop the bleeding without the irreversible cost of wiping or rebuilding. Reboots often destroy memory evidence — avoid them as a reflex.
False positives are dispositions, not non-events. An authorized red-team scan still gets verified, documented, and tuned. Tuning is what keeps the real alerts from drowning.
Everything is documented. Detected-at, triaged-at, contained-at, disposition, and rationale. That trail is simultaneously good incident response and the evidence that your monitoring-and-response control (SOC 2 CC7.2–CC7.4, ISO 27001 logging/response controls) actually operates.

When you review an EDR program as a GRC Engineer, you are checking that alerts route to someone, that severity maps to a defined response, that decisions are recorded, and that noisy rules get tuned rather than ignored. A pile of unacknowledged alerts is not monitoring — it is a finding waiting to be written.