The Citadel Encryption Method

Going back to how the communication was programmed to happen between Zeus v2 variants and their C&C servers researchers recall it was encrypted[1] with a symmetric encryption algorithm: RC4, with a pre-shared key defined by the builder. 

Some variants of Zeus were seen using AES encryption instead of RC4, which is stronger, and still used with a predefined key.

Citadel combined those two encryption methods, and topped them with an additional layer: 

• Every Citadel variant has a hardcoded MD5 string (probably a hash of the password set by the builder) in addition to the RC4 key.
• In runtime, the MD5 string is run through MD5 function a second time 
• The result (the new MD5) is then encrypted using RC4 with the stored key
• That final result is used in the creation of an AES encryption/decryption key using AES schedule routines
• The Trojan’s communication is then encrypted using AES encryption. 

This three-fold effort provides botmasters with strong encryption out of the box – even if they were to choose a weak password, it would practically be impossible to brute-force or break into their bots’ communications.

Local Pharming: Citadel’s Custom DNS Redirection

Right from its first release, Citadel introduced this new option to botmasters, designed to allow them to change the behavior of name resolution on infected machines. Bottom line, this means that the botmaster can decide which URLs the victim can or cannot reach, and what page the victim will land on instead of the original page they were looking for. Local Pharming at its best. 

This particular redirection scheme occurs by installing hooks on two DNS related functions:

1. gethostbyname
2. getaddrinfo

In order to implement this functionality, a new block was added to the config file, containing names and IP pairs.

Whenever an infected process[2] tries to resolve a hostname to an IP address, the request will first pass through Citadel’s routines. The Trojan will then try to resolve the address using regular mechanisms; if successful, it will check its own configuration for a name/IP pair match.

If such a match is found – the Trojan will return the pre-defined (fraudulent) address to the caller.

It’s worth mentioning that if the regular DNS request fails (domain does not exist, network timeout etc.) – Citadel will return the original error message to the caller, even if a matching address is found in its botmaster’s config. This behavior makes the redirection appear less suspicious in aspects of network monitoring and typical request/answer times.

The local Pharming functionality allows botnet operators to leverage two main attack vectors: 

• Isolation of the infected machine, blocking its access to certain “unwanted” services, including AV providers, web-based malware scans, security providers’ web sites, abuse lists and malware update servers.  Team Citadel has been keeping on top of things and makes sure the Trojan comes bundled     with a very long list of known security-related servers and numerous specific URLs for each, to   begin with. In one variant studied by RSA, this list was composed of over 650 different URLs. 
• The second attack vector that can be facilitated greatly by local Pharming is the deployment of sophisticated phishing attacks, redirecting Trojan-infected victims to fraudulent servers when they attempt to reach a legitimate URL via their browser. 

DNS redirection can be a part of SSL compromise attacks, along with other Trojan capabilities.

Citadel’s Windows Hooks

Zeus v2 and all its offspring and variants create function hooks in processes they inject themselves into. 

Citadel too, is a Trojan that hooks Windows processes, taking hostage a larger number of functions than Zeus does in its v2 samples:

These additional hooks cause the program execution flow to pass through Citadel on more events than Zeus monitored, and may also suggest the development of future capabilities of the Trojan. 

The last two process hooks have to do with the DNS redirection routine explained in the previous section of this report.

Citadel’s Chrome browser hooks

Zeus v2 is known for its form-grabbing capabilities and its efficient HTTP injection mechanism, but although Zeus plugins were written to target Firefox and opera, Zeus variants were never programmed to target the Chrome[3] browser specifically.

Citadel’s team did develop this ability and now the Trojan, when injected into Chrome browser’s memory space at runtime, hooks Chrome-specific core functions in chrome.dll.

Citadel’s C&C Server-Side Improvements and Security Patches

The Citadel Trojan used the well known Zeus server panel and patched it against web-based attacks. Another minor change is in the panel’s visual design, making it appear more professional for the users and affording added control over infected bots. Many of Citadel’s functions and options are embedded into the panel ad-hoc as the team sees fit.

The Cost of Cybercrime with Citadel

What can a cyber crook expect to pay for this next generation crimeware kit?  The following table represents the selling price today for Citadel and its respective technical set-up, support, updates and other various features: 

What does Citadel’s Future Hold?

The team developing Citadel appears to be taking the project very seriously and seems to be working tirelessly on patching clunky Zeus mechanisms and adding new ones, making the Trojan increasingly modular and adapted to cybercrime endeavors.

Because of its major similarities to the Zeus v2 assembly, Citadel is still very much like its forefather.  The Citadel Trojan is being aggressively marketed within the fraud underground and will be a crimeware to be reckoned with in 2012.  RSA is conducting research into the Citadel Trojan on an ongoing basis and will continue to report on new findings as they become available.

 [1] Active Zeus v2 variants still use this method today