We recently focused on the latest banking malware: Citadel. The Zeus source code release has made possible the creation of new banking malware, and Citadel is one of them. One of its particularities is the possibility for the customers to request and / or suggest the implementation of new features, so that the malware becomes as close as possible to their expectations.

This post presents the steps performed in order to decrypt the configuration file of a specific sample, which contains all the targets, web injections and other parameters of the malware.

Network

The first step consists in observing the malware network connections as it will likely try to retrieve its configuration file and thus give us a first information to guide our research.

We observe two POST requests to the malware's C&C:

The two pieces of data sent have a respective size of 128 and 123 bytes, and are unfortunately encrypted.

The C&C then responds by sending data back, also encrypted, of 15kB and 408kB, but also adds an interesting HTTP header:

Content-Disposition: attachment; filename="%2e/files/cfgkass.bin"
Content-Disposition: attachment; filename="%2e/files/cit_video.module"

The first query returns a file named cfgkass.bin. We believe that this is the configuration file. The second file, bigger, might be a plugin responsible for video capture, as we have already seen for SpyEye.

Curiosity now drives us to study how the malware handles the received data.

Encryption mechanisms

If we follow the progression of downloaded data in the malware code, we quickly spot a complex encryption function, whose number of rounds and key size reminds us some block cipher algorithms.

A Google search on some of the constants used quickly drives us to AES with a 128 bit key.

Once the AES decryption has been performed, a basic XOR loop, already present in Zeus but also in SpyEye, is responsible for finally making the data readable:

We now face a clear-text configuration file whose structure is identical to that of a Zeus configuration file, which confirms the source code reuse. We can also see that the version section indicates 1.3.1.0.

If we try to decipher the contents of the requests sent by the malware with the same algorithm, we get nothing readable, indicating that other algorithms are also used. Indeed, if we look for the source of the data sent by the malware in the execution flow, we notice an RC4 encryption function.

Using the same encryption key and replacing AES by RC4, we are able to decrypt the sent data:

Again, this structure was also used in Zeus when communicating with its C&C:

• 0x14: data size
• 0x1C: number of sections
• 0x20: MD5 of the following data

Then for each section:

• 0x0: Type (4 bytes)
• 0x8 and 0xC: size (4 bytes)
• 0x10: data

Now let's find the origin of the encryption key, to determine if it is "hardcoded" in the binary or dynamically generated.

If we go back a few functions from the AES decryption, we face the following code:

• The function called get_rc4_blob "deciphers" (a simple XOR) an area of the binary which contains an RC4 permutation table (which reminds us of Zeus, again);
• The MD5 hash of a KEY string is then computed. This string is also present in the binary, and represents a sequence of 32 hexadecimal uppercase characters (this time, it is SpyEye that comes to mind);
• The MD5 hash is then encrypted using the previously extracted RC4 table, and the result is used as the AES decryption key.

Having previously implemented tools to dynamically retrieve the encryption keys of Zeus (RC4 permutation table) and SpyEye (string of 32 hexadecimal uppercase characters), we simply combine both to get the keys to the Citadel

A Distributed Denial of Service technique is actively exploited in the wild by attackers since a few months.
It leverages a vulnerability in game servers running First Person Shooter games based on the Quake III model (Call of Duty, Enemy Territory, etc.) to redirect traffic response to a victim. Some of these gaming servers accept a "GetStatus" request in a small UDP/80 packet from a spoofed source IP address and the server replies by redirecting the answer to the spoofed victim's IP on port 80. Amplification is thus achieved as the packet replied can be 10, 20 or 30 times bigger than the request.

See an example of such redirected flow below :

---

|Date flow start|Proto|Src IP Addr:Port|Dst IP Addr:Port|Flags|Packets|Bytes|Flows|bps|pps|Bpp| 

|2011-10-10 15:55:48.971|UDP|66.23.233.XX:27960|A.B.C.D:80|......|10000|13.3 M|1|2.1 M|195|1329|

---

Thousands of gaming servers can be found online through specific search engines and may enable this kind of attack, but only some of them can be used to conduct such attack. Indeed, games server admins or their hosting providers can mitigate such risks for example by applying patches (when available) or firewall rules (ACL, iptables, etc.) to block or at least limit such fraudulent queries/traffic.

