> For the complete documentation index, see [llms.txt](https://ghostinthehive.gitbook.io/ghostinthehive-as-a-ghost-in-the-hive/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ghostinthehive.gitbook.io/ghostinthehive-as-a-ghost-in-the-hive/windows-and-malware/malware-dissecting/unpacking-dridex.md).

# Unpacking Dridex

## <mark style="color:red;">**Static Analysis**</mark>

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

### **1→ Basic Threat Intel**

Possibly Dridex / Packed

<figure><img src="/files/Au7bLeayKeU6q2zbtLIf" alt=""><figcaption></figcaption></figure>

***

### **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.

<figure><img src="/files/eiCQC0EJXeigGXFOsC6j" alt=""><figcaption></figcaption></figure>

***

## <mark style="color:red;">Dynamically Unpacking the Sample</mark>

**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.

<figure><img src="/files/p8DvxUhveH4g2lFol4Hj" alt=""><figcaption></figcaption></figure>

**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\`\`],

<figure><img src="/files/FbwsvDlcEsuNa7aPb7Fe" alt=""><figcaption></figcaption></figure>

**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.

<figure><img src="/files/VndumdDBClmQR7GnZR5g" alt=""><figcaption></figcaption></figure>

**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.

<figure><img src="/files/2nYU0VFildOzxKbXHfgO" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/MQ4Yx7HLJ9KGKPjTapHU" alt=""><figcaption></figcaption></figure>

**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.

<figure><img src="/files/Dh546t6Y9JJRmmvV7hqG" alt=""><figcaption><p>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 <code>procexp</code> or process hacker to dump the overwritten process.</p></figcaption></figure>

**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.

<figure><img src="/files/cnxilT9mbwO0LEiWU0yY" alt=""><figcaption></figcaption></figure>

**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.

<figure><img src="/files/W6ySWTZ01X5JHi1fZKLm" alt=""><figcaption></figcaption></figure>

**8→**

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

<figure><img src="/files/JDGD1tYR4IEOnysRkuzV" alt=""><figcaption></figcaption></figure>

> 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**](/ghostinthehive-as-a-ghost-in-the-hive/windows-and-malware/windows-internals/malware-evasion-through-injection-pt1.md#self-injection) for more details.
