Uriel Kosayev, co-founder of TrainSec Academy and author of MAoS: Malware Analysis on Steroids and Antivirus Bypass Techniques, pulled a random sample from MalwareBazaar and landed on something worth dissecting: a WannaCry dropper variant carrying a trick that breaks common static analysis tools. In this post, he walks through the full static analysis workflow from the video: from initial triage to tracing three layers of nested droppers and identifying the anti-analysis technique hiding in plain sight. Whether you are doing threat research or sharpening your reverse engineering fundamentals, the techniques here apply to dozens of dropper families beyond WannaCry.
Why WannaCry Variants Still Surface in 2026
WannaCry exploited CVE-2017-0144 (the EternalBlue vulnerability in SMBv1), and the original worm spread globally in May 2017. What makes new samples interesting is not the core ransomware logic (that code is well understood), but how modern threat actors wrap and repackage the dropper chain to evade detection. The sample analyzed here was tagged on MalwareBazaar with WannaCry indicators and confirmed on VirusTotal with dozens of detections referencing MS17-010. The behavioral telemetry in VirusTotal’s sandbox tab was sparse, which is itself a signal: low TTP coverage suggests active anti-sandbox techniques. Understanding how malware really works beyond surface-level detections is essential when working with samples like this.
How to Start: Triage Before You Open IDA
Before loading anything in a disassembler, confirm what you have.
Open the file in HxD and verify the MZ magic bytes at offset 0. Confirm the PE signature (PE\0\0) and the presence of named sections (.text, .data, .pdata). If .pdata exists, debug symbols may not have been stripped, worth noting for later reconstruction.
Next, upload to VirusTotal. On this sample:
- CVE-2017-0144 / EternalBlue (MS17-010) confirmed across multiple engines
- Classified as a Trojan Dropper by most vendors
- Relations tab shows connections to IPs with community negative scores; zero-detection IPs are not automatically clean, especially when community votes flag them and the sample is confirmed malicious
Load the file in PE Studio and CFF Explorer to confirm architecture (64-bit DLL) and subsystem (console). PE Studio’s file-size-ratio column is worth checking: if the resource section dominates the file, that section is almost certainly a container for the next stage.
What Detect It Easy Reveals About Entropy and Packing
Detect It Easy gives you per-section entropy alongside the overall verdict. A file can appear unpacked overall while containing one high-entropy section. On this sample, the resource section shows elevated entropy; the .text and .data sections are within normal range. That pattern points to a dropper rather than a fully packed binary.
Per-section entropy is more useful than the headline score. A packed installer has high entropy everywhere; a dropper typically has clean code sections with a single compressed or encrypted resource.
How to Find and Extract the Embedded Payload with Resource Hacker
Load the file in Resource Hacker. The resource section contains a binary blob that starts with MZ: another PE file. This is the classic WannaCry dropping pattern: the next-stage payload lives inside the resource section and is extracted at runtime.
Export it using Save Binary Resource. Before analyzing the exported file, open it in HxD and check offset 0.
Why Your Analysis Tools Break: The Garbage-Byte Trick
The exported file does not start at offset 0 with MZ. Garbage bytes are prepended to the file before the MZ header. Any tool that reads a PE from the start of the file (CFF Explorer, Detect It Easy, older versions of PE Studio) will fail to parse it or report an unrecognized format.
To recover the file, open it in HxD, locate the MZ signature, remove all bytes before it, and save. After trimming, CFF Explorer, Detect It Easy, and IDA all load correctly.
This technique is simple and effective. It stops automated sandbox parsers and catches analysts who do not inspect raw bytes before loading. Uriel noted that he has seen this trick in several post-2017 WannaCry variants; it is cheap to implement and imposes real cost on the analyst. The same principle of obscuring structure to delay static analysis appears in other ransomware families analyzed in the DarkSide and LockBit case study on EDR evasion.
How the Dropping Mechanism Works in IDA Pro
With the first-stage DLL loaded in IDA Pro, look at the exports. There are two: DllMain (the standard entry point) and a named export. Navigating to that export reveals the dropping logic in a single, focused function.
The dropping function calls FindResourceW, LoadResource, LockResource, and SizeofResource in sequence to locate and map the embedded payload, then writes it to disk with CreateFile and WriteFile, and executes it with CreateProcess.
Use cross-references (Ctrl+X on LoadResource) to count how many places in the code call this sequence. A single cross-reference means one dropped file. Multiple cross-references mean multiple dropped files: know the count before deciding you have seen everything.
What the Multi-Layer Dropper Chain Looks Like
Repeat the extract-trim-analyze cycle on the second-stage file. Its resource section also contains a blob with elevated entropy. Extract it, check for prepended bytes (this layer does not use the garbage-byte trick), and repeat the Resource Hacker inspection.
The third-stage file is a 32-bit PE with a GUI subsystem (an executable, not a DLL). Its resource section entropy is within normal range and the section ratio is not dominated by the resource. Open it in Resource Hacker and you will find a PK magic number: a ZIP archive. The string WannaCry appears in the resource data nearby.
This is the canonical WannaCry final-stage structure: a ZIP-protected archive with a hardcoded password containing the ransomware PE files and ancillary components. The password has not changed across many variants. Attackers repackage the outer dropper layers, but leave the inner payload intact. The approach closely mirrors the dropper behavior documented in the Mirai botnet reverse engineering walkthrough, where the core payload is wrapped by successive layers that handle evasion while the inner logic stays unchanged.
What This Means Practically
- Open every dropped file in HxD before loading it in a disassembler. Garbage bytes before the MZ header are invisible to automated parsers; only raw hex inspection catches them.
- Use Detect It Easy’s per-section entropy view rather than the headline score. Clean overall entropy does not mean the resource section is clean.
- Cross-reference Windows API functions like
LoadResource,CreateFile,WriteFilein your disassembler / decompiler to enumerate all dropped files before analyzing any single stage. Missing a drop means missing a stage. - Treat sparse behavioral telemetry on VirusTotal as a positive indicator of anti-sandbox techniques, not evidence the sample is benign.
- Do not base threat decisions on VirusTotal IP detection counts alone. Check community score and the relations tab for connections to other confirmed malware.
Make sure to watch the above video and get the hash of the sample in the description of the video.
Keep Learning: Malware Analysis Courses at TrainSec
If you want to build a structured methodology for dissecting samples like this, the Malware Analyst Professional Level 1 course covers PE header analysis, static triage, unpacking, and dynamic analysis in depth, taught by Uriel himself. For advanced techniques including custom unpacking and EDR evasion research, continue with Malware Analyst Professional Level 2 (Both are available in a discounted bundle MAoS: Malware Analysis on Steroids).