But for the moment, multi-Gbps DDoS attacks can still be conducted. The volume of "packet love" sent depends on the source (often compromised) machines' capacity and the number of game servers used as amplifiers...

Thanks to Daniel L. for proofreading

The Htran tool has recently been used during several cyberattacks, such as Shady RAT and the attack against RSA. It is a Chinese port forwarding tool, allowing an attacker to use a compromised machine as a pivot to attack a network segment that is not directly accessible from the attacker's machine. Its full name is HUC Packet Transmit Tool. We have found this tool to be used during previous incident response missions, especially during targeted attacks against French industrial companies in 2009.

Presentation

NB: this analysis is based on the tool used in 2009, its behavior may have changed since then and doesn't necessarily reflect the exact tool that have been used in the operations mentioned above.

Htran is an interactive tool showing a usage when no command line argument is passed:

[Usage of Port Transmit:]
tran.exe   -<listen | tran | slave | remove>   <option>
[option:]
-listen <ConnectPort> <TransmitPort>
-tran  <ConnectPort> <TransmitHost> <TransmitPort>
-slave <ConnectHost> <ConnectPort> <TransmitHost> <TransmitPort>
-tran  <ConnectPort> <TransmitHost> <TransmitPort> -i ProcessName
-slave <ConnectHost> <ConnectPort> <TransmitHost> <TransmitPort> -i ProcessName
-remove

The meaning of the options is as follows:

• -listen <ConnectPort> <TransmitPort>: listen on port ConnectPort and transfer data received to the local port TransmitPort;
• -tran <ConnectPort> <TransmitHost> <TransmitPort>: listen on port ConnectPort and transfer data received to the TransmitPort on the TransmitHost machine;
• -slave <ConnectHost> <ConnectPort> <TransmitHost> <TransmitPort>: connect to the ConnectPort port on the ConnectHost machine and transfer data received to the TransmitPort on the TransmitHost machine
• -remove: remove evidence left when using the –i option (see below).

Indeed, it is possible to specify a –i option followed by a process name to the –tran and –slave options. The tool will then inject itself in the process to perform its network operations, to be more stealthy. For example, the following screenshot shows that the process performing network operations is notepad.exe, not tran.exe:

This –i option also adds an Error Help Service service (HKLM\SYSTEM\CurrentControlSet\Services\ErrorService registry key) pointing to C:\WINDOWS\system32\mnlbmgr.exe so that this injection will be restored on each reboot:

The C:\WINDOWS\system32\ntimfos.eng file is used to store the command line arguments. Here is an example of it:

This option also installs a rootkit as a device driver from C:\WINDOWS\system32\drivers\viapack.sys, which will persist on reboot. This rootkit hides some network operations (see below).

Detail behavior

The tran.exe binary has two resources:

• BIN\110: Windows service executable (mnlbmgr.exe), UPX compressed;
• BIN\111: device driver executable (viapack.sys).

The mnlbmgr.exe binary has itself another resource:

• BINO\101: DLL executable (usrtran.dll)

To be stealthier, the mnlbmgr.exe, viapack.sys and usrtan.dll files have their dates set to those of the legitimate C:\WINDOWS\system32\drivers\hal.dll file.

A small trick is used to load the kernel driver. The binary sends a STOP signal to the beep service, overwrites the C:\WINDOWS\system32\beep.sys file with C:\WINDOWS\system32\viapack.sys and immediately starts the beep service again. This exploits a race condition in the Windows File Protection mechanism; the modification is correctly detected by Windows and the original file restored, but this occurs after the service has started with the malicious viapack.sys image, thus loading the rootkit.

Once the driver has been loaded, it creates the HKLM\SYSTEM\CurrentControlSet\Services\viapack registry key to persist on each reboot and attaches itself to the list of devices linked to \Driver\Tcpip\Device\Tcp. On its first launch, it installed itself using the beep.sys trick described above and appears like this in GMER:

After a reboot, it becomes an autonomously loaded driver and appears like this:

According to our tests, it seems that this rootkit only masks a local port bind. Indeed, when the tool is ran with the –tran option without specifying –i, the listening port is listed by Tcpview (port 80 in this example) :

On the other hand, Tcpview no longer shows the listening port with the –tran option when the rootkit is active:

But in –slave mode, Tcpview displays the TCP connections even if the rootkit is active:

