On Dridex and a new "Zero-Day-Distribution" method

The banking trojan Dridex (also known as Cridex, Feodo, Geodo, etc.) has been distributed in the past via malicious documents containing macros sent by E-Mail. Just yesterday we discovered a new distribution method that is undetected by the various Sandbox solutions we have access to and all AV engines. We were able to happily share and send those infected files via Skype, Gmail and other platforms. So while Dridex itself isn't new, the distribution method definitely is --- and it will be very successful looking at current 0% detection ratio. In a sense, it is a "zero-day-distribution" method so we decided to use that term. ;-)

In this blogpost we will analyze a sample file, demonstrate the distribution method and cover some context, finishing up with a link to the updated VxStream Sandbox report at hybrid-analysis.com, as our engine is able to detect and execute the dropper code as of now.

At Payload Security malware analysis and working together with the IT-Security community is our passion, which is why we try to be as reactive and response as possible to new evasion techniques. As a reminder of latest additions to VxStream Sandbox, here are a few pointers:

• Bypassing "image click" macros
• embedded .[diag]cab Office attack vectors
• Cerber using DOT files with password prompt

... but let's get down to the nitty gritty of this Dridex campaign.

Initial Manual Assessment

In this example, we will be taking a look at "remittance advice 58.docx" (SHA256: da82eaeba71eeb95d643b0343b2c095d72b686314cd340631aa8d9fe08a74714).

As has been a recent trend we see for targetted attacks (more on that later), this malicious Office file does not contain any macros (or exploits, actually) to execute the payload:

Instead, the document contains an embedded file, which can be extracted from the "oleObject1.bin" file in the "embeddings" folder. In this case, as it is a Word file, the relative pathway would be word/embeddings/oleObject1.bin. Let's take a look:

As a quick initial assessment of the file, let's take a look at some of the strings we can find:

We quickly detect the following key information:

• a "Windows Shortcut" (.LNK) file seems to be embedded
• a reference to the Windows command prompt

Taking a deeper look we quickly see the actual "dropper" code, which is a powershell command:

A more readable format:

What it does:

• requests a PHP file from a remote server
• downloads the PHP file (which is actually a PE file) and renames it to "calc.exe" (probably in hope of being a bit less suspicious)
• executes the downloaded file

The downloaded file is Dridex. Using Windows Shortcut (.LNK) files as an "under-the-radar" distribution method is actually not that new for the group behind Dridex, as they have used that exact method as part of an E-Mail attachment. So in a sense this is just a new variation, albeit it is quite nested and obviously successful looking at the detection rates.

If you wanted to confirm that the file is Dridex, you could e.g. check the ET PRO rules, which are integrated into all VxStream Sandbox reports, if you have the appropriate license:

Dridex identified by ET PRO Rules

A normal execution of Dridex will download an encrypted DLL and after some security checks, the configuration file.

Why "Common" Dynamic Analysis Fails

Simply opening the document will cause nothing to happen initially. Instead, the embedded file has to be double-clicked. This is the first "hurdle" that most Sandbox systems will have difficulties with.

After double-clicking the file - on a default configured system - an additional prompt will have to be passed:

... only if we click "Open" on that prompt, the actual LNK file and consequently the Command Prompt -> Powershell execution chain will trigger and download Dridex.

Why is it a targetted attack?

The server(s) hosting Dridex seem to be denying access based on the geolocation. This can either be a temporary countermeasure while testing sandbox detection ratios or it can be a hint at a targetted attack for a specific region. We were only able to download the sample if the source IP was located in the region highlighted in green:

All other countries were denied downloading the sample in our case.

How does VxStream Sandbox perform? 

Obviously, we wouldn't be writing this blogpost if VxStream Sandbox would be performing poorly. ;-) To be fair, as we discovered the first files just yesterday, our engine was not parsing the embedded .LNK file properly, as we had been focusing on embedded executables, Powershell, VBScript, Javascript and some other file types. Nevertheless, as the sandbox has technology included that can deal with these kind of attacks in principle, it was an easy task to add support for the new missing file type. After updating the live systems (in less than 24h, noted), we successfully flag the file as malicious *without* the help of any AV detection. Here is a few example screenshots:

Link to report: https://www.hybrid-analysis.com/sample/da82eaeba71eeb95d643b0343b2c095d72b686314cd340631aa8d9fe08a74714?environmentId=100

Hunting more samples

This was actually quite interesting. Based on the embedded file "absolute pathway" that is included in the Word documents, were able to discover additional files that reach back to May/June on our public webservice:

Final Words

In this blogpost we demonstrates a brand new Dridex distribution method, outlined some initial assessment and demonstrated how important "state of the art" security solutions and vendor responsiveness is, as the groups behind malware are very creative, especially considering the money business that ransomware, banking trojans, etc. has become. Stay safe and we hope you enjoyed the read.

Other SHA256s:

bc17109629c455e6bbcf25d313f3c79234a2facf7691bef3df26cc2537071809
96d43a519e857663a78eff84b56bbb0343c7c6fb4b5814c0fd7a302abc74bd79
06eab8037525ba0ac8dc62512a149aea3786c33cd6e7d08b9c5b175777c31da3
1382a68b7a9b0f20670162d8cd8dc91ad27c556ec166a351910cfffeda1f9353
da82eaeba71eeb95d643b0343b2c095d72b686314cd340631aa8d9fe08a74714

Other URLs:

