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

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.

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.

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.

Figure 3. Fetching Citadel’s configuration binary.

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:

The details of the different commands used by Citadel are presented in Table 2.

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.