The SOC hands you a suspicious .exe pulled from a user's machine. What's your FIRST analysis step?
Short answer
Begin with static triage in an isolated environment: compute hashes, pull strings, inspect PE headers and imports, and check reputation, so you understand the sample before risking execution. Running it on your own workstation can infect you and the network. Uploading client samples with identifying names leaks sensitive data to third parties. Deleting it destroys the evidence and the chance to build detections.
When the SOC hands you an unknown binary, the interviewer is testing whether you reach for information before action. A disciplined analyst never executes first — they learn everything they safely can while the sample sits inert.
Why static triage comes first
Static triage extracts evidence without running the code. You compute cryptographic hashes (so you can correlate with threat intel and track the exact sample), pull strings (URLs, mutexes, registry paths, embedded commands), inspect the PE headers and import table (which APIs it links suggests capability — networking, crypto, process injection), and run a reputation lookup. In minutes you often know whether the file is known malware, packed, or something novel — all without exposing a single system. That knowledge then shapes a safe dynamic run later.
Why the other options are wrong
- Double-click it on your workstation. This is the classic junior mistake. Your analysis box is on the corporate network; live malware can encrypt files, beacon out, or move laterally before you learn anything useful. You become patient zero.
- Upload to every public sandbox with the customer's name in the filename. Public sandboxes share submissions. Embedding a client name leaks that the client was targeted, what tooling they use, and potentially regulated data — a real confidentiality and contractual breach. If you submit at all, strip identifying metadata and follow data-handling policy.
- Delete it. Deletion destroys the one artifact you need. Without the sample you cannot build IOCs, write YARA rules, or determine scope, and you blind the SOC to an active threat.
What interviewers look for
A strong answer names concrete static steps and the safety reasoning behind them: isolation, hashing, strings, PE/imports, reputation — then a plan to detonate safely afterward. The hallmark of good judgment here is patience: you treat the binary as evidence to be preserved and understood, not a curiosity to click.
Likely follow-ups
- Which PE header fields or imports would make you suspect packing or injection before you ever run the sample?
- Why is uploading a client sample to VirusTotal sometimes a data-handling violation, and how do you mitigate that?
- How do hashes and strings from static triage feed the detections you hand back to the SOC?