Updates to the Citadel Trojan

• Author: Dell SecureWorks Counter Threat Unit(TM) Threat Intelligence
• Date: 28 November 2012

Summary

The Citadel Trojan horse continues to emerge as a prominent player in the banking trojan marketplace. In October 2012, a new version of Citadel, 1.3.5.1 or "Rain Edition," was announced by the individual who goes by the moniker AquaBox. Since the Dell SecureWorks Counter Threat Unit(TM) (CTU) research team's most recent report on Citadel, this version promises several new features that claim to improve both performance and usability.

Key improvements

Citadel 1.3.5.1 includes several improvements of malware functionality and usability. The CTU research team believes that the following features have the greatest impact on the research community.

Revised cryptography

In a response to continued efforts by the security community to analyze and decrypt configuration files for banking trojans such as Citadel, version 1.3.5.1 has made additional changes to the Advanced Encryption Standard (AES) cryptographic algorithm that it uses to encrypt network communications, files, and data stored in the registry. Citadel has added an extra XOR operation to the implementation. The XOR key is a 16-byte value that appears to be embedded in the builder. The CTU research team has observed that this salt value differs across botnets, so it may be generated by the Citadel author when a builder is created for a specific customer. Data that is encrypted using the modified AES cipher includes the configuration file, log files that serve as a temporary storage for stolen data, and configuration and state data that is stored in the registry. The flow chart in Figure 1 illustrates the revised process for decrypting the Citadel configuration file using the new salt value.

Figure 1. Citadel 1.3.5.1 configuration decryption process. The blue and green areas indicate where the process differs from former versions. (Source: Dell SecureWorks)

The "Visual Decrypt" function shown at the bottom right of Figure 1 is a basic XOR operation that has been used since Zeus 2.0 as an additional "scrambling" operation. Its likely purpose is to reduce the possibility of partial pieces of known plain text being used to derive an encryption key. The following code is a Python function that performs the Visual Decrypt operation:

    def visual_decrypt(buf):
    out_list = list(buf)
    for i in range(len(out_list)-1, 0, -1):
        out_list[i] = chr(ord(out_list[i]) ^ ord(out_list[i - 1]))
    out = ''.join(out_list)
    return out

Dynamic webinjects

The ability to create "webinjects" that can modify the HTML of targeted websites is one of the most powerful tools available to customers of Citadel and other banking trojans. Previously, to add webinjects for new targets, the botnet operator had to rebuild and push out a configuration file that contained all of the webinjects. Citadel 1.3.5.1 has added the ability for the botnet controller to push out new webinjects to infected systems without requiring the creation and update of an entire configuration file. Unlike the webinjects in the configuration file, these dynamic updates do not need to be compiled into a binary format.

This feature provides flexibility for the attacker to easily push out new webinjects to all infected systems, hosts within a single country, or even just to a single host. It also makes it difficult for the security community to collect and monitor webinjects that are dynamically pushed out to only a select population of a botnet.

Firefox cookie grabber module

Citadel 1.3.5.1 includes a separate module for stealing HTTP cookies stored by the Mozilla Firefox web browser. At startup, the Firefox cookie grabber module is downloaded separately from the command and control (C2) server and loaded by the malware.

The Firefox cookie grabber exports a single function named "_getFirefoxCookie". This function creates a thread that gathers the cookie data. The majority of the remaining program is library code to interface with the SQLite database format used by Firefox to store cookie information. Based on the string "2012-06-11 02:05:22 f5b5a13f7394dc143aa136f1d4faba6839eaa6dc" in the module, CTU researchers determined that the version of SQLite used is 3.7.13.

The module runs the following query against the cookies database:

    select * from moz_cookies ORDER BY baseDomain

The schema for the moz_cookies table reveals the following information about HTTP cookies that are available to be stolen:

• name
• value
• host
• path
• expiry
• lastAccessed
• isSecure
• isHttpOnly

The stolen data is then encrypted and uploaded to the Citadel C2 server.

Citadel module encryption

Citadel modules are downloaded from the C2 server at startup and are not stored on disk. The module files are encrypted using Citadel's modified RC4 implementation. To analyze the Citadel Firefox cookie grabber module, the module needs to be decrypted. Two decryption steps using Citadel's modified RC4 cipher are required. The first decryption is of a file header that is added to the beginning of the encrypted module. The first 4 bytes indicate the length of the header. The remainder of the header is then decrypted using the RC4 key and hash string contained in the malware.

Figure 2. Citadel module encrypted header. (Source: Dell SecureWorks)

The decrypted header contains fields with information about the module type and version number. It also contains the MD5 checksum of the decrypted payload for verification. The rest of the header is a separate RC4 key that is used to decrypt the payload. The resulting decrypted payload is a Dynamic Link Library (DLL) that can then be loaded and executed.

Figure 3. Citadel module decrypted header. (Source: Dell SecureWorks)

The encrypted module files are encrypted by the same builder used to generate the malware executable file. The botnet operator places the encrypted modules in the appropriate directory of the Citadel C2 server.

Figure 4 shows a screenshot of the Citadel builder, with the "Build Modules" button used to generate the encrypted module files.

Figure 4. Citadel 1.3.5.1 builder. (Source: Dell SecureWorks)

Campaign activity

The CTU research team monitors campaigns that use Citadel 1.3.5.1. If a group has access to the latest build, it indicates that the group is investing resources to keep its infrastructure up to date and is likely profiting from its criminal activity.

