Unpacking Dridex

Static Analysis

Starting off with some Basic Analysis, we can deduce the Sample is packed

1→ Basic Threat Intel

Possibly Dridex / Packed

---

2→ Basic Static Analysis

Though the entropy of the file is quite low, we can still find a black listed section text1, a noticeable difference in RawSize / VirtualSize with .rsrc section and size-of-code of 0bytes that makes it pretty obvious it's packed.

---

Dynamically Unpacking the Sample

1→

Starting off with putting breakpoints on

• VirtualAlloc() → to see if the sample allocates memory to copy the unpacked executable or the Shellcode responsible for decrypting/unpacking the actual payload.

• _VirtualProtect() →_if the sample changes a protection of a section/ region of memory.

2→

Run the debugger, we hit a breakpoint on VirtualAlloc(), with Execute Till Return [2], following the return value memory address returned from VirtualAlloc() , stored in EAX in Dump [2`], we can see the newly allocated region of memory [2``],

3→

Continuing on Run [F9], we can see an executable being written with normal sections and no .text1 section, though the PE header is a bit strange but this might be important to us.

4→

We hit VirtualAlloc() twice again so we repeat step[2] and investigate the two allocated regions of memory.

4`: Now we can see a similarity between Dump1 and Dump2, both are small, has similar strings and their code starts with the same sequence of bytes.

5→

That leaves Dump3 which is pretty different and is much larger, with a punch of interesting strings including ldr.exe which is what Dridex is known of. So we can go ahead and dump this out since it's still not mapped into memory.

// To make sure we go the right Dump, we would trace the execution until the Sample overwrite itself with the Unpacked Payload, then we use a tool like procexp or process hacker to dump the overwritten process.

To make sure we go the right Dump, we would trace the execution until the Sample overwrite itself with the Unpacked Payload, then we use a tool like procexp or process hacker to dump the overwritten process.

6→

Now that we've hit VirtualProtect() we can jump to user code and look for a jump [eax / reg] [6`] or push <reg/ address>,`` ret, since the process will overwrite itself with the unpacked executable it will need to jump to the entry point of the unpacked executable to run the Malware from there. Once we hit Run we can find Dump3 got moved [6``] which means that the process has overwritten itself with it, meaning this is the unpacked executable we are looking for and the other two Dumps are of no interest to us.

7→

Continuing on we hit a couple of VirtualProtect() calls then we hit the jmp eax breakpoint, stepping into that we find ourselves inside of Dridex' main function at offset 0x10000000, with hashes being pushed and a call to a function that compares some hash to [ESI] which could be the API Hashing routine used by Dridex to resolve APIs. Now we're confident we're inside the Unpacked Payload.

8→

Using Process Hacker we can dump the Memory Block at 0x10000000, which is now overwritten with the Actual Payload.

Since this Dump is mapped into memory we need to fix the Sections' Addresses to match the Virtual Addresses [7`] we dumped it from so the imports are resolved. Also fix the Image Base Address to match the process image's [7``]. I'll use PE-Bear for that.

To Summarize, Dridex used Self-Injection to overwrite it's process memory with the Actual/Unpacked Payload. Check this Overview on Self-Injection for more details.