A verdict arrives fast: sandbox report generated, indicators extracted, write-up filed. Then the same sample turns up somewhere else and behaves nothing like your report says it should. Most bad malware analysis isn't caused by exotic anti-analysis tricks. It's caused by small, repeatable mistakes in how evidence is collected, interpreted, and recorded. Here are the ones that show up most often, and what to do instead.
1. Treating One Sandbox Run as the Final Word
Sandbox output is a first draft, not a verdict. Malware checks for virtualized hardware, odd CPU features, missing user artifacts, small disk sizes, and whether the mouse has moved at all. A sample that detects the environment and exits quietly produces a report that looks benign and is completely wrong.
Common tells that your run got cut short: a burst of anti-analysis calls with no network traffic, a sample that sleeps for ten minutes and hits your timeout, a process tree that ends at the loader and never spawns children. Extend timeouts well past a couple of minutes, detonate in more than one environment, and interact with the desktop instead of letting it sit idle. If the sample stays quiet everywhere, that's a legitimate finding — just say how hard you looked before you concluded it.
2. Abandoning Static Analysis Because the Sample Is Packed
"It's packed, so there's nothing to see" throws away useful intelligence. Identifying the packer matters: entropy per section, unusual section names, a tiny import table, an oversized resource directory. Those are clues about the builder, the campaign, and the malware family.
Unpacking is often less heroic than it sounds. Break on memory allocation or on the write-then-execute transition, dump the region once the stub has run, and rebuild the imports. Watch for payloads hidden in resources and in data appended past the last section. Even a partial dump usually exposes strings and API calls the packed binary was designed to hide.
3. Reading Strings and Imports as Conclusions Instead of Clues
Strings are leads. A hardcoded domain may be a decoy, a parked host, or a legitimate service the malware abuses. A URL that doesn't resolve today may have been live during the campaign. Treat every extracted string as a hypothesis to test, not a fact to publish.
Imports deserve the same skepticism. VirtualAllocEx alongside WriteProcessMemory suggests injection, but plenty of legitimate software does the same thing. Meanwhile the interesting behavior often hides behind GetProcAddress, ordinal imports, or hashed API names — which means a fast glance at the import table tells you almost nothing about capability.
4. Sloppy Sample Handling and Version Drift
If you can't prove which bytes you analyzed, your findings are anecdotes. Record the SHA-256 at intake, verify it before every run, and verify again after. Samples that unpack or self-modify on disk will change hash, so keep the original untouched and store derived artifacts separately.
Reset the snapshot every time. Keep analysis hosts off production networks. Never open a sample on the machine where your notes and credentials live. And if you're unsure whether you're allowed to hold or share a particular sample, resolve that before you touch it — handling rules sit inside policy and law, the details vary by jurisdiction, and the right move is to ask whoever owns that risk in your organization.
5. Confusing Shared Indicators With Attribution
Two samples talking to the same IP is a pivot, not a conclusion. Bulletproof hosting, compromised websites, rented infrastructure, and leaked builder kits all produce overlapping indicators across unrelated actors. Reused mutexes and campaign identifiers are stronger signals, and even those aren't proof.
Pitch your claims at the level the evidence supports. "This sample contacts infrastructure also seen in an earlier intrusion" is honest. "This is the same group" is a different claim and needs more than a shared string. Where you do speculate, label it as speculation and note what evidence would confirm or kill the theory.
6. Notes That Nobody Can Reproduce
The test of good documentation is simple: a colleague with the sample and your notes should reach the same conclusions without asking you a single question. Screenshots alone fail that test, because they show a moment without the configuration that produced it.
Capture at minimum:
- SHA-256, original file name, and where the sample came from
- Date and time in UTC for every observation
- Environment details: OS build, VM or hardware, network setup, real versus simulated internet
- Tool names, versions, and the exact commands or settings used
- Raw artifacts — packet capture, process logs, memory dumps — not only your summary
- Hypotheses you tested, and the ones you couldn't
Timezone sloppiness belongs here too. Mix local time and UTC in one timeline and your beacon interval looks random while your "first seen" timestamp is off by hours. Pick UTC and stay with it.
7. Stopping at the Dropper
Many samples are loaders. They decrypt a payload, inject it, and disappear. Analyze only that first stage and you'll document an installer while missing the actual capability: persistence, command-and-control protocol, exfiltration format.
Go get the next stage. Dump injected regions, proxy or hook the network to capture retrieved payloads, then run the full analysis again on whatever comes down. Repeat until you reach something stable. Only then is your behavior list complete enough to write about with confidence.
Before You Write the Report
Run this short check while the analysis is still fresh and the evidence is still on disk:
- Does the hash I hold match the hash I analyzed?
- Did I run it in more than one environment, long enough to clear sleep timers?
- Is every claim traceable to a raw artifact?
- Have I separated observed facts, inferences, and speculation?
- Would a colleague reach my conclusion from my notes alone?
Nobody gets this perfect on every sample. The point is to make your mistakes visible and correctable instead of baking them into a conclusion someone else will trust. Slow down at the two places where errors are cheapest to catch — intake and write-up — and the messy middle gets far more reliable.
Photo: vickygharat / Pixabay