"Barman" campaign

"Barman" is a name that the CTU research team has assigned to an active campaign that has been using the Citadel malware since at least version 1.3.4.5. The name comes from the string "barman.png", which is used to reference the primary configuration file that this Citadel botnet uses. The Barman campaign has the following distinctions:

• It primarily targets credit card data with webinjects.
• Targets are geographically disperse and multi-lingual.
• Targets are not limited to financial institution websites. Social networking and webmail sites are also being targeted.
• It uses a complex C2 infrastructure with domains that change on almost a daily basis.

The webinjects used by the Barman campaign use multiple lures, including spoofing 'Verified by Visa' and account security verification messages. These lures generate visible popup windows that attempt to trick the victim into divulging sensitive data.

The example popup in Figure 5 has been redacted of target brand information. The popup is typically branded to a specific issuing bank or payment network being targeted. These popups may also be written in the appropriate language of the target financial institution. Popups targeting social networking or webmail sites will typically be branded with a payment network such as Visa or MasterCard.

Figure 5. Redacted popup window used in the Barman campaign. (Source: Dell SecureWorks)

The CTU research team has developed tools to download, decrypt, and parse configuration files from Citadel C2 servers. These configuration files can then be analyzed to show who is being targeted with web injects and the specific type of attack being used. Figure 6 shows the count of distinct URL target patterns found in Barman configuration files since September 2012.

Figure 6. Barman campaign distinct webinject targets. (Source: Dell SecureWorks)

By late September, the campaign had grown to target more than 400 distinct URL patterns with webinject attacks. Activity slowed down during mid-October and started to pick up again in early November with 200 distinct target URL patterns. The addition and subtraction of large numbers of webinjects may indicate that there are multiple groups using this botnet, each with its own set of webinject attacks against specific targets.

tcpopunder

Many of the webinjects used in the Barman campaign belong to a class of webinjects that the CTU research team refers to as "tcpopunder" attacks. This name comes from an HTTP cookie called tcpopunder that is used by webinjects. The tcpopunder webinjects have been active for several years and have been used by campaigns using different banking trojans, including Zeus, Spyeye and Citadel.

The presence of the tcpopunder cookie in a customer's web session with an online banking or financial service application is a strong indicator that the customer is infected with a banking trojan such as Citadel. It also suggests that the customer's credit card account and personal information are at risk of being stolen for fraud purposes.

C2 infrastructure

The Barman campaign uses short-lived domains for its C2 infrastructure, but these domains are not generated with a Domain Generation Algorithm (DGA). Instead, the campaign continually pushes out new configuration files that direct the malware to the new domains. The following patterns make the Barman campaign C2 domains distinct:

• A four or five character "word"
• The use of the word "photo" or "video"
• A two-digit number (e.g., 10, 20, 30)
• Various Top Level Domains (TLDs)

Example Barman C2 domains:

• glexvideo10.info
• glexvideo20.info
• glexvideo30.info
• labzphoto10.co.uk
• labzphoto20.co.uk
• labzphoto30.co.uk
• begsyvideo10.co.uk
• begsyvideo20.co.uk
• begsyvideo30.co.uk
• gopexvideo10.ru
• gopexvideo20.ru
• gopexvideo30.ru

The IP addresses that these domains resolve to also change periodically, but not as frequently as the domains.

Targeted keystroke logger activity

The CTU research team has observed a campaign that uses Citadel's keystroke-logging capability to target applications that may handle sensitive data. The following entry included in the Keylogger section of the malware's configuration file specifies the patterns to match process names against:

        *store*;*putty*;*mstsc*;*pos*;*quickbooks*;*merchant*;*vnc*;*scp*;*eft*;*sage*;*account*;qbw32;*ftp*;*wire*;*term*;*sales*;*morris*;*merchant*;*mira*;

    

When process names match, all keystrokes entered by the victim in that application are logged for an interval specified in the configuration file, which is typically three minutes.

These patterns are intended to match applications used for remote access, merchant and point-of-sale (POS) operations, accounting and electronic payment operations. Table 1 shows a breakdown of the patterns and the possible applications being targeted.

Table 1. Applications suspected to be targeted by the Citadel keylogger.

Threat indicators

The following threat indicators can be used to detect activity related to Citadel 1.3.5.1. The fraud control panels are secondary C2 systems that are used in conjunction with web injects to perform specialized fraud activity. Activity to these fraud control panel domains is not only a strong indicator of a Citadel infection, but it indicates that fraud activity may be in progress.

Table 2. Threat indicators for Citadel 1.3.5.1.

Recommendations

The Citadel trojan continues to build its reputation as a tool of choice among the criminal underground. Its growth enables the advancement of fraud techniques and allows those advancements to reach a growing market of cybercriminals. Citadel not only poses a threat to customers of online banking and financial services, but it is a dangerous threat to the internal security of sensitive data. Organizations should assess the risk that this type of malware poses to their internal information security and to their lines of business. Monitoring for known threat indicators can be a simple method for detecting infected computers.

For internal infections, the CTU research team recommends a response plan that includes the identification and remediation of credentials used on the infected computer. Organizations with an Internet presence that may be targeted by Citadel should leverage their customer data to identify customers at risk. A threat intelligence capability that can monitor and assess the threat posed by Citadel as it evolves and matures can provide insight to a targeted organization.