September 10, 2026
Malware Analysis Diary #01 — What I Look at First in a PE File
The first rule I gave myself: never open a sample in a debugger until I’ve asked the file some basic questions first.
By Pratik Gurav
1 min read
Jumping straight into dynamic analysis is tempting. But static triage tells you whether something is even worth your time and it keeps your environment cleaner, longer.
Here's my actual first-look checklist when a suspicious PE lands in my queue.
1. File Type & Architecture Before anything else: file command output and bitness. A 32-bit binary behaves differently than 64-bit. Mismatched architecture hints at polymorph or multi-stage delivery.
2. PE Metadata & Compiler Signals Hash the sample immediately (SHA256 primary, MD5 for legacy threat intel). Check compile timestamp, Rich Header fingerprint, and subsystem type. The Rich Header often reveals build environment critical for clustering related samples.
3. Sections & Entropy Scan section names (.text, .data, .rsrc, or anomalies like .ndata). Load into DIE and check entropy per section. Anything above 7.2 in executable sections gets flagged. Size mismatches (raw vs. virtual) signal compression or encryption.
4. Entry Point & Imports Where does execution start? Examine the import address table minimal imports paired with heavy LoadLibrary/GetProcAddress usage means runtime resolution hiding. That's a red flag.
5. Resources & Strings Resource sections (.rsrc) often hide payloads or configuration. Quick string extraction can reveal URLs, registry keys, or API calls before you touch a debugger.
6. Packing Indicators Entropy spike + stripped imports + overlay data = likely packed. Tools like UPX leave signatures; others require deeper inspection.
Static triage is not the finish line. It's the filter before the real work begins.
Follow my GitHub for YARA rules built from workflows like this one: Yara-rules at https://github.com/pratik0x/yara-rules