Citadel is a sophisticated descendent of the Zeus botnet. In this two-part article, Aditya Sood and Rohit Bansal provide insight into the bot's design components, including its system infection and data exfiltration tactics. In this, the second part of the article, Aditya and Rohit present the results of their experiments.
Copyright © 2014 Virus Bulletin
Recent years have seen a significant rise in cybercriminal activities, and in particular the theft of online banking credentials. The majority of cybercriminals use automated exploitation frameworks to infect computers and exfiltrate data. The most widely used weapons in this type of cybercrime are botnets. Botnets have been in existence for many years, but their design frameworks have changed over time. We are now seeing a third generation of botnets that are targeting the users of online financial services. This era of targeted attacks started with the rival Zeus and SpyEye botnets and is evolving. In this paper, we look at the design and working details of the Citadel botnet. Citadel, which is believed to have European origins, is a sophisticated descendent of the Zeus botnet. Our analysis provides insight into the design components of Citadel, including its system infection and data exfiltration tactics.
In the first part of this article we looked at Citadel's design and implementation. In this concluding part we present the results and analysis of our experiments.
In this section, we present the results of the experiments we conducted on the Citadel botnet in order to understand infections in progress.
As a part of our experiment, we visited malicious domains serving Citadel. In addition to tracking phishing emails, we queried the malware domain repositories to find the live malicious domains. As Citadel implements geo IP filtering, it was a challenge for us to get hold of a sample. We used VPN servers in different countries so that our requests would be initiated from IP address ranges belonging to the same country as that in which Citadel was hosted. Figure 1 shows that we received the Citadel binary after after successfully accessing the malicious domain from our virtual environment. Once we had dumped the traffic into a pcap file, we performed offline analysis. We extracted the raw data from the pcap files using TCP session stream analysis and used tools such as foremost to get the binary.
As discussed earlier, our goal was to create a virtual environment for behavioural and static analysis including disassembling and debugging. When we extracted the executable and allowed it to install in the virtual environment, it failed. This is because Citadel has an anti-emulation checker that detects the presence of a virtual machine and halts its execution. We noticed a strange behaviour as our virtual machine started sending fake DNS traffic to non-existent domains. That is, we found that Citadel generates a large amount of fake traffic if it is installed in a virtual machine. In addition, it also knocks at the gate to communicate with the C&C, but it will not get any response if present in a virtual machine. We believe that this tactic is used to confuse honeypots and cause traffic anomalies. Figure 2 shows some of the fake DNS traffic encountered during our experiment. The structure of the domains suggests that a Domain Generation Algorithm (DGA) is active. DGAs are basically used for generating a set of seemingly random domain names, one of which is registered by the bot herder for C&C communication. The majority of generated domains result in NXDomain responses.
For behaviour analysis, we created a test environment without a virtual machine and installed the bot on it. Once the bot had successfully been installed, it needed to connect back to the C&C. As discussed earlier, the bot first knocks at the gate before the redirection happens for the downloading of the configuration file and the executable. Figure 3 shows the communication. The bot interacts with the ‘file.php’ gate file by sending a POST request with encrypted content. After that, Citadel issues another POST request to ‘file.php’ to determine whether the ‘config.bin’ file can be fetched. Once the gate has validated the request, Citadel issues a GET request to download the ‘config.bin’ file in order to update the configuration in the infected system.
The Citadel bot is a ring 3 rootkit that installs itself in the user layer of the operating system and controls other applications using a technique known as hooking. Hooking allows the bot to intercept the communication flow among different applications running in the user space and alter their execution accordingly. The bot possesses the following characteristics:
For installation, the bot begins wrapped up within a dropper. The dropper is what was downloaded from the malicious domain. After the dropper has been downloaded onto the infected machine, it melts away, resulting in the extraction of the bot. (‘Melting’ refers to a process of self destruction in which the primary executable deletes itself after extracting the compressed content.) Citadel has a built-in batch code that performs the melting, as shown inFigure 4 .
The dropper extracts the executable in the application directory ‘%APPDATA%’ with a random name. At the same time, a ‘Run’ key is created in the registry, containing a reference to the random executable (Citadel) in order to start it on every (re)boot of the system. Listing 1 shows the structure of the files and directories created by the dropper.
C:\Documents and Settings\Administrator\Application Data\[random] C:\Documents and Settings\Administrator\Application Data\[random]\[random].exe C:\Documents and Settings\Administrator\Application Data\[random]\[random].tmp HKCU\Software\Microsoft\Windows\CurrentVersion\Run Listing 1: Files and directory structure created by Citadel.
After this, Citadel is executed in the system. Citadel infects the primary explorer.exe process by creating a remote thread so that explorer becomes the primary process and the malicious process is its child process. In this way, Citadel acts as a parasite and uses the cover of explorer.exe to perform operations. When explorer.exe is infected, Citadel sends a POST request back to the domain to knock at the gateway, after which the C&C serves the config.bin file to the location shown in Listing 2.
C:\Documents and Settings\Administrator\Application Data\[random]\[random].afq C:\Documents and Settings\Administrator\Local Settings\Temporary Internet Files\Content.IE5\[random]\config.bin Listing 2: Config.bin file location.
After the bot has read the configuration file, it deletes several files from the system to hide its traces. This includes the temporary files, config.bin, and several other cookies files, as shown in Listing 3.
C:\Documents and Settings\Administrator\Application Data\[random]\random.tmp C:\Documents and Settings\Administrator\Cookies\[email protected].txt C:\Documents and Settings\Administrator\Cookies\[email protected].txt C:\Documents and Settings\Administrator\Cookies\[email protected].txt C:\Documents and Settings\Administrator\Cookies\[email protected].txt C:\Documents and Settings\Administrator\Cookies\[email protected].txt C:\Documents and Settings\Administrator\Cookies\[email protected].txt C:\Documents and Settings\Administrator\Local Settings\Temporary Internet Files\Content.IE5\[random]\config.bin Listing 3: Files deleted by Citadel including cookies files.
Citadel performs API hooking, which means it hijacks the communication flow of various APIs provided by the Windows operating system. The primary function of Citadel is to conduct man-in-the-browser (MitB) attacks. As Citadel is present in the system, it can easily hook built-in and system browser-based libraries to control the output of different functions. Having the MitB capability means that Cita-del can steal information from browsers, alter HTTP data and responses, and perform web injections. This is all possible through hooking. Table 1 shows how Citadel hooks different functions in browser-specific libraries.
|Browser type||Real-time browser hooking examples|
|Internet Explorer||HTTPSendRequest, InternetReadFile, InternetWriteFile, HTTPQueryInfo, InternetQueryDataAvailable, etc. functions in WININET.DLL.|
|Mozilla Firefox / Opera||PR_WRITE (p1, p2, p3) function is hooked in NSPR4.DLL. Other hooked functions are PR_READ, PR_CLOSE, PR_OPEN, PR_OpenTCPSocket, etc.|
|Google Chrome||Hooked functions are SSL_Write, PRReadFN and PRWriteFN in PRIOMethods structure present in CHROME.DLL. Additional ones are Open, Close, Read and Write.|
Table 1. Hooked functions in different browsers.
The details of the different commands used by Citadel are presented in Table 2.
|dns_filter_add||Set the mask (filter) to activate browser-based DNS redirection|
|dns_filter_remove||Remove the mask (filter) to disable the DNS redirection in the browser|
|url_open||Force the browser to open a specific web page for advertisement or other purposes|
|user_execute||Download file from remote source and execute it|
|user_destroy||Kill other adversaries (malware) in the system|
|user_logoff||Force the user to terminate the active session|
|bot_uninstall||Uninstall (unload) the bot from the compromised machine|
|bot_update||Update the configuration of the bot present in the infected machine|
|os_shutdown||Shut down the infected system running a bot|
|os_reboot||Reboot the infected system running a bot|
|user_cookies_get||Steal cookies from the browser running on the infected system|
|user_cookies_remove||Remove (clear) cookies from the browser running on the infected system|
|user_certs_get||Collect the stored certificates from the infected system|
|user_certs_remove||Remove the stored certificates from the infected system|
|user_homepage_set||Hijack the default web page in the browser running on the infected system|
|user_flashplayer_get||Collect the Local Shared Object (LSO), i.e. SOL files, from the infected system|
|user_flashplayer_remove||Delete the SOL files from the infected system|
|bot_bc_add||Create a back-connect proxy connection with the bot|
|bot_bc_remove||Remove the back-connect proxy connection activated on the bot|
|bot_httpinject_enable||Enable the functionality in the bot to trigger web injections in the browser|
|bot_httpinject_disable||Disable the web injection capability of the bot|
|info_get_software||Collect the list of the installed software on the infected machine including version, company, product, etc.|
|info_get_antivirus||Get the information about the installed anti-virus on the infected system|
|info_get_firewall||Get the information about the installed firewall on the infected system|
|webinjects_update||Update web inject settings on the bot|
|user_url_block||Block the target URL|
|user_url_unblock||Unblock the target URL|
|user_homepage_set||Configure the home page of the browser|
|user_ftpclients_get||Get the stolen FTP credentials information|
|user_emailclients_get||Get the stolen email credentials information|
|module_execute_enable||Enable the remote file execute module|
|module_execute_disable||Disable the remote file execute module|
|module_download_enable||Enable the remote file download module|
|module_download_disable||Disable the remote file download module|
|search_file||Search for a specific file|
|upload_file||Upload a file|
|download_file||Download a file|
|ddos_start||Start DDoS attack|
|ddos_stop||Stop DDoS attack|
|httpinject_enable||Enable the HTTP inject module|
|httpinject_disable||Disable the HTTP inject module|
Table 2. List of commands used by Citadel botnet.
We also constructed different Snort signatures for Citadel. One of the signatures that we used to detect C&C communication is included in this section. The MD5 of the sample that we used is: dce84b4cf5b4edbcbf394fef14abc572. Listing 4 shows the Snort signature.
alert tcp $HOME_NET 1024: -> $EXTERNAL_NET any ( msg:"citadel - CnC Communication "; flow: established,from_client; content:"POST "; depth:5; content:".php HTTP|2f|1.1|0d 0a|Accept|3a| *|2f|*|0d 0a|User-Agent|3a| Mozilla"; content:"|0d 0a|Content-Length: 1"; content:"|0d 0a|Connection|3a| Keep-Alive|0d 0a|Cache-Control|3a| no-cache|0d 0a 0d 0a|"; distance:2; within:54; isdataat:100,relative; content:!"|0a|"; distance:0 ; within:100; content:!"|0d 0a|Cookie|3a| "; content:!"Content-Type|3a| "; content:!"NetflixId="; reference:md5, dce84b4cf5b4edbcbf394fef14abc572; reference:url, <Reference to Citadel Details>; classtype:trojan-activity; sid:XXXXXXXXX; rev:1; ) Listing 4: Citadel Snort signature – C&C communication channel.
The signature is based on the HTTP header characteristics that are unique to Citadel variants. The ‘content’ tag allows analysts to specify content in the packet payload by stating explicitly the type of HTTP request to be used. The ‘depth’ command tells Snort how far it has to look. In our case, Snort looks at the first five bytes of the payload. We used a distance of 0, which means that Snort does not have to ignore any pattern from the start of the payload. The ‘within’ value of 54 indicates that at least this 54-byte pattern should be matched. For Snort signatures, an HTTP header containing a string such as ‘.php’ , ‘Accept:*/*’ or ‘User-Agent: Mozilla’ can be included along with an ‘isdataat’ value of 100, which actually checks the presence of 100 bytes of encrypted payload communication data to the C&C. It has been observed that Zbot and Zbot variants communicate with an encrypted payload that usually varies from 100 to 130 bytes in size (even legacy Zeus uses the same mechanism, indicating the sharing of the same old Zeus code). We also included negative content-matching strings such as ‘|0d 0a|Cookie|3a|’, ‘Content-Type|3a|’ and ‘NetflixId=’ into the signature to counteract false positives. For privacy reasons, we cannot reveal the list of IP addresses that were tracked using this signature.
In this paper, we have presented a detailed analysis covering the component design and behaviour of the Citadel botnet. We have noticed that Citadel is improving with every new version. However, its core design remains the same, with modifications only made to add new components. We noticed traces of Zeus while analysing Citadel. Citadel’s components include a builder, a gate and a C&C panel that have been designed in a similar manner to Zeus.
Citadel can be thought of as a userland rootkit with man-in-the-browser (MitB) capabilities. It implements anti-tracking and anti-reversing techniques such as geo IP filtering and virtual machine detection. In addition to this, Citadel uses gateways to restrict direct access to the C&C (similar to the mechanism deployed by Zeus). Citadel uses a very sophisticated model of data exfiltration from infected machines that shows significant improvements over that used by Zeus. Citadel supports components such as form grabbers, web injects, a keylogger, screenshot stealer, video grabber and software grabber to exfiltrate stolen information.
Citadel’s designers have worked extensively on the small issues in order to optimize components and secure the communication channel. For example, the encryption process still uses Zeus code, but it has been made more complex by introducing additional encryption layers. Citadel has implemented the concept of bot authentication, in which the bot has to send the login key in an encrypted POST request in order to retrieve the configuration profile – something that is missing from Zeus. The format of the configuration settings is similar to that of Zeus, but with additional settings. All of these characteristics show that Citadel is a well-constructed botnet with strong protection features. Interestingly, the majority of anti-virus systems raise the same alert for Citadel as for Zeus (Zbot) if it is detected in a system. This similarity means that the signatures or heuristics of Citadel closely match those of Zeus. Based on the analysis presented in this paper, we can safely conclude that Citadel is a Zeus descendent with new characteristics and more optimizations.