Detecting and removing Dridex

“The cleanup [of Dridex] is relatively easy”

– Orla Cox, Director, Security Response, Symantec

It’s not that often you see really advanced malware these days. The bad guys don’t have to fight and defeat security professionals. All they need to be successful is to defeat a regular user. It’s up to security experts to protect their users and it’s not always easy to do. Users’ negligence and lack of basic information security hygiene plays on the side of the bad guys. Because of that modern malware doesn’t have to be really advanced. It should be convincing enough to trick the user to launch the malware deliberately and it gets the job done. Of course there are really complex malware out there in the form of APT, but it’s more of governments competing with each other for power. They don’t care much about regular Joe and Jane and stealing money from them. The cybercriminals do.

One of the most advanced malware examples is Dridex. It is believed that it is an evolution of Cridex, which in its turn is an advancement of Zeus banking trojan. It has a long history, spanning through almost 10 years of development. Here I’ll describe how to detect and how to clean the most modern version of it which I dealt with during April and May 2016. A fair share of information on Dridex comes from anti-virus vendors such as Symantec and their typical advice is to use their anti-virus solution to cleanup computers from this malware. The problem is they don’t always work, so here I’m going to break down the clean up process into basic steps that can be automated using regular Windows bat/cmd shell or PowerShell.

First a few words on how this malware is distributed. The main distribution channel of Dridex is phishing email campaigns. Majority of them usually get blocked on a front-end secure email gateway (SEG) level. No matter if you use your corporate email or gmail or other public cloud email services — there’s a solution up there that filters incoming emails for spam and viruses. Unfortunately, there are ways to trick these systems like the one described in the previous post here, so some emails get through. The bad guys have a good deal of personal information about you from various breaches and leaks. If the Dridex gang isn’t affiliated directly with other gangs that have this information or didn’t hack your company or your cloud email service provider themselves, they still can buy your personal information on the black market.

Consider, for example, that in just recent years Target Corp. lost ~100 million of their customer records (that’s 1/3 of the US population), Home Depot lost ~56 million records and Anthem lost ~80 million of their customer records to the hackers, just these three breaches combined give a good chance that your records including emails, full name, DoB, health records and SSN (for Anthem breach), phone, etc are at the hands of the bad guys. And being an insider of this industry I can tell you that majority of breaches aren’t reported to the public, what ends up in the news is just the tip of the iceberg.

So this info is used to compose personalized phishing emails. Usually such an email has a personal greeting with your name and often your position in a company and often looks pretty convincing. Since the primary target of the Dridex gang is the financial sector they use appropriate financial themes. Their typical email is about some outstanding balance or overdraft or invoice or remittance details.

A typical Dridex email contains a zip archive. Inside of this archive you can find either an MS Office document or a .js file. They may add some confusion to a filename disguising it as the one having some expected document extension, so in the end it may look like this “remittance details #4567236.pdf.js”. But this “.pdf” in the middle of the filename doesn’t matter in this case as Windows takes into account the last extension only, which is .js and treats it as a JScript file. Usually it is an obfuscated JScript. If a user double-clicks on a file then it does two main things: a) it downloads an executable from one of the hacked web-sites on the Internet and places it into a %userprofile% subfolder, b) launches this executable. From this point a computer is compromised.

Another approach is using macros in MS Office documents. While stopping .js files is relatively easy (sane people don’t send .js files to each other in unsolicited emails) on a SEG level (with some exceptions, like the one described in the previous post), it doesn’t make sense to stop MS Office documents from coming through as too many people send them. They could be your clients, partners, vendors, etc. Modern versions of MS Office do not allow users to run macros right away by default. In order to run a macro a user has to 1) escape a so-called “protected mode” (click enable the 1st time) and 2) allow macros (click enable for the 2nd time). The bad guys use various techniques to trick the user to click “enable”. For example, they display some gibberish text and provide a brief explanation stating that if you don’t see a proper English text here then you aren’t using the latest version of MS Office, but you still can click “enable” button to convert the text to your MS Office version so you can see it. And some people click. Then a macro gets executed, a malicious executable gets downloaded from the Web and the computer gets compromised.

Here’s one of the many examples, this is one is a pretty straight-forward one. When a user clicks “enable” the malicious macro gets executed:

Dridex distributing document lures the user to enable macros

