Prosecting the Citadel botnet - revealing the dominance of the Zeus descendent: part two


Aditya K. Sood

Michigan State University, USA

Rohit Bansal

Independent Security Researcher, USA
Editor: Martijn Grooten


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.

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.

1. Experimental results

In this section, we present the results of the experiments we conducted on the Citadel botnet in order to understand infections in progress.

1.1 Traffic analysis

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.

Fetching the Citadel bot.

Figure 1. Fetching the Citadel bot.

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.

Fake DNS traffic generated by the Citadel bot.

Figure 2. Fake DNS traffic generated by the Citadel bot.

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.

Fetching Citadel’s configuration binary.

Figure 3. Fetching Citadel’s configuration binary.

1.2 Bot’s design and working

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 .

    Dropper code.

    Figure 4. Dropper code.

  • 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
    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\administrator@adobe[1].txt
    C:\Documents and Settings\Administrator\Cookies\administrator@google[1].txt
    C:\Documents and Settings\Administrator\Cookies\administrator@java[1].txt
    C:\Documents and Settings\Administrator\Cookies\administrator@promotion.adobe[1].txt
    C:\Documents and Settings\Administrator\Cookies\administrator@sun[1].txt
    C:\Documents and Settings\Administrator\Cookies\administrator@walkernews[1].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 typeReal-time browser hooking examples
    Internet ExplorerHTTPSendRequest, InternetReadFile, InternetWriteFile, HTTPQueryInfo, InternetQueryDataAvailable, etc. functions in WININET.DLL.
    Mozilla Firefox / OperaPR_WRITE (p1, p2, p3) function is hooked in NSPR4.DLL. Other hooked functions are PR_READ, PR_CLOSE, PR_OPEN, PR_OpenTCPSocket, etc.
    Google ChromeHooked 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.

Citadel commandsDescription
dns_filter_addSet the mask (filter) to activate browser-based DNS redirection
dns_filter_removeRemove the mask (filter) to disable the DNS redirection in the browser
url_openForce the browser to open a specific web page for advertisement or other purposes
user_executeDownload file from remote source and execute it
user_destroyKill other adversaries (malware) in the system
user_logoffForce the user to terminate the active session
bot_uninstallUninstall (unload) the bot from the compromised machine
bot_updateUpdate the configuration of the bot present in the infected machine
os_shutdownShut down the infected system running a bot
os_rebootReboot the infected system running a bot
user_cookies_getSteal cookies from the browser running on the infected system
user_cookies_removeRemove (clear) cookies from the browser running on the infected system
user_certs_getCollect the stored certificates from the infected system
user_certs_removeRemove the stored certificates from the infected system
user_homepage_setHijack the default web page in the browser running on the infected system
user_flashplayer_getCollect the Local Shared Object (LSO), i.e. SOL files, from the infected system
user_flashplayer_removeDelete the SOL files from the infected system
bot_bc_addCreate a back-connect proxy connection with the bot
bot_bc_removeRemove the back-connect proxy connection activated on the bot
bot_httpinject_enableEnable the functionality in the bot to trigger web injections in the browser
bot_httpinject_disableDisable the web injection capability of the bot
info_get_softwareCollect the list of the installed software on the infected machine including version, company, product, etc.
info_get_antivirusGet the information about the installed anti-virus on the infected system
info_get_firewallGet the information about the installed firewall on the infected system
webinjects_updateUpdate web inject settings on the bot
user_url_blockBlock the target URL
user_url_unblockUnblock the target URL
user_homepage_setConfigure the home page of the browser
user_ftpclients_getGet the stolen FTP credentials information
user_emailclients_getGet the stolen email credentials information
module_execute_enableEnable the remote file execute module
module_execute_disableDisable the remote file execute module
module_download_enableEnable the remote file download module
module_download_disableDisable the remote file download module
search_fileSearch for a specific file
upload_fileUpload a file
download_fileDownload a file
ddos_startStart DDoS attack
ddos_stopStop DDoS attack
httpinject_enableEnable the HTTP inject module
httpinject_disableDisable the HTTP inject module

Table 2. List of commands used by Citadel botnet.

1.3 Citadel’s Snort signature

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 "; 
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;
distance:0 ;
content:!"|0d 0a|Cookie|3a| ";
content:!"Content-Type|3a| "; 
reference:md5, dce84b4cf5b4edbcbf394fef14abc572; 
reference:url, <Reference to Citadel Details>; 
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.



Latest articles:

VB2018 paper: Fake News, Inc.

As the world grapples with massive disinformation campaigns waged by the intelligence agencies of hostile nations, we should not forget that such activities are not limited to the purview of the Bears or Pandas of the world, and that even relatively…

Alternative communication channel over NTP

Nikolaos Tsapakis explores Network Time Protocol (NTP) as an alternative communication channel, providing practical examples, code, and the basic theory behind the idea.

VB2018 paper: Under the hood: the automotive challenge

In an average five-year-old car, there are about 30 different computers on board. In an average new car, there are double that number, and in some cases up to 100. That’s the size of network an average SMB would have, only there’s no CIO/CISO, and…

VB2018 paper: Android app deobfuscation using static-dynamic cooperation

Malicious Android applications are quite common, and can even be found from time to time in the Google Play Store. Thus, a lot of work has been done in both industry and academia on Android app analysis, and in particular, static code analysis. One…

VB2018 paper: Anatomy of an attack: detecting and defeating CRASHOVERRIDE

CRASHOVERRIDE is the first publicly known malware designed to impact electric grid operations. Reviewing previously unavailable data covering logs, forensics, and various incident information, in this paper Joe Slowik outlines the CRASHOVERRIDE…

Bulletin Archive

We have placed cookies on your device in order to improve the functionality of this site, as outlined in our cookies policy. However, you may delete and block all cookies from this site and your use of the site will be unaffected. By continuing to browse this site, you are agreeing to Virus Bulletin's use of data as outlined in our privacy policy.