Dissecting ShadowHammer

Today I had the pleasure of dissecting Shadow Hammer for together with our top malware analyst at InfoGuard(@InfoGuardAG) Stefan Rothenbuehler (@creative83).

ShadowHammer is a piece of malware that was distributed in a supply chain attack mimicking ASUS security updates. Once the malicious update explodes on the target system it loads various libraries it uses to determine the mac addresses of the machine. Only if the MAC address matches a set of predefined addresses it will actually load the next stage and infect the machine.

Sample
setup.exe
Sha256
9a72f971944fcb7a143017bc5c6c2db913bbb59f923110198ebd5a78809ea5fc

While some of the functionality is already well documented we feel like it would make sense to show how you can get the hashes out of the malware. Stefan and myself also want to make sure to do this writeup in an educational fashion. That might lead to some “overdocumenting” at some points. So skilled malware analysts out there, please bear with us.

Finding the malicious part

This sample as a little bit more complex as it contains benign code as well as the malware code.

When starting the analysis using static methods like Ghidra, the functionality of ShadowHammer is not immediately observable as it only executes once the benign part of the software update finished executing. The malware author placed the entry point of the malware just before the Process exit into the __crtExitProcess function. We tagged the function accordingly in win32dbg.

Entry Point to malware

So how do we get there. Using the Symbols tab in win32dbg, we see that the file uses the VirtualAlloc and VirtualProtect function from kernel32.dll. Whenever we find those functions used by a binary we want to look at them more closely. Stefan pointed out a nice way to set a useful breakpoint at the end of the function. This way the eax register shows the target address of the memory allocation. When found jump into the code for Virtual Alloc and set a breakpoint right before the function returns. There are more of those but number 2 is the one you want to look at (just to save you some time).

Search for VirtualAlloc

If you start single stepping through the code from there entering all functions that are not API functions you will eventually end up at a place where you see two calls to GetAdaptersAddresses. The first of the two compares the eax register to 0x6f which is 111 in decimal. This return code would indicate a bufffer overflow. We believe that this fires, if the number of interfaces the machine maps is too high to fit the provided buffer.

The second call is followed by test eax, eax which is true when eax is 0x0. This is the desired return coda as it indicates that we now got our interface structures successfully loaded into the buffer.

Reading the adapter data

After that we are in a loop that creates the md5 sum of every interfaces mac address and stores it to the memory using memcpy. In my case when I dump the source for the memcpy operation the first 16 bytes should the md5 sum of one of my adapters.

The bytes I get are:

93 16 DF 71 02 90 78 CB 6E 33 9C BE 12 0B 1F 49

The mac address for my only adapter is:

00-0C-29-F3-94-EA

Checking that using Cyberchef proves that we got the right data there.

Cyberchef translates my mac address to the correct md5

So now that we see that the malware stores the md5 of our mac addresses, the question is, what does it compare it to?

To figure that we need to keep on stepping. I put a breakpoint shortly before my current function returns. and single-step from there. Eventually you will find a set of memcmp instructions in several loops. they compare the memory space filled with your adapter’s macs to the macs the attacker is looking for. It will compare 0x10 or 16 dec bytes in two memory locations. That’s the size of an md5 sum.

memcmp call to compare md5 sums

So argument one and two are eax and esi. They are on top of the stack so we can easily load them into the data dump window. esi contains our values and eax the value hardcoded in the malware.

My hashed mac address
One of the hashes the malware compares it to

This was just a very short tutorial on how to extract the hashes. For the above sample we have done that for you already at InfoGuard. Find the list at https://www.infoguard.ch/de/blog/shadow-hammer-mac-adressen-hash-liste

We will keep dissecting the malware and post more soon.

Copyright Cyberfox 2019
Tech Nerd theme designed by Siteturner