Responding to Dridex

The Dridex trojan posed a significant threat to major financial institutions since its identification in 2011. Unlike most malware, Dridex continuously evolves, growing more sophisticated over time and escaping detection by hiding behind proxying layers.

A few months back, a CYDEF customer was infected by this malware. The following blog post details steps to malware identification, response efforts and remediation.

What is Dridex?

The Dridex malware is a piece of malicious software designed to steal the infected user's credentials. It earned its reputation as a banking trojan by hijacking credentials used on banking sites.

The malware has gone through multiple evolutions to add capabilities such as crypto wallet theaft and anti-virus (AV) evasion. Part of this evasion capability comes from the use of “Living off the Land” (LoL) techniques, where common system utilities like Microsoft Office are used for malicious purposes. When combined with use of Office macros, the Dridex malware spreads prolifically and without detection. By attaching to well-known, trusted software, Dridex effectively evades standard AV tools.

Once Dridex steals user credentials, the malware operators "have the potential to facilitate fraudulent automated clearing house (ACH) and wire transfers, open fraudulent accounts, and potentially adapt victim accounts for other scams involving business e-mail compromise or money mule activity.” (U.S. Cybersecurity & Infrastructure Security Agency)

Dridex and the COVID-19 Pandemic

In light of the COVID-19 pandemic, attackers may exploit a new set of sensitive resources. With many employees working from home to avoid infection, large and small businesses alike are relying on cloud-based resources to power their workforces, thus providing Dridex a new opportunity to steal credentials.

Identifying the Dridex Incident

In our client’s instance, Dridex was detected while we were conducting our daily system monitoring. We identified a new command line in Powershell:

We also identified new network activity from Powershell going to an unknown ASN geolocated in Russia. We quickly downloaded the logs to make a detailed inquiry about this suspicious activity.

It was then we identified the following Powershell command:

The network communication pointed to the following IP address:

The rundll parent process command line:

Suspicious Powershell Usage

The obfuscated Powershell was already quite suspicious. Add commands spread out and reassembled via string concatenation – we knew something was amiss. The use of rundll32 -s shell32 was a clear indicator that this was illegitimate activity.

Only a programmer trying to bypass security would write code in this way.

At that point we were convinced this was an incident and contacted the client. We also suggested that the IP address be blocked at the firewall.

Once we notified the client about the incident, we dug deeper. Looking at the other unclassified activity, we found the suspicious rundll32 command line and were able to isolate that the parent process: Excel.

Since an Excel file was likely to be the source of the breach, we noted the time of the occurrence and began to sort through the relevant raw logs.

Tackling Anti-Virus Failure and Malware Identification

After gathering the all the raw logs from our cloud storage, we took three steps to understand the breach: we reviewed the anti-virus scan, identified the malware, and pinpointed the time of the breach.

The Antidote to Anti-Virus Failure: Quarantine

Once the breach was identified, our client scanned the machine in question with an anti-virus. However, the AV was not able to find the malware. In order to quarantine the malware, the customer gave us the authorization to use our containment module. We disabled the network card on the machine in question to prevent further spread across the network.

Identifying the Brand of Malware

Once the machine was quarantined, we worked to identify the specific brand of this malware. Identifying the brand would allow us to check if there was a safe way to eradicate the malware, or if re-imaging the system would be the ideal solution.

To do so, we would need to de-obfuscate the code to be able to compare it to other known software. In particular, we needed to extract the base64 encoded expression.

The first step was to deflate the content. This gave us a gzip compressed archive. We then unzipped the file to get the end result.

In the de-obfuscated code, we could find the URL rumetonare[.]com which we used to find the following post that matched both the URL for the CnC and the Powershell code observed

Twitter tracks Dridex

Dridex had infected our client’s machine. With this knowledge, we contacted the client to indicate that the most prudent course of action was to re-image the machine.

Timeline Reconstruction

With the malware identified, we needed to understand the infection timeline. The timeline would indicate the source of the infection, when the breach occurred, and if any further action would needed to repair the client’s environment.

Using the Excel process GUID, we identified all the activity from the process in the raw logs. In particular, we sought out the Excel file that started the infection. Ultimately, a user received an email in Outlook that provided a link to the internal webmail client. Based on the URL, we surmised that the message told the user that an email was quarantined, and that in order to access the email, the user would need to log on to webmail. At this point the victim downloaded the attached Excel file and unwittingly executed Dridex.

Once we identified the source of the infection, we knew that it was unlikely for the breach to re-occur. While it was a potentially damaging incident, it was also an important, teachable moment for internal security awareness.

Identifying Potential Persistence Points

In addition to finding the source, we sought out potential persistence points. We found the following command line linked to the malware:

This line suggested two things: the script was either a form of privilege escalation from the local user account, or a way to achieve persistence (or potentially both). Having found both the initial vector and the potential installation point, we could reconstruct the timeline of events.

The Impacts of Dridex: Re-Imaging a Single Machine

With all of this information in hand, our client decided to re-image the machine. As a precautionary measure, they also asked us to perform ongoing monitoring to ensure no signs of reinfection appeared before rejoining the machine to the enterprise domain. We notified the customer the following day that we didn’t notice any signs of reinfection and the customer could resume normal operation.

When Breaches Occur, CYDEF Persists

This incident highlights the importance of cybersecurity awareness in a business setting. Had this individual user not pursued a prompt from an illegitimate email, the breach would not have occurred.

But, after all, to err is human. Employees make mistakes. That’s when it’s important to user a layered approach – with access to endpoint security, detection tools and managed support. CYDEF was able to step in when the AV couldn’t identify a problem, and we effectively tracked down the breach.

Are you interested in learning more about detecting breaches related to honest human mistakes? Get in touch! We’d love to help.

References

Dridex Banking Trojan Will Soon Target Crypto-Currency Wallets

New Dridex malware strain avoids antivirus software detection

Dridex Malware Alert AA19-339A