Based on the information provided by the ntimfos.eng file, the service creates in the targeted process a new thread whose base address is LoadLibrary() with a usrtran.dll argument, thus loading the malicious library in the memory of this process:

Even two years after our incident response, this malware is still hardly detected by antivirus:

• DrWeb : MULDROP.Trojan
• eTrust Antivirus : Win32/Sybuex!generic
• Sophos : Mal/Behav-160
• Trend Micro : Mal_Xed-20
• Symantec Command Line Scanner : Backdoor.Systack (rootkit uniquement)

Since last year, Microsoft is distributing the KB976002 update, prompting the user to choose among the 5 main browsers. While the two leading Internet Explorer and Firefox have been the targets of banking malware for a long, Chrome, Safari and Opera still seemed to resist the invader.

As recently announced Brian Krebs, two new features have appeared in version 1.3.34 of the SpyEye builder.

SpyEye is able to capture the data sent using Chrome or Opera. The study of a version 1.3.39 sample shows how this capture is performed.

Opera

• Check that the process name contains the string opera
• Hook on TranslateMessage to intercept keystrokes
• Hook on RtlFreeHeap to intercept POST requests when the buffer containing them is freed

Chrome

• Check that the process name contains the string chrome
• Hook on TranslateMessage to intercept keystrokes
• Hook on ZwReadFile to intercept POST requests

In both cases the data are sent to the collector server in the POST requests interception hook, the captured keystrokes are stored in a memory area in the meantime.

After having presented some SpyEye plugins, let's have a look to its features to hide itself from the user.

To fully understand the contents of this post, remind that during an infection, SpyEye will create at the root of disk C: a folder whose name is the executable name set during its generation, and copy itself inside under the same name. Its configuration file is also extracted in this folder.

Typically, this is how an infected machine may look, if the hidding feature is disabled:

In addition, to be persistent when you restart the machine, a Run registry key pointing to the binary will be created.

Let's see how the malware is hide itself from the system's user...

Once the computer is infected, SpyEye will inject in virtually all the running processes and put hooks on the following Windows API functions:

• NtQueryDirectoryFile and NtVdmControl: the hooks on these two functions will allow SpyEye to hide the files it stored on the hard drive. Indeed, these two functions will be called to list the contents of a directory, either from the classic mode, or from 16-bits sub-system (NTDVM). It then checks if a filename is the name of the executable or of the configuration file, and remove it from the list if necessary.
• NtEnumerateValueKey: the hook on this function will hide the Run key when browsing the registry.
• NtResumeThread: this hook does not hide any information, but allows SpyEye to be notified of the creation of any new process, in order to infect them.

This mechanism can be described as a userland rootkit, since no portion of code is executed in the kernel (which is usually the case when it comes to ""rootkits'').

If we look at the hook positioned on the NtResumeThread API, we find that the injection into a new process is performed only if its name is not part of a hard-coded list into the malware. This list of programs varies over the versions of the bot, but a persistent entry is:Skype.exe.

Henceforth, any binary renamed as Skype.exe will bypass the rootkit. So just rename explorer.exe and delete the folder created by SpyEye at the root of the disc and its contents, then rename regedit.exe and go delete the key Run pointing to the binary previously deleted, and then restart the station: your system is now clean!

SpyEye is endlessly evolving: while a new version was just released (version 1.3.10), new plugins appear, turning this banking malware into a Swiss Army knife that could quickly become the new standard in the cyber criminal world.

While we identified a USB devices propagation plugin earlier this month, Trend Micro states that another plugin, called "spySpread.dll", includes this capability. This plugin is also reponsible for spreading Spyeye through instant messaging, by sending a message enticing to download a fake photo. Unfortunately we have not captured a sample of it yet, but another plugin called "ddos.dll" caught our eye.

The associated configuration file (ddos.dll.cfg) contains the targets list, with the following format:

 <type> <IP/domain> <port> [<time>]

<Type> can take the following values:

• ssyn: although the name suggests a SYN flood attack, this mode just opens multiple TCP connections (100 in parallel)
• udp: UDP flood attack (100 open sockets in parallel)
• slowloris: attack against web servers by keeping open an HTTP session (only one session open)

The two fields after <type> speak for themselves, and the last field indicates the duration of the attack, in seconds.

