In depth analysis of Caphaw/Shylock from “FirefoxUpdate.exe” campaign – Part 2

Welcome to the second part of our analysis of Caphaw/Shylock. In the first chapter we have gone through the dropping and unpacking stages of this malware. In this second part we will go through the remaining HSE:: Step(s) – in particular we will see how the previously gathered information will be used, the network interactions between the bot and the Command and Control Server and finally how Caphaw injects its malicious code inside explorer.exe process.

Please note that the encryption key is composed of a dynamic part (DGA generated domain) and a static string given by ca5f2abe. Such key building scheme will allow the receiving DGA generated domain to decrypt the POST data, because the domain name is in itself a piece of the encryption key, the remaining shared secret is given by the static string ca5f2abe.

As you can see .NET CLR version 1.0.5718 is composed by the 4-digits-hash version. The user-agent depends on previously computed hash (which can be considered as an Indicator of Compromise) will allow the server to evaluate the consistency and authenticity of the request.

Since we are dealing with DGA, it’s a very common situation that the requested domain is offline, for this reason Caphaw needs a to reiterate the request until an active domain replies. In the core (the component we are analysing now) this attempt is restricted to a limited number of attempts, while in the explorer.exe injected code we will see a thread dedicated to this specific scope.

We have finished the very long Call 00EE48DB (please refer to the first part of the article) that characterised the HSE::Step 5. In synthesis this call:

Collects information about the victim in order to build a POST request.

Generates via DGA the domains where stolen data will be sent.

Encrypts the collected details.

Contacts and sends POST request to the malicious domains.

We are now again inside the main call, as usual we will consider only the most significant calls.

HSE::Step 8 is functionally characterised by the installation of a method to remain persistent after reboot, in order to grant that FirefoxUpdate.exe will be executed during each system reboot. Call 00EE9B6E can be synthesised as follows:

RegOpenKeyA("Software\Microsoft\Windows\CurrentVersion\Run")
RegQueryValueExA(HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run)
If entry does not exists then build a string like this one:
C:\Documents and Settings\<user>\Application Data\Microsoft\Internet Explorer\mmc.exe
mmc.exe file is a copy of FirefoxUpdate.exe binary.
RegOpenKeyA("Software\Microsoft\Windows\CurrentVersion\Run")
RegSetValueExA(HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run)

The path and binary name of the new copy could arbitrary change for each infection, in this way Caphaw attempts to disguise itself, making intelligence activities based on research of static artefacts a little more difficult.

HSE::Step 9 can be resumed by the call 00ED635F which retrieves PID of explorer.exe by enumerating processes via CreateToolhelp32Snapshot() method. Immediately after, we reach HSE::Step 10 which is the last one.

This time size matches with the first VirtualAllocEx that has PAGE_EXECUTE_READWRITE protection, this means that we have a block of executable data (Code), we can follow the code in the dump window to observe the source buffer.

An entire PE is injected inside the target process, its whole memory region is executable.

Here it happens an interesting thing: CloseHandle API used by explorer.exe will be patched, more precisely we have a patch 7 bytes long, let’inspect Buffer parameter:

0012F6BC 90 NOP
0012F6BD 68 0000BE00 PUSH 0BE0000
0012F6C2 C3 RETN

Once reached, RETN execution jumps at address 0BE0000, which is the block of code previously injected via WriteProcessMemory. This is how Caphaw performs Code Injection and executes its own code inside explorer.exe!

7 bytes of CloseHandle() will be patched,

this is how Caphaw performs code injection

inside explorer.exe

The first time that CloseHandle will be called by explorer.exe the execution will jump to the Caphaw malicious code. It is worth to note that the patched API isn’t always CloseHandle, under different circumstances (different OS) the chosen API could change.

All 10 HSE Steps are now completed, malicious code analysis will now continue in explorer.exe.

How to approach and debug the injected code

How do we proceed in order to analyse the injected code?

If we execute the last WriteProcessMemory (the one that patches the API) explorer could call at any time CloseHandle and the malicious code would be automatically executed. As you can see from the 7 disassembled bytes, the landing address is ‘leaked’ -> 0BE0000 this means that we have an address where to set a breakpoint. The first operation is to open another explorer.exe instance inside Olly and locate this leaked address (ctrl + G), set a breakpoint and let explorer run normally. We can now go back to the dropper and execute the patching WriteProcessMemory – the debugged explorer instance will hit the breakpoint right away.

Conclusions

In this second episode we have seen the information gathered and how they are encrypted, how networking activity is performed by Caphaw and finally we have analyzed its code injection capability. We are at 2/3 of our path toward the complete analysis. In the next final episode we will deal with the code injected in explorer.exe. We will meet again DGA algorithm and networking stuff, but this time we will follow another branch. Finally we will also take a glance to Caphaw/Shylock’s configuration and webinjects.