meow://4thkantonind.top/egypt/hashish/afghankush.php
meow://47matroskin.top/nazareth/animals/listen.php
meow://17uhrtreuhand.top/nazareth/animals/listen.php
meow://37virginiaslim.top/nazareth/animals/listen.php
meow://17uhrtreuhand.top/nazareth/animals/listen.php

Follow us on Twitter: https://twitter.com/payloadsecurity

Public Webservice: https://www.hybrid-analysis.com/

VxStream Sandbox: https://www.payload-security.com/products/vxstream-sandbox

About Dridex, decoding and deobfuscating VBE files, behavior signature triplets and other features

Decoding and deobfuscating embedded VBE files

We will start out this blogpost outlining the technologically speaking probably most exciting feature that we added recently: VxStream Sandbox is now able to detect, extract, decode and deobfuscate VBE (encoded visual basic) macros from input samples. This is a feature we are quite proud of, because we are probably the first and only sandbox that is capable of doing so. We would like to demonstrate the feature on a sample that someone just recently made us aware of: it's a dridex variant (the hash / sample is available at the bottom) that appears in form of a Windows shortcut file and contains an embedded VBE macro as part of its overlay. The sample does not yield good results on some 'APT industry leader' solutions, as we have heard. Anyway, what our system will do is the following:

• Detect embedded VBE files
• Carve them out as an 'extra file' for analysis
• Decode the VBE file to a VBS file for later post-analysis-analysis
• Launch the carved VBE file additionally to the input sample (in case the input sample fails to launch its payload)
• Deobfuscate the decoded VBE file
• Put all that information into the report and have it reflected as part of the Threat Score

The steps an analyst would usually need to take to extract/decode and deobfuscate the macro (to obtain e.g. the malicious URL) would be quite time intensive, so seeing all that in an automated fashion happening within minutes makes us quite happy. The following screenshots will give you just a brief excerpt of the most stunning parts of the report:

As can be seen, it is possible to even download the decoded *.vbs file for further analysis. Also, an interesting conclusion of this sample, especially if the actual payload is not executed, is that pure static analysis can be a very powerful tool when analyzing macros. It might be generic to instrument VB execution and extract data, but that always depends on a successful execution (i.e. what if the file doesn't run as expected?). That's why we believe in the combination of both dynamic and static analysis techniques: something we try to describe as 'Hybrid Analysis'.

Report (including download of sample): Here

Other progress

It is difficult to stay up-to-date with all the feature we add to our webservice, because there is no published changelog. That's why every now and then we like to make a blogpost that gives some insights, but also to recap and archive the development progress we made for ourself. Looking at our public webservice as a visitor, there is two places you can use to indirectly see the development:

Version number on the front page

Total behavior signatures

The total number of behavior has been on a constant rise since we went online late 2014. Whenever we find a new interesting sample, we check if there is some malicious/suspicious behavior that can be turned into a generic and replicable signature. For example, we just recently added a 'Sample was identified as malicious by a large number of Antivirus engines' signature in addition to the previous 'Sample was identified by at least one Antivirus engine'. The new signature has a far higher relevance on our internal 'Threat Score' calculation, because if 25% of 50+ AVs agree that a file is malicious, the chances of a false positive is quite low. While this isn't an example for a generic signature, it is a good example of the gradual and constant improvements that happen to our system all the time.

Incident Response Section

After getting some feedback of incident responders we decided to add a new section called 'Incident Response' that contains a 'Risk Assessment' and a 'Network' area. The 'Risk Assessment' area basically displays some more broad categories (such as 'Spyware/Leak') depending on whether a signature or a combination of signatures matched (configured internally). The idea behind it is to answer the question 'How worried should I be?' (e.g. if the submitter knows an information leaking file was executed on a computer in the finance dept.). 

The 'Network' area is a summary of what you would find in the 'Network Traffic' section to allow quick response based on the IPs and domain names. Ovearll, it does not contain more information than you would be able to read by sifting through the report, but it can save some time on a first glance. This is still a work in progress.

Platform Intelligence Section

The 'Platform Intelligence' section is also new and may appear on malicious reports. It is the beginning of a broader development agenda that we want to learn about a file by comparing/associating its data with data from other reports on the platform. As the database is growing (we have about 30k reports online right now), there will be more and more useful applications.

The first feature implemented as part of the 'Platform Intelligence' section is the 'Report Behavior Comparison' section, which - under the hood - is quite effective in regard to determining if a file is malicious if the report database is large and diverse. What we noticed was the following: if one looks at a single behavior signature (e.g. 'Contains ability to retrieve keyboard strokes') it is often not a strong enough indicator to make a verdict about the file (think of an installer, which is often packed, drops files, shows network activity, sets an autostart registry key, etc.). When one looks at certain combinations of signatures though (e.g. 'Contains ability to retrieve keyboard strokes' AND 'Writes data to a remote process' AND ...) and you check each combination against every report (benign or malicious) in the entire database, it is possible to isolate signature combinations that are unique to malware. Using signature combinations, it is also possible to classify malware, but we have not gone that far yet. Anyway, what we can say is: the larger the number of signature tuples, the higher the confidence will be, but the more specific to certain malware families. Again, this is still a work in progress, but what is nice about the implementation is that we calculate all tuples on-the-fly based on a live snapshot of all triplets of all malicious reports in the database (i.e. if you refresh a report the next day, you might see different data). This feature has been a research topic of one of our main developers some years ago, and because it is still a work in progress and relatively experimental, the results of the section are not added to the 'Threat Score', but just displayed as an additive to the rest of the report.