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

We are finally at the end of our Caphaw/Shylock analysis. This time we will deal entirely with the code injected into explorer.exe process, the context will be a little more complex than previousepisodes because we will work within a multithreaded environment. The injected code will identify an active domain (DGA based) in order to download other executables (binary update for example), modules and the botnet configuration which leads to httpinject. The latter component will contain the Web Injection (HTML/JS) code used to modify banking portals via MiTB (Man in The Browser) attacks.

Authors

Exploring the Injected Code

In the second episode we left the analysis immediately after the API patched code lead us to the injected code, we are now inside explorer’s malicious code. We will keep an eye on functional analysis, so we will try to skip the non-essential parts, this means that we will not deal with every spawned thread, but only with the most important ones. Analysis will be done by inspecting every thread twice:

New-Thread event ON -> will give an overview of the whole thread’s structure and relations between them.

New-Thread event OFF -> in order to follow without interruptions every single thread.

This block of code could be considered the starting point of the code injection, where, in other words, the execution flow lands after the patched API is called. The scope of the above reported code is to:

Restore the original API code.

Open a new branch of execution.

It should be clear now that altering the code of a function introduces the risk of instability for the entire system, so it’s mandatory that once we get into the malicious code, the original API completes its work. At the same time, if we give back execution to the original code, we will loose the possibility to run the malicious one. For this reason it’s necessary to create a new execution branch and this is achieved by creating a new thread. From a reverse engineering point of view we need to catch this secondary execution branch, it’s pretty easy in this case: we can setup a Pause on New Thread event and reach RETN which calls the original API code.

Resolves a few APIs addresses and place them inside the injected PE, in other words it builds a pretty basic IAT and immediately after it fixes the executable base address. The code that belongs to the injected executable will be used later on.

Here we go, that’s an old friend: as you should remember, in the Core component we used to see “HSE::” – now we have “HPA::”. call 017FE7A9 will resolve API addresses used to perform networking operations, we have already seen some of them in use like InternetConnect, HttpSendRequest etc. but as you should remember in the previous case Caphaw was unable to reach an active domain. Here the idea is to check the other networking APIs used, in order to catch a different execution branch, more precisely let’s see which API is used in case we get to an active domain so we can place a breakpoint on it. Among the resolved APIs addresses we have:

InternetReadFile

InternetQueryDataAvailable -> “Queries the server to determine the amount of data available.”

InternetQueryInfoA

The first one is pretty interesting for our scopes “Reads data from a handle opened by the InternetOpenUrl, FtpOpenFile, or HttpOpenRequest function.” – this implies that if we want to track/analyse what happens when a file is downloaded, we can place a Breakpoint on InternetReadFile.

Call 017F7DB0 invokes CreateThread API, as previously seen, let’s place a breakpoint on the StartAddress, that in our case is 018041e6. Immediately after call 017F7DB0 we reach the end of Call 01805696 and another RETN (end of the thread). Let’s see the handle table situation:

As you can see from the red rectangle this thread has spawned some Events. Let’s take a look at the next thread:

New thread – The hooking

This thread is responsible of the hook installation and works essentially in two steps:

Establish if the process is a browser (Firefox or Internet Explorer) or not (Explorer.exe).

This check-and-hook thread begs the question – how code is injected into browsers or other processes? – answer is pretty simple and verifiable by setting a breakpoint on WriteProcessMemory. Suddenly emerges that the method adopted is identical to the one previously seen to inject the malicious code into explorer.exe -> allocate and copy some code in the victim process then patch an API to reach this block of code.

Basically this thread loops around a WaitForSingleObject until its status returns something different from WAIT_TIMEOUT, we can leave it running by placing a breakpoint immediately after the JE. After a while we will be brought back to thread 14, and more precisely inside 01804099 (previously reported). There are no notable actions from a functional point of view, except a CreateThread that leads to the execution of thread 20.

Call 00B248DB creates a certain number of Events, the names adopted follows the already analysed rule: encrypt(MD5_EVT_*) for more information please check episode 2. In order to get to the next important step, we need to land in one thread after the current one.

Configuration and WebInjects

Every (valuable) banking trojan adopts a Configuration and WebInjection system:

WenInject: Contains the HTML/JS code to be injected into the browser via MiTB (Man in The Browser).

We will take a look to both these components, which are served by the DGA based domains previously seen, this implies that the configuration and webinjects need to be dowloaded. As suggested by the previously seen networking APIs, let’s place a breakpoint on InternetReadFile. When InternetReadFile is executed, it means that Caphaw has received a correct response from the DGA domain and something is returned back. Let’s see the “download manager” structure:

We have the botnet name (“net1” in this case), multiple C&C server URLs as <url_server url=”URL”/> and finally <httpinject> that contains the WebInject URL path and its MD5. This configuration could contain also references to additional plugins in the form:

Usually the web injection component (httpinject, as it is called by Caphaw itself) is delivered as binary data which is encrypted/compressed in order to disguise the injected HTML/JS and reduce the size of the file itself.

Identificator #3 with the constant 00001021 (if you can’t get it, simply google for xor with 00001021), clearly it indicates that call 0194C6DD computes a sort of CRC, the value is finally placed in EAX.

httpinject is now decrypted. We avoid to report the content of CALL 0194F131 on purpose since it’s very long and essentially it decompresses the previously decrypted data by using Zlib 1.2.3. The presence of a compressed element can be also confirmed by using binwalk:

As previously seen, this trojan makes use of Mutexes and spawns a lot of Events, by inspecting explorer.exe via ProcessHacker:

The first highlighted mutex uses the already seen MD5 Hash (please note that this named mutex matches with the configuration decryption key). A single hash based mutex name means nothing, but associated with the second entry, it provides a valid indication.

Such event names clearly help to raise the level of suspicion.

Hooks:

We can use WinDbg to discover installed hooks and in a very easy way. Caphaw injects code into Internet Explorer process, this implies that in the address space of this process we will find traces of infection. Hooking means that the original API code needs to be modified in order to alter the normal execution flow. In other words a hooked function looks different from a “clean” one, enumerating all modules and looking for differences between the symbol and the actual function should do the job: