Enough malware analysis to make a decision

Why this matters

You are not expected to be a reverse engineer. CS0-004 expects an analyst who can take a suspicious file, establish enough about it to decide what to do, and know when the answer requires somebody else.

That framing is the useful one in practice too. Malware analysis on an incident has a purpose — it tells you what the thing does, what else to look for, and how bad this is. Analysis that does not change one of those three answers is a hobby being funded by an incident, and the clock is running.

The lesson

Static triage: strings, hashes, signing

Static analysis examines the file without running it. It is fast, safe, and answers a surprising amount.

Hashing comes first. Compute SHA-256 and look it up in a reputation service. Three outcomes, each meaning something different:

• Known bad, with a family name — you have your answer in seconds, plus public reporting describing what it does and what indicators to hunt for.
• Known good, matching a legitimate signed binary — likely a false positive, or a legitimate tool being abused, which lesson 7's living-off-the-land point makes a real possibility.
• Unknown. Neither, which is the interesting case: targeted malware is unknown by design, and "no detections" is not reassurance.

One warning the exam likes: uploading a sample to a public service publishes it. The file becomes visible to subscribers, including the attacker, who may well be monitoring for their own sample's hash. Uploading is a disclosure decision, and during a targeted intrusion it can be the thing that tells the adversary you have found them. Hash lookups are safe; file uploads are not automatically so.

Strings extracts readable text from the binary — URLs, domains, IP addresses, file paths, registry keys, command lines, error messages, mutex names, and sometimes whole scripts. It frequently gives you the command-and-control destination and the persistence mechanism in one pass, which is most of what a responder needs. Expect packed or obfuscated samples to yield little; that absence is itself a signal.

Signing answers whether the file carries a valid digital signature, and whose. Useful, with a caveat: a valid signature means the publisher is who they claim, not that the file is safe. Stolen and abused code-signing certificates are a well-established technique, and signed malware exists in quantity.

Other quick static observations worth taking: file type versus extension (a .pdf that is a PE executable), compile timestamp, imported functions (crypto, networking, process injection APIs suggest capability), embedded resources, and entropy, where uniformly high entropy suggests packing or encryption.

Detonation in a sandbox, and sandbox evasion

Dynamic analysis runs the sample in an instrumented, isolated environment and records what it does: files written, registry changed, processes spawned, network contacted, persistence installed.

Its advantage over static analysis is decisive against packed or obfuscated code — the sample has to unpack itself to run, so behaviour is observable where the file contents were not.

What to take from a sandbox report, in priority order for a responder:

1. Network destinations — domains, IPs, URLs, and the protocol. These are what you hunt with.
2. Persistence installed, which is what you must remove.
3. Files created or modified, especially in startup and system locations.
4. Processes spawned, and whether it injects into others.
5. Credential or data access attempted.
6. Family classification, if the sandbox recognises it.

Sandbox evasion is the limitation to state clearly, because a clean sandbox report is routinely over-trusted. Malware commonly checks whether it is being watched and does nothing if it thinks it is:

• Environment checks for virtualisation artefacts, hypervisor traces, analysis tools, or small disks and low memory.
• Time delays — sleeping past the sandbox's observation window, which is usually minutes.
• User interaction requirements: no mouse movement, no documents in Recent, no real browsing history means no execution.
• Domain or geography checks, which is why targeted malware often does nothing anywhere but the victim's network — and why a sandbox verdict of "benign" on a sample found during a live intrusion proves very little.
• Command-and-control dependence. If the server is down or the sample needs a key from it, the interesting behaviour never happens.
• Staged payloads, where the sandbox sees only a downloader.

So: a sandbox that shows malicious behaviour is proof; a sandbox that shows nothing is not. That asymmetry is the exam point and the practical one. It is the same shape as every other claim in this course — a negative result from a test that could have failed to see the thing is not evidence of its absence.

Extracting indicators worth hunting on

The output that justifies the analysis: a set of things to search your estate for, per lesson 13.

