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
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
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
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
shows the embedded DOCM file, and Figure 6 shows a snippet of the
Figure 5: DOCM file header in Object 3
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
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:
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 , it then
re-tries the communication with another host.
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
184.108.40.206 and 220.127.116.11 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.
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
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
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
FireEye Multi Vector Execution (MVX) engine is able to
recognize and block this threat.
Enable enhanced PowerShell logging: Improving your
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.
*** This is a Security Bloggers Network syndicated blog from Threat Research Blog authored by Threat Research Blog. Read the original post at: http://www.fireeye.com/blog/threat-research/2017/05/dridex_and_lockyret.html