Some may say this is crazy, I call it Wednesday.

This came across my desk yesterday and I worked it out today. It came as the payload following a java exploit from an old 2012 CVE (SecurityManager one I think). I’m calling it 0day because there were no listing for the exe in VirusTotal / Malwr both packed and unpacked.

Initial inspection in IDA reveals an error:



This means the asshat who made this probably knew at some point, someone like me would be taking a look. There are actually quite a few modifications you can do to an exe that will mess up disassemblers but that windows will ignore.

Inspecting the exe with CFF Explorer, we see an error with one of the NT headers, specifically within ‘Data Directories’ at the Delay Import Directory RVA field. CFF is nice enough to highlight for us that the value 0x00000040 is wrong. Zeroing this out seems to fix it.



Saving the exe and re-opening in IDA, we no longer get the error and the thing open’s without a hitch.

A quick glance over the exe in IDA shows us its an MFC application. How do I know this? It says so right in the imports section under Library:

The application is of course, packed. Memory packed. No section header modification, just your typical memory pack.

What this means is that, static analysis is out of the question. We need to do dynamic analysis in order to probe further. Immunity away!

Before we get into immunity and the VM, there are a couple of interesting things inside the exe that aren’t immediately apparent in IDA, but show in CFF explorer. For starters, there are a couple files that stick out like a sore thumb hidden in the resources directory.

The first is a PNG file



And the second is an html file



Odd. Viewing the PNG file in IfranView (best image viewer ever BTW) shows a small black image, but it doesn’t add up as the image itself is 55 kb. Obviously something is hidden within. Stenography?



Next we have the HTML file. Loading it up (and cleaning it up) with notepad++, we see some sort of browser detection code:



Why this is in the resources section and not packed with the other code is a mystery, but keep the resources section in mind for later. Now lets get back to unpacking this thing.

First thing we do is load up Immunity debugger and Virtual Box, and load our anti-anti-debug python plugin.



Now we run the sucker and inspect memory after the thing has completed running:



I see a few memory ranges marked Read Write Execute (RWE). One at address 00910000, one at 00930000, one at 00940000, and lastly, one at 00970000. Inspecting a few shows us only 3 of the 4 contain programs. Still 3 programs hiding in 1? Cool beans.

Now we need to dump our programs from memory into a file for further analysis. Bringing up OllyDumpEx and feeding it our 0090 ranges, we see the programs at 0091000 and 00970000 match the original program based on their size, section headers and characteristics. The memory range at 00950000 however is different from the others. We see different section headers, different sizes. This must be our golden egg.

We’re going to dump the exe using the ‘Binary(Raw)’ dump mode instead of rebuild mode as to preserve the integrity of the dumped exe.



The 2 section headers are a dead give away that the program is packed with UPX. Running the upx utility against it confirms this. This means we can easily unpack our golden egg:



Our new exe is about 40 KB bigger and unpacked proper, so now we can finally take a peek inside with IDA. Taking a look at the strings, we see some interesting info.



What’s this? HTTP request info. Looks like this thing sends home to Mamma using POST requests.

But what about the C&C server you may ask? It doesn’t appear to be in plain text in our program. Remember what I said earlier about the resources section? Let’s take a peek in the resources section of our golden_egg.exe.

Bingo. http://31.207.6.161. How nice of the coder to leave this in plain text for us. Security through obscurity strikes again.