Dridex and Locky Return Via PDF Attachments in Latest Campaigns

Dridex and Locky, two prolific malware families that made waves in 2016 after being distributed in several high-volume spam campaigns, have returned after a brief hiatus. FireEye observed a decline in the volume of Dridex and Locky in the latter half of 2016, but we recently observed two new large campaigns.

While the PDF downloader described in this post is responsible for spreading both Dridex and Locky, for the purposes of this blog, we will be discussing the PDF downloader and the Dridex binary.

The larger of the two campaigns (Figure 1) involved a “payment receipt” theme and, according to our telemetry, primarily affected the insurance industry in the U.S.

Figure 1: Telemetry for the larger campaign

In the smaller of the two campaigns (Figure 2), the attachment was claimed to be an alert from a printer for a scanned document. This campaign primarily affected the government sector in the Middle East, U.S., and Japan.

Figure 2: Telemetry for the smaller campaign

Execution Flow

As seen in Figure 3, at a high-level, the execution flow consists of:

• Spam campaign email containing a malicious PDF file
• Attached PDF file drops and executes a DOCM document
• Dropped document file contains a macro which launches a PowerShell script upon execution.
• PowerShell script then fetches an encrypted binary from the command and control (C2) server
• Encrypted Binary is decrypted and executed, and malicious payload is dropped and launched

Figure 3: Full Execution Flow

Spam Campaign

We observed two patterns of subject lines used in these campaigns. One is Payment_XXX, where XXX refers to any random number, while the other one is Scanned image from MX-2600N. Figure 4 shows sample spam emails from both campaigns.

Figure 4: Spam Email Examples

The Attachments

Attached PDF File:

The PDF attachment contains several objects, but the most relevant ones are an embedded DOCM file (a macro enabled doc file) and a JavaScript object that drops and launches the DOCM file. Figure 5 shows the embedded DOCM file, and Figure 6 shows a snippet of the JavaScript that drops the DOCM file.

Figure 5: DOCM file header in Object 3

Figure 6: Dropper JavaScript snippet with reference to DOCM file to be dropped and executed

When the PDF document is opened, Adobe Reader displays a warning as shown in Figure 7, clearly stating that the attached file may be harmful.

Figure 7: Security Warning by Adobe

If the user ignores the warning and clicks OK, the DOCM file is written to %temp% and then launched.

Dropped Document File:

The document file opens in read only or protected mode, which means the macro inside the document file is not able to execute. To bypass this mechanism, the document displays a message prompting the user to “Enable Editing”, as seen in Figure 8.

Figure 8: Protected Document Asking for Permission to Enable Editing

Once a victim clicks “Enable Editing”, the embedded macro executes. In Figure 9, we can see that the command to be executed is hidden in the caption of form1. This macro executes a PowerShell command to communicate with the C2 server and downloads the next payload.

Figure 9: Embedded Macro

Figure 10 shows how the command is hidden a form.

Figure 10: Command Hidden a Form

PowerShell Script

The powershell is obfuscated and it can be de-obfuscated with the algorithm in Figure 11. Once executed, the scripts main function is to connect with the C2 server to retrieve a payload. The script contains an array of URIs, and it tries each one until it successfully receives a valid response from the server.

Figure 11: De-obfuscation routine for the obfuscated Powershell script

After de-obfuscating the script, it appears to be divided into two parts:

1. C2 Communication: In this step, the script generates the C2 domains and sends requests to them via HTTP. It checks for the response received, and if the response is not OK [200], it then re-tries the communication with another host.
2. Decryption of received data: If the server is alive, it responds with the data. The data is encrypted before being sent and then decrypted by the script via simple XOR. Figure 12 shows the C2 server communication details.

Figure 12: C2 Communication

During a sample run, the script requests the resource “/dfv45” from 192.232.251.217 and 216.87.186.133 and successfully receives a response from the second host.

The response is XOR encrypted. Figure 13 shows the response header.

Figure 13: C2 Response Header

The PowerShell script decodes the response and writes the decoded executable into %temp%. A python script to decode the response is shown in Figure 14.

Figure 14: Decryption Routine Code Snippet

The Final Payload

Up to this point, the process for distributing Dridex and Locky payloads has been the same. The malware that is delivered depends on the C2 server that is contacted.

In this case, the sample fetched the Dridex payload. When executed, Dridex unpacks and runs itself within the context of svchost.exe or spoolsv.exe via process hallowing to evade detection.

Conclusion

Dridex and Locky have been highly active and prolific in the past several months, and although the delivery mechanism often changes, the core behavior of the family remains unchanged. Dridex is one of the most active banking Trojans from the last few years, and Locky is one of the most active ransomware families. If the past year is any indication, Dridex and Locky distributors will continue to search for ways to evade detection. FireEye is committed to remaining vigilant against these efforts.

URLs seen distributing Dridex

URLs seen distributing Locky

Dridex C2 Servers

216.177.132[.]93:4143
152.66.249[.]132:44343
85.214.113[.]207:4743
192.184.84[.]119:4743
199.36.194[.]27:4743
104.131.182[.]74:4743
199.233.245[.]109:4743
74.220.207[.]120:80

Mitigations

Due to the widespread nature of these phishing campaigns, organizations can better protect themselves by addressing several key areas:

• Implement a web proxy: By deploying a web proxy, organizations will have the capability to craft rules which block outbound access to the unique URI parameters “/dvf45/” and “kjv783r/” used by Dridex and Locky. Note that this is a mitigation with limited durability and will require an increased awareness of these campaigns.
• Develop egress firewall policies: Develop and understanding of the necessary outbound traffic your organizations requires and, combined with a web proxy, block all unnecessary outbound traffic while forcing web and other authorized traffic through the proxy. By monitoring for violations, an organization can develop additional detection capabilities.

FireEye Multi Vector Execution (MVX) engine is able to recognize and block this threat.

• Enable enhanced PowerShell logging: Improving your organizations visibility into PowerShell logging has numerous benefits, one of which being the ability to determine malicious use of PowerShell such as is leveraged in this campaign.