We see a lot of new malware names on a daily basis. Some are brand new and unique, and others are spin-off variants of well known malware. Recently the name ‘Zberp’ appeared in the media, with reports suggesting it combines some of the most powerful features of the Zeus and Carberp malware. But how different is it from Zbot, and what advanced features does it possess? In this blog, we will detail the features of ‘Zberp’, explain how to protect ourselves from it, and reveal why the hype surrounding it is somewhat unfounded.
In previous blog on Zeus GameOver we saw an increase in that particular variant during April and May but as we can see in the following heatmap, the popularity of Zeus variants in general has decreased since the large spikes we saw at the end of February and throughout March.
Identification – same old Zeus?
Firstly, we need to check whether this is actually a known Zeus variant. Uploading a sample of Zberp to Zeus tracker suggests that it is indeed the KINS variant:
KINS is also known as ‘ZeusVM’ in the security community and has been well documented in the past. Its features include the usage of a virtual machine code obfuscation to execute code using (and abusing) a commercial product known as ‘VMProtect‘, and hiding the download of its configuration file in images with a well known technique called steganography. Also seen in some KINS versions is the ability to hide its registry modifications that allow it to be launched on start-up, an interesting persistence feature that makes it a bit more challenging to detect. However, the underlying malware dubbed ‘Zberp’ is almost identical to Zeus and has no behavioral differences, so what is different after all? Let’s have a deeper look.
Dumping the configuration file from Zberp shows us that the version number is 188.8.131.52, a common KINS version. Unsurprisingly, the configuration file format itself is very much the same as many other Zeus variants:
COMMAND AND CONTROL URL
Evasion Techniques & Unique Features
‘Zberp’ has a slight change to the code that handles its hooks. Before we dive a bit deeper, what exactly is hooking doing in malware context? In short, Hooking is a technique used by malware to ‘spy’ on the victim’s actions and subsequently steal relevant information. In simple terms, think of opening your banking website in your browser: the data that goes to and is received from the banking website can be intercepted using hooking at the application level (this means it will subvert any SSL encryption too) . Back to our analysis, a typical KINS/Zeus hook on the HttpSendRequest Windows API looks like this:
Whereas a ‘Zberp’ hook is quite different:
The ‘handler’ is the part of the hook that utilises and intercepts the information from the API. The purpose of changing the hook in the manner shown is presumably to hinder detection from antivirus products or specific products aimed at identifying financial malware that targets bank-related credentials and other confidential data. The style of hook is indeed similar to how the Carberp malware works and may have been taken from the leaked Carberp source code.
‘Zberp’ also uses SSL for its command and control (C&C) communication, but this has been seen before in other variants. We have not seen any usage of valid certificates for this, though. Typically the certificates used are self-signed or non-valid certificates that were stolen or re-used from other domains. One way to check the validity of the certificate is by browsing to the domain through a browser that employs certificate checks which will result in a certificate warning:
There are also the usual KINS features such as steganography and stealth registry keys. Steganography is used to disguise the configuration file that is downloaded over the network, causing many security solutions to believe it is a normal image file. However, the RC4-encrypted configuration is appended to the image in base64 encoded format. The registry keys used for its persistence are deleted on system startup and only written back into the registry upon shutdown, evading any scans that may detect them.
Protecting from Zeus – why is SSL inspection essential?
It may seem like a difficult task to reliably detect and prevent a Zeus infection, especially considering the advanced and differing techniques that each variant employs. However, Zeus is still Zeus and can be prototyped as such. Websense ACE, our Advanced Classification Engine, is designed and pre-loaded with the ability to stop Zeus infections and attempted infection in real time.
The use of SSL in Zeus variants can be intercepted with the ability to provide SSL real-time inspection for HTTPS connections: enabling an extra layer of security for the protocol can include supported checks for certificate validity and certificate revocation lists (CRLs). The network traffic generated and relied upon by Zeus, including its attempts to download a configuration file and upload stolen information at the ‘call home’ stage, are prototyped and can be identified in real time. For example one of the traits that allows us to identify Zeus is its way of transmitting encrypted data with the RC4 algorithm, which in conjunction with other features allows ACE to prototype its communication patterns. Finally, most Zeus variants exhibit certain dynamic behavioral patterns that allow it to be identified with an application sandbox, such as our Websense TRITON ThreatScope solution.
Websense customers are protected with ACE, our Advanced Classification Engine, at the stages detailed below:
- Stage 2 (Lure) – ACE has proactive detection for the email lures.
- Stage 4 (Exploit Kit) – ACE has detection for the malicious code that attempts to execute this cyber-attack.
- Stage 5 (Dropper Files) – ACE has detection for the binary files associated with this attack.
- Stage 6 (Call Home) – Communication to the associated C&C server is prevented.
Websense customers are also protected with ThreatScope behavioral analysis at stage 5, which identifies Zberp as malicious:
Here is the full ThreatScope report.
A Few Words About Data Theft as a Service
The Zeus family is well known as a banking trojan, and in recent times we have seen the use of ‘automated transfer scripts’ (‘ATS’) that do all of the dirty work. ‘ATS’ is a way of hijacking a browser in order to force it to include external scripts when browsing to specific websites. Typically, these scripts are provided as a service by 3rd party malware authors and kept up to date when banking websites change.
For example, Zeus-based malware may detect when a browser is loading a banking website and trick it into using a script from an external source (a 3rd party delivering the script as a service). This external script may contain tailored code that modifies the target banking website and captures personal information like usernames and passwords. These scripts can be offered as a premium service to users of the malware, where all of the captured information is stored on their personal account and they are given a login to access it. This is a typical example of the increasing move by malware authors to offer paid-for services and products that are much like a legitimate, professional business.
While we do see a new type of hooking code employed in Zberp, it is still basically the KINS variant of Zeus. The use of steganography, hiding registry keys, and using SSL for C&C communication are nothing new but are still noteworthy features. We expect to see a continuing use of the Zeus malware framework, including more variants and modifications, in this never-ending cat-mouse saga. However, when the underlying framework is properly understood and prototyped it is straightforward to protect against.