Why is Bredolab Still a Challenge to AV?

Posted on behalf of Bhaskar Krishnappa

Symantec has blogged about the Bredolab malware in the past and its method of infection with the goal of creating awareness in innocent users. Apart from blogs Symantec has also published a research paper explaining how the malware works, why it’s so widespread and the motivations behind it.

This post focuses on why this threat is still a challenge for AV vendors to comprehensively detect.

What does Bredolab bring in?

The latest Bredolab samples are downloading and installing rogue security products on victim’s machines for financial gains as shown below in step: 1 and step: 2.

Rogue security products generate fake security threat warnings on user’s machines to provoke the user to buy these fake products.

If the user doesn’t pay for the product then these rogue products behave as ransomware by not allowing the user to run any  applications.

This latest Bredolab sample (Md5: ac576a1983f6c455bf6a5e4f587ebc3a) that is installing the rogue security product was detected (at the time of composing this blog) by only five security vendors including Symantec AV.

Why bredolab is hard to detect?

From past few weeks we have seen different bredoalb samples in huge numbers with different tactics to evade AV detections.
Main ones are:

1) Start-code obfuscation approach
2) Hack pack approach

Start-code obfuscation approach: In this code, the entry point is obfuscated by introducing unwanted instructions in between valid instructions. One interesting example we have seen is as below.

In this sample the start code is obfuscated by introducing conditional jumps in-between starcode instructions.

If an AV engine tries to follow these instructions then these conditional jumps will lead to more conditional jumps where the AV engine will lose track in triggering its start code signatures.

 Most of the Bredolab samples we have seen are UPX-packed and they get unpacked with the standard UPX unpacker.

Hack pack approach:

Last week we saw a few samples which were UPX-packed but once unpacked with the standard UPX, it resulted in a corrupted executable with all sections showing their PhySize and offset as zero as shown below.

 
UPX Packed Sample

Unpacked sample with PhysSize and Offset = 00000000

If we try to load this unpacked executable to IDA Pro IDA, a multi-processor disassembler and a debugger, we get the below warnings as Standard UPX unpacker wasn’t able to re-construct the original executable.

This is due to the hack pack approach where the standard open source UPX packer source code is customized to generate a customized executable.

This tactic is to protect the original executable from getting extracted from the packer for two reasons. First, to prevent it from reaching the hands of security researchers so that they don’t reverse engineer it and second, to protect it from getting detected by AV signatures.

In summary the attacker’s approach towards evading AV detections is getting stronger and stronger as AV detections are reaction based. We have found that e-mail is the attacker’s favorite medium to spread these threats.