What to extract, and what each is worth:

• Network indicators — domains, IPs, URLs, user agents, JA3/TLS fingerprints, and the beaconing interval. Generally the most immediately useful, because they find other infected hosts fast.
• File indicators — hashes, filenames, paths. Hashes are precise and trivially changed; a path an implant always uses is often more durable.
• Host artefacts — registry keys, service names, scheduled task names, mutex names. A unique mutex is an excellent hunting indicator and is rarely varied.
• Behavioural indicators — the parent-child process chain, the command-line pattern, the injection technique. Hardest to write, hardest for the attacker to change, and the most durable, which is the pyramid of pain's whole point.

Practical guidance:

• Hunt the estate immediately with what you have, before analysis finishes. A network indicator in hand is worth more searched now than refined later.
• Judge each indicator's specificity before deploying it. Blocking a legitimate shared CDN because a sample used it is a self-inflicted outage, and it happens.
• Feed indicators into detections, not just a block list, so the next occurrence alerts rather than silently failing.
• Record their provenance — which sample, which incident, which date — so they can be expired. Indicator lists nobody prunes become noise, and then they become ignored.

Knowing when analysis stops changing the response

The judgement this lesson exists to teach, and the exam does ask it as a scenario.

Analysis should continue while it can change a decision. Ask directly:

• Does this change containment? If you already know the host is compromised and it is isolated, further detail about the payload may change nothing.
• Does this give more indicators to hunt with? The strongest reason to continue, and the one that most often justifies another hour.
• Does this change scope? Discovering worm-like spreading, or credential theft, or data staging changes what you search and who you tell.
• Does this change the severity or the notification position? Whether the sample exfiltrates data may decide a regulatory clock, per lesson 26.
• Does this change eradication? If it installs persistence you have not yet enumerated, yes.

Stop when the answer to all of those is no. Specifically, you can usually stop when you have: the network indicators, the persistence mechanism, the capability at the level of "steals credentials / encrypts files / provides remote access", and a family identification if one exists. Rebuilding the host, which is the default from lesson 32, makes many remaining questions moot.

Conversely, keep going — or escalate to a specialist — when the sample is novel and targeted, when attribution or legal proceedings matter, when you must prove what data was accessed, or when the same unknown implant is widespread enough that you need a reliable detection rather than a hash.

The failure this guards against is real and common: an analyst disappears into a disassembler for a day while the containment decision waits and the attacker works. Deep analysis is valuable and it is rarely urgent, and separating those two is most of what this section is for.

Handling samples safely

The operational hygiene, which matters because the mistakes are irreversible.

• Never execute a sample on a production system, or on your own workstation, or on anything joined to the domain. Detonate in an isolated environment with no route to anything you care about — the lab from lesson 2.
• Isolate the network, or accept that detonation contacts the attacker's infrastructure from your address space, which announces you.
• Snapshot before, revert after. Never reuse an analysis environment across samples without reverting.
• Store samples in an encrypted, password-protected archive, with an obvious marker in the filename. This is convention rather than security: it stops the file being executed by accident, and stops the mail gateway or the EDR deleting the evidence — which is a routine way of losing a sample.
• Neuter filenames — rename to .malware or similar — so a double-click cannot run it.
• Control access. A sample is dangerous, and it may also contain the victim's data.
• Think before uploading, per the disclosure point above.
• Record chain of custody as for any other evidence, per lesson 31, since a sample can end up in a legal process.

One last point, because it costs people their week: handling and transporting a sample is when it gets run by accident. Nearly every infection of an analyst's own machine is a naming and handling failure rather than an analysis one, which is why the conventions above exist and why they look disproportionate until the day they do not.

Topics this lesson owns

• [x] Static triage: strings, hashes, signing
• [x] Detonation in a sandbox, and sandbox evasion
• [x] Extracting indicators worth hunting on
• [x] Knowing when analysis stops changing the response
• [x] Handling samples safely