Finally, here is the contents of the configuration file we captured:

 ssyn spyeyetracker.abuse.ch 443 3600

It seems that the plugin creators and/or users do not like the tracker maintained by abuse.ch to identify and block all SpyEye command and control servers, similar to what has been made for ZeuS.

SpyEye, a banking malware hitting the headlines after the announcement of its merge with the famous ZeuS, is a very modular clone of it, since plugins can be easily developed to add new functionalities.

Among these, we have identified a module for allowing it to spread through removable storage devices, rather rare ability in the world of banking malware, which usually only steal confidential and personal data on the host they infected, without trying to expand to other systems.

The associated configuration file only contains one line:

c:\cleansweep.exe\cleansweep.exe|servicess.exe

Two parameters are separated by a pipe:

• The name of the malware executable on the host;
• The name of the executable as it will be copied to the removable disk.

The module internals are simple: every 10 seconds, the list of the disks attached to the host is browsed to find removable devices (if the GetDriveType function returns DRIVE_REMOVABLE). For each removable device, the following actions are performed:

• Check for presence of malware autorun on the disk;
• If the disk is not infected:
  • Create a folder RECYCLER ;
  • Create a subfolder ii4-34gJUGE-3g4y33-fwuu4grj in RECYCLER, whose letters have been changed from uppercase to lowercase or vice versa, randomly;
  • Copy the malware executable in this subfolder under the name specified in the configuration file, using the same algorithm as before;
  • Create a file autorun.inf in the root directory of the disk, which content is as follows (most strings are subject to the same "obfuscation" algorithm as seen above):
  • Apply attributes FILE_ATTRIBUTE_READONLY, FILE_ATTRIBUTE_HIDDEN and FILE_ATTRIBUTE_SYSTEM on all created folders and files, to hide them to the user.

One amusing detail: this plugin does not work out of the box with version 1.2.8 we have captured, because its author did not name the exported functions properly. This problem may explain why its has gone relatively unnoticed so far ...

What can we learn from this module?

• Basic propagation mechanisms are emerging in banking malware. No doubt that future versions will include this kind of functionality in the base version;
• The technical expertise of this module's developers seems rather low: very basic obfuscation mechanisms, path of the malware executable "hardcoded" in the configuration file, no test in real conditions before putting into production... This reminds that SpyEye amateurism (for version 1.2 and below) is far away from ZeuS professionalism.

Finally, an advice that never hurts: disable autorun and autoplay for removable devices.

Microsoft released the awaited patch fixing the LNK vulnerability on Monday. Let's have a look at how Microsoft fixed it, by performing a differential analysis on the shell32.dll library for Windows XP SP3.

Several new functions have been added to the fixed version of the DLL; knowing that the vulnerability is related to the way shortcuts to control panel (CPL) elements are handled, the new CControlPanelFolder:: _IsRegisteredCPLApplet() function immediately focuses our attention. The CControlPanelFolder:GetUIObjectOf() function has been altered to add a new block calling this function:

At the bottom of the screenshot, there is a call to _ControlExtractIcon_CreateInstance(), which will initiate the extraction of the icon. This call will therefore be performed only if the return code of _IsRegisteredCPLApplet() is not null.

Looking at _IsRegisteredCPLApplet(), we see that after having fetched the registered control panel elements with CPLD_GetModules(), the function iterates with DSA_GetItemPtr() until a match is found by CompareString() with the DLL pointed by the shortcut (return value of 2, namely CSTR_EQUAL, in which case _IsRegisteredCPLApplet() returns 1), or if there is no more element to compare with (in which case _IsRegisteredCPLApplet() returns 0):

If we create a CPL shortcut pointing to C:\Windows\system32\zuaucpl.dll (instead of the legitimate wuaucpl.dll), we observe that Windows does compare the name of our DLL with the registered control panel elements:

Windows will therefore only load a CPL to retrieve its icon if it was registered in a legitimate way.

This update also adds support for the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\AutoplayHandlers\IsAutorunForCDROMOnly registry value (without creating it by default), enabling to disable AutoRun on any media except CDs and DVDs. This is the default behavior on Windows 7 and Microsoft released the KB971029 for the previous Windows versions.

In fact, there is a call to a new _IsAutorunForCDROMOnly() function at the top of the CMountPoint::_ProcessAutoRunFile() and CContentTypeData::Init() functions:

