It's the kind of alert that shows up at the worst hour: an EDR flags an executable dropped by an email attachment, the sandbox queue already has six samples ahead of it, and someone upstream wants a verdict in five minutes, not forty. Detonating it is the right long-term answer. It is also not an option right now. So the question becomes: what can you actually learn from this file without running a single instruction of it?
More than most people expect. A PE file's import table lists every external function the binary declared it might call, resolved by name at load time. You don't need to execute anything to read it, and it tells you what the program was built to be capable of, whether or not it ever gets the chance. Some combinations are worth recognizing on sight. VirtualAlloc, WriteProcessMemory and CreateRemoteThread showing up together is the classic process injection triad: allocate memory in another process, write code into it, start a thread there. WinHttpOpen or InternetOpenUrl next to URLDownloadToFile reads as a downloader. Heavy CryptAcquireContext and CryptEncrypt usage is worth flagging before you know anything else about the sample. None of this proves malicious intent by itself, plenty of legitimate software calls these same functions, but it narrows what you're looking at and what dynamic analysis should actually go check.
The more interesting case is when the import table doesn't show you much at all: a handful of entries, mostly LoadLibraryA and GetProcAddress, nothing that looks like real functionality. That's not a boring binary. That's a binary resolving its real imports manually at runtime specifically so a static import table won't show them, which is standard packer and custom-loader behavior. The thinness of the table is itself the finding. Pair that with section entropy: legitimate native code sections tend to sit somewhere in the middle of the range, while a section pushing toward the high end of Shannon entropy per byte is almost always compressed or encrypted content, which is exactly what a packed payload looks like before it unpacks itself in memory. A binary with a sparse, uninformative import table and one section entropy reading way higher than the rest isn't ambiguous. It's a sample that is actively trying not to be read statically, and that itself is enough to justify spending real sandbox time on it instead of the five other things in the queue.
This is the actual shape of triage under time pressure: read the header, read the imports, check entropy, and use those three things to decide what dynamic analysis needs to answer, rather than detonating everything with equal priority because nobody looked first. Static analysis doesn't replace dynamic analysis. It tells you which dynamic questions are worth asking, and in what order, when the queue is backed up and someone is waiting on an answer.
That triage instinct, reading a PE file cold and knowing what the header, imports and entropy are actually telling you before committing to a sandbox run, is exactly what the Static and Dynamic Malware Analysis Guide builds from the ground up, lab setup included: https://resources.codelivly.com/product/practical-malware-analysis-guide/
Top comments (0)