Crimeware based Targeted Attacks: Citadel case, Part III
Posted by ngriffin on 28 April 2014 08:20 AM
In our previous blog (part 2 in this 3 part series), we outlined how Citadel infects a host machine, and we extracted some string references that we used to detect it via YARA. However, we have yet to really understand how this crimeware works and the risk it poses.
In this third part, we will dive deeper into the analysis and try to extract Citadel's configuration settings, as well as write more solid detection code.
A good start for our analysis is to look for any suspicious network traffic, so let's monitor our system for exactly that:
We observe that explorer.exe is communicating with an external server over HTTP! This is definitely suspicious. Let's see what was sent and received:
It appears that something related to configuration is being downloaded. The filename is declared as 'config.dll' but there is no PE header in the payload, and we cannot trust what the server is saying. Whatever the content is, there is a good chance it is encrypted.
In order to see how the payload is handled, we need to debug explorer.exe and set a breakpoint on Winsock's send and recv APIs. The idea is to see when the target URL is being requested via send, receive the data with recv, and then set a hardware access breakpoint on the received HTTP payload. We can then run the program and track how the received data is accessed, including memory copies that we will also hardware breakpoint. Using this method, we should eventually end up in the final decryption routine:
We can see here that the final decryption routine is a simple XOR that works backward through the data. This subroutine might be a good opportunity for a new YARA rule, but let's come back to that later.
We need to find a reference to the size and the beginning of the decrypted payload so that we can dump it after it is decrypted. A good way to find this information is to start again and set a breakpoint on the decryption routine before it is executed. In this example, the EAX register should start off as the size of the payload, and EAX+ESI should finish as being the beginning of it.
Now that we have the location and size of the decrypted payload in memory, we can go ahead and dump that memory region to file:
The configuration file contains a header (marked in red) and then blocks of data (marked in blue) with their own headers and payloads (marked in green). The header of the file contains 20 random characters, followed by the size of the whole file (0x9A64), flags, the amount of blocks in the file (0x7F or 127), and finally an MD5 hash. The block headers have an identifier that describes the payload (0x00004E21 means version), flags (0x10000000 means optional), compressed size (0x04), and raw size (0x04). The block payload then follows, which we see as 0x01030501. This is the version number of the configuration file. We can probably assume then, that we are looking at Citadel version 18.104.22.168.
If we look further down the file, we can see some unreadable payloads:
The start of the block is marked, and we can see that the flags are 0x10000001. The flag 0x01 means that the payload is compressed. We can also see that the compressed size of 0x47 is smaller than the raw size of 0x6B. Citadel/Zbot uses the NRV2B compression algorithm, and we can write a simple tool to loop through all of the blocks to decompress them.
Our tool also outputs each block in a human-readable format. Additionally, Zbot configurations usually declare HTTP injections to conduct on specific webpages, and these are also parsed and formatted correctly. As a result, we see some interesting configuration options (we have replaced http with hxxp to prevent hyperlinks):
There are definitions here for the bot download URL (LAST VERSION URL), and the data extraction URL (URL SERVER), as well as some HTTP 'filters.' It is possible to screen record, screen capture, or ignore a website or webpage(s) using these filters. There is also a large DNS list, which is used for overriding the host's DNS lookup, presumably to prevent an infected host from being able to visit an antivirus website, or to redirect users to a malicious host.
Further down the file, we see the list of HTTP injections to perform, including this one:
A URL is declared, which can contain wildcards for matching any URL path or domain name. There are also flags that specify how to capture data (i.e., GET data and/or POST data). We then have information about what code to look for on the webpage, and the injected code to insert at the location where that code is found.
In this example, a popular banking website is affected. The normal webpage has the following fields:
The injected code makes the page appear differently:
To an unsuspecting victim, there is nothing too alarming here. The modification looks legitimate, and asking for a customer's memorable word is a somewhat believable security measure. However, when the information entered is submitted to the login form, it is captured and sent to the data extraction server.
So we know how Zbot downloads and uses its configuration file, and this is a key function of the trojan. However, more functionality can be called with remote commands. These remote commands exist within an array of strings that Zbot uses for its core functionality. Another tool of ours can find this array in memory, and then decrypt and dump the strings in C-style formatting. Here are some of the more interesting strings:
Note: It is not feasible to target these strings with a YARA rule as they remain encrypted until used.
We can see here that browser, email, and FTP related information is referenced. Due to the nature of the string references, we can assume that sensitive private data is being targeted for extraction.
Also in the string dump are the command declarations for the bot:
There are 45 commands in total for this particular Citadel build. Among other things, it can shut down the host's OS, update itself, block URLs, involve itself in DDoS attacks, and extract data on demand.
Clearly Citadel has a lot of functionality, and its ability to encrypt and decrypt data on the fly means that relying on a YARA rule that targets a string is weak. The decryption routine we found earlier might be a better target for a more generic detection. Zbot, Citadel, and other variants use this same decryption routine, and it is a solid foundation from which we can write a detection.
So here is our new, updated YARA rule:
Citadel is a feature rich toolkit that mostly targets personal information. The intended victims of this attack, detailed in part 1 of this blog, were top personnel in key financial positions. This makes plenty of sense, because decrypting Citadel's configuration file and the strings it uses reveals how and what it targets in more detail, including banking information and login credentials. The author of this attack was probably aiming for financial gain above all else.
Finally, Citadel's ability to add and change code on-demand makes it a huge security risk once it has infected a host machine, but disabling it may be as simple as removing the start-up entry from the Windows registry. Additionally, creating a YARA rule for detection is fairly straightforward and should provide a solid foundation for identifying Citadel and Zbot variants in the future. Even if the decryption routine changes, we now have a good understanding of how the trojan works.
Read more »
Crimeware based Targeted Attacks: Citadel case, Part II
Posted by ngriffin on 24 April 2014 11:45 AM
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.
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.
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.
Read more »