Malware Triage in 5 Minutes — A First-Responder Checklist

A SOC analyst gets a ticket: “EDR flagged update_helper.exe on a finance laptop.” The file is sitting in a sandbox folder. The user says they don’t recognize it. The clock starts.

The next 5 minutes determine whether this becomes a contained workstation-level event or a 3-day investigation. Get triage right and you have a defensible escalation path, useful IOCs for hunting across the rest of the fleet, and a clear yes/no on isolation. Get it wrong and you either escalate every false positive (burning analyst time) or contain reflexively (destroying evidence and tipping off attackers).

This is the first-responder checklist — what to do in the first 5 minutes, in order, with the explicit decision points that say “escalate now” or “keep triaging.”

The 5-minute triage objective

Triage is not analysis. The goal is not to understand the malware fully — it is to answer four questions well enough to make the next decision:

1. Is this binary malicious? (yes / no / unknown)
2. What family or capability class is it? (ransomware loader, infostealer, RAT, dropper, legitimate misclassified)
3. What is the blast radius? (single user / lateral / persistence already established)
4. Do I escalate, contain, or close?

Five minutes is the discipline. If you cannot answer those four questions in 5 minutes, the answer to question 4 is “escalate” and you hand off to a deeper analysis workflow.

Step 0 — Don’t execute it (yet)

Before anything, verify the file is in a state where you cannot accidentally execute it. That means: copied off the host into a quarantine share with no execute permission, hash recorded, original location and host noted in your case-management ticket.

The single most common rookie mistake is double-clicking the binary to “see what it is.” That detonates it on the analyst’s own workstation. The first-responder principle: the file does not get launched until you decide to launch it in a controlled environment.

If the EDR has not already quarantined the file, request the file from the host via your EDR’s “request file” capability — that gives you a copy without changing access timestamps on the host’s filesystem, which matters for any later forensic work.

Step 1 — Hash and lookup (60 seconds)

Calculate three hashes (MD5, SHA-1, SHA-256). MD5 and SHA-1 are deprecated for security but ubiquitous in threat-intel feeds, so include them for compatibility.

1sha256sum update_helper.exe
2sha1sum update_helper.exe
3md5sum update_helper.exe

Take the SHA-256 and look it up — without uploading the file itself:

