New Era in Anti-Virus Detection Evasions

In the last couple of months, we wrote about the discoveries we found in Dridex, the long-lived banking Trojan that is still quite active in-the-wild. In the blog post, TL;DR, we mentioned the Trojan has equipped with new module that could be used to evade one of the anti-virus products, however, the affected vendor has now released a fix, so we decided to share the details. In this post, we will briefly discuss some of the novel techniques used by the Trojan to evade detection by anti-virus.

The Evolution of Anti-Virus Detection Evasions

I’m pretty sure that this is not something new, as malware authors have been constantly fighting with anti-malware products to avoid being caught once they managed to get a footprint on a compromised machine. Traditionally, if for some reason the anti-malware product installed on the machine did not pick up the sample when it was dropped and executed, and successfully established persistence on the compromised machine, the very first thing the old-fashioned malware did was to terminate or kill the anti-malware process. Obviously, this invasive technique could easily trigger the attention of the victims and make them believe that their machine has been compromised. In addition, this old-school technique is pretty well-known and should have already been circumvented by most of the security vendors, so it should no longer work against modern anti-virus products. It’s also worth mentioning that there are also other traditional detection evasion methods, like adding obfuscation and using custom packers which are typically deployed by the malware author on their piece of work.

Obviously, the traditional way to circumvent anti-virus detection revolves around hardening the malware binaries. Nowadays, threat actors take this one step further and adapt some innovative approaches to avoid being detected by anti-malware. It is not necessary to utilize sophisticated vulnerabilities to exploit an anti-malware product because there are some simple yet effective ways to do this. We have been observing this very thing from Dridex:

1. Tackling the automatic update components of anti-malware
2. Tackling the exclusion components of anti-malware

The first approach has already been documented by researchers from ThreatTrack with limited elaboration. In a nutshell, the following commented pseudo-code demonstrates the actions carried out by the Trojan to make the automatic update component became non-functional:

At the same time, we tried to dig out older variants of Dridex, and as far as we are aware, the same code has been around in the variants found from middle of 2015 until today. We were curious about the effectiveness of this code, so we tested it with the latest version of AVG and the result was positive. We were not surprised that this flaw was not affecting the latest version of AVG, because the vendor could have fixed the flaw already since the Trojan has been adapting the same code for more than a year. In short, as demonstrated by Dridex, one could make the folder storing the downloaded update files become inaccessible, which simultaneously impairs the product’s update component.

At the end of March 2016, we discovered another anti-malware product being targeted by this Trojan, and this time it involved a zero-day vulnerability in the product in order to evade detection. Anti-malware products typically implement an exclusion functionality, which is a feature commonly found in anti-virus products to avoid some files or folders from being scanned by anti-virus engines, for various reasons, but not limited to the following:

• Permit accessing some detected files while awaiting vendors to fix a false positive
• Optimize the performance of the machine running the anti-malware product, especially if there is an enormous number of files known to be clean in a particular folder

For some products, the exclusion functionality is implemented separately in a dynamic link library (DLL) module, possibly for scalability. We believe that this DLL is designed and allowed to be executed by an arbitrary application with non-administrative privileges. In other words, this arbitrary application is free to execute and call the export functions provided by the DLL.

Figure 1: VizorUniclientLibrary.dll default permission allows non-administrative users to execute the file

The fact is that this DLL module will allow an arbitrary application to call the vulnerable export functions that are responsible in adding a file or folder to the product’s exclusion list. Due to the insufficient integrity check in this vulnerable function, an arbitrary application could trivially exclude a desired file or folder location into the exception list to avoid probing.

Figure 2: Arbitrary application calling the vulnerable export functions to add arbitrary folder to exception list

Finally, it is important to note that the detection evasions discussed above might be effective only against signature-based detection technology.

This blog post is meant to give a heads up to security vendors that malware authors have been adapting novel methods to circumvent their security products in order to stay undetected on the infected machine for as long as possible. Doing this buys them more time to harvest more profit per infected machine, or worse, the banking Trojan implementing these evasion techniques could wreak further havoc on the victims. We are striving to better understand the tactics of the bad guys’ to keep on improving our products to further protect end-users.

-= FortiGuard Lion Team =-

Appendix

Hashes

10CF55031C31F8A615B93CEC9D3675B6AF2FB7D9AA4EF5163723B55E43B9A9F4 - Dropper distributed in June 2016 

F5A56C7005C100D5D50517C255F50F25884CAFD7709A0F5942B6C78C41CAB4F5 - ‘mod9’ exploiting TM exclusion vulnerability

Disclosure Timeline

• 18 March 2016 - Reported issue to one of internal contacts in Trend Micro
• 04 April 2016 - Vendor replied and requested for report and POC
• 04 April 2016 - Sent report and POC to vendor
• 06 April 2016 - Vendor said they were unable to replicate the issue
• 06 April 2016 - Asked for clarification of how POC was tested at vendor’s end 
• 07 April 2016 - Vendor replied the POC was executed on Windows 10 64-Bit
• 07 April 2016 - Clarified with vendor that the POC should execute on 32-Bit platform
• 13 April 2016 - Vendor managed to reproduce the issue and sent us the fixed binary for testing
• 13 April 2016 - Replied to vendor that the fixed binary works as expected and requested the ETA when the patch will be released to public
• 15 April 2016 - Vendor replied with the release schedule set on 30 June 2016
• 16 April 2016 - Both sides agreed with the public disclosure date
• 23 June 2016 - Followed up with vendor about advisory disclosure
• 28 June 2016 - Vendor said they are working on the advisory and requested for reporter's acknowledgment information
• 28 June 2016 - Replied with acknowledgement information and informed vendor that our advisory will be released on schedule
• 30 June 2016 - Asked vendor for their advisory's URL
• 06 July 2016 - Vendor said the fix is scheduled to be released on July 19
• 14 July 2016 - Vendor said the schedule of releasing the fix will be delayed
• 20 July 2016 - Vendor updated the next release schedule will be set on July 26
• 27 July 2016 - The fix is publicly released