At the bottom of CContentTypeData::Init(), a new test has been added to decide whether AddRemovableOrFixedDiskAutorunINFHandler() should be called, depending on the return value of _IsAutorunForCDROMOnly() (in CMountPoint::_ProcessAutoRunFile(), there are multiple places where this is checked):

The _IsAutorunForCDROMOnly() simply retrieves the registry value:

More surprising, this update also adds several functions (InitializeFormatDlg(), BeginFormat() and FileSysChange()) which add a new "exFAT" item to the disk format dialog:

But only the dialog has been modified; the exFAT driver is not installed and formating the disk will therefore not be possible... exFAT support requires a distinct update, KB955704, which install several other files, not only shell32.dll.

Besides the security fix, this new version of shell32.dll also comes with two functional updates (support for the complete AutoRun disabling except for CDs and DVDs, as well as a partial support for exFAT disk format), which is, to our knowledge, not documented anywhere (except in shell32.dll updates in previously released KBs).

For a few days, the security ecosystem has been focusing on the Stuxnet malware and its innovative propagation method using a previously unknown vulnerability in the way Windows handles icons in LNK files. In Windows 7, using AppLocker helps mitigates the flaw.

In a LNK file, it is possible to point an icon resource to a malicious DLL. When the Windows shell will display the icon, it will load the DLL and execute the code in its main function. Unfortunately, Microsoft recommendations are either not applicable (disable all shortcut icons!), or only cover one exploitation vector (disabling the WebDAV client, which doesn't prevent the vulnerability from being exploited by USB drives or remote SMB shares).

Some suggested to use SRP to restrict the execution of binaries (EXE and DLL) to the C: drive. This is better, but can block legitimate binaries executed from other drives (which is likely to happen in a corporate environment). Of course, it is possible to whitelist other drives as well, but this reopens the SMB and WebDAV exploitation vectors...

That's why it seems that the best solution to protect against this vulnerability would be to block every unknown DLL, which is exactly what AppLocker was designed for. However, there is a huge counterpart: this only works on Windows 7 and 2008 R2 (using SRP can thus be useful on older systems).

AppLocker is an evolution of SRP which can be used to block PE binaries, MSI installers and VBS scripts (among others), with customizable rules. The advantage of AppLocker over SRP is its ability to write rules specific to DLLs, without tempering with the execution of traditional EXE binaries, which perfectly matches our case.

After running the "Application identity" service required to apply the rules, DLL rules have to be explicitly allowed by checking the following checkbox (and bypassing warnings...):

Default rules can then be applied to protect the system; don't forget to remove the last rule as it allows any administrator to load any DLL. From now on, DLLs can only be loaded from C:\Windows and C:\Program Files.

After a (now unsuccessful) attempt to exploit the vulnerability, a 8004 event appears in Applications and services log -> Microsoft -> Windows -> AppLocker, indicating that the DLL has been blocked:

This solution is not perfect as legitimate DLLs can no longer be loaded from other directories, including remote ones. However, it is expected that this drawback has less consequences than blocking every remote EXE.

No one missed it, the fix for the vulnerability in Windows Media Services that we reported to Microsoft was honored to be part of the small circle of patches pulled by the editor for not fixing the problem.

Immediately after the publication of the original patch, we have executed out of curiosity our proof of concept on the revised version of the service. This immediately caused a crash. Back with a debugger attached to the service, we found that the vulnerability was in a great shape! A changed return address later and our proof of concept worked perfectly against the new version of the service. We immediately contacted Microsoft, who was already working on the problem.

A few days later, Microsoft announced the withdrawal of the patch MS10-025, because it did not correct the vulnerability. The reason is as follows: "The original issue was missed due to focusing on a variant of the original report early in the investigation". Understand: we started on the wrong way early in the investigation (which lasted about eight months). Knowing that the proof of concept mentioned earlier has been sent to Microsoft when first contacting them to report the vulnerability, a simple test on the supposedly fixed version would have immediately exposed the problem ... Might the close Windows 2000 end of life be the cause of this neglect?

However, we have appreciated the transparency of the editor through the MSRC blog and Twitter.

Today, everything seems back to normal: a new patch properly fixing the vulnerability has been released by Microsoft.