Now, what exactly Dridex does to your PC? Lots of things. It is really a Swiss-knife type of malware employing a multi-module approach. The main module just waits silently for you to start online banking operations and then intervenes. Other modules include a keylogger that records all your keyboard input to sniff on your credentials, a module that allows the bad guys to use your PC as a pivoting point, sending Dridex emails to people from your contact list, a VNC module allowing the bad guys to take full remote control of your PC and press your keys and move your mouse as if they sat at your PC, a module that collects information about your PC, about your domain users and uploads everything to the Dridex cloud, a module that scans your documents for valuable information, etc. Ultimately, each successful Dridex infection should be considered as a breach, especially if a PC is a domain-joined enterprise workstation.

How come that Dridex infects a PC bypassing anti-viruses? Can’t they spot it and prevent its malicious activity? Not always and here’s some evidence to support this from April and May of 2016. VirusTotal is a cloud service that lets you upload a file to their web-site and scan it using ~55 anti-virus engines, so you can immediately tell who can catch it. Of course, first you need to locate Dridex files on an infected PC which isn’t always easy, we’ll discuss this process in detail a little later. Meanwhile see these screenshots to get an idea of Dridex detection situation at the time of the active Dridex phishing campaign:

AVs-that-detect-dridex6 AVs-that-detect-dridex5 AVs-that-detect-dridex1

As you can easily witness from these VirusTotal screenshots, it’s a rare occasion that an AV detects Dridex modules. They aren’t quick at reacting as well, probably because the gang behind Dridex does a good job at quality repacking their executables often.

Take a note, that in some cases some AVs detected this malware as “generic” type of trojan. It usually means that the AV does not have this particular virus signature in its database and therefore can’t detect and clean it robustly. Instead, it relies on its “heuristics” engine that watches for specific indicators, such as API use, file and registry operations, that are often employed by the bad guys and never or rarely by legitimate programs. For our purposes it’s worth noting that because heuristics isn’t as robust as signature-based detection, many AVs DO NOT clean a potential malware if their heuristics module gets triggered. They will report it for sure, but without cleaning you end up with an infected computer you don’t know how to clean.

So how do you clean Dridex from a computer running Windows OS? I’m going to describe the ways it preserves itself in a system, its general behavior and hiding techniques, and finally how to clean it up manually. I’m going to describe both detection and cleanup procedures using command-line tools that are easily scriptable to ensure their convenient use in large scale corporate environments. I will not dive deeply into the malware internal structure, i.e. no static analysis. It is usually something that AV vendors are interested in, but for the purpose of incident response in a typical enterprise it’s not worth the effort in majority of cases. In addition to that, static analysis is very time consuming, especially when analyzing malware so advanced as Dridex. I may decide to do it later though, but not likely.

So, because Dridex is a banking trojan and AV detection rates are very low, chances are that the infection will not be noticed until someone tries to conduct online banking operations on an infected computer. That’s when Dridex wakes up and tries to act behind the scenes. Dridex recognizes a few hundreds online banking services, knows how to deal with them, hijacks you banking session and tries to transfer money from your account using your credentials. Money get transferred through a chain of banks and accounts and usually dissolve somewhere in post-Soviet Union space.

This activity has its own unique indicators, so banks can use it to detect and prevent bad things from happening. But it’s not always the case, especially for smaller banks, so you’d better not rely on their security controls. It’s in their best interest to prevent a fraudulent activity from happening, but be realistic, they can’t always keep up with all the malware threats, especially considering that many anti-virus vendors can’t do that as well.

With a typical malware infection you would expect some rogue process running among legit processes on an infected Windows computer, which is something that is pretty easy to spot in Task Manager or using a more advanced tool many malware analysts use that is Mark Russinovich’s “Process Explorer”. But it’s not the case with Dridex! There are NO rogue processes on a Dridex-infected computer:

Dridex-no-rogue-processes

Take a note that all processes displayed in this screenshot from Process Explorer are legit. That happens because instead of spawning its own process with its own executable which would be easy to spot, Dridex hijacks Windows’ explorer.exe process that is present on every windows computer (with the exception of “server core” or “nano” type of Windows Server installations). Here’s how it can be seen, this is a screenshot with handles opened by explorer.exe process, filtered by certain location and name:

 Dridex-explorer.exe-open-handle

