As a community, we focus so much on zero-day attacks and make many of our investment decisions based on addressing those. But a good phishing attack doesn't require a zero-day. In fact, some advanced social-engineering in simple phishing emails can go a long way to compromise your users. We spend so much effort on understanding and protecting against the latest zero-day, but in truth attackers are using simpler and better means of getting in. Chances are that unless you are a high profile target such as a government agency, defence contractor, or similar business involved in highly sensitive intelligence work, the proliferation of advanced phishing and social engineering tactics is a greater and more damaging threat than that of zero-day exploits. The most recent example of the return of the Dridex malware illustrates this trend well, with the banking malware reportedly being used to steal over $40M from victims in the UK and US via large scale phishing attacks.
In this post we’ll dissect a Dridex attack that was delivered via a phishing email campaign. By examining the malware payload and its activity we can better understand how Dridex works while building a baseline for defending against similar malware attacks as well as responding to these types of incidents. We’ll explode the malware in a secure lab environment so we can observe its behaviour without incurring any actual damage.
Phishing Email Examples
Two of the Security BSides email addresses that I manage were recently hit by similar phishing campaigns. Here are three phishing emails that I received at those addresses – two are classic “unpaid balance” phishing schemes while the other is an infected file masquerading as a resume for an open position. Note that there are red flags in each email that are indicative of potential phishing – all three lack personalisation and are rather vague, but use urgent language to compel the user into acting. Looking closely you’ll also note that the names associate with each sender’s email address don’t match up to the domain names of those addresses:
Phishing emails like these are one of the primary ways that the banking Trojan Dridex continues to proliferate and impact users across Europe, especially the UK. More recently Dridex has been seen appearing in the US as well. Dridex campaigns use crafted phishing emails with malicious Word, Excel or even PDF attachments and compelling language engineered to lure the user to activate the macro and drop itself. The second example above is particularly tricky, as the attachment opens claiming to be a “protected document” and has instructions to get the recipient to enable macros – as we’ll see below, this is a critical step in enabling the malware to launch. Once launched, the Trojan’s primary purpose is to infect the user’s computer and steal their banking credentials. Recently the UK’s National Crime Agency warned that Dridex has been used to steal an estimated £20 million from UK bank accounts via a phishing campaign being run out of Eastern Europe.
How Dridex Infects the User's Computer
Now that we’ve established how Dridex is most often delivered, let's take a look at how the Trojan deploys itself. In this scenario, the user has opened an attached invoice in Excel file format (similar to any of the malicious attachments in the above examples). When the user opens this, he/she sees a seemingly innocuous spreadsheet, unaware that something has happened in the background – in this case the background process is Excel launching a macro. Using process explorer, we see that one process is created by Excel:
When this occurred, the DG Management Console received an alert from the DG agent called ATP9006-Suspected Office macro phishing attack. Several defenses could be deployed in response to this alert, from blocking the process to killing the file entirely.
Let's take a deeper dive and look at how Digital Guardian sees the events that are occurring and why we deemed this process to be a phishing attack. The first anomaly detected is that Excel is launching a macro, that macro promptly communicates out to the Internet.
The network data for the macro’s outbound communication shows the following:
| IP | 202.124.241.199 |
| Source Port | 49186 |
| Remote Port | 80 |
| DNS | members[.]webshade[.]com[.]au |
| Direction | Outbound |
| Protocol | HTTP |
| URL | hxxp://members[.]webshade[.]com[.]au/43t3f/45y4g[.]exe |
Following the network communication, we see Excel writing a binary file:
The binary file is captured so that we can submit it to additional tools to determine what it is exactly.
Once written, the process is launched, and we can gather more information about the process. Using the process investigation feature, we can see the process’ properties, including information like where it is stored and launched from, its hashes (to investigate in VirusTotal or a similar tool), and so on. Looking at VirusTotal results, we can see that the file is indeed a Trojan, which most tools have identified as Dridex.
We can also examine the alerts associated with the phishing attack to glean more details, like the fact that the user opened an email attachment and then Office executed code:
From there we can drill down further to look at the details of these events and gather forensics data. This information is often useful in searching for other users who might have opened the attachment or for use in counter measures, such as adding the file attachment name or email title/sender to a block list in the email system.
We can continue to look deeper to see that Dridex malware actually got in. For the moment we only know that Excel launched a macro and downloaded an executable. But how did that macro arrive on the user’s workstation?
We have designed a calculated action that tells us that the file involved in the attack originally came from an email:
Drilling deeper, we see the original XLS file that was opened by the user; we can use this information to block such file attachments at the perimeter or even apply this to blocking rules managed by the DG agent. Clicking on the final custom data icon, we can see the email title – another piece of forensics data that can be used to help control or investigate the spread of this phishing campaign:
Focusing back on the process that was created, its first task is to connect and register with its C&C server. Again we see the network connections being tracked, as this process was created as part of a longer chain of events. The network activity is tracked under a specific category and throws an alert called ATP2020-D-NET.Identified Process doing TCP outbound connections.
Two things stand out here. The first is the IP address, which is hosted in Ukraine:
The other interesting thing is the communications on port 8448. This is an unusual port and could be used to detect other hosts that might be infected with this version of the Trojan. These network points provide more forensics evidence for the response team to take actions and do further investigations.
Defending Against Dridex
There you have it – we just explored how one of the most prolific Trojans is compromising users. Note that no zero-day was actually used to enter the machine but rather the success of the attack hinged on the willingness of an end user to go along with what they see in front of them.
A good security awareness program is probably the best solution to help your users combat these advanced phishing attacks. However, by having an understanding of the processes and behaviour that are common to malware attacks it is possible to build effective mitigation measures to stop an in-progress attack that has successfully compromised a user. In this case, policy-based controls should be deployed to prevent Office programs from downloading and/or writing binaries following a macro launch upon the opening of an email attachment. In order to make users better aware of these threats, user prompts could even be deployed to warn users when an Office program attempts to download a file from the Internet or write a file to disk. This would prevent such activities from happening in the background without users being aware, and would help train users to recognize and report attacks in progress. Moving further down the kill chain, blocking outbound network connections to known malicious domains (such as when this Dridex example attempted to connect with its C&C server), or in a worst case scenario, inbound network traffic from those domains, is a critical last line of defense in preventing the malware from executing.
