The Signature Matched.
Now Prove It Actually Ran.
A static process reference for the alert that fires when EDR, AV, or a sandbox flags a file or process as malicious: what to check first, how to separate a true positive from a false positive, when to escalate, and what to contain immediately. Scoped to this one alert, not a full incident lifecycle. For writing a detection rule off the sample, see the YARA guide; for deeper sample analysis, see MAL-OPS.
Alert Overview
This is the alert nearly every SOC sees on a daily basis, in one form or another. The trigger source changes how much you trust it before you've looked at anything else.
Common Trigger Sources
EDR/AV detection on file write or execution └── The endpoint tool flags a file the moment it's written to disk, or the moment a process tries to run it // the most common trigger, and the broadest in scope, quality depends heavily on tool and policy Hash match against a known-malicious sample └── The file's hash matches an entry in a threat intel feed, whether a public source like VirusTotal or an internal blocklist // high confidence on its own, but only as good as the feed it was checked against Behavioral detection ├── Process injection, an unusual API call sequence, or a LOLBIN abuse pattern └── The tool isn't matching a signature here, it's matching a pattern of behavior // catches malware a signature would miss, but also catches legitimate tools doing something unusual Sandbox verdict from an email or web security gateway └── An attachment or downloaded file was detonated in a sandbox before it ever reached the endpoint, and came back malicious // the file may never have executed on the actual host, check delivery status before assuming compromise
Initial Triage Steps
Five checks, done in this order, before deciding anything about severity or escalation.
Working The Alert, In Order
1. Identify what was actually detected ├── Pull the file hash, the process name, and the detection type: signature match, behavioral rule, or ML model verdict └── The detection type changes how much weight the alert carries on its own // a raw ML confidence score needs more corroboration than a straight signature hit 2. Identify execution context ├── Parent process, full command line, user context (SYSTEM vs a standard user), and the file's origin └── Origin means download, email attachment, USB, or network share, not just where the file sits now // the same binary is a different alert depending on what launched it and who was logged in 3. Check whether execution was blocked or completed ├── Confirm if the tool quarantined or killed the process, or if it ran to completion └── A completed execution changes the scope of the entire response // a prevented file write and a fully executed payload are not the same alert 4. Check for lateral indicators ├── Did the process spawn child processes, open outbound connections, or touch other hosts └── Any of these turns a single-host alert into a scoping exercise // don't close the ticket until this question has an answer either way 5. Check prevalence ├── Is this hash or file seen on other hosts (a mass campaign) or only here (a targeted drop) └── Prevalence tells you whether this is commodity malware or something aimed at this environment specifically // a targeted drop deserves more scrutiny than volume alone would suggest
True Positive Indicators
Signals that consistently point to real malicious activity, on their own or stacked together.
TRUE POSITIVE
Known-Malicious Hash Match
Confirmed identity, not a guess
The file hash matches a sample already catalogued by VirusTotal, an internal detection feed, or a paid threat intel source. This is about as close to certainty as triage gets. Treat it as a true positive unless there's a documented reason the hash is a known false positive.
TRUE POSITIVE
Unusual Parent-Child Process
Office spawning a shell is never normal
winword.exe, excel.exe, or another Office process spawning powershell.exe, cmd.exe, or wscript.exe almost always means a macro or embedded object ran malicious code. Legitimate documents don't need a shell.
TRUE POSITIVE
Active Behavioral Flags
The tool is describing behavior, not just a signature
Code injection into another process, calls to credential-access APIs like reading LSASS memory (T1003.001), or registry writes tied to a known persistence technique mean the sample is doing something, not just sitting on disk. Behavioral detections carry more weight than a static match alone.
TRUE POSITIVE
Malicious File Origin
Where it came from matters as much as what it does
A file that arrived as a phishing attachment or was pulled from a drive-by download on a low-reputation site has already failed the trust test before execution. Combined with any other indicator here, close it as a true positive.
TRUE POSITIVE
LOLBIN Abuse Pattern
Legitimate binary, illegitimate use
certutil.exe fetching a remote file (T1105), mshta.exe executing inline script (T1218.005), or rundll32.exe calling an export it has no business calling (T1218.011) are known abuse patterns, not edge cases. Match the command line against a LOLBAS reference before dismissing it as benign tooling.
False Positive Indicators
Signals that usually mean the detection logic fired, not that anything malicious happened.
FALSE POSITIVE
Signed Binary, Heuristic Misfire
The vendor is legitimate, the detection logic isn't perfect
A properly signed binary from a known vendor gets flagged by a behavioral heuristic that's simply too broad. If the hash already has a documented false-positive entry on file, close it as such instead of re-running the same investigation every time it fires.
FALSE POSITIVE
Sanctioned Internal Tooling
The tool is working exactly as intended
An approved red-team utility or admin script trips the same detection logic it was built to validate. Confirm it's on the approved tooling list and that the activity lines up with an expected window or ticket before closing it out.
FALSE POSITIVE
Fully Preventive Block
Nothing happened after the block, because nothing could
The control stopped execution before it started, and a follow-up sweep shows no child processes, no network connections, and no file system changes. A clean prevention with no downstream activity is the strongest false-positive signal available.
Escalation Criteria
The three conditions that move this from a triage ticket to something bigger.
ESCALATE
Execution Succeeded, Post-Exploitation Behavior
The block failed, so the response can't be routine
If the sample ran to completion and shows further activity, network connections, credential access, additional process spawns, hand this to IR immediately. Triage is done; containment and investigation take over.
ESCALATE
Multiple Hosts, Same Indicator
A pattern, not a coincidence
The same hash or behavioral signature appearing on more than one host at the same time is a campaign, not three separate alerts. Escalate as a single incident and pull in whoever owns cross-host correlation, don't triage each host in isolation.
ESCALATE
Ransomware Or Wiper Family Match
The highest-priority path on this list, no exceptions
If the sample's static or behavioral signature matches a known ransomware or wiper family, escalate immediately and treat every minute as lost ground. Once confirmed, hand off to the dedicated Ransomware IR playbook rather than continuing generic malware triage from here.
Containment Actions
What to actually do once the alert is confirmed as a true positive, in the order that limits damage fastest.
CONTAIN
Isolate The Affected Host
Cut network access before anything else
Pull the host off the network, whether through NIC disable, port isolation, or an EDR-enforced quarantine. This stops lateral movement and outbound exfiltration while the rest of triage continues.
CONTAIN
Kill The Process, Preserve Evidence First
Speed matters, but not at the cost of losing the record
If the malicious process is still running, terminate it. Where the tooling allows a memory capture or disk snapshot first, take it. A killed process with no evidence behind it makes root-cause analysis much harder later.
CONTAIN
Hunt Across The Environment
One alert rarely means one host
Search for the same hash, file path, or behavioral indicator across every endpoint the tooling can see. A single detection is often the first visible instance of something already sitting on other machines.
CONTAIN
Rotate Exposed Credentials
Only when credential access actually happened
If the process made calls consistent with credential theft, LSASS access, browser credential store reads, cached credential dumping, rotate the credentials that were reachable from that session. Skip this step for detections with no credential-access behavior; rotating everything by default just creates noise.