In all my tests Dridex always started from this locallow location. From what I can tell it mimics Cisco WebEx temporary files, that occasionally get created in this folder and have a similar naming convention. All WebEx files that I managed to collect have filenames that start with “pre” or “wbk” which followed by what seems to be a hexadecimal word. Basically it is a four symbol combination, that may contain numbers from 0 to 9 and Latin letters from A to F.

Dridex files, on the other hand, start with three completely random lowercase Latin letters, followed by a random hex word similarly to WebEx files. Here are some examples (WebEx files are underlined with green lines):

Dridex-modules

The bad guys not always have a quality assurance step in their software development life cycle so their malware is often of inferior quality and can crash periodically. Dridex is not an exception and on a few occasions I noticed that Dridex dynamically loaded library injected into explorer.exe dies by itself (this could be done on purpose though, however, it’s not clear why would they do that in this case), so detecting it by an open handle to its main module isn’t 100% bulletproof, however, can be used with some degree of certainty. So in addition to a handle.exe command line I’ve shown above you can check locallow folder for the presence of Dridex files.

For example, if you have MS SCCM (Microsoft System Center Configuration Manager) deployed to your endpoints you can create a configuration item that you can use to check all your machines for compliance. Here is a PowerShell script you can use:

$ComplianceExcludePre¬† = ‘Compliant’
$Check = get-childitem $env:userprofile\appdata\locallow *.tmp|where {$_.Name -notlike “pre*” -and $_.Name -notlike “wbk*”}
If ($Check) {$ComplianceExcludePre = ‘Non-Compliant’}
$ComplianceExcludePre

The only problem here would be the case with potential false negatives when Dridex generates filenames that match WebEx file naming scheme exactly, but the chances are pretty low. If you want to be 100% sure you can either remove “where” condition, but in this case you’ll have plenty of false positives, or advance this script to check for other conditions. For example, all legit “wbk” files I’ve found are of relatively small size. Dridex modules are usually 342 KB and above, while wbk files are just tens of kilobytes in size. This could be checked in a script. Another option in addition to this would be testing if the file is a 7z LZMA archive, as all legit “pre” files I’ve found were archives with various WebEx DLLs and other WebEx auxiliary files.

And getting back to Dridex unreliability. Probably, in order to make sure that Dridex gets restarted each time it crashes, the bad guys create a task in Windows Task Scheduler that attempts to launch it each 10 minutes. This is also a method of persistence that allows it to survive a computer reboot. Here is a Dridex task:

¬†Dridex-Windows-Task-SchedulerA hexadecimal GUID string in curly braces seems to be random, so in order to get this task description you have to know it beforehand. Here’s a command you can use to check if there’s a Dridex task present on a computer:

schtasks /query /fo list|findstr /i /c:”user_feed”

However, in addition to Dridex task, this could bring up a task generated by MS Office Outlook RSS feed synchronization feature. It turns out that Dridex task in order to disguise itself mimics Outlook RSS task. Here’s how a legit Outlook RSS task looks like:

Microsoft-Outlook-RSS-Feed-Synchronization

There are a few ways to distinguish between a legit task and a Dridex rogue task. One thing, you can rely on the fact that the legit Outlook task has a GUID identifier that contains capitals only, while the Dridex task always has letters in lowercase. Another approach would be to check for a program to run. In a legit scenario, obviously, a task points to a legit Microsoft msfeedssync.exe executable. Dridex, on the other hand, gets launched using a legit Microsoft rundll32.exe software that has a malicious DLL supplied to it from a %userprofile% subfolder.

Now you know a couple of ways to detect the presence of running and functional Dridex. It’s time to clean it up. As I already briefly mentioned above, Dridex preserves itself by creating a scheduled task in Windows Task Scheduler. Here’s how it looks in Mark Russinovich’s “Autoruns”:

Dridex-Autorstart-Entry

Note that the bad guys mask their task by supplying some additional disguising information, such as description. You won’t see this often in modern malware, usually these fields are left blank.

The simplest approach to clean up Dridex would be to do the following procedure:

  1. Kill explorer.exe process from memory, taskkill /f /im explorer.exe
  2. Remove all tmp files from C:\users\username\data\locallow, del %userprofile%\appdata\locallow\*.tmp. There could be more than one user on a PC and you’d better traverse through all users’ profile folders to check for Dridex files.
  3. Remove Dridex task, schtasks /delete /tn “User_Feed_Synchronization-{Dridex-Random-Hex-GUID}” /f
  4. Reboot the PC.

