Crimeware based Targeted Attacks: Citadel case, Part II

In this part II of our Citadel blog, we will take a closer look at how to better understand and detect this crimeware using basic techniques and tools. We will show how to identify the infection, and extract some useful information during the analysis. In our previous blog we explored how this campaign was launched as a low volume, targeted attack. The personnel targeted were in key financial positions, and as such we assume that financial gain was the biggest motive. 

'Citadel' is a variant of the Zeus crimeware toolkit (aka ZBot), and was first witnessed in late 2011 after the leak of the ZBot v2 source code. It is capable of a number of functions including stealing data, controlling the host machine, and performing DDoS attacks. It is important to understand the basis of how the initial infection occurs, before diving deeper into more complicated analysis.

Infection

The first thing we see is that it injects code into other processes. The injected code is ultimately responsible for everything that Citadel does and some basic system monitoring reveals how this occurs:

We see how the original file spawns a new process named 'beafy.exe', a randomly generated name that is dropped in the %APPDATA% folder. The new process then proceeds to inject code into explorer.exe and executes that injected code with CreateRemoteThread. The original file is sometimes deleted while the new process adds an entry to the Windows registry, allowing it to be run every time Windows is started.

Citadel then hooks important APIs in order to perform its tasks. We can figure out which APIs are being hooked by using volatility's apihooks tool:

vol.py -f /path/to/vmdump.vmem apihooks -p 620

And the output:

We can see that a push/ret style hook has been implemented on this API. The purpose of this hook is to intercept any data being sent from Winsock's send API, which can then be saved and sent to the bot's command and control (C&C) server. This could potentially contain important personally identifiable information (PII).

The hook is redirecting to code in an unknown module, so we then use volatility's malfind tool to find and dump the unknown region. We again specifically target explorer.exe:

vol.py -f /path/to/vmdump.vmem malfind -p 620 -D /path/to/memory/dumps/

One of these resulting dumps is a module (DLL) file, although analysis revealed that it was obfuscated/mangled and so static analysis was very limited. At this point, it is useful to extract all of the string references in these dumps using the Sysinternals strings tool:

strings -q -o /path/to/memory/dumps/*.dmp > /path/to/memory/dumps/strings.txt

The strings referenced contain a lot of garbage at first glance. However, some interesting ones include:

bc_remove bc_add config.bin Coded by BRIAN KREBS for personal use only. I love my job & wife. SOFTWARE\Microsoft\Tuyxr

All of these are unique to ZBot and it's variants, with the registry key having a randomly generated name.  The 'bc_add' and 'bc_remove' strings are typical ZBot commands, although usually they are encrypted. The amusing reference to Brian Krebs is unique to the Citadel variant in particular, and as such we can conclude that this is indeed Citadel. We could also verify this by doing a full memory search of an infected process (ie. explorer.exe, and searching for 'citadel', which should reveal references to 'citadelhost'.

By verifying that these strings do not show up in any clean processes, including a check on a clean explorer.exe, we can safely assume that we are good to create detection for this. So using YARA, we can create a signature to automatically find the reference to the Brian Krebs string:

Great! We now have a simple detection for Citadel.

Summary

We know that Citadel injects code into other processes, and Volatility has shown us some evidence of the malware. We have written a simple YARA rule to detect Citadel, but relying on a string reference is fragile, and we have yet to really dive into this crimeware to understand its true functionality.

In part III we will look into this malware in greater depth, aiming to understand its configuration and core behaviour.  We shall also present a more robust method of identification.