CVE-2017-10271 Used to Deliver CryptoMiners: An Overview of TechniquesUsed Post-Exploitation and Pre-Mining


FireEye researchers recently observed threat actors abusing
CVE-2017-10271 to deliver various cryptocurrency miners.

CVE-2017-10271 is a known input validation vulnerability that exists
in the WebLogic Server Security Service (WLS Security) in Oracle
WebLogic Server versions and prior, and attackers can
exploit it to remotely execute arbitrary code. Oracle released a Critical
Patch Update
that reportedly fixes this vulnerability. Users who
failed to patch their systems may find themselves mining
cryptocurrency for threat actors.

FireEye observed a high volume of activity associated with the
exploitation of CVE-2017-10271 following the public posting of proof
of concept code in December 2017. Attackers leveraged this
vulnerability to subsequently download cryptocurrency miners in victim
environments. The recent cryptocurrency boom has resulted in a growing
number of operations – employing diverse tactics – aimed at stealing
cryptocurrencies. The idea that these cryptocurrency mining operations
are less risky, along with the potentially nice profits, could lead
cyber criminals to begin shifting away from ransomware campaigns.

Tactic #1: Delivering the miner directly to a vulnerable server

Some tactics we’ve observed involve exploiting CVE-2017-10271,
leveraging PowerShell to download the miner directly onto the victim’s
system (Figure 1), and executing it using ShellExecute().

Figure 1: Downloading the payload directly

Tactic #2: Utilizing PowerShell scripts to deliver the miner

Other tactics involve the exploit delivering a PowerShell script,
instead of downloading the executable directly (Figure 2).

Figure 2: Exploit delivering PowerShell script

This script has the following functionalities:

  • Downloading miners from remote servers

Figure 3: Downloading cryptominers

As shown in Figure 3, the .ps1 script
tries to download the payload from the remote server to a vulnerable server.

  • Creating scheduled tasks for persistence

Figure 4: Creation of scheduled task

  • Deleting scheduled tasks of other known cryptominers

Figure 5: Deletion of scheduled tasks
related to other miners

In Figure 4, the cryptominer creates a
scheduled task with name “Update service for Oracle
”.  In Figure 5, a different variant deletes this task
and other similar tasks after creating its own, “Update service for
Oracle productsa

From this, it’s quite clear that
different attackers are fighting over the resources available in the system.

  • Killing processes matching certain strings associated with other

Figure 6: Terminating processes directly

Figure 7: Terminating processes matching
certain strings

Similar to scheduled tasks deletion,
certain known mining processes are also terminated (Figure 6 and
Figure 7).

  • Connects to mining pools with wallet key

Figure 8: Connection to mining pools

The miner is then executed with
different flags to connect to mining pools (Figure 8). Some of the
other observed flags are: -a for algorithm, -k for keepalive to
prevent timeout, -o for URL of mining server, -u for wallet key, -p
for password of mining server, and -t for limiting the number of miner threads.

  • Limiting CPU usage to avoid suspicion

Figure 9: Limiting CPU Usage

To avoid suspicion, some attackers are
limiting the CPU usage of the miner (Figure 9).

Tactic #3: Lateral movement across Windows environments using
Mimikatz and EternalBlue

Some tactics involve spreading laterally across a victim’s
environment using dumped Windows credentials and the EternalBlue vulnerability

The malware checks whether its running on a 32-bit or 64-bit system
to determine which PowerShell script to grab from the command and
control (C2) server. It looks at every network adapter, aggregating
all destination IPs of established non-loopback network connections.
Every IP address is then tested with extracted credentials and a
credential-based execution of PowerShell is attempted that downloads
and executes the malware from the C2 server on the target machine.
This variant maintains persistence via WMI (Windows Management Instrumentation).

The malware also has the capability to perform a Pass-the-Hash
attack with the NTLM information derived from Mimikatz in order to
download and execute the malware in remote systems.

Additionally, the malware exfiltrates stolen credentials to the
attacker via an HTTP GET request to:

If the lateral movement with credentials fails, then the malware
uses PingCastle MS17-010 scanner (PingCastle is a French Active
Directory security tool) to scan that particular host to determine if
its vulnerable to EternalBlue, and uses it to spread to that host.

After all network derived IPs have been processed, the malware
generates random IPs and uses the same combination of PingCastle and
EternalBlue to spread to that host.

Tactic #4: Scenarios observed in Linux OS

We’ve also observed this vulnerability being exploited to deliver
shell scripts (Figure 10) that have functionality similar to the
PowerShell scripts.

Figure 10: Delivery of shell scripts

The shell script performs the following activities:

  • Attempts to kill already running cryptominers

Figure 11: Terminating processes matching
certain strings

  • Downloads and executes cryptominer malware

Figure 12: Downloading CryptoMiner

  • Creates a cron job to maintain persistence

Figure 13: Cron job for persistence

  • Tries to kill other potential miners to hog the CPU

Figure 14: Terminating other potential miners

The function shown in Figure 14 is used
to find processes that have high CPU usage and terminate them. This
terminates other potential miners and maximizes the utilization of resources.


Use of cryptocurrency mining malware is a popular tactic leveraged
by financially-motivated cyber criminals to make money from victims.
We’ve observed one threat actor mining around 1 XMR/day, demonstrating
the potential profitability and reason behind the recent rise in such
attacks. Additionally, these operations may be perceived as less risky
when compared to ransomware operations, since victims may not even
know the activity is occurring beyond the slowdown in system performance.

Notably, cryptocurrency mining malware is being distributed using
various tactics, typically in an opportunistic and indiscriminate
manner so cyber criminals will maximize their outreach and profits.

FireEye HX, being a behavior-based solution, is not affected by
cryptominer tricks. FireEye HX detects these threats at the initial
level of the attack cycle, when the attackers attempt to deliver the
first stage payload or when the miner tries to connect to mining pools.

At the time of writing, FireEye HX detects this activity with the
following indicators:

Detection Name

Indicators of Compromise

MD5 Name
3421A769308D39D4E9C7E8CAECAF7FC4 cranberry.exe/logic.exe
B3A831BFA590274902C77B6C7D4C31AE xmrig.exe/yam.exe
26404FEDE71F3F713175A3A3CEBC619B 1.ps1
D3D10FAA69A10AC754E3B7DDE9178C22 2.ps1
9C91B5CF6ECED54ABB82D1050C5893F2 info3.ps1
3AAD3FABF29F9DF65DCBD0F308FF0FA8 info6.ps1
933633F2ACFC5909C83F5C73B6FC97CC lower.css
B47DAF937897043745DF81F32B9D7565 lib.css
3542AC729035C0F3DB186DDF2178B6A0 bootstrap.css

Thanks to Dileep Kumar Jallepalli and Charles Carmakal for their
help in the analysis.

Go to Source
Author: Rakesh Sharma

ReelPhish: A Real-Time Two-Factor Phishing Tool

Social Engineering and Two-Factor Authentication

Social engineering campaigns are a constant threat to businesses
because they target the weakest chain in security: people. A typical
attack would capture a victim’s username and password and store it for
an attacker to reuse later. Two-Factor Authentication (2FA) or
Multi-Factor Authentication (MFA) is commonly seen as a solution to
these threats.

2FA adds an extra layer of authentication on top of the typical
username and password. Two common 2FA implementations are one-time
passwords and push notifications. One-time passwords are generated by
a secondary device, such as a hard token, and tied to a specific user.
These passwords typically expire within 30 to 60 seconds and cannot be
reused. Push notifications involve sending a prompt to a user’s mobile
device and requiring the user to confirm their login attempt. Both of
these implementations protect users from traditional phishing
campaigns that only capture username and password combinations.

Real-Time Phishing

While 2FA has been strongly recommended by security professionals
for both personal and commercial applications, it is not an infallible
solution. 2FA implementations have been successfully defeated using real-time
phishing techniques
. These phishing attacks involve interaction
between the attacker and victims in real time.

A simple example would be a phishing website that prompts a user for
their one-time password in addition to their username and password.
Once a user completes authentication on the phishing website, they are
presented with a generic “Login Successful” page and the one-time
password remains unused but captured. At this point, the attacker has
a brief window of time to reuse the victim’s credentials before expiration.

Social engineering campaigns utilizing these techniques are not new.
There have been reports of real-time
phishing in the wild
as early as 2010. However, these types of
attacks have been largely ignored due to the perceived difficulty of
launching such attacks. This article aims to change that perception,
bring awareness to the problem, and incite new solutions.

Explanation of Tool

To improve social engineering assessments, we developed a tool –
named ReelPhish – that simplifies the real-time phishing technique.
The primary component of the phishing tool is designed to be run on
the attacker’s system. It consists of a Python script that listens for
data from the attacker’s phishing site and drives a locally installed
web browser using the Selenium
. The tool is able to control the attacker’s web browser
by navigating to specified web pages, interacting with HTML objects,
and scraping content.

The secondary component of ReelPhish resides on the phishing site
itself. Code embedded in the phishing site sends data, such as the
captured username and password, to the phishing tool running on the
attacker’s machine. Once the phishing tool receives information, it
uses Selenium to launch a browser and authenticate to the legitimate
website. All communication between the phishing web server and the
attacker’s system is performed over an encrypted SSH tunnel.

Victims are tracked via session tokens, which are included in all
communications between the phishing site and ReelPhish. This token
allows the phishing tool to maintain states for authentication
workflows that involve multiple pages with unique challenges. Because
the phishing tool is state-aware, it is able to send information from
the victim to the legitimate web authentication portal and vice versa.


We have successfully used ReelPhish and this methodology on numerous
Red Team
engagements. The most common scenario we have come
across is an externally facing VPN portal with two-factor
authentication. To perform the social engineering attack, we make a
copy of the real VPN portal’s HTML, JavaScript, and CSS. We use this
code to create a phishing site that appears to function like the original.

To facilitate our real-time phishing tool, we embed server-side code
on the phishing site that communicates with the tool running on the
attacker machine. We also set up a SSH tunnel to the phishing server.
When the authentication form on the phishing site is submitted, all
submitted credentials are sent over the tunnel to the tool on the
attacker’s system. The tool then starts a new web browser instance on
the attacker’s system and submits credentials on the real VPN portal.
Figure 1 shows this process in action.

Figure 1: ReelPhish Flow Diagram

We have seen numerous variations of two-factor authentication on VPN
portals. In some instances, a token is passed in a “secondary
password” field of the authentication form itself. In other cases, the
user must respond to a push request on a mobile phone. A user is
likely to accept an incoming push request after submitting credentials
if the phishing site behaved identically to the real site.

In some situations, we have had to develop more advanced phishing
sites that can handle multiple authentication pages and also pass
information back and forth between the phishing web server and the
tool running on the attacking machine. Our script is capable of
handling these scenarios by tracking a victim’s session on the
phishing site and associating it with a particular web browser
instance running on the attacker’s system. Figure 1 shows a general
overview of how our tool would function within an attack scenario.

We are publicly releasing the tool on the FireEye GitHub
. Feedback, pull requests, and issues can also be
submitted to the Git repository.


Do not abandon 2FA; it is not a perfect solution, but it does add a
layer of security. 2FA is a security mechanism that may fail like any
other, and organizations must be prepared to mitigate the impact of
such a failure.

Configure all services protected by 2FA to minimize attacker impact
if the attacker successfully bypasses the 2FA protections. Lowering
maximum session duration will limit how much time an attacker has to
compromise assets. Enforcing a maximum of one concurrent session per
user account will prevent attackers from being active at the same time
as the victim. If the service in question is a VPN, implement strict
network segmentation. VPN users should only be able to access the
resources necessary for their respective roles and responsibilities.
Lastly, educate users to recognize, avoid, and report social
engineering attempts.

By releasing ReelPhish, we at Mandiant hope to highlight the need
for multiple layers of security and discourage the reliance on any
single security mechanism. This tool is meant to aid security
professionals in performing a thorough penetration test from beginning
to end.

During our Red Team engagements at Mandiant, getting into an
organization’s internal network is only the first step. The tool
introduced here aids in the success of this first step. However, the
overall success of the engagement varies widely based on the target’s
internal security measures. Always work to assess and improve your
security posture as a whole. Mandiant provides a variety of services
that can assist all types of organizations in both of these activities.

Go to Source
Author: Pan Chan

Microsoft Office Vulnerabilities Used to Distribute Zyklon Malware inRecent Campaign


FireEye researchers recently observed threat actors leveraging
relatively new vulnerabilities in Microsoft Office to spread Zyklon
HTTP malware. Zyklon has been observed in the wild since early 2016
and provides myriad sophisticated capabilities.

Zyklon is a publicly available, full-featured backdoor capable of
keylogging, password harvesting, downloading and executing additional
plugins, conducting distributed denial-of-service (DDoS) attacks, and
self-updating and self-removal. The malware may communicate with its
command and control (C2) server over The Onion Router (Tor) network if
configured to do so. The malware can download several plugins, some of
which include features such as cryptocurrency mining and password
recovery, from browsers and email software. Zyklon also provides a
very efficient mechanism to monitor the spread and impact.

Infection Vector

We have observed this recent wave of Zyklon malware being delivered
primarily through spam emails. The email typically arrives with an
attached ZIP file containing a malicious DOC file (Figure 1 shows a
sample lure).

The following industries have been the primary targets in this campaign:

  • Telecommunications
  • Insurance
  • Financial Services

Figure 1: Sample lure documents

Attack Flow

  1. Spam email arrives in the
    victim’s mailbox as a ZIP attachment, which contains a malicious DOC
  2. The document files exploit at least three known
    vulnerabilities in Microsoft Office, which we discuss in the
    Infection Techniques section. Upon execution in a vulnerable
    environment, the PowerShell based payload takes over.
  3. The
    PowerShell script is responsible for downloading the final payload
    from C2 server to execute it.

A visual representation of the attack flow and execution chain can
be seen in Figure 2.

Figure 2: Zyklon attack flow

Infection Techniques


This vulnerability was discovered
by FireEye
in September 2017, and it is a vulnerability we have
observed being exploited in the wild.

The DOC file contains an embedded OLE Object that, upon execution,
triggers the download of an additional DOC file from the stored URL
(seen in Figure 3).

Figure 3: Embedded URL in OLE object


Similarly, we have also observed actors leveraging another newly discovered
vulnerability (CVE-2017-11882) in Microsoft Office. Upon opening the
malicious DOC attachment, an additional download is triggered from a
stored URL within an embedded OLE Object (seen in Figure 4).

Figure 4: Embedded URL in OLE object

Figure 5: HTTP GET request to download
the next level payload

The downloaded file, doc.doc, is XML-based and contains a
PowerShell command (shown in Figure 6) that subsequently
downloads the binary Pause.ps1.