All these steps are better scripted because you don’t want to end up in a situation when a Dridex task gets triggered and relaunches Dridex while you are half way through the procedure.

Fourth step is probably not necessary, but because the cleanup script that I’ve written runs in NT Authority\SYSTEM security context there’s no easy way to relaunch explorer.exe in a user’s security context. You are welcome to share better approaches in comments. Now that I covered both detection and cleanup procedures, I’d like to share a few facts and odd situations I’ve noticed while working on cleaning up Dridex.

First thing is the bad guys use a Windows PE executable for the initial infection. This executable gets downloaded from the Internet as a second stage by either JScript or Visual Basic Script, depending on initial attack vector (pure .js or MS Office document). This executable places Dridex dynamically loaded library into a %userprofile% subfolder, creates a scheduled task and launches Dridex. This is a serious flaw in infection design as it lets people with configured SRP (Software Restriction Policies) or AppLocker or 3rd-party TE (Trusted Execution) tech software to avoid infection as the 2nd stage executable will never be able to run from the %userprofile% if the TE solution is configured properly. Preventing DLLs to run from the %userprofile% folder is a more resource-heavy security control and isn’t something that is used often. Dridex would be able to run just fine even on many TE-protected computers, but it wouldn’t be able to infect them because they use a PE executable on the 2nd stage of the infection process.

Second, Dridex is multi-module malware. The main module is the one that gets launched by rundll32.exe. All other modules share the same naming convention as the main module. I assume they get launched by the main module, but the logic used in the process is unknown. In majority of cases I was getting only one Dridex tmp file in %userprofile%\appdata\locallow, but in some cases there were several. I don’t know when and how they get downloaded and what is their exact purpose.

Third, while Dridex stays for the most part in dormant state, sometimes it decides to redistribute itself through MS Outlook. It is unknown if it supports other email clients. With Outlook it queries for Outlook contact list, selects a bunch of contacts, composes emails and sends them to these contacts, attaching typical Dridex distribution malware in a form of a zipped JScript or a zipped MS Office document. This mass mailing technique is especially dangerous because a) the contacts receive emails from a person they know, b) email formatting is typical for this person and the contacts are familiar with it, it increases their level of trust to the malicious email even more, c) if Outlook is set up to use S/MIME or PGP to digitally sign or encrypt emails the resulting malicious emails will be digitally signed and maybe even encrypted that raises contacts’ level of trust to this message once more. Overall, the chances of successful Dridex infection of Outlook contacts in this case are significantly higher than in a case when Dridex is distributed using a regular Dridex phishing campaign approach.

And, finally, some random fun facts about Dridex.

Dridex communicates to some kind of Dridex cloud on the Internet using TCP port 8443. You can set up your IDS to catch this suspicious activity. Here’s an example of me checking a certain Dridex cloud host on the Internet before it gets shut down:

Dridex-communication-network-cloud

Dridex infected computers talk to Dridex cloud hosts on the Internet by direct IPs, not by predefined domain names or DGA-generated random domain names as one would expect. This could lead to Dridex communication not getting detected if your IDS solution relies solely on catching suspicious DNS queries or DGA DNS queries. Here’s an example of a communication:

Dridex-cloud-communication

Dridex seems to be operated by a Russian-speaking gang. We know that from the fact that some arrests of Russian-speaking crooks related to the Dridex gang already made, these arrests were covered by Brian Krebs in his blog. Here’s another piece of evidence from McAfee short entry on Dridex:

Dridex-Zalupa-Kurva“Zalupa” means literal “dickhead” in Russian. “Kurva” is originally a Polish word meaning “bitch”, it is also used by the Russians in this exact spelling as the Polacks write it as “Kurwa”, note the difference between ‘v’ and ‘w’.

I plan to add to this post a link to some archived Dridex samples that I have, so you can play with them/reverse by yourself. Don’t expect me to reverse them earlier than in Autumn 2016 as I’m pretty busy and reversing is more of a hobby for me.

Stay safe!

Leave a Reply

Your email address will not be published. Required fields are marked *