Skilled attackers continually seek out new attack vectors, while
employing evasion techniques to maintain the effectiveness of old
vectors, in an ever-changing defensive landscape. Many of these threat
actors employ obfuscation frameworks for com…
Skilled attackers continually seek out new attack vectors, while
employing evasion techniques to maintain the effectiveness of old
vectors, in an ever-changing defensive landscape. Many of these threat
actors employ obfuscation frameworks for com…
I (Matthew Haigh) recently contributed to FLARE’s FakeNet-NG
network simulator by adding content-based protocol detection and
configuration. This feature is useful for analyzing malware that uses
a protocol over a non-standard port; for example, …
In 2016, FLARE introduced
FakeNet-NG, an open-source network analysis tool written in
Python. FakeNet-NG allows security analysts to observe and interact
with network applications using standard or custom protocols on a
single Windows host, which is especially useful for malware analysis
and reverse engineering. Since FakeNet-NG’s release, FLARE has added
support for additional protocols. FakeNet-NG now has out-of-the-box
support for DNS, HTTP (including BITS), FTP, TFTP, IRC, SMTP, POP,
TCP, and UDP as well as SSL.
Building on this work, FLARE has now brought FakeNet-NG to Linux.
This allows analysts to perform basic dynamic analysis either on a
single Linux host or using a separate, dedicated machine in the same
way as INetSim. INetSim has made amazing contributions to the
productivity of the security community and is still the tool of choice
for many analysts. Now, FakeNet-NG gives analysts a cross-platform
tool for malware analysis that can directly integrate with all the
great Python-based infosec tools that continually emerge in the field.
If you are running REMnux, then
good news: REMnux now comes with FakeNet-NG installed, and existing
users can get it by running the update-remnux command.
For other Linux distributions, setting up and using FakeNet-NG will
require the Python pip package manager, the net-tools package, and the development files for
OpenSSL, libffi, and libnetfilterqueue. Here is how to quickly obtain
the appropriate prerequisites for a few common Linux distributions:
Once you have the prerequisites, you can download the
latest version of FakeNet-NG and install it using setup.py install.
On Linux, FakeNet-NG can be deployed in MultiHost mode on a separate host dedicated to
network simulation, or in the experimental SingleHost mode for analyzing software locally.
Windows only supports SingleHost mode.
FakeNet-NG is configured by default to run in NetworkMode: Auto, which will automatically
select SingleHost mode on Windows or MultiHost mode on Linux. Table 1 lists the
currently supported NetworkMode settings by
Table 1: FakeNet-NG NetworkMode support per platform
FakeNet-NG’s support for SingleHost mode
on Linux currently has limitations.
First, FakeNet-NG does not yet support conditional redirection of
specific processes, hosts, or ports on Linux. This means that settings
like ProcessWhiteList will not work as
expected. We plan to add support for these settings in a later
release. In the meantime, SingleHost mode
supports redirecting all Internet-bound traffic to local listeners,
which is the main use case for malware analysts.
Second, the python-netfilterqueue library
is hard-coded to handle datagrams of no more than 4,012 octets in
length. Loopback interfaces are commonly configured with high maximum
transmittal unit (MTU) settings that allow certain applications to
exceed this hard-coded limit, resulting in unanticipated network
behavior. An example of a network application that may exhibit issues
due to this would be a large file transfer via FTP. A workaround is to
recompile python-netfilterqueue with a
larger buffer size or to decrease the MTU for the loopback interface
(i.e. lo) to 4,012 or less.
In addition to the new NetworkMode
setting, Linux support for FakeNet-NG introduces the following
Linux-specific configuration items:
Before using FakeNet-NG, also be sure to disable any services that
may bind to ports corresponding to the FakeNet-NG listeners you plan
to use. An example is Ubuntu’s use of a local dnsmasq service. You can use netstat to find such services and should refer to
your Linux distribution’s documentation to determine how to disable them.
You can start FakeNet-NG by invoking fakenet with root privileges, as shown in Figure 1.
Figure 1: Starting FakeNet-NG on Linux
You can alter FakeNet-NG’s configuration by either directly editing
the file displayed in the first line of FakeNet-NG’s output, or by
creating a copy and specifying its location with the -c command-line option.
FakeNet-NG now brings the convenience of a modern, Python-based,
malware-oriented network simulation tool to Linux, supporting the full
complement of listeners that are available on FakeNet-NG for Windows.
Users of REMnux can make use of FakeNet-NG already, while users of
other Linux distributions can download and
install it using standard package management tools.
Throughout the past few months, FireEye Labs has observed an
increased use of Windows Management Instrumentation (WMI) queries for
environment detection and evasion of dynamic analysis and
virtualization engines. WMI provides high-level interaction with
Windows objects using C/C++, VBScript, JScript, C#, and more in the
form of WMI Query Language (WQL). Last year, FireEye published a white
paper detailing an in-depth analysis of WMI infrastructure and
potential abuse of WMI services by malware writers.
In this post we will present an analysis of some samples found in
the wild in 2016. For the purposes of this blog post, we will focus on
evasion only, ignoring other malicious aspects of the samples.
Anti-virus can be detected by a WMI query as they are registered in
AntiVirusProduct class under
root\SecurityCenter2 (root\SecurityCenter before Vista)
namespace. We analyzed a sample that checked the operating system from
Win32_OperatingSystem class under
root\cimv2 namespace first and if the OS version was
above 6 (Windows Vista and above), then anti-virus check was
performed. Figure 1 shows the VBScript code of anti-virus check.
Figure 1: Anti-virus product checks in VBScript
code using WMI query
Anti-virus and other user information is sent to the server for
fetching the right payload or performing evasion, as shown in Figure 2.
Figure 2: Anti-virus and other info being sent
to the server and actions against response
One of the samples was found to monitor many security products using
different techniques, but most popular virtualization software (such
as VMware and VirtualBox) were being detected using WMI queries. It
retrieves BIOS information from
Win32_BIOS class under
root\cimv2 namespace. Specific fields/columns can also be
retrieved similar to an SQL query. The following queries were found in
this sample binary (Figure 3).
Figure 3: Virtualization software checks by the
malware using WMI queries
The query yields the following result when executed in PowerShell in
Bochs Emulator, as shown in Figure 4.
Figure 4: Query result in PowerShell in Bochs Emulator
Figure 5 shows the full scale environment detection being performed
by this sample. Other services may be checked by enumerating the
running processes or using Windows Registry.
Figure 5: Security products being monitored by
Another sample used
Win32_ComputerSystem class for virtual machines
detection, as show in Figure 6.
Figure 6: ComputerSystem WMI query found in the sample
The result of the query (Figure 9) has ’Model’ field (Figure 7),
which holds the virtual machine information in case of VMware,
VirtualBox and Virtual Machine.
Figure 7: Model column retrieval
When any of the three strings matched with ‘Model’ field
output, virtualization gets detected by matching the stored value with
the one created in the process, as evident in Figure 8.
Figure 8: VirtualBox, VMware and Virtual Machine checks
When the aforementioned query was executed in PowerShell in VMware
workstation 12.0, it gave the result illustrated in Figure 9.
Figure 9: Query result in PowerShell 2.0
Another sample has used Win32_DiskDrive to detect Virtual Box
(Figure 10), Virtual Hard disk (Figure 11) and VMware (Figure 12).
When any of the virtual machines get detected, the process terminates
itself, evading the behavioral analysis.
Figure 10: VirtualBox detection
Figure 11: Virtual Hard disk detection
Figure 12: VMware detection
We analyzed a sample that not only checked a specific process from
Win32_Process class under namespace
root\cimv2, but also killed it. Immunity debugger, a
well-known debugger, is terminated and its folder is deleted after
changing permissions using Windows Script Host shell, as evident in
the code in Figure 13.
Figure 13: Immunity debugger being terminated
and folder being deleted
Moreover, anti-virus vendor Kingsoft Corporation’s processes are
also forced to stop execution, meaning its anti-virus processes are
being killed. The code is shown in Figure 14. Usually samples use
CreateToolHelp32Snapshot, Process32First and Process32Next APIs for
finding a process, but here it is evident that
one WMI query comes in handy to replace tens of lines of code.
Figure 14: Code designed to kill processes
associated with Kingsoft (an anti-virus product company)
Another sample, an MS Office key generator, checked Windows Office
Software Protection Service through WMI queries (Figure 15). This
service enables software vendors to enforce secure
licensing on the client machines. If this service is not running,
it is started as shown in Figure 16. Once the Office Software
Protection Service object is retrieved, it is then used to install MS
Office product key.
Figure 15: OfficeSoftwareProtectionService check
using WMI query
Figure 16: Code to start/restart OfficeSoftwareProtectionService
During analysis and research, it has been observed that WMI queries,
shown in Figure 17, can be used for environment detection and (with
more details) for evasion as well. There may be more queries that are
not listed here, but we suggest security researchers should at least
monitor these queries for evaluating the samples.
Figure 17: Possible WMI queries for environment detection/evasion
Malware writers are always in search of new ways to evade analysis
frameworks and sandboxes in order to make the payload execution
successful in their targeted environments and platforms. WMI provides
a simple way of environment detection that can be used to evade
sandboxes and dynamic analysis tools, which seems to be underestimated
by reverse engineers and others in the security community. Mitigation
Steps should be taken to monitor WMI queries that could lead to
We would like to thank Matthew Dunwoody for his valuable input.
Moreover, we are also grateful to Muhammad Umer Khan and Imran Khan
for their continuous support in providing relevant sample sets and
Since 2010, Mandiant, a FireEye company, has presented trends,
statistics and case studies of some of the largest and most
sophisticated cyber attacks. In February 2016, we released our annual
report based on data from the brea…
Devices that are connected to the Internet or run a full operating
system are becoming more and more prevalent in today’s society. From
devices for locomotives to wireless light switches, the Internet of
Things (IoT) trend is on the rise and here to stay. This has the
potential to make our lives much easier; however, the increasing
sentience of once analog devices also enables adversaries to target
them and potentially misuse them.
With the ubiquity of these Internet-connected devices, there is a
surplus of “Things” to exploit. The main intent of this blog post is
to generalize how an individual would reverse engineer an embedded
device and the process for attempting to find vulnerabilities.
For this demonstration, we will be looking at the WeMo Link, which
is a part of the Belkin WeMo LED Lighting Starter Set
(http://www.belkin.com/us/p/P-F5Z0489/). There have been
vulnerabilities identified in previous iterations of this device;
however, these vulnerabilities were more focused on the web services
component and not based on analyzing the built-in security of the
There are several steps that an analyst should take when examining
their device. These steps, at a high-level, are:
These steps are crucial to understanding the device being analyzed
and are required to help identify vulnerabilities. In the following
scenario, I will walk through the aforementioned steps and explain
each, the path I took, and what other potential sub-paths one could
take, given their specific scenario.
The scope of this project involved examining IoT embedded hardware
devices that primarily ran embedded Linux as its operating system. I
looked at several IoT devices and decided on the WeMo Link due to its
ability to be controlled by a mobile application and to be used for
home automation, its utilization of wireless components, and its
ability to be controlled over the Internet.
The WeMo product allows a mobile application to dim or turn the
bulbs on and off remotely, or add a bit of intelligence to the bulbs
by having them sync with the sunrise or sunset automatically. There
are two main components that drive the device: the WeMo Link and the
WeMo bulb. The WeMo Link is comprised of a WiFi 2.4GHz radio component
as well as a ZigBee component that communicates on the same band. In
terms of the software, the user downloads a mobile application for
their Android or iOS device to initially setup the WeMo Link, which
then allows them to control the WeMo bulb.
When initially setup, the WeMo Link broadcasts its SSID of
“WeMo.Bridge.XXX”. The user then connects to this AP (Access Point)
with their mobile device, shares the user’s wireless AP credentials,
and the WeMo takes care of the rest. The WeMo then takes any command
sent from the mobile application, sends it to the user’s router, to
the WeMo Link, and then transmits the command over ZigBee to execute
the command to the appropriate bulb(s). Pretty simple.
In this example, the brains of the operation appear to be the WeMo
Link component. In order to be certain, we need to take the device
apart. The lid easily pops off by applying force with a flathead under
the lip of the plastic. There are several ways of identifying how to
properly disassemble a device – from identifying pull tabs to
uncovering screws that are covered with warranty warning tape. In this
case, the device had a slightly protruding lid held down by four tabs.
Behind the plastic lid were two main components: the mainboard, and
the AC/DC converter consisting of a transformer, rectifier, etc.
As we examine the mainboard, we will need to identify the datasheets
associated with each component in order to get a better idea as to how
the device works. On the mainboard itself, what is immediately visible
(we will remove the shielding in a bit) is a Winbound W9825G6KH-61
SDRAM and a Winbound 25Q128FVSG
16MB serial NOR flash memory with the ability to communicate over SPI
(Serial Peripheral Interface) (this will be important later), as seen
in Figure 1. The latter chip is used for storing the more permanent
memory on the board, even while the device is powered off.
Figure 1: Winbound 25Q128FVSG flash memory
After removing the two metal pieces of shielding on the
opposite-side of the board (easily pried-off with a flathead screw
driver), we uncover three more main components.
As seen in Figure 2, the first chip is a SoC (System-on-a-Chip)
is a MIPS embedded processor commonly used for networking devices and
supports SPI communication, 360 MHz MIPS24KEc CPU core, 802.11n
wireless communication, and more. This component is used to drive the
device’s main functions, communicate over its debugging interface,
interact with its ZigBee component, and communicate with our router
over its built-in Wi-Fi component.
Figure 2: Ralink RT5350F chip
As shown in Figure 3, the other shielded section contains the SoC
for the ZigBee device labeled as Silicon Labs EM357
which handles all of the ZigBee 2.4GHz communication and processing
power (32-bit ARM Cortex M3 processor) used to relay information to
and from the WeMo light bulbs. The other chip residing in the same
section is a SkyWorks SKY65336
transmit/receive front-end module used for the ZigBee transmission,
which appears to be utilized by the aforementioned Silicon Labs EM357
ZigBee SoC to perform the actual transmission of the data to the light bulbs.
Figure 3: Silicon Labs EM357 chip
When debugging/interacting with a device, the two most common ways
consist of JTAG (Joint Test Action Group) and UART (Universal
Asynchronous Receiver/Transmitter). JTAG is a dedicated debugging port
implemented as a serial interface used for communicating with the
target device. UART is a means of serial communication that can easily
be bridged over USB via any UART-to-USB bridge. When looking for UART
communication, a lot of times you will see three to four pins that are
grouped together with tracings routed to other parts of the board. To
help us identify these pins, we can use a multimeter. By touching each
of the suspect pins with the positive end on the pad and negative end
to a ground (such as the shielding), we can monitor the voltage and
identify what the pins are. However, in this case, the WeMo’s circuit
board silk screening was friendly enough to label exactly what pads
were utilized for interfacing with the device. They were labeled
conveniently as UART_RX, UART_TX, GND, and VCC, as seen in Figure 4.
Figure 4: Accessible UART pads found on board
To be sure that the labels are accurate, we can still utilize the
multimeter to test each pad’s connection. By powering up the device
and monitoring each pin, the UART_RX oscillated throughout a series of
voltages. This indicates that data is being streamed across this pad,
which is what we will later utilize to view the device’s console.
UART_TX is utilized for transmitting commands to the device and can be
a bit tricky to identify. This pad also displayed as 3.3V, but given
its placement, I did not anticipate this to be VCC. VCC sometimes will
also have a thicker trace than the other pads, indicating it is used
for supply power. The GND pad provided 0 volts on the multimeter,
implying it was the ground pin, and the VCC supplied a steady 3.3
volts, implying it was the power pad. We will utilize these
connections later on after we analyze the extracted firmware from the
As mentioned earlier in the WeMo teardown section of this post, we
identified the flash memory that is used to store the bootloader and
firmware for this device. This is the core component of the device
that an attacker would attempt to modify. We have two ways to dump the
memory off of this component, and I will highlight one method. These
methods consist of: connecting a test clip to the chip itself while it
is still soldered to the board and utilizing a tool such as the bus
pirate to dump the flash memory, or desoldering the chip and then
placing the chip in a programmer to read the memory off of the chip.
For the sake of being as hardware-oriented as possible, I went with
the method of dumping of the SPI flash memory via the bus pirate
without desoldering the chip. I wanted to take a non-invasive approach
such that my analysis might not be discovered (no physical
modifications) by the naked eye. For this method, I purchased a bus
pirate from Dangerous Prototypes and an SOIC8/SOP8 test clip (these
stand for different types of chip packages, meaning small outlined
integrated circuit and small outlined package). This particular flash
chip fit perfectly with my 8-pin test clip and was used to make a
connection while not removing the chip from the board. I then
correctly wired the chip with respect to the bus pirate ports, while
following the datasheet and pinout of the chip, as seen in Figure 5.
Figure 5: Chip pin layout
To dump the flash memory from the chip, it must be powered by
something. In this case, we utilize the bus pirate’s 3.3v line to
provide power to the chip, as seen in Figure 6 and Figure 7.
Figure 6: Attaching the test clip to the chip
Figure 7: Full setup for dumping the memory with
the Bus Pirate
The problem with this is that, at times, voltage injection may occur
and wake up other chips on the board. This means that other chips will
communicate with our flash chip, interrupting our flash dumping
process. This is why it is generally recommended to desolder the chip
with a rework station and read the contents of the chip with a
programmer. Thankfully, we were lucky and this was not the case. To
dump the entire 16777232 bytes (exactly 16MB) worth of content from
the flash chip, I utilized a tool called flashrom, which works well
with the bus pirate device to extract the flash memory in full, as
seen in Figure 8.
Figure 8: Dumping the content from the flash chip
Now that we have a flash dump from the device, we can use the tool
binwalk to analyze the headers within the flash dump to get a better
understanding of what the dump consists of, as seen in Figure 9.
Figure 9: Binwalk analysis of the flash dump
At first glance, we see that the device utilizes U-Boot as its
bootloader (common for embedded Linux devices), and that there are
several file system types such as SquashFS, JFFS2, and the like.
Luckily, binwalk has a very neat feature that can automatically
extract as much as it can identify from signatures in the flash dump
and provide us with the full filesystem of the device. By running
binwalk with the filesystem extraction flag (binwalk -e), we are
presented with several filesystems, one of which is displayed in
Figure 10: The extracted filesystem
Within this directory, we can now take off our hardware reverse
engineering hat and put on our software reverse engineering hat and
begin looking for interesting items such as encryption keys used to
sign WeMo device firmware, hashed root passwords, interesting services
that may start on boot, etc.
What I found interesting after dumping the flash memory was that all
of the memory was directly readable from the chip, and that the
bootloader was bundled onto the same flash chip. This implies that,
since there are no read controls on the flash chip as well as the
bootloader existing on the same (potentially unprotected) chip, I
might be able to write my own data to the device. I performed a few
tests where I manipulated the flash dump binary itself, such as
changing the serial of the device (which in turn changed the wireless
broadcasting AP SSID). This initial test was to see if I could
successfully modify part of the flash memory to display these changes
in a real-world environment, this case being renaming the broadcast AP
SSID, “WeMo.Bridge.HAK” as opposed to the original “WeMo.Bridge.CBD”,
as seen in Figure 11.
Figure 11: Modified AP broadcast by the WeMo device
I was encouraged in my efforts because I could write a new binary
file to the device, completely overwriting the original content. To
examine this further, I needed to make modifications to the flash dump
and judge the results by viewing the startup console for the device.
This involved connecting to the device’s UART debugging pads, as
described earlier, and viewing the output of the console. To interact
with the UART_TX pad, I used an alligator clip wrapped with electrical
tape to hold down a wire that touched the pad and connected to my UART
to USB device, attached to the UART_RX pin. It is important to note
that since the device was plugged into an outlet and was already
receiving power, that I only needed to connect to the transmission
pad(s) as well as ground – but not power. This would have fried the
device. As illustrated in Figure 12, I decided to connect the ground
wire to the shielding, which already acts as a ground. This was much
easier than attempting to connect the ground wire to the corresponding
Figure 12: Wiring the board to communicate via UART
On the software side, I used the program baudrate.py to easily
determine the baud rate (transmission rate) of the device via UART.
After powering on the device and cycling through several garbled lines
of text, I was met with a baud rate of 57600, which presented readable
text, displaying the entire boot process of this device, as shown in
Figure 13: WeMo device booting process displayed
I now had the ability to compare the strings found in the flash dump
to what was displayed during the boot process of the device. To
confirm my theory of potentially modifying the bootloader, I matched
strings found in the binary to what was displayed in the console and
attempted to modify those strings and rewrite this section of the
bootloader, U-Boot. While using a hex editor to modify the binary file
and flashrom to erase/write my file to the flash chip, I successfully
modified the strings found in the bootloader process. I changed the
bootloader header from “U-Boot 20140225_MFG (Feb 13 2015 – 16:58:37)”
to “Mandiant Bootloader (May 18, 2016 – 15:38:25)”, as seen in Figure 14.
Figure 14: Modified bootloader to display
“Mandiant Bootloader” instead of “U-Boot 20140225_MFG”
I was also able to modify various field names regarding the image
verification process, most likely around the time where the bootloader
checks the validity of the firmware, as seen in Figure 15.
Figure 15: A modified field name to display “MandiantHak”
The checks present in the image verification process are irrelevant
if portions of the bootloader can be modified. In theory, if the above
assertions are correct, an adversary could non-invasively rewrite a
new, malicious bootloader and firmware to the device, with the ability
to perform malicious acts on the user’s network as a trusted device.
Such a scenario could consist of a reseller of this product placing a
custom bootloader and firmware onto this device, and then selling the
product to an unsuspecting customer, having a control point in the
user’s network. This could theoretically enable an attacker to
intercept traffic on the network, acquire data on the network, modify
data, and more.
The following recommendations do not take into consideration all of
the variables that are involved when making significant changes to a
device in order to implement security improvements. These
recommendations are things to consider when attempting to remediate
the aforementioned scenario.
There are a few hardware-based actions that could be taken that
would make it significantly more difficult for an adversary to
read/write to the flash chip, among other areas. One such action is to
implement hardware authentication chips. This involves storing a
cryptographic mechanism on the board along with the required key for
decryption, hindering an adversary’s ability to clone or tamper the
data on the device. This is a cost-effective method for IoT device manufacturers.
A second action is to protect the bootloader by storing it in
protected storage or a SoC, or to require the SoC to communicate with
an authentication chip during the boot process. The problem with
implementing the bootloader on a flash chip that is unprotected and
can be manipulated by disabling the CRC checks in place when
decompressing the firmware image on boot and overwriting the image
with a malicious one. If the bootloader must be stored on the flash
chip, it could be included in OTP (One-Time Programmable) memory,
disallowing this area to be written by a third party.
It is important to keep in mind the amount of attention paid to
security is generally proportional to the value of the device.
Implementing strict security features for a relatively inexpensive
home automation system may not make sense for all but the most
security-conscious consumer. That said, it is important to understand
how easily an adversary can implement a malicious bootloader/firmware
with a backdoor, allowing for command-and-control on devices we may
rely on in our homes. A device as simple as a wireless light bulb can
still be used as an entry point to our home systems.
By taking the previously outlined steps to analyze an embedded
device, we successfully identified relevant chips, a UART debugging
port, and how to read and write raw data to the accessible flash chip,
affecting the boot process of the device. Following the previously
defined steps will help you further investigate most embedded devices
in order to identify vulnerabilities.
Upon notifying Belkin of our intention to release this research,
they provided the following statement:
“Wemo appreciates the work of FireEye and other white hat
researchers who often play a critical role in identifying potential
security issues and keeping connected devices safe for consumers. As
malicious hackers grow more sophisticated, it is critical that we, and
other smart home manufacturers, work with these groups to mitigate any
serious threats to safety and security.
“Though Wemo is aware of the potential vulnerability published by
FireEye in their recent blogpost, we do not believe it is serious
enough to warrant what would be a major change to our hardware
production. In order to facilitate this attack scenario, a hacker
would have to have physical access to a Wemo Link device, tamper with
its circuitry and then either return the hacked device or resell it,
both of which are extremely unlikely. With this particular
vulnerability, there is no remote or even local network threat to
users, so we believe that the best way to prevent this is to always
purchase new, unopened merchandise from an official Wemo dealer.”
Throughout August, FireEye Labs has observed a few massive email
campaigns distributing Locky ransomware. The campaigns have affected
various industries, with the healthcare industry being hit the hardest
based on our telemetry, as seen in Figure 1.
Figure 1. Top 10 affected industries
Numerous countries are affected, with the United States, Japan, and
Republic of Korea topping the list, as seen in Figure 2.
Figure 2. Top affected countries
From our trend analysis seen in Figure 3, Locky ransomware started
being delivered via DOCM format email attachments more extensively
beginning in August. This marks a change from the large campaigns we
observed in March,
These detection spikes and change in tactics suggest that the
cybercriminals are investing more to infect systems and maximize their
profits. Additionally, we have observed that the delivery of Dridex
via this distribution channel seems to have stopped, or nearly so,
which could explain why we are seeing the Locky uptick.
Figure 3. Massive DOCM related campaigns on Aug.
9, Aug. 11 and Aug. 15, 2016
Our analysis showed high similarity in the macro code that was used
in the Aug. 9, Aug. 11 and Aug. 15 campaigns. The following are the
Plain [i] = Cipher [i] ^ Key [i % length of Key], where Plain is the
computed plain text, Cipher is the cipher text, Key is the xor key,
and i is the byte offset (see File Decoder in Figure 4).
Figure 4. Technical Overview
The volume of Locky ransomware downloaders is increasing and the
tools and techniques being used in campaigns are constantly changing.
downloader to infect victims to using the DOCM format. On top of that,
cybercrime trends have shown that attackers are distributing more
ransomware these days than banking trojans, as the former appears to
be more lucrative.
These latest campaigns are a reminder that users must be cautious
when it comes to opening attachments in emails or they run the risk of
becoming infected and possibly disrupting business operations.
At the Black Hat USA 2016 conference in Las Vegas
last week, I was fortunate to sit down with Michael Sikorski,
Director, FireEye Labs Advanced Reverse Engineering (FLARE) Team.
During our conversation we discussed the origin of the FLARE team,…
As a reverse engineer on the FLARE (FireEye Labs Advanced Reverse
Engineering) team, I regularly perform basic dynamic analysis of
malware samples. The goal is to quickly observe runtime
characteristics by running binaries in a safe environment. One
important task during dynamic analysis is to emulate the network
environment and trick the malware into thinking it is connected to the
Internet. When done right, the malware reveals its network signatures
such as command and control (C2) domain names, User-Agent strings,
URLs queried, and so on.
One tool of choice is FakeNet. In this blog, I will discuss a major
overhaul to FakeNet and how it helps you perform basic malware dynamic
analysis. Some of the new features include full support for Windows
Vista and later operating systems, process logging, advanced process
and host traffic filtering engine, support for third party tools (e.g.
debuggers, HTTP proxies, etc.) and many others.
This blog covers the basic installation and most common scenarios
for running FakeNet-NG. I invite you to review the complete
documentation available here.
The tool can be found on FLARE’s official Github repository here.
From the releases page, download the latest pre-compiled archive.
Next, copy the release archive to the Malware Analysis VM and extract
it in an easily accessible location.
The simplest way to run FakeNet-NG is to double click on
fakenet64.exe or fakenet32.exe for the 64-bit or 32-bit versions of
Windows, respectively, as illustrated in Figure 1.
Figure 1: Running FakeNet-NG
The tool requires Administrator access, so you will have to confirm
the UAC prompt requesting elevated privileges. Once launched you will
see a console window similar to the one in Figure 2.
Figure 2: FakeNet-NG Startup
By default, FakeNet-NG is configured to start several most commonly
At this point you are ready to run a malware sample and observe its
behavior. Figure 3 illustrates sample malware communication to the C2 server.
Figure 3: Sample malware communication
There are quite a few things going on in the log output above so
let’s break it down into smaller components.
Once launched, the malware attempts to resolve a C2 domain
evil.mandiant.com by querying the configured DNS server 184.108.40.206.
Figure 4 illustrates how FakeNet-NG diverts the traffic from 220.127.116.11
to the local machine’s IP address 172.16.163.131.
Figure 4: Diverting DNS traffic
A major benefit of running FakeNet-NG on the same host as the
malware is that it can perform additional analysis of running
executables. For example, FakeNet-NG is capable of detecting the exact
executable name that is generating traffic. In this case, we can see
that level1_payload.exe is generating the above DNS traffic.
Continuing with the analysis, Figure 5 shows FakeNet-NG’s DNS
listener providing a fake response to the query pointing malware to a
fake C2 IP address 192.0.2.123.
Figure 5: Faking DNS response
After successfully resolving the domain, the malware proceeds to
communicate with the C2 domain name, as shown in Figure 6.
Figure 6: Faking C2 communication
FakeNet-NG implements a few popular network listeners. In this case,
the malware is communicating using the HTTP protocol on port 80. The
output above provides us with several good network indicators such as
the exact URL requested and User-Agent used in the communication, as
well as the unencrypted beacon payload containing the compromised
host’s machine name. All of these indicators can be used to create
good network signatures to detect this malware sample.
By default, FakeNet-NG captures all of the intercepted traffic in
PCAP files so you can perform additional analysis. For example, Figure
7 shows both original and diverted packets performing DNS resolution
as well as HTTP POST requests to the C2 server.
Figure 7: Wireshark PCAP
Captured PCAP files are stored in the same directory as the
FakeNet-NG’s executable. As an added logging feature, FakeNet-NG will
also preserve complete HTTP POST payloads in separate text files also
stored in the executable’s working path.
By default, FakeNet-NG is configured to cover the majority of
malware analysis scenarios. However, if you encounter a more complex
sample, then you can easily adapt the tool by editing one of the few
configuration files located in the configs directory. By default,
FakeNet-NG loads default.ini configuration file when it loads. You can
either modify that file or create a new one and point FakeNet-NG to
load it with the –c command-line parameter. Consider a sample
scenario, where you have malware communicating using a binary protocol
on port 4444. Figure 8 illustrates a sample listener configuration
that will fake this service.
Figure 8: Custom Listener Configuration
The key elements of the configuration above are Port,
Protocol and Listener. Port and Protocol
attributes define the port and protocol used to both setup the
listener service and define the rule to divert traffic. The
Listener attribute is used to define a specific listener class.
In this case, RawListener is used to handle arbitrary binary
protocols. Alternatively, if you wanted to setup a listener to handle
HTTP or HTTPS traffic you would use HTTPListener instead.
Please refer to the documentation for a complete list of supported
listeners and available options.
With the above configuration appended to the active configuration
file, we can now launch FakeNet-NG and intercept traffic destined to
TCP port 4444, as shown in Figure 9.
Figure 9: Diverting to Custom Listener
The scenario above was for a single, known port that the malware
would use for its communication. In many cases it is hard to predict
the exact port used from basic static or dynamic analysis. Instead,
let’s use another powerful feature that essentially allows you to
handle any traffic to any port by a default listener. In order to
configure the default listener, edit the [Diverter] section in the
configuration file as follows in Figure 10.
Default Listener Configuration
Now, if the same malware sample decided to communicate on another
port (e.g. 5555), it would still be intercepted and handled by the
previously defined CustomListener4444.
Figure 11: Diverting to Default Listener
The Figure 11 illustrates traffic going to the unknown port 5555
being diverted to the previously defined custom listener on port 4444.
It is important to note that any explicitly defined listeners will
take precedence over the default listener. So if you have DNS or HTTP
listeners defined on UDP port 53 and TCP port 80 respectively, then
they would handle diverted traffic instead of the default listener as expected.
The new FakeNet-NG is developed completely in Python so it is easy
to implement new services and features. It no longer uses the
deprecated LSP (WinSock Layered Service Provider) driver implemented
in the original FakeNet. Instead, FakeNet-NG relies on the excellent
PyDivert\WinDivert library, which comes with a WFP (Windows Filtering
Platform) driver that performs all of the traffic redirection.
This blog shares a few techniques that can be used to quickly
perform basic dynamic malware analysis and extract good network-based
indicators. FakeNet-NG is a powerful and highly configurable tool that
can be used to perform more advanced tasks such as process and traffic
filtering, aiding in automatic malware unpacking, security assessment
of thick-client applications and many others. Stay tuned for future
blog posts that demonstrate the full features of this tool.
Try out FakeNet-NG the next time you need to perform malware
analysis, security assessment or simply to divert network traffic and
fake network responses. We hope you love this tool as much as we do on
the FLARE team.
A security researcher recently published source code
for a working exploit for CVE-2016-0189 and the Neutrino Exploit Kit
(EK) quickly adopted it.
CVE-2016-0189 was originally exploited as a zero-day vulnerability
attacks in Asia. The vulnerability resides within scripting
engines in Microsoft’s Internet Explorer (IE) browser, and is
exploited to achieve Remote Code Execution (RCE). According to the
researcher’s repository, the open source exploit affects IE on at
least Windows 10. It is possible that attackers could use or repurpose
the attack for earlier versions of Windows.
Microsoft patched CVE-2016-0189
in May on Patch Tuesday. Applying this patch will protect a
system from this exploit.
The popular Neutrino EK was quick to adopt this exploit. Neutrino
works by embedding multiple exploits into one Shockwave Flash (SWF)
file. Once run, the SWF profiles the victim’s system – shown in Figure
1 – to determine which of its embedded exploits to use.
Figure 1. Neutrino EK SWF profiles a victim
Next, it decrypts and runs the applicable exploit, as shown in
Figure 2. This is different from most other EKs, in which an earlier
exploits from the server.
Figure 2. Decrypt and embed the selected exploit
into an iframe
In this example, Neutrino embedded exploits for five vulnerabilities
that have been patched since May or earlier: three for Adobe Flash
Player (CVE-2016-4117, CVE-2016-1019, CVE-2015-8651) and two for
Internet Explorer (CVE-2016-0189, CVE-2014-6332). CVE-2016-0189 is the
newest addition to Neutrino’s arsenal.
This CVE-2016-0189 vulnerability stems from a failure to put a lock
on an array before working on it. This omission can lead to an issue
when the array is changed while another function is in the middle of
working on it. Memory corruption can occur if the “valueOf “ property
of the array is set to a script function that changes the array size,
as shown in Figure 3.
Figure 3. Neutrino setting triggering conditions
After Microsoft released the patch, a security researcher compared
the original and patched programs to identify the root cause of the
vulnerability and create a fully functioning exploit. The exploit
embedded within Neutrino is identical to this researcher’s exploit,
except for the code that runs after initial control.