Figure 6: PowerShell command to download
the Pause.ps1 payload

Dynamic Data Exchange (DDE)

Dynamic Data Exchange (DDE) is the interprocess communication
mechanism that is exploited to perform remote code execution. With the
help of a PowerShell script (shown in Figure 7), the next payload
(Pause.ps1) is downloaded.

Figure 7: DDE technique used to download
the Pause.ps1 payload

One of the unique approaches we have observed is the use of dot-less
IP addresses (example: hxxp://258476380).

Figure 8 shows the network communication of the Pause.ps1 download.

Figure 8: Network communication to
download the Pause.ps1 payload

Zyklon Delivery

In all these techniques, the same domain is used to download the
next level payload (Pause.ps1), which is another PowerShell
script that is Base64 encoded (as seen in Figure 8).

The Pause.ps1 script is responsible for resolving the APIs
required for code injection. It also contains the injectable
shellcode. The APIs contain VirtualAlloc(), memset(), and
CreateThread(). Figure 9 shows the decoded Base64 code.

Figure 9: Base64 decoded Pause.ps1

The injected code is responsible for downloading the final payload
from the server (see Figure 10). The final stage payload is a PE
executable compiled with .Net framework.

Figure 10: Network traffic to download
final payload (words.exe)

Once executed, the file performs the following activities:

  1. Drops a copy of itself in
    %AppData%svchost.exesvchost.exe and drops an XML file, which
    contains configuration information for Task Scheduler (as shown in
    Figure 11).
  2. Unpacks the code in memory via process
    hollowing. The MSIL file contains the packed core payload in its
    .Net resource section.
  3. The unpacked code is Zyklon.

Figure 11: XML configuration file to
schedule the task

The Zyklon malware first retrieves the external IP address of the
infected machine using the following:

  • api.ipify[.]org
  • ip.anysrc[.]net
  • myexternalip[.]com
  • whatsmyip[.]com

The Zyklon executable contains another encrypted file in its .Net
resource section named tor. This file is decrypted and injected
into an instance of InstallUtiil.exe, and functions as a Tor anonymizer.

Command & Control Communication

The C2 communication of Zyklon is proxied through the Tor network.
The malware sends a POST request to the C2 server. The C2 server is
appended by the gate.php, which is stored in file memory. The
parameter passed to this request is getkey=y. In response to this
request, the C2 server responds with a Base64-encoded RSA public key
(seen in Figure 12).

Figure 12: Zyklon public RSA key

After the connection is established with the C2 server, the malware
can communicate with its control server using the commands shown in
Table 1.

Command Action
sign Requests system information
settings Requests settings from C2 server
logs Uploads harvested passwords
wallet Uploads harvested cryptocurrency wallet
proxy Indicates SOCKS proxy port opened
miner Cryptocurrency miner commands
error Reports errors to C2 server
ddos DDoS attack commands

Table 1: Zyklon accepted commands

The following figures show the initial request and subsequent server
response for the “settings” (Figure 13), “sign” (Figure 14), and
“ddos” (Figure 15) commands.

Figure 13: Zyklon issuing “settings”
command and subsequent server response

Figure 14: Zyklon issuing “sign” command
and subsequent server response

Figure 15: Zyklon issuing “ddos” command
and subsequent server response

Plugin Manager

Zyklon downloads number of plugins from its C2 server. The plugin
URL is stored in file in following format:

  • /plugin/index.php?plugin=<Plugin_Name>

The following plugins are found in the memory of the Zyklon malware:

  • /plugin/index.php?plugin=cuda
  • /plugin/index.php?plugin=minerd
  • /plugin/index.php?plugin=sgminer
  • /plugin/index.php?plugin=socks
  • /plugin/index.php?plugin=tor
  • /plugin/index.php?plugin=games
  • /plugin/index.php?plugin=software
  • /plugin/index.php?plugin=ftp
  • /plugin/index.php?plugin=email
  • /plugin/index.php?plugin=browser

The downloaded plugins are injected into WindowsMicrosoft.NETFrameworkv4.0.30319RegAsm.exe.

Additional Features

The Zyklon malware offers the following additional capabilities (via plugins):

Browser Password Recovery

Zyklon HTTP can recover passwords from popular web browsers, including:

  • Google Chrome
  • Mozilla Firefox
  • Internet Explorer
  • Opera
  • Chrome Canary/SXS
  • CoolNovo Browser
  • Apple Safari
  • Flock Browser
  • SeaMonkey
  • SRWare Iron Browser
  • Comodo Dragon
FTP Password Recovery

Zyklon currently supports FTP password recovery from the following
FTP applications:

  • FileZilla
  • SmartFTP
  • FlashFXP
  • FTPCommander
  • Dreamweaver
  • WS_FTP
Gaming Software Key Recovery

Zyklon can recover PC Gaming software keys from the following games:

  • Battlefield
  • Call
    of Duty
  • FIFA
  • NFS
  • Age of Empires
  • Quake
  • The Sims
  • Half-Life
  • IGI
  • Star Wars
Email Password Recovery

Zyklon may also collect email passwords from following applications:

  • Microsoft Outlook
  • Microsoft Outlook 2002/XP/2003/2007/2010/2013
  • Mozilla Thunderbird
  • Windows Live Mail 2012
  • IncrediMail, Foxmail v6.x – v7.x
  • Windows Live
  • MSN Messenger
  • Google Talk
  • GMail
  • PaltalkScene IM
  • Pidgin (Formerly Gaim)
  • Miranda Messenger
  • Windows Credential
License Key Recovery

The malware automatically detects and decrypts the license/serial
keys of more than 200 popular pieces of software, including Office,
SQL Server, Adobe, and Nero.

Socks5 Proxy

Zyklon features the ability to establish a reverse Socks5 proxy
server on infected host machines.

Hijack Clipboard Bitcoin Address

Zyklon has the ability to hijack the clipboard, and replaces the
user’s copied bitcoin address with an address served up by the actor’s
control server.

Zyklon Pricing

Researchers identified different versions of Zyklon HTTP being
advertised in a popular underground marketplace for the following prices:

  • Normal build: $75
  • Tor-enabled build: $125 (USD)
  • Rebuild/Updates:
    $15 (USD)
  • Payment Method: Bitcoin (BTC)


Threat actors incorporating recently discovered vulnerabilities in
popular software – Microsoft Office, in this case – only increases the
potential for successful infections. These types of threats show why
it is very important to ensure that all software is fully updated.
Additionally, all industries should be on alert, as it is highly
likely that the threat actors will eventually move outside the scope
of their current targeting.

At this time of writing, FireEye Multi Vector Execution (MVX)
 is able to recognize and block this threat. Table 2 lists
the current detection and blocking capabilities by product.

Detection Name Product Action
Malware.Binary.rtf EX/ETP/NX Block
Malware.Binary EX/ETP/NX Block
FE_Exploit_RTF_CVE_2017_8759 EX/ETP/NX Block
FE_Exploit_RTF_CVE201711882_1 EX/ETP/NX Block

Table 2: Current detection capabilities by
FireEye products

Indicators of Compromise

The contained analysis is based on the representative sample lures
shown in Table 3.

MD5 Name
d91bed734a8e98b52b8ab0c7fafc6573 accounts.doc
4bae7fb819761a7ac8326baf8d8eb6ab Courier.doc
eb5fa454ab42c8aec443ba8b8c97339b doc.doc
886a4da306e019aa0ad3a03524b02a1c Pause.ps1
04077ecbdc412d6d87fc21e4b3a4d088 words.exe

Table 3: Sample Zyklon lures

Network Indicators

Go to Source
Author: Swapnil Patil

Debugging Complex Malware that Executes Code on the Heap


In this blog, I will share a simple debugging tactic for creating
“save points” during iterative remote debugging of complex multi-stage
samples that execute code in heap memory at non-deterministic
addresses. I’ll share two examples: one contrived, and the other a
complex, modular malware sample (MD5 hash:
830a09ff05eac9a5f42897ba5176a36a) from a family that we call
POISONPLUG. I will focus on IDA Pro and WinDbg, but I’ll explain how
to achieve the same effect with other tools as well. With this tactic,
you can also hand off program execution between multiple debuggers
using the strengths of different tools (e.g. unpacking a binary,
dumping memory maps, combatting anti-RE, or normal debugging).

The essence is merely suspending the malware. To set the stage, I
must first explain how malware influences our debugging tactics to
necessitate this. This explanation will serve as a review of common
techniques that make malware debugging easier and culminate in the
case study of POISONPLUG. If you’re already a seasoned analyst using
IDA Pro to remotely debug malware, and you’re only interested in the
bottom line of how to suspend and snapshot live malware, then skip to
the Summary section at the end.

VMs and Snapshots as Save Points

To prevent malware from doing damage, most malware reverse engineers
debug in an isolated VM. This gives rise to the powerful tactic of
capturing VM snapshots throughout the debugging process to be able to
return to a “save point” after making a mistake. The analyst is then
free to be aggressively experimental about exploring malware behavior.
The only consequence of an error is that the analyst must revert the
VM and avoid making the same mistake again.

Remote Debugging

Debugging malware on the same system where static analysis artifacts
are stored is dangerous; malware (e.g. ransomware) can destroy notes
and disassembly databases, or malware anti-RE measures can inflict
data loss (e.g. by rebooting). Consequently, it makes sense to use
separate systems for debugging versus disassembly and note-taking.
Depending on the tools used, this can force the analyst to flip back
and forth between viewing disassembler output and the debugger, like a
spectator at a tennis match. These transitions are distracting.

Unifying Static and Dynamic Analysis with IDA Pro as a Front-End

Fortunately, IDA Pro (and probably most modern disassemblers) can
act as a debugging front-end, superimposing disassembly annotations
over live memory and register state in a running program. This lets
the analyst see and directly alter disassembly annotations in response
to their observations, without switching back and forth.

Malware that Modifies its Memory Map at Runtime

There is one frequent scenario that further shapes the requirements
for a dynamic analysis methodology: malware that allocates heap
memory, writes code to that memory, and executes that code. Consider
Figure 1, which shows a simple program written in C.

Figure 1: Simple shellcode example program

The program allocates memory using malloc, copies six bytes to that
location using memcpy, logically inverts each byte, calls the buffer
as a function, and finally returns the shellcode’s return value (error
checking omitted both for brevity and realism). Figure 2 shows the
decoded shellcode in memory.

Figure 2: Simple shellcode function
returns 42

Without this code, the disassembly database is missing useful
information about the malware’s code, leaving its behavior as a bit of
a black box. This simple example demonstrates a common pattern, but
its trivial nature isn’t compelling enough to consider this a serious
problem. A more realistic example will provide more substantial
motivation for the debugging tactic at hand.


For a realistic example, consider the sample with MD5 hash
830a09ff05eac9a5f42897ba5176a36a (which is available from VirusTotal).
This malware creates a thread that decodes and calls shellcode, which
unpacks and calls into the entry point of a modified DLL module. The
module in turn unpacks six additional modules before finally calling a
function within one of those modules. The DllEntryPoint functions of
several modules each create several anti-RE threads that attempt to
detect common analyst tools and terminate the malware in response.
After completely unpacking the malware, tools such as Tyler Dean’s injectfind
for flare-dbg
or my own flare-qdb
(Query-Oriented Debugger)
can expose all the read/write/execute
(R/W/X) mappings in memory that, in this case, point directly to the
malware modules. Figure 3 shows the output from flare-qdb debugging a
subset of the malware to this point and dumping its R/W/X allocations.

Figure 3: POISONPLUG R/W/X memory
locations after unpacking

Figure 4 shows the unpacked shellcode-based loader from this sample,
which is intricate, obfuscated, and time-consuming to annotate.

Figure 4: POISONPLUG’s shellcode-based loader

This shellcode implements several anti-RE features specific to this
malware family, and a copy of this is used to unpack seven modules
altogether with modified/custom PE-COFF headers. A common response to
finding an entire executable file in memory is to dump the file and
create its own disassembly database. However, the modules use a list
of function pointers stashed in a mapping of the paging file to locate
and call into one-another’s function “exports” in spaghetti code
fashion to deliberately obfuscate control flow and functional
semantics. Figure 5 shows an example, where each lane represents one
executable code module, and the boxes inside each lane represent
distinct function entry point RVAs within that module.

Figure 5: Partial interaction diagram for
retrieving and decoding configuration

The code at offset 0x11f2 in module 0 is simply calling into other
modules to eventually arrive at code within its own module (at offset
0x1d42). Dumping to separate disassembly databases creates
distractions for the analyst as they must Alt+Tab between entirely
different disassembly databases to follow the path of execution.

These types of complex samples create a dual problem for the
debugging tactics described so far…

Challenge 1: Syncing Code from the Heap

The first problem is that the code written to memory is generally
not readily available in the original disassembly output, and dumping
to separate disassembly databases is not always appropriate. It can
also be a lot of work to neutralize anti-reversing measures and
shepherd a sample to the point where it has unpacked all its encoded
modules into heap memory. A debugging mistake can entail a lot of
additional work to fix and resume analysis. Live memory is a resource
that could hasten reverse engineering if it can be preserved beyond
the life of the debug session. Luckily, this first problem of making
unpacked modules conveniently available in a single disassembly
database can be solved trivially, at least in IDA Pro:

  1. Visit each dynamically
    allocated code region to change its segment attributes (Alt+S) and
    mark each as a Loader segment
  2. Pull the dynamically
    allocated memory into the disassembly database (Debugger >
    Take memory snapshot > Loader Segments)

If you are following along without having started a debugging
session, IDA’s Change segment attributes dialog will omit the
Loader segment checkbox. Figure 6 shows this dialog during a
debugging session, with the Loader segment checkbox highlighted.

Figure 6: Change segment attributes
dialog during debugging session

After pulling in live memory, it is possible to read and annotate
unpacked modules and code in heap allocations even after terminating
the debugging session, as shown in Figure 7.

Figure 7: Function code from heap saved
from a debug memory snapshot

Challenge 2: Non-Deterministic Memory Maps

A second problem arises from samples that execute code in
dynamically allocated memory. Recovering from a debugging mistake
still requires debugging the program again, but modules frequently
occupy varying addresses across different executions. Consequently,
the helpful annotations created in IDA Pro at the original addresses
are absent from the new code locations. Figure 8 shows an example
containing the same code as in Figure 7, but loaded at a different
address during a subsequent execution of the program. The analyst must
then recognize and/or relabel everything to continue the analysis.
This can be scripted, but it is a time-consuming distraction.

Figure 8: Same code at a different
address lacks annotations

The reason the code appears at varying addresses across debugging
sessions is that Windows’ memory allocation functions such as
VirtualAlloc do not always return consistent addresses from one
execution of a program to the next. For example, the first time a
program runs, it may obtain memory at address 0xe000, the second time
at 0x11a000, et cetera. For complex malware with several modules, this
presents a problem.

We’d like the memory map to be uniform from one debug session to
another so we can continue to build on our existing static analysis
annotations, each of which IDA Pro has associated with a single
virtual address. Alas, even though VirtualAlloc accepts an optional
lpAddress parameter to indicate the starting address of the region to
allocate, this is merely a suggestion unless memory was already
reserved and uncommitted at that address. Forcing the lpAddress
parameter to a desired value rarely (in my experience, never) yields success.

Alternately, it would be nice to go back to using virtual machine
snapshots to create “save points” like before. Unfortunately, when
debugging remotely over a network, the process of reverting a virtual
machine snapshot breaks the TCP connection between the debug server
and IDA Pro and prevents the malware from continuing under the control
of the debugger.

…Where we Lay our Scene

The stage is now set to introduce the new technique. First, a short
recap of how we got here:

  • Need to debug in a VM to
    avoid damage to the host system
  • Prefer to use IDA Pro as
    the debugging front-end to unify static and dynamic analysis
  • Need to use remote debugging to avoid damage to static analysis
    artifacts and documentation
  • Need to debug iteratively
    across multiple debug sessions
  • Disassembly annotations must
    align with the memory map in the debug session to be useful

Malware behavior and analyst preferences seem to have painted us
into a corner. Running the malware repeatedly results in a
non-deterministic memory map that does not align with the annotations
in the disassembly database, and using IDA Pro to unify the static
view with live remote debugging appears impede the use of VM snapshots
to act as save points. What should an analyst do?

Park Your Malware

To capture a VM snapshot that allows us to repeatedly reattach to
and resume debugging, we’ll increase the suspend count of all the
threads in the program and detach the debugger. The debug server will
gracefully close its TCP connection, and the program will stay
suspended until we reattach. We then capture a VM snapshot. Finally,
we can repeatedly revert the VM, reattach, and resume execution to
continue our analysis. This way, you can park your malware once, and
then crash it over and over again until you understand its behavior.

As it turns out, IDA Pro’s facility for suspending threads
(right-click -> Suspend) doesn’t maintain its effect after
detaching the debugger. Instead, we’ll specifically use WinDbg as
IDA’s debugger back-end (see the directions
at Hex-Rays’ site

The WinDbg command for viewing thread status is ~ (tilde). The ~
command accepts an optional numeric argument to specify which thread
to display (e.g. ~3), or you can specify ~* to display full status for
all threads. WinDbg also supports commands ~n and ~m for
suspending and resuming threads. These also permit
numeric or asterisk arguments, so we can use ~*n to suspend all
threads before detaching, and ~*m to resume them upon
reattaching. Figure 9 shows IDA/WinDbg output after viewing thread
status, suspending all threads, and finally viewing their status once more.

Figure 9: Viewing thread status,
suspending, and viewing again

The suspend count increases from 1 to 2 after issuing the ~*n
command. Now, when the debugger detaches from the process and
decrements the suspend count of all threads (as usual), the
artificially elevated suspend count of each thread will remain greater
than zero. Consequently, the NT dispatcher will not schedule any
threads in the process to run, and the process will continue to exist
in a suspended state.

Now, we can capture a VM snapshot that can be repeatedly reverted to
resume debugging from where we left off. Figure 10 shows the process
attachment dialog in IDA Pro after reverting the VM snapshot and
clicking Debugger -> Attach to process…

Figure 10: Attaching to the suspended process

You can create these “save points” at various junctures – as many as
you have disk space to store.

The one caveat to this procedure is that it is easy to forget to
resume threads between reattaching and attempting to continue
debugging. If you forget this step, then the “Please wait…” modal
dialog in Figure 11 will appear.

Figure 11: Debugging a suspended process

A reverse engineer might be accustomed to seeing this dialog only
after making a mistake and allowing malware to run free, but in this
case, the program is not actually executing any instructions. To fix
it, simply click the Suspend button in IDA Pro’s “Please wait…” dialog
and then resume all threads (WinDbg: ~*m) to decrease their suspend
count. Then, execution can continue as normal.


To suspend a program that you are running within an IDA Pro + WinDbg
remote debug session to capture a reusable VM snapshot:

  1. Suspend all threads
    (WinDbg: ~*n)
  2. Detach from the process (IDA Pro:
    Debugger -> Detach from process)
  3. Capture
    your VM snapshot

To resume the suspended program:

  1. Attach to the remote
    process (IDA Pro: Debugger -> Attach to
  2. Resume all threads (WinDbg: ~*m)
  3. Resume
    debugging as normal

If you aren’t interested in using WinDbg commands, you can instead
use SysInternals’ Process Explorer to suspend the process in your
debugging VM and simply detach using IDA Pro. You could also write a
Python ctypes script or native program to directly use the relevant
Windows APIs if you prefer (specifically via CreateToolhelp32Snapshot
with the TH32_SNAPTHREAD flag, OpenThread, SuspendThread, and ResumeThread).

This tactic allows us to cope with complex multi-stage shellcode or
modular malware that has several (sometimes cascading) unpacked code
regions. It lets us create save points in our debug session while
maintaining the same memory map so our disassembly annotations always
remain aligned with the memory map in the debug session. It also
allows us to suspend malware execution in one debugger and pick it up
in another, provided each debugger allows thread suspend count to
remain at a non-zero value before detaching.

Before closing, I’d like to give credit to Tarik Soulami for his
explanation of WinDbg thread management in his book, “Inside Windows
Debugging” (Microsoft Press, 2012). If you’re starting to confront
more difficult debugging scenarios in your journey as a reverse
engineer, I strongly encourage you to pick up “Inside Windows
Debugging” to augment your repertoire and further understand the
powerful debugging capabilities of WinDbg and Windows itself.

Go to Source
Author: Michael Bailey

Attackers Deploy New ICS Attack Framework “TRITON” and Cause OperationalDisruption to Critical Infrastructure


Mandiant recently responded to an incident at a critical
infrastructure organization where an attacker deployed malware
designed to manipulate industrial safety systems. The targeted systems
provided emergency shutdown capability for industrial processes. We
assess with moderate confidence that the attacker was developing the
capability to cause physical damage and inadvertently shutdown
operations. This malware, which we call TRITON, is an attack framework
built to interact with Triconex Safety Instrumented System (SIS)
controllers. We have not attributed the incident to a threat actor,
though we believe the activity is consistent with a nation state
preparing for an attack.

TRITON is one of a limited number of publicly identified malicious
software families targeted at industrial control systems (ICS). It
follows Stuxnet which was used against Iran in 2010 and Industroyer
which we believe was deployed by Sandworm Team against Ukraine in
2016. TRITON is consistent with these attacks, in that it could
prevent safety mechanisms from executing their intended function,
resulting in a physical consequence.

Malware Family Main Modules Description
TRITON trilog.exe Main
executable leveraging Custom
communication library for interaction with Triconex

Table 1: Description of TRITON Malware

Incident Summary

The attacker gained remote access to an SIS engineering workstation
and deployed the TRITON attack framework to reprogram the SIS
controllers. During the incident, some SIS controllers entered a
failed safe state, which automatically shutdown the industrial process
and prompted the asset owner to initiate an investigation. The
investigation found that the SIS controllers initiated a safe shutdown
when application code between redundant processing units failed a
validation check — resulting in an MP diagnostic failure message.

We assess with moderate confidence that the attacker inadvertently
shutdown operations while developing the ability to cause physical
damage for the following reasons:

  • Modifying the SIS could
    prevent it from functioning correctly, increasing the likelihood of
    a failure that would result in physical consequences.
  • TRITON was used to modify application memory on SIS controllers
    in the environment, which could have led to a failed validation
  • The failure occurred during the time period when
    TRITON was used.
  • It is not likely that existing or external
    conditions, in isolation, caused a fault during the time of the


FireEye has not connected this activity to any actor we currently
track; however, we assess with moderate confidence that the actor is
sponsored by a nation state. The targeting of critical infrastructure
as well as the attacker’s persistence, lack of any clear monetary goal
and the technical resources necessary to create the attack framework
suggest a well-resourced nation state actor.  Specifically, the
following facts support this assessment:

The attacker targeted the SIS suggesting an interest in causing a
high-impact attack with physical consequences. This is an attack
objective not typically seen from cyber-crime groups.

The attacker deployed TRITON shortly after gaining access to the SIS
system, indicating that they had pre-built and tested the tool which
would require access to hardware and software that is not widely
available. TRITON is also designed to communicate using the
proprietary TriStation protocol which is not publicly documented
suggesting the adversary independently reverse engineered this protocol.

The targeting of critical infrastructure to disrupt, degrade, or
destroy systems is consistent with numerous attack and reconnaissance
activities carried out globally by Russian, Iranian, North Korean,
U.S., and Israeli nation state actors. Intrusions of this nature do
not necessarily indicate an immediate intent to disrupt targeted
systems, and may be preparation for a contingency.

Background on Process Control and Safety Instrumented Systems

Figure 1: ICS Reference Architecture

Modern industrial process control and automation systems rely on a
variety of sophisticated control systems and safety functions. These
systems and functions are often referred to as Industrial Control
Systems (ICS) or Operational Technology (OT).

A Distributed Control System (DCS) provides human operators with the
ability to remotely monitor and control an industrial process. It is a
computerized control system consisting of computers, software
applications and controllers. An Engineering Workstation is a computer
used for configuration, maintenance and diagnostics of the control
system applications and other control system equipment.

A SIS is an autonomous control system that independently monitors
the status of the process under control. If the process exceeds the
parameters that define a hazardous state, the SIS attempts to bring
the process back into a safe state or automatically performs a safe
shutdown of the process. If the SIS and DCS controls fail, the final
line of defense is the design of the industrial facility, which
includes mechanical protections on equipment (e.g. rapture discs),
physical alarms, emergency response procedures and other mechanisms to
mitigate dangerous situations.

Asset owners employ varied approaches to interface their plant’s DCS
with the SIS. The traditional approach relies on the principles of
segregation for both communication infrastructures and control
strategies. For at least the past decade, there has been a trend
towards integrating DCS and SIS designs for various reasons including
lower cost, ease of use, and benefits achieved from exchanging
information between the DCS and SIS. We believe TRITON acutely
demonstrates the risk associated with integrated designs that allow
bi-directional communication between DCS and SIS network hosts.

Safety Instrumented Systems Threat Model and Attack Scenarios

Figure 2: Temporal Relationship Between
Cyber Security and Safety

The attack lifecycle for disruptive attacks against ICS is similar
to other types of cyber attacks, with a few key distinctions. First,
the attacker’s mission is to disrupt an operational process rather
than steal data. Second, the attacker must have performed OT
reconnaissance and have sufficient specialized engineering knowledge
to understand the industrial process being controlled and successfully
manipulate it.

Figure 2 represents the relationship between cyber security and
safety controls in a process control environment. Even if cyber
security measures fail, safety controls are designed to prevent
physical damage. To maximize physical impact, a cyber attacker would
also need to bypass safety controls.

The SIS threat model below highlights some of the options available
to an attacker who has successfully compromised an SIS.

Attack Option 1: Use the SIS to shutdown the process

  • The attacker can
    reprogram the SIS logic to cause it to trip and shutdown a process
    that is, in actuality, in a safe state. In other words, trigger a
    false positive.
  • Implication: Financial losses due to
    process downtime and complex plant start up procedure after the

Attack Option 2: Reprogram the SIS to allow an unsafe state

  • The attacker can
    reprogram the SIS logic to allow unsafe conditions to persist.
  • Implication: Increased risk that a hazardous situation will
    cause physical consequences (e.g. impact to equipment, product,
    environment and human safety) due to a loss of SIS

Attack Option 3: Reprogram the SIS to allow an unsafe state – while
using the DCS to create an unsafe state or hazard

  • The attacker can
    manipulate the process into an unsafe state from the DCS while
    preventing the SIS from functioning appropriately.
  • Implication: Impact to human safety, the environment, or damage
    to equipment, the extent of which depends on the physical
    constraints of the process and the plant design.

Analysis of Attacker Intent

We assess with moderate confidence that the attacker’s long-term
objective was to develop the capability to cause a physical
consequence. We base this on the fact that the attacker initially
obtained a reliable foothold on the DCS and could have developed the
capability to manipulate the process or shutdown the plant, but
instead proceeded to compromise the SIS system. Compromising both the
DCS and SIS system would enable the attacker to develop and carry out
an attack that causes the maximum amount of damage allowed by the
physical and mechanical safeguards in place.

Once on the SIS network, the attacker used their pre-built TRITON
attack framework to interact with the SIS controllers using the
TriStation protocol. The attacker could have caused a process shutdown
by issuing a halt command or intentionally uploading flawed code to
the SIS controller to cause it to fail. Instead, the attacker made
several attempts over a period of time to develop and deliver
functioning control logic for the SIS controllers in this target
environment. While these attempts appear to have failed due one of the
attack scripts’ conditional checks, the attacker persisted with their
efforts. This suggests the attacker was intent on causing a specific
outcome beyond a process shutdown.

Of note, on several occasions, we have observed evidence of long
term intrusions into ICS which were not ultimately used to disrupt or
disable operations. For instance, Russian operators, such as Sandworm
Team, have compromised Western ICS over a multi-year period without
causing a disruption.

Summary of Malware Capabilities

The TRITON attack tool was built with a number of features,
including the ability to read and write programs, read and write
individual functions and query the state of the SIS controller.
However, only some of these capabilities were leveraged in the
trilog.exe sample (e.g. the attacker did not leverage all of TRITON’s
extensive reconnaissance capabilities).

The TRITON malware contained the capability to communicate with
Triconex SIS controllers (e.g. send specific commands such as halt
or read its memory content) and remotely reprogram them with an
attacker-defined payload. The TRITON sample Mandiant analyzed added an
attacker-provided program to the execution table of the Triconex
controller. This sample left legitimate programs in place, expecting
the controller to continue operating without a fault or exception. If
the controller failed, TRITON would attempt to return it to a running
state. If the controller did not recover within a defined time window,
this sample would overwrite the malicious program with invalid data to
cover its tracks.


Asset owners who wish to defend against the capabilities
demonstrated in the incident, should consider the following controls:

  • Where technically feasible, segregate safety system networks
    from process control and information system networks. Engineering
    workstations capable of programming SIS controllers should not be
    dual-homed to any other DCS process control or information system
  • Leverage hardware features that provide for physical
    control of the ability to program safety controllers. These usually
    take the form of switches controlled by a physical key. On Triconex
    controllers, keys should not be left in the PROGRAM mode other than
    during scheduled programming events.
  • Implement change
    management procedures for changes to key position. Audit current key
    state regularly.
  • Use a unidirectional gateway rather than
    bidirectional network connections for any applications that depend
    on the data provided by the SIS.
  • Implement strict access
    control and application whitelisting on any server or workstation
    endpoints that can reach the SIS system over TCP/IP.
  • Monitor ICS network traffic for unexpected communication flows
    and other anomalous activity.

Figure 3: Triconex Key Switch (source)

Appendix: Technical Analysis

Figure 4: TRITON Architecture and Attack Scenario

TRITON was deployed on an SIS engineering workstation running the
Microsoft Windows operating system. The malware was named to
masquerade as the legitimate Triconex Trilog application. This
application is used for reviewing logs and is a part of the TriStation
application suite. The malware was delivered as a Py2EXE compiled
python script dependent on a zip file containing standard Python
libraries, open source libraries, as well as the attacker-developed
Triconex attack framework for interacting with the Triconex
controllers. Along with the executable, two binary files,
inject.bin (malicious function code) and imain.bin
(malicious control logic)
, were deployed as the controller’s
payload. These file names were hard coded in the Py2EXE compiled
python script.

Trilog.exe took one option from the command line, which was a single
IP address of the target Triconex device. It did not leverage the
underlying TRITON library’s capability for Triconex device discovery,
instead an instance of trilog.exe had to be invoked separately for
each target controller in the environment. Once invoked, trilog.exe
checked the status of the controller, then read the configuration
information exposed by the TriStation protocol. If the controller was
in a running state, trilog.exe encoded the two payload files
inject.bin and imain.bin and passed them to the
communication libraries to be appended to the controller’s program
memory and execution table.

After payload files were inserted into memory on the Triconex
controller, the script initiated a countdown, periodically checking
the status of the controller. If an error was detected, the
communication library’s method SafeAppendProgramMod attempted
to reset the controller to the previous state using a TriStation
protocol command. If this failed, trilog.exe attempted to write a
small ‘dummy’ program to memory. We assess that this was an
anti-forensics technique to hide the presence of the attacker code on
the Triconex controller.

Working with the asset owner, Mandiant ran trilog.exe in a lab
environment with a valid Triconex controller and discovered a
conditional check in the malware that prevented the payload binary
from persisting in the environment. Mandiant confirmed that, after
correcting patching the attack script to remove this check, the
payload binary would persist in controller memory, and the controller
would continue to run.

TRITON implements the TriStation protocol, which is the protocol
used by the legitimate TriStation application, to configure controllers.

TsHi is the high-level interface created by the
malware’s authors that allows the threat actor’s operators to
implement attack scripts using the TRITON framework. It exposes
functions for both reconnaissance and attack. The functions generally
accept binary data from the user, and handle the code ‘signing’ and
check sums prior to passing the data to lower level libraries for
serialization on to the network.

TsBase, another attacker-written module, contains the
functions called by TsHi, which translate the attacker’s
intended action to the appropriate TriStation protocol function code.
For certain functions, it also packs and pads the data in to the
appropriate format.

TsLow is an additional attacker module that implements the
TriStation UDP wire protocol. The TsBase library primarily
depends on the ts_exec method. This method takes the function
code and expected response code, and serializes the commands payload
over UDP. It checks the response from the controller against the
expected value and returns a result data structure indicating success
or a False object representing failure.

TsLow also exposes the connect method used to check
connectivity to the target controller. If invoked with no targets, it
runs the device discovery function detect_ip. This leverages a
“ping” message over the TriStation protocol using IP
broadcast to find controllers that are reachable via a router from
where the script is invoked.


Filename / Domain / IP Address MD5 Hash or Description
trilog.exe 6c39c3f4a08d3d78f2eb973a94bd7718
imain.bin 437f135ba179959a580412e564d3107f
inject.bin 0544d425c7555dc4e9d76b571f31f500 0face841f7b2953e7c29c064d6886523
TS_cnames.pyc e98f4f3505f05bf90e17554fbc97bba9
TsBase.pyc 288166952f934146be172f6353e9a1f5
TsHi.pyc 27c69aa39024d21ea109cc9c9d944a04
TsLow.pyc f6b3a73c8c87506acda430671360ce15
sh.pyc 8b675db417cc8b23f4c43f3de5c83438


author =
“nicholas.carr @itsreallynick”
md5 =
description = “TRITON framework recovered during Mandiant
ICS incident response”
$python_compiled = “.pyc” nocase ascii wide
$python_module_01 = “__module__” nocase
ascii wide
$python_module_02 =
“” nocase ascii wide
$python_script_01 = “import Ts” nocase ascii
$python_script_02 = “def ts_”
nocase ascii wide

$py_cnames_01 =
“” nocase ascii wide
$py_cnames_02 = “TRICON” nocase ascii wide
$py_cnames_03 = “TriStation ” nocase ascii
$py_cnames_04 = ” chassis ”
nocase ascii wide

$py_tslibs_01 =
“GetCpStatus” nocase ascii wide
$py_tslibs_02 = “ts_” ascii wide
$py_tslibs_03 = ” sequence” nocase ascii wide
$py_tslibs_04 = /import Ts(Hi|Low|Base)[^:alpha:]/
nocase ascii wide
$py_tslibs_05 =
/modules?version/ nocase ascii wide
$py_tslibs_06 = “bad ” nocase ascii wide
$py_tslibs_07 = “prog_cnt” nocase ascii

$py_tsbase_01 = “”
nocase ascii wide
$py_tsbase_02 =
“.TsBase(” nocase ascii wide

$py_tshi_01 = “” nocase ascii
$py_tshi_02 = “keystate” nocase
ascii wide
$py_tshi_03 =
“GetProjectInfo” nocase ascii wide
$py_tshi_04 = “GetProgramTable” nocase ascii
$py_tshi_05 =
“SafeAppendProgramMod” nocase ascii wide
$py_tshi_06 = “.TsHi(” ascii nocase wide

$py_tslow_01 = “” nocase ascii
$py_tslow_02 =
“print_last_error” ascii nocase wide
$py_tslow_03 = “.TsLow(” ascii nocase wide
$py_tslow_04 = “tcm_” ascii wide
$py_tslow_05 = ” TCM found” nocase ascii

$py_crc_01 = “crc.pyc” nocase
ascii wide
$py_crc_02 =
“CRC16_MODBUS” ascii wide
= “Kotov Alaxander” nocase ascii wide
$py_crc_04 = “CRC_CCITT_XMODEM” ascii wide
$py_crc_05 = “crc16ret” ascii wide
$py_crc_06 = “CRC16_CCITT_x1D0F” ascii
$py_crc_07 = /CRC16_CCITT[^_]/ ascii

$py_sh_01 = “sh.pyc” nocase
ascii wide

$py_keyword_01 = ”
FAILURE” ascii wide
$py_keyword_02 =
“symbol table” nocase ascii wide

$py_TRIDENT_01 = “inject.bin” ascii nocase
$py_TRIDENT_02 = “imain.bin”
ascii nocase wide

of ($python_*) and 7 of ($py_*) and filesize < 3MB

Go to Source
Author: Blake Johnson

New Targeted Attack in the Middle East by APT34, a Suspected IranianThreat Group, Using CVE-2017-11882 Exploit

Less than a week after Microsoft issued a patch for CVE-2017-11882
on Nov. 14, 2017, FireEye observed an attacker using an exploit for
the Microsoft Office vulnerability to target a government organization
in the Middle East. We assess this activity was carried out by a
suspected Iranian cyber espionage threat group, whom we refer to as
APT34, using a custom PowerShell backdoor to achieve its objectives.

We believe APT34 is involved in a long-term cyber espionage
operation largely focused on reconnaissance efforts to benefit Iranian
nation-state interests and has been operational since at least 2014.
This threat group has conducted broad targeting across a variety of
industries, including financial, government, energy, chemical, and
telecommunications, and has largely focused its operations within the
Middle East. We assess that APT34 works on behalf of the Iranian
government based on infrastructure details that contain references to
Iran, use of Iranian infrastructure, and targeting that aligns with
nation-state interests. The full report on APT34 is available to our
customer community

APT34 uses a mix of public and non-public tools, often conducting
spear phishing operations using compromised accounts, sometimes
coupled with social engineering tactics. In May 2016, we published a
blog detailing a spear
phishing campaign
targeting banks in the Middle East region that
used macro-enabled attachments to distribute POWBAT malware. We now
attribute that campaign to APT34. In July 2017, we observed APT34
targeting a Middle East organization using a PowerShell-based backdoor
that we call POWRUNER and a downloader with domain generation
algorithm functionality that we call BONDUPDATER, based on strings
within the malware. The backdoor was delivered via a malicious .rtf
file that exploited CVE-2017-0199.

In this latest campaign, APT34 leveraged the recent Microsoft Office
vulnerability CVE-2017-11882 to deploy POWRUNER and BONDUPDATER.

CVE-2017-11882: Microsoft Office Stack Memory Corruption Vulnerability

CVE-2017-11882 affects several versions of Microsoft Office and,
when exploited, allows a remote user to run arbitrary code in the
context of the current user as a result of improperly handling objects
in memory. The vulnerability was patched by Microsoft on Nov. 14,
2017. A full proof of concept (POC) was publicly released a week later
by the reporter of the vulnerability.

The vulnerability exists in the old Equation Editor (EQNEDT32.EXE),
a component of Microsoft Office that is used to insert and evaluate
mathematical formulas. The Equation Editor is embedded in Office
documents using object linking and embedding (OLE) technology. It is
created as a separate process instead of child process of Office
applications. If a crafted formula is passed to the Equation Editor,
it does not check the data length properly while copying the data,
which results in stack memory corruption. As the EQNEDT32.exe is
compiled using an older compiler and does not support address space
layout randomization (ASLR), a technique that guards against the
exploitation of memory corruption vulnerabilities, the attacker can
easily alter the flow of program execution.


APT34 sent a malicious .rtf file (MD5:
a0e6933f4e0497269620f44a083b2ed4) as an attachment in a malicious
spear phishing email sent to the victim organization. The malicious
file exploits CVE-2017-11882, which corrupts the memory on the stack
and then proceeds to push the malicious data to the stack. The malware
then overwrites the function address with the address of an existing
instruction from EQNEDT32.EXE. The overwritten instruction (displayed
in Figure 1) is used to call the “WinExec” function from kernel32.dll,
as depicted in the instruction at 00430c12, which calls the “WinExec” function.

Figure 1: Disassembly of overwritten
function address

After exploitation, the ‘WinExec’ function is successfully called to
create a child process, “mshta.exe”, in the context of current logged
on user. The process “mshta.exe” downloads a malicious script from
hxxp://mumbai-m[.]site/b.txt and executes it, as seen in Figure 2.

Figure 2: Attacker data copied to corrupt
stack buffer

Execution Workflow

The malicious script goes through a series of steps to successfully
execute and ultimately establish a connection to the command and
control (C2) server. The full sequence of events starting with the
exploit document is illustrated in Figure 3.

Figure 3: CVE-2017-11882 and POWRUNER
attack sequence

  1. The malicious .rtf file
    exploits CVE-2017-11882.
  2. The malware overwrites the
    function address with an existing instruction from
  3. The malware creates a child process,
    “mshta.exe,” which downloads a file from:
  4. b.txt contains a PowerShell
    command to download a dropper from: hxxp://dns-update[.]club/v.txt.
    The PowerShell command also renames the downloaded file from v.txt
    to v.vbs and executes the script.
  5. The v.vbs script drops
    four components (hUpdateCheckers.base, dUpdateCheckers.base,
    cUpdateCheckers.bat, and GoogleUpdateschecker.vbs) to the directory:
  6. v.vbs uses
    CertUtil.exe, a legitimate Microsoft command-line program installed
    as part of Certificate Services, to decode the base64-encoded files
    hUpdateCheckers.base and dUpdateCheckers.base, and drop
    hUpdateCheckers.ps1 and dUpdateCheckers.ps1 to the staging
  7. cUpdateCheckers.bat is launched and creates a
    scheduled task for GoogleUpdateschecker.vbs persistence.
  8. GoogleUpdateschecker.vbs is executed after sleeping for five
  9. cUpdateCheckers.bat and *.base are deleted from the
    staging directory.

Figure 4 contains an excerpt of the v.vbs script pertaining to the
Execution Workflow section.

Figure 4: Execution Workflow Section of v.vbs

After successful execution of the steps mentioned in the Execution
Workflow section, the Task Scheduler will launch
GoogleUpdateschecker.vbs every minute, which in turn executes the
dUpdateCheckers.ps1 and hUpdateCheckers.ps1 scripts. These PowerShell
scripts are final stage payloads – they include a downloader with
domain generation algorithm (DGA) functionality and the backdoor
component, which connect to the C2 server to receive commands and
perform additional malicious activities.

hUpdateCheckers.ps1 (POWRUNER)

The backdoor component, POWRUNER, is a PowerShell script that sends
and receives commands to and from the C2 server. POWRUNER is executed
every minute by the Task Scheduler. Figure 5 contains an excerpt of
the POWRUNER backdoor.

Figure 5: POWRUNER PowerShell script hUpdateCheckers.ps1

POWRUNER begins by sending a random GET request to the C2 server and
waits for a response. The server will respond with either “not_now” or
a random 11-digit number. If the response is a random number, POWRUNER
will send another random GET request to the server and store the
response in a string. POWRUNER will then check the last digit of the
stored random number response, interpret the value as a command, and
perform an action based on that command. The command values and the
associated actions are described in Table 1.

Command Description Action
0 Server response string contains batch
Execute batch
commands and send results back to server
1 Server response string is a file path Check for file path and
upload (PUT) the file to server
2 Server response string is a file path Check for file path and
download (GET) the file

Table 1: POWRUNER commands

After successfully executing the command, POWRUNER sends the results
back to the C2 server and stops execution.

The C2 server can also send a PowerShell command to capture and
store a screenshot of a victim’s system. POWRUNER will send the
captured screenshot image file to the C2 server if the “fileupload”
command is issued. Figure 6 shows the PowerShell “Get-Screenshot”
function sent by the C2 server.

Figure 6: Powershell Screenshot Functionality

dUpdateCheckers.ps1 (BONDUPDATER)

One of the recent advancements by APT34 is the use of DGA to
generate subdomains. The BONDUPDATER script, which was named based on
the hard-coded string “B007”, uses a custom DGA algorithm to generate
subdomains for communication with the C2 server.

DGA Implementation

Figure 7 provides a breakdown of how an example domain
(456341921300006B0C8B2CE9C9B007.mumbai-m[.]site) is generated using

Figure 7: Breakdown of subdomain created

  1. This is a randomly
    generated number created using the following expression: $rnd =
    -join (Get-Random -InputObject (10..99) -Count (%{ Get-Random
    -InputObject (1..6)}));
  2. This value is either 0 or 1. It is
    initially set to 0. If the first resolved domain IP address starts
    with 24.125.X.X, then it is set to 1.
  3. Initially set to 000,
    then incremented by 3 after every DNS request
  4. First 12
    characters of system UUID.
  5. “B007” hardcoded string.
  6. Hardcoded domain “mumbai-m[.]site”

BONDUPDATER will attempt to resolve the resulting DGA domain and
will take the following actions based on the IP address resolution:

  1. Create a temporary file
    in %temp% location

    • The file created will have the last two
      octets of the resolved IP addresses as its filename.
  2. BONDUPDATER will evaluate the last character of the file
    name and perform the corresponding action found in Table 2.
Character Description
0 File contains batch commands, it executes the
batch commands
1 Rename the temporary file as .ps1
2 Rename the temporary file as .vbs

Table 2: BONDUPDATER Actions

Figure 8 is a screenshot of BONDUPDATER’s DGA implementation.

Figure 8: Domain Generation Algorithm

Some examples of the generated subdomains observed at time of
execution include:




Network Communication

Figure 9 shows example network communications between a POWRUNER
backdoor client and server.

Figure 9: Example Network Communication

In the example, the POWRUNER client sends a random GET request to
the C2 server and the C2 server sends the random number (99999999990)
as a response. As the response is a random number that ends with ‘0’,
POWRUNER sends another random GET request to receive  an additional
command string. The C2 server sends back Base64 encoded response.

If the server had sent the string “not_now” as response, as shown in
Figure 10, POWRUNER would have ceased any further requests and
terminated its execution.

Figure 10: Example “not now”
server response

Batch Commands

POWRUNER may also receive batch commands from the C2 server to
collect host information from the system. This may include information
about the currently logged in user, the hostname, network
configuration data, active connections, process information, local and
domain administrator accounts, an enumeration of user directories, and
other data. An example batch command is provided in Figure 11.

Figure 11: Batch commands sent by
POWRUNER C2 server


APT34 has used POWRUNER and BONDUPDATER to target Middle East
organizations as early as July 2017. In July 2017, a FireEye Web MPS
appliance detected and blocked a request to retrieve and install an
APT34 POWRUNER / BONDUPDATER downloader file. During the same month,
FireEye observed APT34 target a separate Middle East organization
using a malicious .rtf file (MD5: 63D66D99E46FB93676A4F475A65566D8)
that exploited CVE-2017-0199. This file issued a GET request to
download a malicious file from:


As shown in Figure 12, the script within the dupatechecker.doc file
attempts to download another file named dupatechecker.exe from the
same server. The file also contains a comment by the malware author
that appears to be an apparent taunt to security researchers.

Figure 12: Contents of dupdatechecker.doc script

The dupatechecker.exe file (MD5: C9F16F0BE8C77F0170B9B6CE876ED7FB)
drops both BONDUPDATER and POWRUNER. These files connect to
proxychecker[.]pro for C2.

Outlook and Implications

Recent activity by APT34 demonstrates that they are capable group
with potential access to their own development resources. During the
past few months, APT34 has been able to quickly incorporate exploits
for at at least two publicly vulnerabilities (CVE-2017-0199 and
CVE-2017-11882) to target organziations in the Middle East.
We assess that APT34’s efforts to continuously update their malware,
including the incorporation of DGA for C2, demonstrate the group’s
commitment to pursing strategies to deter detection. We expect APT34
will continue to evolve their malware and tactics as they continue to
pursue access to entities in the Middle East region.


Filename / Domain / IP Address MD5 Hash or Description
CVE-2017-11882 exploit
b.txt 9267D057C065EA7448ACA1511C6F29C7
v.txt/v.vbs B2D13A336A3EB7BD27612BE7D4E334DF
dUpdateCheckers.base 4A7290A279E6F2329EDD0615178A11FF
hUpdateCheckers.base 841CE6475F271F86D0B5188E4F8BC6DB
cUpdateCheckers.bat 52CA9A7424B3CC34099AD218623A0979
dUpdateCheckers.ps1 BBDE33F5709CB1452AB941C08ACC775E
hUpdateCheckers.ps1 247B2A9FCBA6E9EC29ED818948939702
GoogleUpdateschecker.vbs C87B0B711F60132235D7440ADD0360B0
hxxp://mumbai-m[.]site POWRUNER C2
hxxp://dns-update[.]club Malware Staging Server
CVE-2017-0199 exploit document 63D66D99E46FB93676A4F475A65566D8 Malware Staging Server
dupdatechecker.doc D85818E82A6E64CA185EDFDDBA2D1B76
dupdatechecker.exe C9F16F0BE8C77F0170B9B6CE876ED7FB
proxycheker[.]pro C2 Has resolved mumbai-m[.]site &
hpserver[.]online Has resolved mumbai-m[.]site and
dns-update[.]club Has resolved dns-update[.]club Has resolved dns-update[.]club Has resolved ns2.dns-update[.]club
& hpserver[.]online & anyportals[.]com E6AC6F18256C4DDE5BF06A9191562F82
dUpdateCheckers.base 3C63BFF9EC0A340E0727E5683466F435
hUpdateCheckers.base EEB0FF0D8841C2EBE643FE328B6D9EF5
cUpdateCheckers.bat FB464C365B94B03826E67EABE4BF9165
dUpdateCheckers.ps1 635ED85BFCAAB7208A8B5C730D3D0A8C
hUpdateCheckers.ps1 13B338C47C52DE3ED0B68E1CB7876AD2
googleupdateschecker.vbs DBFEA6154D4F9D7209C1875B2D5D70D5
hpserver[.]online C2
v7-anyportals.hta EAF3448808481FB1FDBB675BC5EA24DE
dUpdateCheckers.base 42449DD79EA7D2B5B6482B6F0D493498
hUpdateCheckers.base A3FCB4D23C3153DD42AC124B112F1BAE
dUpdateCheckers.ps1 EE1C482C41738AAA5964730DCBAB5DFF
hUpdateCheckers.ps1 E516C3A3247AF2F2323291A670086A8F
anyportals[.]com C2

Go to Source
Author: Manish Sardiwal

Newly Observed Ursnif Variant Employs Malicious TLS Callback Techniqueto Achieve Process Injection


TLS (Thread Local Storage) callbacks are provided by the Windows
operating system to support additional initialization and termination
for per-thread data structures.

As previously
, malicious TLS callbacks, as an anti-analysis trick, have
been observed for quite some time and can allow for PE files to
include malicious TLS callback functions to be executed prior to the
AddressOfEntryPoint field (the normal start of intended execution) in
the PE header. In essence, unsuspecting analysts and automated
security tools can miss the actual entry point to malcode if they do
not account for it in the beginning of their analysis and insert a
breakpoint on the regular offset pointed to by AddressOfEntryPoint.

We recently came across a Ursnif/Gozi-ISFB sample that manipulated
TLS callbacks while injecting to child process. Though many of the
malware binaries (or their packers) use some variation of
GetThreadContext/SetThreadContext or CreateRemoteThread Windows API
functions to change the entry point of the remote process during
injection, this sample (and the related cluster) is using a relatively
lesser-known stealth technique. This little deviation from the
standard textbook approach may cause some generic unpackers or tools
to break following the execution flow, if they do not account for the technique.


Since early 2017, we have regularly observed the abuse of
compromised Sharepoint accounts to host malicious payloads, with
distribution of URIs via spam emails. Some of the major campaigns
we’ve observed involve distributing Dridex within the UK and
Ursnif/Gozi-ISFB in Australia. The recently observed Ursnif variant
discussed in this post was discovered via a spam email. A sample lure
can been seen in Figure 1.

Figure 1: Malicious email lure
distributing Ursnif

After clicking on the “REVIEW DOCUMENT” button, the malware
downloads a ZIP file named from the
following location:


The ZIP file contains a malicious JavaScript file that, when
executed, will download and execute the Ursnif/Gozi-ISFB payload.

The activities of the distribution are difficult to identify within
an organization’s normal network activity because the command and
control (C2) server of this payload communicates over HTTPS and the
compromised Sharepoint accounts being used also communicate over HTTPS.

Variant Analysis

On execution, the observed sample (MD5:
13794d1d8e87c69119237256ef068043) tries to create a child process
named svchost.exe (using the svchost.exe file from the
System32 folder) using the CreateProcessW API function in suspended mode.

Next, for process hollowing of svchost.exe, the malware
creates a section object and maps the section using
ZwMapViewOfSection. It uses the memset function to fill the mapped
section with zeroes, and then leverages memcpy to copy the unpacked
DLL to that region. The malware then resolves three lower level API
functions by walking the ntdll.dll module.

The malware then constructs its entry shellcode into a newly mapped
region in memory.

In an effort to manipulate and identify the mapped sections of the
child process, it reads out the PEB structure of the process using a
call to ZwReadVirtualMemory.

The malware will then change protection permissions of the PE header
of the child process to enable write access to that page. It then uses
a call to ZwWriteVirtualMemory to write 18 bytes of buffer at offset
0x40 from the start of svchost.exe process executable in the
target child process. The malware then cleverly changes the region
protection back to “read only” to avoid suspicion.

Again, it repeats the procedure of changing protections for the PE
image of svchost.exe to write 8 bytes at an offset of 0x198
bytes from the start of the process executable.

The Stealthy Tweak

This buffer, when correctly placed at the offset, will represent the
TLS directory offset for the process because offset 0x198 is the
location of the TLS directory in PE executable, and the next DWORD
represents the size of the directory (seen in Figure 2). Notice how
the malware writes the offset 0x40 for directory and the size 0x18
bytes in an effort to point to the buffer it had already crafted at
offset 0x40 with size 0x18 bytes.

Figure 2: TLS directory location and size

The TLS directory structure, when used to parse out that buffer of
0x18 bytes, points to an offset containing a list of pointers
representing AddressOfCallBacks (see Figure 3).

Figure 3: TLS directory structure with pointers

If we take a look at offset 0xe058, it points to the list of
AddressOfCallBacks (Figure 4), and if we go to the offset 0xe058 in
memory we are pointed to the only callback address at offset 0xe068 –
which is in fact the actual entry point code (Figure 5).

Figure 4: Offset 0xe058

Figure 5: Offset 0xe068 in memory

Finally, the malware unmaps the view using ZwUnmapViewOfSection and
calls ResumeThread to begin malicious execution of its injected
process (from the injected TLS callback address instead of the regular
AddressOfEntryPoint listed in the PE header). Hence, the execution
will first land at the injected TLS callback (see Figure 6).

Figure 6: Actual entry point


The leaked
source code
of Ursnif/Gozi-ISFB used the standard DllMain call
entry point to initialize the injected DLL image and execute its entry
(see Figure 7).

Figure 7: DllMain call used in leaked
Ursnif source code

This newer variant shows that actors are not only modifying the
malware to evade signatures, they are also equipping them with
stealthier techniques. Unaware debugging environments or detection
frameworks can potentially miss the actual hidden TLS callback entry
point, allowing the malware to perform its malicious activities under
the hood.

Indicators of Compromise

MD5 :
SHA256 : 772bc1ae314dcea525789bc7dc5b41f2d4358b755ec221d783ca79b5555f22ce

Filename : YourMYOBSupply_Order.js
MD5 :
SHA256 : 9f7413a57595ffe33ca320df26231d30a521596ef47fb3e3ed54af1a95609132

Filename : download[1].aspx
MD5 :
SHA256 : e498b56833da8c0170ffba4b8bcd04f85b99f9c892e20712d6c8e3ff711fa66c

Go to Source
Author: Abhay Vaish

BACKSWING – Pulling a BADRABBIT Out of a Hat

Executive Summary

On Oct. 24, 2017, coordinated strategic web compromises started to
distribute BADRABBIT ransomware to unwitting users. FireEye appliances
detected the download attempts and blocked our user base from
infection. During our investigation into the activity, FireEye
identified a direct overlap between BADRABBIT redirect sites and sites
hosting a profiler we’ve been tracking as BACKSWING. We’ve identified
51 sites hosting BACKSWING and four confirmed to drop BADRABBIT.
Throughout 2017, we observed two versions of BACKSWING and saw a
significant increase in May with an apparent focus on compromising
Ukrainian website. The pattern of deployment raises the possibility of
a strategic sponsor with specific regional interests and suggest a
motivation other than financial gain. Given that many domains are
still compromised with BACKSWING, we anticipate that there is a risk
that they will be used for future attacks.

Incident Background

Beginning on Oct. 24 at 08:00 UTC, FireEye detected and blocked
attempts to infect multiple clients with a drive-by download
masquerading as a Flash Update (install_flash_player.exe) that
delivered a wormable variant of ransomware. Users were redirected to
the infected site from multiple legitimate sites (e.g.
simultaneously, indicating a coordinated and widespread strategic web
compromise campaign.

FireEye network devices blocked infection attempts at over a dozen
victims primarily in Germany, Japan, and the U.S. until Oct. 24 at
15:00 UTC, when the infection attempts ceased and attacker
infrastructure – both 1dnscontrol[.]com and the legitimate websites
containing the rogue code – were taken offline.

BACKSWING Framework Likely Connected to BADRABBIT Activity

Strategic web compromises can have a significant amount of
collateral targeting. It is common for threat actors to pair a
strategic web compromise with profiling malware to target systems with
specific application versions or victims. FireEye observed that
BACKSWING, a malicious JavaScript profiling framework, was deployed to
at least 54 legitimate sites starting as early as September 2016.  A
handful of these sites were later used to redirect to BADRABBIT
distribution URLs.

FireEye iSIGHT Intelligence tracks two distinct version of BACKSWING
that contain the same functionality, but differ in their code styles.
We consider BACKSWING a generic container used to select attributes of
the current browsing session (User-Agent, HTTP Referrer, Cookies, and
the current domain). This information is then relayed to a “C2”
sometimes to referred to as a “receiver.” If the receiver is online,
the server returns a unique JSON blob to the caller which is then
parsed by the BACKSWING code (Figure 1).

Figure 1: BACKSWING Reply

BACKSWING anticipates the JSON blob to have two fields,
“InjectionType” (expected to be an integer) and “InjectionString”
(expected to be string containing HTML content). BACKSWING version 1
(Figure 2) explicitly handles the value of “InjectionType” into two
code paths:

  • If InjectionType == 1 (Redirect browser to URL)
  • If
    InjectionType != 1 (render HTML into the DOM)

Figure 2: Backswing Version 1

In Version 2 (Figure 3), BACKSWING retains similar logic, but
generalizes the InjectionString to be handled strictly to render the
reply into the DOM.

Figure 3: BACKSWING Version 2

Version 1:

  • FireEye observed the first version of BACKSWING in late 2016
    on websites belonging to a Czech Republic hospitality organization
    in addition to a government website in Montenegro. Turkish-tourism
    websites were also injected with this profiler.
    v1 was commonly injected in cleartext to affected websites, but over
    time, actors began to obfuscate the code using the open-source
    Dean-Edwards Packer and injected it into legitimate JavaScript
    resources on affected websites. Figure 4 shows the injection
  • Beginning in May 2017, FireEye observed a number of
    Ukrainian websites compromised with BACKSWING v1, and in June 2017,
    began to see content returned from BACKSWING receivers.
  • In
    late June 2017, BACKSWING servers returned an HTML div element with
    two distinct identifiers. When decoded, BACKSWING v1 embedded two
    div elements within the DOM with values of
    07a06a96-3345-43f2-afe1-2a70d951f50a and
    9b142ec2-1fdb-4790-b48c-ffdf22911104. No additional content was
    observed in these replies.

Figure 4: BACKSWING Injection Content

Version 2:

  • The earliest that FireEye observed BACKSWING v2 occurred on
    Oct. 5, 2017 across multiple websites that previously hosted
  • BACKSWING v2 was predominantly injected into
    legitimate JavaScript resources hosted on affected websites;
    however, some instances were injected into the sites’ main
  • FireEye observed limited instances of websites hosting
    this version were also implicated in suspected BADRABBIT infection
    chains (detailed in Table 1).

Malicious profilers allow attackers to obtain more information about
potential victims before deploying payloads (in this case, the
BADRABBIT “flash update” dropper). While FireEye has not directly
observed BACKSWING delivering BADRABBIT, BACKSWING was observed on
multiple websites that were seen referring FireEye customers to
1dnsccontrol[.]com, which hosted the BADRABBIT dropper.

Table 1 highlights the legitimate sites hosting BACKSWING that were
also used as HTTP referrers for BADRABBIT payload distribution.

Compromised Website BACKSWING Receiver BACKSWING Version Observed BADRABBIT Redirect
blog.fontanka[.]ru Not Available Not Available 1dnscontrol[.]com[.]jp http://185.149.120[.]3/scholargoogle/ v2 1dnscontrol[.]com
www.fontanka[.]ru http://185.149.120[.]3/scholargoogle/ v2 1dnscontrol[.]com
www.mediaport[.]ua http://172.97.69[.]79/i/ v1 1dnscontrol[.]com
www.mediaport[.]ua http://185.149.120[.]3/scholargoogle/ v2 1dnscontrol[.]com
www.smetkoplan[.]com http://172.97.69[.]79/i/ v1 1dnscontrol[.]com
www.smetkoplan[.]com http://38.84.134[.]15/Core/Engine/Index/default v1 1dnscontrol[.]com
www.smetkoplan[.]com http://185.149.120[.]3/scholargoogle/ v2 1dnscontrol[.]com

Table 1: Sites hosting BACKSWING profilers and
redirected users to a BADRABBIT download site

The compromised websites listed in Table 1 demonstrate one of the
first times that we have observed the potential weaponization of
BACKSWING. FireEye is tracking a growing number of legitimate websites
that also host BACKSWING underscoring a considerable footprint the
actors could leverage in future attacks. Table 2 provides a list of
sites also compromised with BACKSWING

Compromised Website BACKSWING Receiver BACKSWING Version
akvadom.kiev[.]ua http://172.97.69[.]79/i/ v1[.]ua http://dfkiueswbgfreiwfsd[.]tk/i/ v1[.]ua http://172.97.69[.]79/i/ v1[.]ua http://172.97.69[.]79/i/ v1[.]ua http://172.97.69[.]79/i/ v1[.]me http://38.84.134[.]15/Core/Engine/Index/two v1
Evrosmazki[.]ua http://172.97.69[.]79/i/ v1
forum.andronova[.]net http://172.97.69[.]79/i/ v1
forum.andronova[.]net http://91.236.116[.]50/Core/Engine/Index/two v1
grandua[.]ua http://172.97.69[.]79/i/ v1
grupovo[.]bg http://185.149.120[.]3/scholargoogle/ v2
hr.pensionhotel[.]com http://38.84.134[.]15/Core/Engine/Index/default v1[.]ua http://172.97.69[.]79/i/ v1[.]ua http://185.149.120[.]3/scholargoogle/ v2
icase.lg[.]ua http://172.97.69[.]79/i/ v1
montenegro-today[.]com http://38.84.134[.]15/Core/Engine/Index/two v1
montenegro-today[.]ru http://172.97.69[.]79/i/ v1
most-dnepr[.]info http://172.97.69[.]79/i/ v1
most-dnepr[.]info http://185.149.120[.]3/scholargoogle/ v2
obereg-t[.]com http://172.97.69[.]79/i/ v1
sarktur[.]com http://104.244.159[.]23:8080/i v1
sarktur[.]com http://38.84.134[.]15/Core/Engine/Index/default v1[.]ua http://172.97.69[.]79/i/ v1
sinematurk[.]com http://91.236.116[.]50/Core/Engine/Index/two v1
vgoru[.]org http://172.97.69[.]79/i/ v1
www.2000[.]ua http://172.97.69[.]79/i/ v1
www.444android[.]com http://172.97.69[.]79/i/ v1
www.444android[.]com http://91.236.116[.]50/Core/Engine/Index/two v1[.]jp http://38.84.134[.]15/Core/Engine/Index/default v1
www.alapli.bel[.]tr http://91.236.116[.]50/Core/Engine/Index/two v1
www.ambilet[.]ro http://185.149.120[.]3/scholargoogle/ v2
www.andronova[.]net http://91.236.116[.]50/Core/Engine/Index/two v1[.]ua http://172.97.69[.]79/i/ v1
www.dermavieskin[.]com https://bodum-online[.]gq/Core/Engine/Index/three v1
www.evrosmazki[.]ua http://172.97.69[.]79/i/ v1
www.hercegnovi[.]me http://38.84.134[.]15/Core/Engine/Index/two v1
www.len[.]ru http://185.149.120[.]3/scholasgoogle/ v2
www.montenegro-today[.]com http://38.84.134[.]15/Core/Engine/Index/two v1
www.montenegro-today[.]com http://91.236.116[.]50/Core/Engine/Index/two v1
www.otbrana[.]com http://38.84.134[.]15/Core/Engine/Index/default v1
www.pensionhotel[.]be http://38.84.134[.]15/Core/Engine/Index/default v1
www.pensionhotel[.]cz http://38.84.134[.]15/Core/Engine/Index/default v1
www.pensionhotel[.]de http://172.97.69[.]79/i/ v1
www.pensionhotel[.]de http://38.84.134[.]15/Core/Engine/Index/default v1
www.pensionhotel[.]dk http://38.84.134[.]15/Core/Engine/Index/default v1
www.pensionhotel[.]nl http://38.84.134[.]15/Core/Engine/Index/default v1
www.pensionhotel[.]pl http://38.84.134[.]15/Core/Engine/Index/default v1
www.pensionhotel[.]ro http://46.20.1[.]98/scholargoogle/ v1
www.pensionhotel[.]sk http://38.84.134[.]15/Core/Engine/Index/default v1
www.sinematurk[.]com http://91.236.116[.]50/Core/Engine/Index/two v1
www.t.ks[.]ua http://172.97.69[.]79/i/ v1
www.teknolojihaber[.]net http://91.236.116[.]50/Core/Engine/Index/two v1
www.uscc[.]ua http://172.97.69[.]79/i/ v1
www.vertizontal[.]ro http://91.236.116[.]50/Core/Engine/Index/three v1
www.visa3777[.]com http://172.97.69[.]79/i/ v1
www.www.pensionhotel[.]de http://38.84.134[.]15/Core/Engine/Index/default v1

Table 2: Additional sites hosting BACKSWING
profilers and associated receivers

The distribution of sites compromised with BACKSWING suggest a
motivation other than financial gain. FireEye observed this framework
on compromised Turkish sites and Montenegrin sites over the past year.
We observed a spike of BACKSWING instances on Ukrainian sites, with a
significant increase in May 2017. While some sites hosting BACKSWING
do not have a clear strategic link, the pattern of deployment raises
the possibility of a strategic sponsor with specific regional interests.

BADRABBIT Components

BADRABBIT is made up of several components, as described in Figure 5.

Figure 5: BADRABBIT components

Install_flashPlayer.exe (MD5: FBBDC39AF1139AEBBA4DA004475E8839)

The install_flashplayer.exe payload drops infpub.dat (MD5:
C4F26ED277B51EF45FA180BE597D96E8) to the C:Windows directory and
executes it using rundll32.exe with the argument
C:Windowsinfpub.dat,#1 15. This execution format mirrors that of EternalPetya.

infpub.dat (MD5: 1D724F95C61F1055F0D02C2154BBCCD3)

The infpub.dat binary is the primary ransomware component
responsible for dropping and executing the additional components shown
in the BADRABBIT Components section. An embedded RSA-2048 key
facilitates the encryption process, which uses an AES-128 key to
encrypt files. The extensions listed below are targeted for encryption:

The following directories are ignored during the encryption process:

  • Windows
  • Program Files
  • ProgramData
  • AppData

The malware writes its ransom message to the root of each affected
drive with the filename Readme.txt.

The inpub.dat is capable of performing lateral movement via WMI or
SMB. Harvested credentials provided by an embedded Mimikatz executable
facilitate the infection of other systems on the network. The malware
contains lists of common usernames, passwords, and named pipes that it
can use to brute-force other credentials for lateral movement.

If one of four Dr.Web antivirus processes is present on the system,
file encryption is not performed. If the malware is executed with the
“-f” command line argument, credential theft and lateral movement are bypassed.

dispci.exe (MD5: B14D8FAF7F0CBCFAD051CEFE5F39645F)

The dispci.exe binary interacts with the DiskCryptor driver
(cscc.dat) to install the malicious bootloader. If one of three McAfee
antivirus processes is running on the system, dispci.exe is written to
the %ALLUSERSPROFILE% directory; otherwise, it is written to
C:Windows. The sample is executed on system start using a scheduled
task named rhaegal.

cscc.dat (MD5s: B4E6D97DAFD9224ED9A547D52C26CE02 or EDB72F4A46C39452D1A5414F7D26454A)

A 32 or 64-bit DiskCryptor
driver named cscc.dat facilitates disk encryption. It is installed in
the :Windows directory as a kernel driver service named cscc.

Mimikatz usage (MD5s: 37945C44A897AA42A66ADCAB68F560E0 or 347AC3B6B791054DE3E5720A7144A977)

A 32 or 64-bit Mimikatz variant is written a temporary file (e.g.,
651D.tmp) in the C:Windows directory and executed by passing a named
pipe string (e.g., \.pipe{8A93FA32-1B7A-4E2F-AAD2-76A095F261DC}) as
an argument. Harvested credentials are passed back to infpub.dat via
the named pipe, similar to EternalPetya.

BADRABBIT Compared to EternalPetya

The infpub.dat contains a checksum algorithm like the one used in
EternalPetya. However, the initial checksum value differs slightly:
0x87654321 in infpub.dat, 0x12345678 in EternalPetya. infpub.dat also
supports the same command line arguments as EternalPetya with the
addition of the “-f” argument, which bypasses the malware’s credential
theft and lateral movement capabilities.

Like EternalPetya, infpub.dat determines if a specific file exists
on the system and will exit if found. The file in this case is
cscc.dat. infpub.dat contains a wmic.exe lateral movement capability,
but unlike EternalPetya, does not contain a PSEXEC binary used to
perform lateral movement.

Both samples utilize the same series of wevtutil and fsutil commands
to perform anti-forensics:

wevtutil cl Setup & wevtutil cl
System & wevtutil cl Security & wevtutil cl Application
& fsutil usn deletejournal /D %SYSTEMDRIVE%

FireEye Detections

Product Detection Names
NX,EX,AX,FX,ETP malware.binary.exe,
Trojan.Ransomware.MVX, Exploit.PossibleWaterhole.BACKSWING
Created], WINDOWS METHODOLOGY [Service Installation], WINDOWS
Ordinal Arg], WINDOWS METHODOLOGY [Wevtutil Clear-log],
METHODOLOGY [Multiple Admin Share Failures]

We would like to thank Edward Fjellskål for his assistance with
research for this blog.


File: Install_flashPlayer.exe
install_flashplayer.exe drops infpub.dat

File: infpub.dat
Hash: 1D724F95C61F1055F0D02C2154BBCCD3
Description: Primary ransomware component

File: dispci.exe
Hash: B14D8FAF7F0CBCFAD051CEFE5F39645F
Description: Interacts with the DiskCryptor driver (cscc.dat) to
install the malicious bootloader, responsible for file decryption.

File: cscc.dat
Hash: B4E6D97DAFD9224ED9A547D52C26CE02 or
Description: 32 or 64-bit
DiskCryptor driver

File: .tmp
37945C44A897AA42A66ADCAB68F560E0 or
Description: 32 or 64-bit
Mimikatz variant

File: Readme.txt
Hash: Variable
Description: Ransom note

Command: system32rundll32.exe C:Windowsinfpub.dat,#1 15
Description: Runs the primary ransomware component of BADRABBIT. Note
that “15” is the default value present in the malware and may be
altered by specifying a different value on command line when executing install_flash_player.exe.

Command: %COMSPEC% /c schtasks /Create /RU SYSTEM /SC ONSTART /TN
rhaegal /TR “<%COMSPEC%> /C Start “”
“” -id
Description: Creates
the rhaegal scheduled task

Command: %COMSPEC% /c schtasks /Create /SC once /TN drogon /RU
SYSTEM /TR “%WINDIR%system32shutdown.exe /r /t 0 /f” /ST

Description: Creates the drogon scheduled task

Command: %COMSPEC% /c schtasks /Delete /F /TN drogon
Description: Deletes the drogon scheduled task

Command: %COMSPEC% /c wswevtutil cl Setup & wswevtutil cl System
& wswevtutil cl Security & wswevtutil cl Application &
fsutil usn deletejournal /D :
Description: Anti-forensics

Scheduled Task Name: rhaegal
Scheduled Task Run:
“<%COMSPEC%> /C Start “”
“” -id
&& exit”
Description: Bootloader interaction

Scheduled Task Name: drogon
Scheduled Task Run:
“%WINDIR%system32shutdown.exe /r /t 0 /f”
Description: Forces a reboot

Service Name: cscc
Service Display Name: Windows Client Side
Caching DDriver
Service Binary Path: cscc.dat

Embedded usernames from infpub.dat (1D724F95C61F1055F0D02C2154BBCCD3)
other user
Embedded passwords from infpub.dat (1D724F95C61F1055F0D02C2154BBCCD3)
Embedded pipe names from infpub.dat (1D724F95C61F1055F0D02C2154BBCCD3)

Yara Rules

rule FE_Hunting_BADRABBIT {
@TekDefense & nicholas.carr @itsreallynick”
md5 =
// Messages
$msg1 =
“Incorrect password” nocase ascii wide
$msg2 = “Oops! Your files have been encrypted.”
ascii wide
$msg3 = “If you see this text,
your files are no longer accessible.” ascii wide
$msg4 = “You might have been looking for a way to
recover your files.” ascii wide
$msg5 =
“Don’t waste your time. No one will be able to recover
them without our” ascii wide
$msg6 =
“Visit our web service at” ascii wide
$msg7 = “Your personal installation key#1:” ascii
$msg8 = “Run DECRYPT app at your
desktop after system boot” ascii wide
= “Password#1” nocase ascii wide
$msg10 = “caforssztxqzf2nm.onion” nocase ascii
$msg11 = /partition (unbootable|not
(found|mounted))/ nocase ascii wide

// File
$fref1 =
“C:\Windows\cscc.dat” nocase ascii wide
$fref2 = “\\.\dcrypt” nocase ascii wide
$fref3 = “Readme.txt” ascii wide
$fref4 = “\Desktop\DECRYPT.lnk” nocase ascii
$fref5 = “dispci.exe” nocase
ascii wide
$fref6 =
“C:\Windows\infpub.dat” nocase ascii wide
$meta1 =
“” nocase ascii wide
$meta2 = “dispci.exe” nocase ascii wide
$meta3 = “GrayWorm” ascii wide
$meta4 = “viserion” nocase ascii wide
$com1 = “ComSpec” ascii
$com2 = “\cmd.exe” nocase ascii
$com3 = “schtasks /Create” nocase
ascii wide
$com4 = “schtasks /Delete /F /TN
%ws” nocase ascii wide
(uint16(0) == 0x5A4D)
(8 of
($msg*) and 3 of ($fref*) and 2 of ($com*))
(all of ($meta*) and 8 of ($msg*))

author =
md5 =
rev = 1
$api1 =
“GetSystemDirectoryW” fullword
$api2 = “GetModuleFileNameW” fullword
$dropped_dll = “infpub.dat” ascii fullword
$exec_fmt_str = “%ws
C:\Windows\%ws,#1 %ws” ascii fullword wide
$extract_seq = { 68 ?? ?? ?? ?? 8D 95 E4 F9 FF FF 52 FF
15 ?? ?? ?? ?? 85 C0 0F 84 C4 00 00 00 8D 85 A8 ED FF FF 50 8D
8D AC ED FF FF E8 ?? ?? ?? ?? 85 C0 0F 84 AA 00 00 00 }
(uint16(0) == 0x5A4D and
uint32(uint32(0x3C)) == 0x00004550) and filesize < 500KB
and all of them

author = “muhammad.umair”
md5 = “1d724f95c61f1055f0d02c2154bbccd3”
rev = 1
$api1 =
“WNetAddConnection2W” fullword
$api2 = “CredEnumerateW” fullword
$api3 = “DuplicateTokenEx” fullword
$api4 = “GetIpNetTable”
$del_tasks = “schtasks /Delete /F /TN drogon” ascii
fullword wide
$dropped_driver =
“cscc.dat” ascii fullword wide
$exec_fmt_str = “%ws C:\Windows\%ws,#1 %ws” ascii
fullword wide
$iter_encrypt = { 8D 44 24 3C
50 FF 15 ?? ?? ?? ?? 8D 4C 24 3C 8D 51 02 66 8B 31 83 C1 02 66
3B F7 75 F5 2B CA D1 F9 8D 4C 4C 3C 3B C1 74 07 E8 ?? ?? ?? ??
$share_fmt_str =
“\\%ws\admin$\%ws” ascii fullword wide
(uint16(0) == 0x5A4D and
uint32(uint32(0x3C)) == 0x00004550) and filesize < 500KB
and all of them

author =
md5 =
rev = 1
$api1 =
“WriteProcessMemory” fullword
$api2 = “SetSecurityDescriptorDacl” fullword
$api_str1 = “BCryptDecrypt” ascii fullword
$mimi_str = “CredentialKeys”
ascii fullword wide
$wait_pipe_seq = { FF 15
?? ?? ?? ?? 85 C0 74 63 55 BD B8 0B 00 00 57 57 6A 03 8D 44 24
1C 50 57 68 00 00 00 C0 FF 74 24 38 4B FF 15 ?? ?? ?? ?? 8B F0
83 FE FF 75 3B }
(uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550)
and filesize < 500KB and all of them

author =
md5 =
rev = 1
$api1 =
“CryptAcquireContextW” fullword
$api2 = “CryptEncrypt” fullword
$api3 = “NetWkstaGetInfo” fullword
$decrypt_seq = { 89 5D EC 78 10 7F 07 3D 00 00 00 01 76 07 B8
00 00 00 01 EB 07 C7 45 EC 01 00 00 00 53 50 53 6A 04 53 8B F8
56 89 45 FC 89 7D E8 FF 15 ?? ?? ?? ?? 8B D8 85 DB 74 5F
$msg1 = “Disk decryption
progress…” ascii fullword wide
$task_fmt_str = “schtasks /Create /SC ONCE /TN
viserion_%u /RU SYSTEM /TR “%ws” /ST
%02d:%02d:00″ ascii fullword wide
= “\\.\dcrypt” ascii fullword wide
$tok2 = “C:\Windows\cscc.dat” ascii fullword
(uint16(0) ==
0x5A4D and uint32(uint32(0x3C)) == 0x00004550) and filesize
< 150KB and all of them

Go to Source
Author: Barry Vengerik

Magniber Ransomware Wants to Infect Only the Right People


Exploit kit (EK) use has been on the decline since late 2016;
however, certain activity remains consistent. The Magnitude Exploit
Kit is one such example that continues to affect users, particularly
in the APAC region.

In Figure 1, which is based on FireEye Dynamic threat Intelligence
(DTI) reports shared in March 2017, we can see the regions affected by
Magnitude EK activity during the last three months of 2016 and the
first three months of 2017.

Figure 1: Magnitude EK distribution as
seen in March 2017

This trend continued until late September 2017, when we saw
Magnitude EK focus primarily on the APAC region, with a large chunk
targeting South Korea. Magnitude EK activity then fell off the radar
until Oct. 15, 2017, when it came back and began focusing solely on
South Korea. Previously it had been distributing Cerber ransomware,
but Cerber distribution has declined (we have also seen a decline of
Cerber being distributed via email) and now it is distributing
ransomware known as Magniber.


The first reappearance of Magnitude EK on Oct. 15 came as a
malvertising redirection from the domain: fastprofit[.]loan. The
infection chain is shown in Figure 2.

Figure 2: Infection chain

The Magnitude EK landing page consisted of CVE-2016-0189, which was
first reported by FireEye as being used in Neutrino
Exploit Kit
after it was patched. Figure 3 shows the landing
page and CVE usage.

Figure 3: Magnitude EK landing page

As seen previously with Magnitude EK, the payload is downloaded as a
plain EXE (see Figure 4) and domain infrastructure is hosted on the
following server:

“Apache/2.2.15 (CentOS) DAV/2 mod_fastcgi/2.4.6”

Figure 4: Magnitude payload header and
plain MZ response


In the initial report published
by our colleagues at Trend Micro
, the ransomware being
distributed is referred to as Magniber. These ransomware payloads only
seem to target Korean systems, since they won’t execute if the system
language is not Korean.

Magniber encrypts user data using the AES128. The sample used
(dc2a2b84da359881b9df1ec31d03c715) for this analysis was pulled from
our DTI system when the campaign was active. Of note, this sample
differs from the hash shared publically by Trend Micro, but the two
exhibit the same behavior and share the infection vector, and both
were distributed around the same time.

The malware contains a binary payload in its resource section
encrypted in reverse using RC4. It starts unpacking it from the end of
the buffer to its start. Reverse RC4 decryption keys are 30 bytes long
and also contain non-ASCII characters. They are as follows:

  • dc2a2b84da359881b9df1ec31d03c715 RC4 key:
    • { 0x6b,
      0xfe, 0xc4, 0x23, 0xac, 0x50, 0xd7, 0x91, 0xac, 0x06, 0xb0,
      0xa6, 0x65, 0x89, 0x6a, 0xcc, 0x05, 0xba, 0xd7, 0x83, 0x04,
      0x90, 0x2a, 0x93, 0x8d, 0x2d, 0x5c, 0xc7, 0xf7, 0x3f }

The malware calls GetSystemDefaultUILanguage, and if the
system language is not Korean, it exits (instructions can be seen in
Figure 5). After unpacking in memory, the malware starts executing the
unpacked payload.

Figure 5: Language check targeted at Korea

A mutex with name “ihsdj” is created to prevent multiple
executions. The payload then generates a pseudorandom 19-character
string based on the CPU clock from multiple GetTickCount calls.
The string is then used to create a file in the user’s %TEMP%
directory (e.g. “xxxxxxxxxxxxxxxxxxx.ihsdj”), which contains
the IV (Initialization Vector) for the AES128 encryption and a copy of
the malware itself with the name “ihsdj.exe”.

Next, the malware constructs 4 URLs for callback. It uses the
19-character long pseudorandom string it generated, and the following
domains to create the URLs:


In order to evade sandbox systems, the malware checks to see if it’s
running inside a VM and appends the result to the URL callback. It
does this by sandwiching and executing CPUID instructions (shown in
Figure 6) between RDTSC calls, forcing VMEXIT.

Figure 6: CPUID instruction to detect VM presence

The aforementioned VM check is done multiple times to gather the
average execution time of the CPUID, and if the average execution time
is greater than 1000, it considers the system to be a VM. In case the
test fails and the malware thinks the system is a VM, a “1”
is appended at the end of the URL (see Figure 7); otherwise,
“0” is appended. The format of the URL is as follows:

  • http://[19 character pseudorandom string].[callback
    domain]/new[0 or 1]

Examples of this would be:

  • http://7o12813k90oggw10277.bankme[.]date/new1
  • http://4bg8l9095z0287fm1j5.bankme[.]date/new0

Figure 7: Command and control communication

If the malware is executed a second time after encryption, the
callback URL ends in “end0” or “end1” instead of
“new”. An example of this would be:

  • hxxp://j2a3y50mi0a487230v1.bankme[.]date/end1

The malware then starts to encrypt user files on the system,
renaming them by adding a “.ihsdj” extension to the end. The
public key for the AES128 and IV for the sample analyzed are:

  • IV: EP866p5M93wDS513
  • Public Key AES128: S25943n9Gt099y4K

A text file “READ_ME_FOR_DECRYPT_xxxxxxxxxxxxxxxxxxx_.txt”
is created in the user’s %TEMP% directory and shown to the user. The
ransom message is shown in Figure 8.

Figure 8: Ransom message for the infected user

The malware also adds scheduled tasks to run its copy from %TEMP%
with compatibility assistant, and loads the user message as follows:

  • schtasks /create /SC MINUTE /MO 15 /tn ihsdj /TR
    “pcalua.exe -a %TEMP%ihsdj.exe
  • schtasks /create /SC
    MINUTE /MO 15 /tn xxxxxxxxxxxxxxxxxxx /TR

The malware then issues a command to delete itself after exiting,
using the following local ping to provide delay for the deletion:

  • cmd /c ping localhost -n 3 > nul & del

Figure 9 contains the Python code for unpacking the malware payload,
which is encrypted using RC4 in reverse.

Figure 9: Python script for unpacking
malware payload


Ransomware is a significant threat to enterprises. While the current
threat landscape suggests a large portion of attacks are coming from
emails, exploit kits continue to put users at risk – especially those
running old software versions and not using ad blockers. Enterprises
need to make sure their network nodes are fully patched.


Malware Sample Hash
  • dc2a2b84da359881b9df1ec31d03c715 (decryption key shared)
Malverstiser Domains
  • fastprofit[.]loan
  • fastprofit[.]me
EK Domain Examples
  • 3e37i982wb90j.fileice[.]services
  • a3co5a8iab2x24g90.helpraw[.]schule
  • 2i1f3aadm8k.putback[.]space
Command and Control Domains

Go to Source
Author: Muhammad Umair

Significant FormBook Distribution Campaigns Impacting the U.S. and South Korea

We observed several high-volume FormBook malware distribution
campaigns primarily taking aim at Aerospace, Defense Contractor, and
Manufacturing sectors within the U.S. and South Korea during the past
few months. The attackers involved in these email campaigns leveraged
a variety of distribution mechanisms to deliver the information
stealing FormBook malware, including:

  • PDFs with download links
  • DOC and XLS files with
    malicious macros
  • Archive files (ZIP, RAR, ACE, and ISOs)
    containing EXE payloads

The PDF and DOC/XLS campaigns primarily impacted the United States
and the Archive campaigns largely impacted the Unites States and South Korea.

FormBook Overview

FormBook is a data stealer and form grabber that has been advertised
in various hacking forums since early 2016. Figure 1 and Figure 2 show
the online advertisement for the malware.

Figure 1: FormBook advertisement

Figure 2: FormBook underground pricing

The malware injects itself into various processes and installs
function hooks to log keystrokes, steal clipboard contents, and
extract data from HTTP sessions. The malware can also execute commands
from a command and control (C2) server. The commands include
instructing the malware to download and execute files, start
processes, shutdown and reboot the system, and steal cookies and local passwords.

One of the malware’s most interesting features is that it reads
Windows’ ntdll.dll module from disk into memory, and calls its
exported functions directly, rendering user-mode hooking and API
monitoring mechanisms ineffective. The malware author calls this
technique “Lagos Island method” (allegedly originating from
a userland rootkit with this name).

It also features a persistence method that randomly changes the
path, filename, file extension, and the registry key used for persistence.

The malware author does not sell the builder, but only sells the
panel, and then generates the executable files as a service.


FormBook is a data stealer, but not a full-fledged banker (banking
malware). It does not currently have any extensions or plug-ins. Its
capabilities include:

  • Key logging
  • Clipboard monitoring
  • Grabbing
    HTTP/HTTPS/SPDY/HTTP2 forms and network requests
  • Grabbing
    passwords from browsers and email clients
  • Screenshots

FormBook can receive the following remote commands from the C2 server:

  • Update bot on host system
  • Download and execute
  • Remove bot from host system
  • Launch a command
    via ShellExecute
  • Clear browser cookies
  • Reboot
  • Shutdown system
  • Collect passwords and create
    a screenshot
  • Download and unpack ZIP archive


The C2 domains typically leverage less widespread, newer generic
top-level domains (gTLDs) such as .site, .website, .tech, .online, and .info.

The C2 domains used for this recently observed FormBook activity
have been registered using the WhoisGuard privacy protection service.
The server infrastructure is hosted on, a Ukrainian
hosting provider. Each server typically has multiple FormBook panel
installation locations, which could be indicative of an affiliate model.

Behavior Details

File Characteristics

Our analysis in this blog post is based on the following
representative sample:

Filename MD5 Hash Size (bytes) Compile Time
Unavailable CE84640C3228925CC4815116DDE968CB 747,652 2012-06-09

Table 1: FormBook sample details


The malware is a self-extracting RAR file that starts an AutoIt
loader. The AutoIt loader compiles and runs an AutoIt script. The
script decrypts the FormBook payload file, loads it into memory, and
then executes it.


The FormBook malware copies itself to a new location. Themalware
first chooses one of the following strings to use as a prefix for its
installed filename:

ms, win, gdi, mfc, vga, igfx, user, help, config, update, regsvc,
chkdsk, systray, audiodg, certmgr, autochk, taskhost, colorcpl,
services, IconCache, ThumbCache, Cookies

It then generates two to five random characters and appends those to
the chosen string above

followed by one of the following file extensions:

  • .exe, .com, .scr, .pif, .cmd, .bat

If the malware is running with elevated privileges, it copies itself
to one of the following directories:

  • %ProgramFiles%
  • %CommonProgramFiles%

If running with normal privileges, it copies itself to one of the
following directories:

  • %TEMP%


The malware uses the same aforementioned string list with a random
string to create a prefix, appends one to five random characters, and
uses this value as the registry value name.

The malware configures persistence to one of the following two
locations depending on its privileges:

  • (HKCU|HKLM)SOFTWAREMicrosoftWindowsCurrentVersionRun
  • (HKCU|HKLM)SOFTWAREMicrosoftWindowsCurrentVersionPoliciesExplorerRun


The malware creates two 16-byte mutexes. The first mutex is the
client identifier (e.g., 8-3503835SZBFHHZ). The second mutex value is
derived from the C2 information and the username (e.g., LL9PSC56RW7Bx3A5).

The malware then iterates over a process listing and calculates a
checksum value of process names (rather than checking the name itself)
to figure out which process to inject. The malware may inject itself
into browser processes and explorer.exe. Depending on the target
process, the malware installs different function hooks (see
the Function Hooks section for further detail).


The malware uses several techniques to complicate malware analysis:

  • Timing checks using the RDTSC instruction
  • Calls
    NtQueryInformationProcess with InfoClass=7 (ProcessDebugPort)
  • Sample path and filename checks (sample filename must be shorter
    than 32 characters)
  • Hash-based module blacklist
  • Hash-based process blacklist
  • Hash-based username
  • Before communicating, it checks whether the C2
    server is present in the hosts file

The results of these tests are then placed into a 16-byte array, and
a SHA1 hash is calculated on the array, which will be later used as
the decryption key for subsequent strings (e.g. DLL names to load).
Failed checks may go unnoticed until the sample tries to load the
supporting DLLs
(kernel32.dll and advapi32.dll).

The correct 16-byte array holding the result of the checks is:

  • 00 00 01 01 00 00 01 00 01 00 01 00 00 00 00 00

Having a SHA1 value of:

  • 5b85aaa14f74e7e8adb93b040b0914a10b8b19b2

After completing all anti-analysis checks, the sample manually maps
ntdll.dll from disk into memory and uses its exported functions
directly in the code. All API functions will have a small stub
function in the code that looks up the address of the API in the
mapped ntdll.dll using the CRC32 checksum of the API name, and sets up
the parameters on the stack.

This will be followed by a direct register call to the mapped
ntdll.dll module. This makes regular debugger breakpoints on APIs
inoperable, as execution will never go through the system mapped ntdll.dll.

Process Injection

The sample loops through all the running processes to find
explorer.exe by the CRC32 checksum of its process name. It then
injects into explorer.exe using the following API calls (avoiding more
commonly identifiable techniques such as WriteProcessMemory and CreateRemoteThread):

  • NtMapViewOfSection
  • NtSetContextThread
  • NtQueueUserAPC

The injected code in the hijacked instance of explorer.exe randomly
selects and launches (as a suspended process) a built-in Windows
executable from the following list:

  • svchost.exe, msiexec.exe, wuauclt.exe, lsass.exe, wlanext.exe,
    msg.exe, lsm.exe, dwm.exe, help.exe, chkdsk.exe, cmmon32.exe,
    nbtstat.exe, spoolsv.exe, rdpclip.exe, control.exe, taskhost.exe,
    rundll32.exe, systray.exe, audiodg.exe, wininit.exe, services.exe,
    autochk.exe, autoconv.exe, autofmt.exe, cmstp.exe, colorcpl.exe,
    cscript.exe, explorer.exe, WWAHost.exe, ipconfig.exe, msdt.exe,
    mstsc.exe, NAPSTAT.EXE, netsh.exe, NETSTAT.EXE, raserver.exe,
    wscript.exe, wuapp.exe, cmd.exe

The original process reads the randomly selected executable from the
memory of explorer.exe and migrates into this new process via
NtMapViewOfSection, NtSetContextThread, and NtQueueUserAPC.

The new process then deletes the original sample and sets up
persistence (see the Persistence section for more detail). It
then goes into a loop that constantly enumerates running processes and
looks for targets based on the CRC32 checksum of the process name.

Targeted process names include, but are not limited to:

  • iexplore.exe, firefox.exe, chrome.exe, MicrosoftEdgeCP.exe,
    explorer.exe, opera.exe, safari.exe, torch.exe, maxthon.exe,
    seamonkey.exe, avant.exe, deepnet.exe, k-meleon.exe, citrio.exe,
    coolnovo.exe, coowon.exe, cyberfox.exe, dooble.exe, vivaldi.exe,
    iridium.exe, epic.exe, midori.exe, mustang.exe,
palemoon.exe, qupzilla.exe, sleipnir.exe,
    superbird.exe, outlook.exe, thunderbird.exe, totalcmd.exe

After injecting into any of the target processes, it sets up
user-mode API hooks based on the process.

The malware installs different function hooks depending on the
process. The primary purpose of these function hooks is to log
keystrokes, steal clipboard data, and extract authentication
information from browser HTTP sessions. The malware stores data in
local password log files. The directory name is derived from the C2
information and the username (the same as the second mutex created above: LL9PSC56RW7Bx3A5).

However, only eight bytes from this value are used as the directory
name (e.g., LL9PSC56). Next, the first three characters from the
derived directory name are used as a prefix for the log file followed
by the string log. Following this prefix are names corresponding to
the type of log file. For example, for Internet Explorer passwords,
the following log file would be created:

  • %APPDATA%LL9PSC56LL9logri.ini.

The following are the password log filenames without the prefix:

  • (no name): Keylog data
  • rg.ini: Chrome passwords
  • rf.ini: Firefox passwords
  • rt.ini: Thunderbird
  • ri.ini: Internet Explorer passwords
  • rc.ini: Outlook passwords
  • rv.ini: Windows Vault
  • ro.ini: Opera passwords

One additional file that does not use the .INI file extension is a
screenshot file:

  • im.jpeg

Function Hooks

Keylog/clipboard monitoring:

  • GetMessageA
  • GetMessageW
  • PeekMessageA
  • PeekMessageW
  • SendMessageA
  • SendMessageW

Browser hooks:

  • PR_Write
  • HttpSendRequestA
  • HttpSendRequestW
  • InternetQueryOptionW
  • EncryptMessage
  • WSASend

The browser hooks look for certain strings in the content of HTTP
requests and, if a match is found, information about the request is
extracted. The targeted strings are:

  • pass
  • token
  • email
  • login
  • signin
  • account
  • persistent

Network Communications

The malware communicates with the following C2 server using HTTP requests:

  • www[.]clicks-track[.]info/list/hx28/


As seen in Figure 3, FormBook sends a beacon request (controlled by
a timer/counter) using HTTP GET with an “id” parameter in
the URL.

Figure 3: FormBook beacon

The decoded “id” parameter is as follows:

  • FBNG:134C0ABB 2.9:Windows 7 Professional x86:VXNlcg==


  • “FBNG” – magic bytes
  • “134C0ABB”
    – the CRC32 checksum of the user’s SID
  • “2.9” –
    the bot version
  • “Windows 7 Professional” –
    operating system version
  • “x86” – operating system
  • “VXNlcg==” – the Base64 encoded
    username (i.e., “User” in this case)

Communication Encryption

The malware sends HTTP requests using hard-coded HTTP header values.
The HTTP headers shown in Figure 4 are hardcoded.

Figure 4: Hard-coded HTTP header values

Messages to the C2 server are sent RC4 encrypted and Base64 encoded.
The malware uses a slightly altered Base64 alphabet, and also uses the
character “.” instead of “=” as the pad character:

  • Standard Alphabet:
    • ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/
  • Modified Alphabet:
    • ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_

The RC4 key is created using an implementation of the SHA1 hashing
algorithm with the C2 URL. The standard SHA1 algorithm reverses the
DWORD endianness at the end of the algorithm. This implementation does
not, which results in a reverse endian DWORDs. For example, the SHA1
hash for the aforementioned URL
is “9b198a3cfa6ff461cc40b754c90740a81559b9ae,” but when
reordering the DWORDs, it produces the correct RC4
key: 3c8a199b61f46ffa54b740cca84007c9aeb95915. The first DWORD
“9b198a3c” becomes “3c8a199b.”

Figure 5 shows an example HTTP POST request.

Figure 5: Example HTTP POST request

In this example, the decoded result is:

  • ClipboardrnrnBlank Page – Windows Internet

Accepted Commands

When a command is sent by the C2 server, the HTTP response body has
the format shown in Figure 6.

Figure 6: FormBook C2 server response
with command

The data begins with the magic bytes “FBNG,” and a
one-byte command code from hex bytes 31 to 39 (i.e., from
“1” to “9”) in clear text. This is then followed
by the RC4-encoded command data (where the RC4 key is the same as the
one used for the request). In the decrypted data, another occurrence
of the magic FBNG bytes indicates the end of the command data.

The malware accepts the commands shown in Table 2.

Command Parameters
(after decryption)
‘1’ (0x31) <pe_file_data>FBNG Download and execute file from
%TEMP% directory
‘2’ (0x32) <pe_file_data>FBNG Update bot on host machine
‘3’ (0x33) FBNG Remove bot from host machine
‘4’ (0x34) <command_string>FBNG Launch a command via
‘5’ (0x35) FBNG Clear browser cookies
‘6’ (0x36) FBNG Reboot operating system
‘7’ (0x37) FBNG Shutdown operating system
‘8’ (0x38) FBNG Collect email/browser passwords and create a
‘9’ (0x39) <zip_file_data>FBNG Download and unpack ZIP archive into
%TEMP% directory

Table 2: FormBook accepted commands

Distribution Campaigns

FireEye researchers observed FormBook distributed via email
campaigns using a variety of different attachments:

  • PDFs with links to the “” URL-shortening
    service, which then redirected to a staging server that contained
    FormBook executable payloads
  • DOC and XLS attachments that
    contained malicious macros that, when enabled, initiated the
    download of FormBook payloads
  • ZIP, RAR, ACE, and ISO
    attachments that contained FormBook executable files

The PDF Campaigns

The PDF campaigns leveraged FedEx and DHL shipping/package delivery
themes (Figure 7 and Figure 8), as well as a document-sharing theme.
The PDFs distributed did not contain malicious code, just a link to
download the FormBook payload.

The staging servers (shown in Table 3) appeared to be compromised websites.

Figure 7: Example PDF campaign email lure
with attachment

Figure 8: Example PDF campaign attachment

Sample Subject Lines Shorted URLs Staging Servers
<Recipient’s_Name> – You have a
parcel awaiting pick up

– I shared a file with you

















Table 3: Observed email subjects and download
URLs for PDF campaign

Based on data from the links, there were a total of
716 hits across 36 countries. As seen in Figure 9, most of the
malicious activity from the PDF campaign impacted the United States.

Figure 9: Geolocation statistics from URL shortener

The DOC/XLS Campaigns

The email campaigns distributing DOC and XLS files relied on the use
of malicious macros to download the executable payload. When the
macros are enabled, the download URL retrieves an executable file with
a PDF extension. Table 4 shows observed email subjects and download
URLs used in these campaigns.

Sample Subject Lines Staging Server URL

ACS PO 1528

ORDER – PO-074




sdvernoms[.]ml /oc/runpie.pdf









Table 4: Observed email subjects and download
URLs for the DOC/XLS campaign

FireEye detection technologies observed this malicious activity
between Aug. 11 and Aug. 22, 2017 (Figure 10). Much of the activity
was observed in the United States (Figure 11), and the most targeted
industry vertical was Aerospace/Defense Contractors (Figure 12).

Figure 10: DOC/XLS campaign malicious
activity by date

Figure 11: Top 10 countries affected by
the DOC/XLS campaign

Figure 12: Top 10 industry verticals
affected by the DOC/XLS campaign

The Archive Campaign

The Archive campaign delivered a variety of archive formats,
including ZIP, RAR, ACE, and ISO, and accounted for the highest
distribution volume. It leveraged a myriad of subject lines that were
characteristically business related and often regarding payment or
purchase orders:

Sample Subject Lines

BCCMKE806868TSC Counterparty:.


Fw: Remittance Confirmation


PO. NO.: 10701 –
Send Quotaion Pls

Re: bgcqatar project

August korea ORDER

Purchase Order #234579

purchase order for August017

FireEye detection technologies observed this campaign activity
between July 18 and Aug. 17, 2017 (Figure 13). Much of the activity
was observed in South Korea and the United States (Figure 14), with
the Manufacturing industry vertical being the most impacted (Figure 15).

Figure 13: Archive campaign malicious
activity by date

Figure 14: Top 10 countries affected by
the Archive campaign

Figure 15: Top 10 industry verticals
affected by the Archive campaign 


While FormBook is not unique in either its functionality or
distribution mechanisms, its relative ease of use, affordable pricing
structure, and open availability make FormBook an attractive option
for cyber criminals of varying skill levels. In the last few weeks,
FormBook was seen downloading other malware families such as NanoCore.
The credentials and other data harvested by successful FormBook
infections could be used for additional cyber crime activities
including, but not limited to: identity theft, continued phishing
operations, bank fraud and extortion.

Go to Source
Author: Nart Villeneuve