• VirusTotal (hash search via https://www.virustotal.com/gui/file/<sha256>)
• AbuseIPDB / MalwareBazaar / ANY.RUN public report search
• Your internal threat-intel platform if you have one

Three outcomes:

• Known-bad with multiple AV hits and a recent first-seen date → you have a commodity sample. Skip ahead to capability classification (step 4).
• Known-clean (signed by Microsoft, hash in the goodware list) → likely false positive but verify by digging into why the EDR flagged it.
• Unknown hash → continue with static analysis. Do not upload the file yet.

The reason “do not upload yet” matters: if the file is a targeted-attack tool unique to your environment, uploading to public VT tips off the adversary, who actively monitor VT for their own hashes appearing. Bespoke malware authors use VT as their canary.

Step 2 — Static signature checks (60 seconds)

Run a fast static scan to grab the obvious indicators without executing anything:

 1# basic file type + headers
 2file update_helper.exe
 3exiftool update_helper.exe
 4
 5# Authenticode signature — is it signed? by whom?
 6sigcheck.exe -i -h update_helper.exe   # Windows
 7osslsigncode verify update_helper.exe  # Linux
 8
 9# PE header inspection
10pe-bear update_helper.exe              # GUI; CLI alternative: pefile (Python)
11
12# Strings — pull all printable ASCII and Unicode strings
13strings -n 8 -a update_helper.exe > strings.txt
14strings -n 8 -a -e l update_helper.exe >> strings.txt  # UTF-16LE

What you are looking for in the first pass:

• Signature: signed by a known-good publisher (Microsoft, Adobe, etc.) with a valid certificate chain? Strong signal toward false-positive. Self-signed or no signature? Stay suspicious.
• Compile timestamp: legitimate software usually has a sensible recent timestamp. Older malware sometimes has obviously-fake timestamps (year 2000, year 2038).
• Sections: a PE with a writable + executable section, oddly-named sections like .UPX0, or a tiny .text section and a huge .rsrc section is suspicious.
• Imports: presence of VirtualAlloc, CreateRemoteThread, WriteProcessMemory, WinExec, CryptEncrypt together is a strong code-injection or ransomware signal.
• Strings: URLs, IP addresses, registry paths under Run keys, PowerShell command fragments, base64 blobs, ransom-note language.

The deliverable from step 2 is a short bullet list of indicators that lets you make the static-confident vs needs-dynamic call.

Step 3 — CAPA capability classification (60 seconds)

CAPA from Mandiant maps PE imports + strings to capability classes — “this binary encrypts data,” “this binary persists via run-key,” “this binary communicates over HTTPS.” It runs in seconds against a static file.

1capa update_helper.exe

Sample output that resolves your triage in 10 seconds:

ATT&CK Tactics:
  TA0002 Execution      | Command and Scripting Interpreter (PowerShell)
  TA0003 Persistence    | Registry Run Keys
  TA0005 Defense Evasion| Obfuscated Files or Information
  TA0011 C2             | Application Layer Protocol (HTTPS)
  TA0040 Impact         | Data Encrypted for Impact

When CAPA returns “Data Encrypted for Impact,” “Registry Run Keys,” and “Application Layer Protocol C2” — your triage answer is “ransomware-loader-class binary with persistence and C2.” That is enough to declare an incident and trigger containment without ever running the file.

When CAPA returns nothing interesting or shows generic capabilities only — escalate to dynamic.

Step 4 — Dynamic detonation in a sandbox (when needed)

If static was inconclusive and the hash is unknown, detonate in a sandbox. Two approaches:

• Cloud sandbox — ANY.RUN, Joe Sandbox, Hatching Triage, VMRay. Upload the file, get a 2–3 minute behavioural report with network captures, dropped files, registry changes, and screenshots of the user-visible behaviour.
• Local sandbox — a snapshotted Windows VM on an isolated network (or with a fake-internet appliance like INetSim or FakeNet-NG). More controllable, no public exposure, but takes longer to spin up.

Use the cloud sandbox if the file is not too sensitive to upload and you need an answer in 5 minutes. Use the local sandbox if the file is bespoke or contains environment-specific data.

What you are watching for:

• Network: any outbound connection. Note the destination (IP, domain, port, protocol).
• File writes: persistence (Startup folder, scheduled tasks, services), staging (temp directories), or impact (mass file rename = ransomware).
• Process tree: spawned children — cmd.exe, powershell.exe, rundll32.exe, regsvr32.exe, mshta.exe. Especially squamous if the parent is something innocuous like Office or a PDF reader.
• Registry: HKCU\Software\Microsoft\Windows\CurrentVersion\Run writes, scheduled task registration, WMI subscription creation.
• User-visible behaviour: ransom note? fake update prompt? credential theft form?

The dynamic step produces concrete IOCs (domains, IPs, file paths, mutex names, registry keys) that you immediately use for the next step.

Step 5 — Hunt with the IOCs (60 seconds)

Take every IOC from static + dynamic and run them against your SIEM and EDR:

• File hashes → search all endpoints for any process that ever executed a file with this hash
• Network IOCs → search proxy / firewall / DNS logs for connections to the C2 destinations
• Registry keys → search EDR telemetry for any host that has those keys present
• Parent-child process patterns → search EDR for the same execution chain on other hosts

This is the step that turns triage into containment scope. If the IOCs only fire on the originating host, the blast radius is one machine. If they fire on three other hosts, you have a lateral-movement situation and the incident severity escalates.

Step 6 — Sigma rule + threat-intel write-up

Convert what you found into a Sigma rule for ongoing detection. Sigma is the YAML-based generic SIEM rule format that translates to Splunk, Elastic, Sentinel, etc.

A minimal Sigma rule for the process pattern you found:

 1title: Suspicious Office Spawning PowerShell with Encoded Command
 2status: experimental
 3logsource:
 4  product: windows
 5  category: process_creation
 6detection:
 7  selection:
 8    ParentImage|endswith:
 9      - '\WINWORD.EXE'
10      - '\EXCEL.EXE'
11    Image|endswith: '\powershell.exe'
12    CommandLine|contains: '-enc'
13  condition: selection
14level: high
15tags:
16  - attack.execution
17  - attack.t1059.001

Save the rule to your detection-as-code repo, push to the SIEM, and add the hash + IOCs to your TIP. This is what turns this incident from “one ticket” into “improved detection forever.” It’s the Post-Incident-Activity NIST phase happening in real time.

When to stop triaging and escalate

Escalate (don’t keep triaging) when any of these are true:

• The hash has zero AV hits and zero VT history (likely bespoke / targeted)
• The binary shows anti-analysis behaviour (sandbox detection, debugger detection, packed with a custom packer)
• The IOC hunt shows the file is on more than 2 hosts
• Static analysis suggests capability beyond what a first responder can confidently classify (kernel driver, signed-binary abuse, novel persistence mechanism)
• The user is a high-value target (executive, finance approver, sysadmin, IT contractor with admin rights)
• Anything ransomware-class, even a single-host hit

When you escalate, the package you hand over is: original file (in quarantine), all hashes, sigcheck output, strings output, CAPA report, dynamic sandbox report, IOC list, hunt results, and your written 4-question assessment. That packet is what the next analyst needs — without it they will redo every step you just did.

What ECIH actually tests

The ECIH v3 exam covers malware triage as part of the Detection & Analysis phase (the NIST 800-61 lifecycle you already know). Expect:

• Order-of-operations questions (“what is the first step when a file is suspected of being malicious?”)
• Decision questions on when to upload to public sandboxes
• IOC-classification questions (file hash vs network IOC vs behavioural IOC vs YARA rule)
• Tool-to-purpose mapping (CAPA, YARA, Sigma, MITRE ATT&CK)
• Scenario questions where the right answer is “preserve evidence before executing”

The exam loves the “do not modify the file before hashing” trap question. The right answer is always: hash first, copy second, analyze third.

What to read next

If you came here because you need to actually build the playbook this triage feeds into, go to Building an Incident Response Playbook from Zero.

If the triage is suggesting ransomware and you need to make the containment call, Containment Decisions Under Pressure covers the trade-offs.

If the triage tells you you need real forensics (not just live response), Post-Incident Forensics vs Live Response is the decision matrix.

And if you need to image the host afterward to preserve evidence, Disk Imaging in Forensics — dd vs FTK Imager vs Autopsy is the next step.