This is a follow up to the last post:

Malware Analysis #3: Hesperbot, Part 1

With some assistance from CERT Australia, it’s possible to identify this particular malware sample as Hesperbot, or at least a very close relative. This also matches their data about this particular campaign.

I’ll quickly go through the results of further analysis of the malware.

As I mentioned in the last post, the packer for this particular malware appears to be broken – a typical dynamic analysis of the binary simply fails with a “bad data” message and no other modifications of the system apparent:

Delving further into the issue, the “Bad Data” message comes from the C# TripleDESCryptoServiceProvider throwing an exception. The decryptor function is encapsulated within a try-catch block which creates a dialogue to display the output of any exception.

So why is an exception being thrown?

The data and key turned out to be okay, but the padding mode needed some tweaking. More specifically, setting to PaddingMode.None allowed me to extract the payload (The default padding mode for Microsoft’s TripleDESCryptoProvider is PKCS7):

However, things are still not quite right. The unpacking process goes something like this:

1. Extract encrypted data from bitmap.
2. Decrypt data
3. Bitwise XOR decrypted data with the encryption key
4. Reverse the decrypted data.

What seems to happen is that there is some leftover data appended to the end of the file, possibly during the encryption process. When the data is reversed, this data ends up at the beginning of the file before the PE header, meaning the file does not run properly when executed.

Once we strip those leading 14150 bytes from the start of the file, however, we get a .NET PE file:

Which gets even more interesting. Because at face value, there is nothing in this program except an empty Main function:

Yet how does such a small amount of code compile into such a large binary? On closer inspection, there are two .NET general metadata headers within the file:

In the stripped file, first is at location 0x0000025c and the second at location 0x0002ba22. Which is interesting, as generally a .NET program would only have one metadata header. This seems to indicate that there has been an attempt to inject a second assembly into the dummy program.

By delving further into the raw file and comparing with a known Hesperbot sample, it turns out there are Hesperbot functions hidden in there somewhere…

Hesperbot sample provided by CERT:

Sample extracted from the packer:

So far, however, I haven’t figured out how it’s supposed to access the embedded Hesperbot part of the program. Running the application directly does nothing but run the empty dummy program (No assembly instructions appear to have been injected) and loading the assembly as intended by the original packer also does nothing.

However, at least we can confidently identify this as Hesperbot, which is something, right?

If anyone has any insights / suggestions, feel free to get in touch! . Also, if you are interested in a copy of the binaries for your own research just send me an email and I’ll get them to you.

Final note: Have I made an error? If you have any feedback, please let me know! Use the ‘Contact’ link at the top of the page.