On Aug. 23, 2016, FireEye detected a potentially new ATM malware
sample that used some interesting techniques not seen before. To add
more fuel to an existing fire, the sample was uploaded to VirusTotal
from an IP address in Thailand a couple of minutes before the Bangkok
Post newspaper reported the theft of 12 million baht from ATMs at
banks in Thailand.
In this blog, FireEye Labs dissects this new ATM malware that we
have dubbed RIPPER (due to the project name “ATMRIPPER”
identified in the sample) and documents indicators that strongly
suggest this piece of malware is the one used to steal from the ATMs
at banks in Thailand.
RIPPER can maintain persistence using two modes: either as
standalone service or masquerading as a legitimate ATM process.
RIPPER is installed as a service if called with the following arguments:
Before creating the service, it will kill the process “dbackup.exe”,
which is specific to one common ATM vendor:
cmd /c taskkill /IM dbackup.exe /T /F
Then it will replace the original dbackup.exe binary under
c:\Windows\system32\ (if present) with itself.
Finally it will install a persistent service with following attributes:
RIPPER can delete the “DBackup Service” service if run with the
RIPPER can stop or start the “DBackup Service” with the following arguments:
“service start” or “service stop”
RIPPER also supports the following command line switches:
/autorun: Will Sleep for 10 minutes and then run in the
background, waiting for interaction.
/install: RIPPER will replace the ATM software running on the
ATM as follows:
Upon execution, RIPPER will kill the processes running in memory for
the three targeted ATM Vendors via the native Windows “taskkill” tool.
RIPPER will examine the contents of directories associated with the
targeted ATM vendors and will replace legitimate executables with
itself. This technique allows the malware to maintain the legitimate
program name to avoid suspicion.
RIPPER will maintain persistence by adding itself to the
\Run\FwLoadPm registry key (that might already exist as part of the
vendor installation), passing the “/autorun” parameter that is
understood by the malware, as seen in Figure 1.
Figure 1: Registry key added for persistency
/uninstall: RIPPER removes the registry keys created
If RIPPER is executed without any parameters, it will perform the
1. It will connect with the Cash Dispenser, Card Reader and the
Pinpad. Since every ATM brand has its own unique devices names, RIPPER
will identify the current devices installed by enumerating them under
the following registry key:
2. RIPPER will make sure the devices are available by querying
their status (Figure 2), and if not available, will exit.
Figure 2: Querying the devices status via
3. For the Dispenser it will obtain information such as the Cash
Unit details to determine the number and type of available notes.
4. Finally it starts two threads; the first of which will
monitor the status of the ATM devices to make sure they are available
and will read all the keystrokes received from the Pinpad device
waiting to interact with the thieves (see step 7), as seen in Figure 3.
Figure 3: Monitoring Pinpad keystrokes
5. The second thread monitors the Card Reader, and once a card
is inserted it validates the EMV chip for authentication to the ATM Malware.
6. Once a valid card with a malicious EMV chip is detected,
RIPPER will instantiate a timer to allow a thief to control the
machine. Figure 4 depicts the timer function.
Figure 4: Monitoring the Card Reader
7. Once the thieves start interacting with RIPPER, they enter
instructions via the Pinpad and multiple options are displayed,
including methods for dispensing currency. Figure 5 depicts some of
the options available to the thieves.
a. CLEAN LOGS: Will clear the log stored at: C:\WINDOWS\temp\clnup.dat
b. HIDE: Will hide the Malware GUI by calling
c. NETWORK DISABLE: Will shut down the ATM local network
interface to prevent it from communicating with the bank. It can
re-enable the connection if needed.
Figure 5: Main Menu
d. REBOOT: Will call ExitWindowsEX() API without sending
WM_QUERYENDSESSION message to avoid prompts for confirmation, causing
the system to reboot.
e. BACK: Ejects the malicious ATM card back to the
thieves by calling the WFSExecute() with the command:
WFS_CMD_IDC_EJECT_CARD. This option, depicted in Figure 6, was
observed being used by the SUCEFUL family.
Figure 6: Asking Card Reader to eject the chip card
Through open sources, we’ve identified a family of malware that may
have been used in recent ATM robberies and which bears some
similarities to known families of malware. This malware family can be
used to compromise multiple vendor platforms and leverages uncommon
technology to access physical devices. In addition to requiring
technical sophistication, attacks such as that affecting the ATMs in
Thailand require coordination of both the virtual and the physical.
This speaks to the formidable nature of the thieves.
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 breaches we responded to in 2015.
Now, we are releasing M-Trends
Asia Pacific, our first report to focus on this very diverse and
Some of the key findings include:
Asia Pacific to learn more.
We’ve been tracking some more spam dropping Zepto ransomware variants. Like earlier posts, we’re seeing infected attachments with malicious macro scripts used as the entry point for the threat actor. (See images below of some recent spam samples.) As we dig deeper into our analysis, we found out that these macro scripts are not crafted […]
In 2015, a record $5 trillion dollars was tied up in mergers and
acquisitions (M&A) deals, according to JP
Morgan. So far, mega deals in 2016 include Microsoft’s purchase of
LinkedIn, Shire’s acquisition of Baxalta, and Marriott’s acquisition
of Starwood. These market-moving events often involve a massive
expenditure of capital and are largely conducted in secret to comply
with legal requirements, making them attractive targets for
cybercriminals and nation-state threat groups alike. Threat actors are
primarily driven by three motives related to M&A activity:
Additionally, acquisition targets may be compromised prior to the
M&A for reasons wholly unrelated to the transaction. Enterprises
should be especially alert for malicious cyber activity before,
during, and shortly after M&A-related activities, ensuring that
due-diligence processes incorporate assessments of each party’s cyber
M&A activity generates significant amounts of sensitive
corporate communications, which cyber criminals may attempt to obtain
and exploit for financial gain. For example, cyber criminals could
attempt to gather data about a company’s operations, financial status
or future plans, which could then be used in stock market trades. To
obtain such sensitive information, attackers can target the companies
directly involved in the M&A activity themselves or other
organizations involved in the deal, such as law firms and PR agencies.
Securities and Exchange Commission (SEC) in 2015 announced that
since at least 2010, two Ukrainian cyber criminals breached multiple
newswire services and distributed pre-release information to a rogue
network of international traders and hedge fund managers.
In 2013 and 2014, a group of cyber criminals known as FIN4
sought to acquire information about M&A discussions in order to
game the stock market. The group frequently used M&A and
SEC-themed lures with Visual Basic for Applications (VBA) macros
implemented to steal the usernames and passwords of key individuals.
Many of FIN4’s lures were apparently stolen documents from actual deal
discussions that the group then weaponized and sent to individuals
directly involved in the deal. FIN4 typically included links to fake
Outlook Web App (OWA) login pages designed to capture the user’s
credentials. Once equipped with the credentials, FIN4 then obtained
access to real-time email communications and presumably insight into
potential deals and their timing.
One side involved in M&A negotiations could use cyber espionage
to acquire sensitive information about a deal counterparty in an
attempt to obtain more favorable terms. Based on past threat actor
activity, we have observed multiple China-based threat actors breach
companies to observed this type of activity in sizeable deals
involving Chinese state-owned enterprises.
High tech companies in particular face an evolving cyber risk as
Chinese interests advance toward acquisition of technology and
expertise that will sustain the country’s economic growth through a
shift to an economy built on knowledge-based products and services.
During the past decade, flush with cash and often with state backing,
Chinese companies have snatched up well-known Western companies in
industries ranging from agriculture to energy to consumer products.
The Wall Street Journal reported that as of May 2016, Chinese
companies have struck over $110.8 billion in overseas deals,
surpassing the $106.8 billion in deals done in 2015, despite a
slowdown in the Chinese economy.
As recently as late 2015, we have observed several likely
China-based threat groups targeting companies engaged in
M&A-related activity. At least four different China-based APT
groups conducted computer network intrusions that we believe were
primarily motivated by the targeted companies’ involvement in an acquisition.
In 2015, Mandiant conducted a compromise assessment for a business
services company. We identified two periods of activity by the
China-based threat group APT8 within the network, the most recent of
which coincided with the victim company’s participation in acquisition
negotiations. Although our visibility into APT8’s operations was
limited, the threat group possibly sought information pertaining to
the negotiation and acquisition itself, based on the timing in which
APT8 resumed their activity within the network.
Mergers and acquisitions often result in an increased attack surface
for the companies involved. As two or more companies integrate their
IT assets, a group that has compromised one company could potentially
use that access to compromise the other(s). For instance, the Australian
telecom firm Telstra in 2015 announced that the networks of a
recently acquired subsidiary, Pacnet, were exploited.
Although the most obvious example of the increased attack surface
issue is when M&A activity causes companies to combine their
networks, it can also include factors such as one company’s particular
susceptibility to social-networking attacks or vulnerabilities in
products produced by one of the companies. In other words, strong
security practices at one company can be obviated by poor practices at
This threat is likely elevated during and immediately after a merger
or acquisition, since IT employees at the purchasing company may not
have had time to analyze the security posture of the purchased
company, or the combined staffs are unable to comprehensively monitor
the entirety of the newly combined network. Mergers and acquisitions
also generally increase the opportunities for “lateral compromise” by
targeting trusted relationships (i.e., the relationship between the
companies involved in the M&A activity). When a well protected
network recognizes a less secure network as trusted, the overall
security posture of the combined network is lowered, allowing
intruders to gain access by exploiting hastily-granted trust between systems.
Mandiant has observed instances where APT actors were able to regain
a foothold in an organization’s network following remediation by
compromising the network of an affiliate. Actors targeting companies
during M&A activity could use similar tactics to move laterally
from one company to another.
An example of this is when Mandiant performed an incident response
investigation for Company A, where we identified the presence of
several advanced threat actors. After remediating Company A’s
networks, an APT group attempted to re-compromise the network through
a sister organization (Company B), which had also been previously
compromised. Although this effort failed, a different APT group was
able to regain access to Company A’s systems through a strategic web
compromise embedded on Company B’s website. Our investigation of the
sister company’s network revealed that the vast majority of stolen
data there pertained to the network infrastructure linking the organizations.
Another example occurred at Company C, where we identified four APT
groups active in a network. Analysis about the timing and behavior of
at least one of these groups suggested that they were able to leverage
their previously attained access at Company D (a sister organization)
to access Company C’s network. During our investigation at Company D,
we discovered at least two threat groups, with activity dating back
three years earlier. We believe these actors used information
harvested from Company D’s network to help exploit Company C in a
Business leaders responsible for M&A business strategy should be
aware that threat actors often target companies engaged in mergers and
acquisitions, and that malicious activities such as phishing attacks
will likely increase during such periods. Additionally, a data breach
or severe security posture weaknesses could negate the business
strategy of acquisition due to the often-high cost of fixing
weaknesses or conducting incident response. Technology risk should be
evaluated and incorporated into the overall business risk strategy
before an M&A transaction is completed. In addition, companies
engaged in M&A should ensure that an examination of cyber security
is included as a key component of the due diligence process.
Today cyber due diligence is oftentimes performed superficially and
as an afterthought. This examination should include details of the
company’s security capabilities such as data safeguards, access
controls, threat detection, incident response and infrastructure
security controls, the threat landscape of the organization, any
records of past attacks, and any underground actors known to be
particularly interested in targeting the company. Allowing sufficient
time (four to six weeks) to perform an actual compromise assessment on
the sellers’ infrastructure will provide the optimal visibility into
the security posture of the acquisition.
When sufficient time is provided and cyber due diligence is
conducted, senior executives at the acquiring organization will
understand the business threats and technology risk posed by the
acquisition target, enabling them to incorporate this information into
the overall enterprise risk picture for informed decision-making. In
the majority of transactions, the decision to move forward with the
acquisition will still continue; however, senior executives will be
better equipped to make informed decisions about:
It’s important for all parties to a transaction to work with their
respective counsel to ensure any cyber due diligence activities are
performed in a compliant manner (e.g., to avoid creating privacy
issues) and in a way that helps preserve any available legal privileges.
Cyber security should be planned for like any other due diligence –
as early as possible. Because of some fairly specific requirements to
ensure the quality of cyber security due diligence, some language may
need to be inserted into agreement documents such as a Letter of
Intent (LOI). This will enable key components of a cyber security due
diligence, such as network monitoring.
M&A due diligence teams sometimes contain information technology
(IT) subject matter experts (SMEs) who are occasionally asked to also
provide an opinion on cyber security posture; however, cyber security
is a specialized field, and if security expertise is not available on
staff, due diligence providers should start planning to retain outside resources.
The following are factors that should be incorporated into effective
cyber security due diligence planning. Note that M&As can vary
widely in terms of ramp-up time. Some allow for a very short due
diligence effort, while longer deals can afford months to assess risk.
Business decisions control this pace, not the due diligence team –
therefore it is important to have relatively quick and lightweight
cyber due diligence options as well as longer, more in-depth approaches.
If the window for due diligence is short (e.g., 1-2 weeks), there is
still substantial cyber security due diligence that can be
accomplished to provide a high-level view of the risk levels of the
seller’s environment. A week provides time for cyber security experts
to conduct documentation review and interviews with seller staff,
which they then analyze in a focused risk framework. The product of
this activity should be a quantified risk assessment across important
cyber security domains (e.g., data safeguarding, infrastructure
security, and others) that results in a brief, easy-to-understand
report on risk and general recommendations for the buyer.
Even minimal cyber security due diligence should have a technical
component to provide an objective view of the health of the seller’s
security posture. One of the most important aspects of a technical
assessment is creating a historical scorecard going back in time: Have
the seller’s computers been compromised in the past, and what was the
character of those breaches (advanced and persistent, commodity,
insider, financial fraud, etc.)? The Freshfields survey discovered
90% of respondents believed that a past breach could
reduce the value of a deal.
Also important is a current snapshot: detecting malicious activity
(or the lack of such activity) from the seller provides insight into
the overall security posture and types of possible intruders already
in place. This information needs to be derived and analyzed in a
relatively short time frame. With this kind of analysis, the buyer
already can act knowledgably and prevent major missteps.
In-Depth Due Diligence
If more time is available, more detailed and granular cyber security
due diligence is possible. In addition to a risk assessment conducted
by cyber security analysts, software agents can be deployed in the
seller’s network to report on the state of the endpoints.
Network monitoring can examine traffic to and from the network for a
period of time to collect very detailed information on the state of
the organization’s cyber security and what compromises are already
happening, or have already happened. This allows the buyer to know the
seller’s environment inside and out from a real-world risk
perspective, and would provide both the high-level view needed to
inform decisions and granular detail to estimate remediation costs.
Only with due diligence can risk be incorporated in planning, with
various planned costs and benefits. Without due diligence, there are
only unexpected costs and reputational impacts.
Information gathered during due diligence can be further used to
guide post-acquisition activities.
A fairly common follow-on activity, particularly with mergers, is
integration of the two companies’ IT infrastructure. In the long run,
this should reduce costs and ease management; however, in the
short-term it can create its own set of problems and become a
One of the first questions to answer is: what can be trusted? Is it
safe for the buyer to connect to certain acquired systems? Can two-way
trust relationships be established? All of these depend on assessing
the security of both the overall environment and specific systems.
Cyber security due diligence provides a good start down this road, and
can allow for a level of effort and cost estimates to be made and
included in IT planning.
The impact of adverse cyber security events has been felt by
businesses for some time, and paying a little attention to the news
gives some sense of the scale of the challenges that have emerged as
even local businesses become exploitable by global criminals. Cyber
security risk is not science fiction, even though it has essentially
been treated as science fiction by being left out of M&A
processes. Acquiring companies and due diligence practitioners must
now catch up to the reality of the costs and risks that cyber security
issues create, and the benefits that cyber security due diligence can
bring. Doing so will eventually separate successes from the also-rans.
For more information on how Mandiant Consulting can help before,
during and after a merger or acquisition, visit Fireeye.com/services.html.
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.”
Recently, we’ve spotted Zepto ransomware spreading through spam email containing fake invoices (see image below). These attachments contain a Macro-Enabled word document file known as Donoff, which downloads the Zepto executable that encrypts all your files and will later ask for payment of the decryption key. We decided to take a closer look on the Donoff […]
WMI has been a core component of Windows since Windows 98, but it is
not exactly old wine in a new bottle. WMI more closely resembles that
bottle of ‘61 Bordeaux wine that continues to impress us as it ages
and matures. WMI was developed as Microsoft’s interpretation of
web-based enterprise management (WBEM) for system management and
auditing; however, adversaries can use it for all stages of the Attack
Lifecycle (shown in Figure 1), from creating the initial foothold on a
system to stealing data from the environment and everything
in-between. From an investigative perspective, WMI has only recently
been used by a select few groups of attackers and it is an artifact
that may be overlooked during investigations. Though WMI does not
provide a default detailed tracing log of
execution or persistence activity.
Figure 1. The Attack Lifecycle
In this blog post we will discuss how attackers can use WMI as a
remote execution utility and as a persistence mechanism to execute
malware, as well as what you can do to detect this activity at
We were recently onsite for a Red Teaming for Security Operations
engagement, where our Red Team utilized WMI as a remote execution
utility (similar to PsExec) and as a malware persistence mechanism
(similar to a system service). We quickly realized that the client’s
Security Operations Center (SOC) did not have the capabilities to
detect this activity from both a network and endpoint perspective, so
we opted to pause the red teaming activities and work with the client
to identify a solution to this lack of visibility.
We determined that following the attacker adage of “living off the
land” was what we needed to solve the problem from a defense
perspective. In other words, we leveraged WMI to monitor itself and
feed WMI-invoked process creations and persistence activity directly
into the system’s Application event log. This allowed our client the
ability to feed these logs from endpoints into their SIEM and achieve
greater visibility into their entire environment.
To accomplish this, we created a WMI subscription. A subscription is
the term used for WMI persistence, and it consists of the following
This WMI Subscription is similar to the Subscriptions created by
attackers for persistence; however, we’re repurposing this method to
perform a different type of action. Instead of executing malware when
a condition is met, such as when the system uptime reaches 200
seconds, we’re instructing WMI to log any newly created Consumers or
WMI-induced process executions to the Application event log. We
utilized PowerShell to configure WMI with these new instructions. At a
high level, the PowerShell script performs the following:
1. Uses WMI Query Language (WQL) to identify:
Recently created “__EventConsumer” events (persistence
b. WMI-based process executions
2. Creates an Event Filter (condition), to perform an action if
any of the above WQL conditions are true
3. Creates an Event Consumer (action), to log details of the
newly created “__EventConsumer” or executed process
log details, we call the “NTEventLogEventConsumer” WMI class that logs
a custom message to the Application event log that contain the
following details, depending on if this was a new Event Consumer or
ii. Event Consumer Command
iii. Process Call Method
iv. Process Call Command
4. Creates and registers the Binding, which associates the
Condition to the Action
Figure 2 shows the general details of the newly created WMI Consumer
that we aptly named “_EvilConsumer_” in the Application event log.
Figure 2. General view of WMI Persistence event log
Figure 3 shows the detailed view of the event log, which contains
the Consumer Name and Command Executed for the creation of the new WMI
Figure 3. Detailed view of the WMI Persistence
The following example illustrates another common use-case,
demonstrating how attackers utilize WMI for process execution against
remote systems. Figure 4 shows a command-line example of Windows
Management Instrumentation Command-line (WMIC) usage to execute a
remote PowerShell process. The command used the “Invoke-Expression”
(IEX) cmdlet to download and execute the “execPayload.ps1” script over
HTTP on the remote system “WIN-RD35VEB5LRT”.
Figure 4. WMIC command used to execute
PowerShell on WIN-RD35VEB5LRT
Because the PowerShell process was ultimately executed via WMI, our
WMI monitoring subscriber logged the process name and the process
arguments. Figure 5 shows the general details of the WMI process
execution in the Application event log on the victim system “WIN- RD35VEB5LRT”.
Figure 5. General view of the WMI process
creation event log
Figure 6 shows the detailed view of the event log, which contains
the command executed “powershell.exe” from the WMI-invoked process creation.
Figure 6. Detailed view of the WMI process
creation event log
Now that we can log newly created Event Consumers and processes
spawned via WMI, we can take steps to make this more
enterprise-friendly. Our client’s SOC used a third-party utility to
inject log data into their SIEM. Our client could now feed the newly
defined Application event logs into their SIEM and alert on these
events to perform follow-up analysis. Environments of all sizes can
follow these similar steps to enact this WMI persistence monitoring
and alert on new events:
This process provided an enterprise-friendly way to monitor and
detect for certain WMI events in near-real time for our client,
without having to perform endpoint forensic collection and analysis.
You can download the PowerShell script from the GitHub page here. Note: You
must run PowerShell as administrator before using the script. The
script requires PowerShell version 3 or above (most recent is version
5) and will run in its current state as two separate PowerShell
functions. Figure 7 shows a screenshot of how to import the modules
from the script and how to run each module.
Figure 7. Screenshot showing the import of the
WMIMonitor script modules and running each module
We would like to thank Matt Graeber (@mattifestation) for his help
with developing Windows Management Instrumentation (WMI) as an
Intrusion Detection System. We combined and modified two PowerShell
scripts – originally developed by Matt – to alert on WMI Event
Consumers and process creations and output details of these events
directly to the Application event log. Matt Graeber’s WMI work that we
used to identify and log malicious WMI actions can be found here
 Windows 7 and above operating systems contain
the WMI Activity Operational event log, however, this does not provide
details of newly created Consumers, Filters or Bindings used for WMI persistence.