BIOS Boots What? Finding Evil in Boot Code at Scale!

The second issue is that reverse engineering all boot records is
impractical. Given the job of determining if a single system is
infected with a bootkit, a malware analyst could acquire a disk image
and then reverse engineer the boot bytes to determine if anything
malicious is present in the boot chain. However, this process takes
time and even an army of skilled reverse engineers wouldn’t scale to
the size of modern enterprise networks. To put this in context, the
compromised enterprise network referenced in our ROCKBOOT blog post had approximately
10,000 hosts. Assuming a minimum
of two boot records per host, a Master Boot Record (MBR) and a Volume
Boot Record (VBR), that is an average of 20,000 boot records to analyze! An
initial reaction is probably, “Why not just hash the boot records and
only analyze the unique ones?” One would assume that corporate
networks are mostly homogeneous, particularly with respect to boot
code, yet this is not the case. Using the same network as an example,
the 20,000 boot records reduced to only 6,000 unique records based on
MD5 hash. Table 1 demonstrates this using data we’ve collected across
our engagements for various enterprise sizes.

Enterprise Size (# hosts) Avg # Unique Boot Records (md5)
100-1000 428
1000-10000 4,738
10000+ 8,717

Table 1 – Unique boot records by MD5 hash

Now, the next thought might be, “Rather than hashing the entire
record, why not implement a custom hashing technique where only
subsections of the boot code are hashed, thus avoiding the dynamic
data portions?” We tried this as well. For example, in the case of
Master Boot Records, we used the bytes at the following two offsets to
calculate a hash:

md5( offset[0:218] + offset[224:440] )

In one network this resulted in approximately 185,000 systems
reducing to around 90 unique MBR hashes. However, this technique had
drawbacks. Most notably, it required accounting for numerous special
cases for applications such as Altiris, SafeBoot, and PGPGuard. This
required small adjustments to the algorithm for each environment,
which in turn required reverse engineering many records to find the
appropriate offsets to hash.

Ultimately, we concluded that to solve the problem we needed a
solution that provided the following:

  • A reliable collection of
    boot records from systems
  • A behavioral analysis of boot
    records, not just static analysis
  • The ability to analyze
    tens of thousands of boot records in a timely manner

The remainder of this post describes how we solved each of these challenges.

Collect the Bytes

Malicious drivers insert themselves into the disk driver stack so
they can intercept disk I/O as it traverses the stack. They do this to
hide their presence (the real bytes) on disk. To address this attack
vector, we developed a custom kernel driver (henceforth, our “Raw
Read” driver) capable of targeting various altitudes in the disk
driver stack. Using the Raw Read driver, we identify the lowest level
of the stack and read the bytes from that level (Figure 1).

Figure 1: Malicious driver inserts itself
as a filter driver in the stack, raw read driver reads bytes from
lowest level

This allows us to bypass the rest of the driver stack, as well as
any user space hooks. (It is important to note, however, that if the
lowest driver on the I/O stack has an inline code hook an attacker can
still intercept the read requests.) Additionally, we can compare the
bytes read from the lowest level of the driver stack to those read
from user space. Introducing our first indicator of a compromised
boot system: the bytes retrieved from user space don’t match those
retrieved from the lowest level of the disk driver stack.

Analyze the Bytes

As previously mentioned, reverse engineering and static analysis are
impractical when dealing with hundreds of thousands of boot records.
Automated dynamic analysis is a more practical approach, specifically
through emulating the execution of a boot record. In more technical
terms, we are emulating the real mode instructions of a boot record.

The emulation engine that we chose is the Unicorn project. Unicorn
is based on the QEMU emulator and supports 16-bit real mode emulation.
As boot samples are collected from endpoint machines, they are sent to
the emulation engine where high-level functionality is captured during
emulation. This functionality includes events such as memory access,
disk reads and writes, and other interrupts that execute during emulation.

The Execution Hash

Folding down (aka stacking) duplicate samples is critical to reduce
the time needed on follow-up analysis by a human analyst. An
interesting quality of the boot samples gathered at scale is that
while samples are often functionally identical, the data they use
(e.g. strings or offsets) is often very different. This makes it quite
difficult to generate a hash to identify duplicates, as demonstrated
in Table 1. So how can we solve this problem with emulation? Enter the
“execution hash”. The idea is simple: during emulation, hash the
mnemonic of every assembly instruction that executes (e.g.,
“md5(‘and’ + ‘mov’ + ‘shl’ + ‘or’)”). Figure 2 illustrates this
concept of hashing the assembly instruction as it executes to
ultimately arrive at the “execution hash”

Figure 2: Execution hash

Using this method, the 650,000 unique boot samples we’ve collected
to date can be grouped into a little more than 300 unique execution
hashes. This reduced data set makes it far more manageable to identify
samples for follow-up analysis. Introducing our second indicator of
a compromised boot system: an execution hash that is only found on a
few systems in an enterprise!

Behavioral Analysis

Like all malware, suspicious activity executed by bootkits can vary
widely. To avoid the pitfall of writing detection signatures for
individual malware samples, we focused on identifying behavior that
deviates from normal OS bootstrapping. To enable this analysis, the
series of instructions that execute during emulation are fed into an
analytic engine. Let’s look in more detail at an example of malicious
functionality exhibited by several bootkits that we discovered by
analyzing the results of emulation.

Several malicious bootkits we discovered hooked the interrupt vector
table (IVT) and the BIOS Data Area (BDA) to intercept system
interrupts and data during the boot process. This can provide an
attacker the ability to intercept disk reads and also alter the
maximum memory reported by the system. By hooking these structures,
bootkits can attempt to hide themselves on disk or even in memory.

These hooks can be identified by memory writes to the memory ranges
reserved for the IVT and BDA during the boot process. The IVT
structure is located at the memory range 0000:0000h to 0000:03FCh and
the BDA is located at 0040:0000h. The malware can hook the interrupt
13h handler to inspect and modify disk writes that occur during the
boot process. Additionally, bootkit malware has been observed
modifying the memory size reported by the BIOS Data Area in order to
potentially hide itself in memory.

This leads us to our final category of indicators of a compromised
boot system: detection of suspicious behaviors such as IVT hooking,
decoding and executing data from disk, suspicious screen output from
the boot code, and modifying files or data on disk.

Do it at Scale

Dynamic analysis gives us a drastic improvement when determining the
behavior of boot records, but it comes at a cost. Unlike static
analysis or hashing, it is orders of magnitude slower. In our cloud
analysis environment, the average time to emulate a single record is
4.83 seconds. Using the compromised enterprise network that contained
ROCKBOOT as an example (approximately 20,000 boot records), it would
take more than 26 hours to dynamically analyze (emulate) the records
serially! In order to provide timely results to our analysts we needed
to easily scale our analysis throughput relative to the amount of
incoming data from our endpoint technologies. To further complicate
the problem, boot record analysis tends to happen in batches, for
example, when our endpoint technology is first deployed to a new enterprise.

With the advent of serverless cloud computing, we had the
opportunity to create an emulation analysis service that scales to
meet this demand – all while remaining cost effective. One of the
advantages of serverless computing versus traditional cloud instances
is that there are no compute costs during inactive periods; the only
cost incurred is storage. Even when our cloud solution receives tens
of thousands of records at the start of a new customer engagement, it
can rapidly scale to meet demand and maintain near real-time detection
of malicious bytes.

The cloud infrastructure we selected for our application is Amazon
Web Services (AWS). Figure 3 provides an overview of the architecture.

Figure 3: Boot record analysis workflow

Our design currently utilizes:

  • API Gateway to provide a RESTful interface.
  • Lambda functions to do validation, emulation, analysis, as
    well as storage and retrieval of results.
  • DynamoDB to track progress of processed boot records through
    the system.
  • S3 to store boot records and emulation reports.

The architecture we created exposes a RESTful API that provides a
handful of endpoints. At a high level the workflow is:

  1. Endpoint agents in
    customer networks automatically collect boot records using FireEye’s
    custom developed Raw Read kernel driver (see “Collect the bytes”
    described earlier) and return the records to FireEye’s Incident
    Response (IR) server.
  2. The IR server submits batches of boot
    records to the AWS-hosted REST interface, and polls the interface
    for batched results.
  3. The IR server provides a UI for
    analysts to view the aggregated results across the enterprise, as
    well as automated notifications when malicious boot records are

The REST API endpoints are exposed via AWS’s API Gateway, which then
proxies the incoming requests to a “submission” Lambda. The submission
Lambda validates the incoming data, stores the record (aka boot code)
to S3, and then fans out the incoming requests to “analysis” Lambdas.

The analysis Lambda is where boot record emulation occurs. Because
Lambdas are started on demand, this model allows for an incredibly
high level of parallelization. AWS provides various settings to
control the maximum concurrency for a Lambda function, as well as
memory/CPU allocations and more. Once the analysis is complete, a
report is generated for the boot record and the report is stored in
S3. The reports include the results of emulation and other metadata
extracted from the boot record (e.g., ASCII strings).

As described earlier, the IR server periodically polls the AWS REST
endpoint until processing is complete, at which time the report is downloaded.

Find More Evil in Big Data

Our workflow for identifying malicious boot records is only
effective when we know what malicious indicators to look for, or what
execution hashes to blacklist. But what if a new malicious boot record
(with a unique hash) evades our existing signatures?

For this problem, we leverage our in-house big data platform engine
that we integrated into FireEye
following the acquisition of X15 Software. By loading the
results of hundreds of thousands of emulations into the engine X15,
our analysts can hunt through the results at scale and identify
anomalous behaviors such as unique screen prints, unusual initial jump
offsets, or patterns in disk reads or writes.

This analysis at scale helps us identify new and interesting samples
to reverse engineer, and ultimately helps us identify new detection
signatures that feed back into our analytic engine.


Within weeks of going live we detected previously unknown
compromised systems in multiple customer environments. We’ve
identified everything from ROCKBOOT and HDRoot!
bootkits to the admittedly humorous JackTheRipper,
a bootkit that spreads itself via floppy disk (no joke). Our system
has collected and processed nearly 650,000 unique records to date and
continues to find the evil needles (suspicious and malicious boot
records) in very large haystacks.

In summary, by combining advanced endpoint boot record extraction
with scalable serverless computing and an automated emulation engine,
we can rapidly analyze thousands of records in search of evil. FireEye
is now using this solution in both our Managed
and Incident


Dimiter Andonov, Jamin Becker, Fred House, and Seth Summersett
contributed to this blog post.

Go to Source
Author: Ryan Fisher

Chinese Espionage Group TEMP.Periscope Targets Cambodia Ahead of July2018 Elections and Reveals Broad Operations Globally


FireEye has examined a range of TEMP.Periscope activity revealing
extensive interest in Cambodia’s politics, with active compromises of
multiple Cambodian entities related to the country’s electoral system.
This includes compromises of Cambodian government entities charged
with overseeing the elections, as well as the targeting of opposition
figures. This campaign occurs in the run up to the country’s July 29,
2018, general elections. TEMP.Periscope used the same infrastructure
for a range of activity against other more traditional targets,
including the defense industrial base in the United States and a
chemical company based in Europe. Our previous blog post focused on
the group’s targeting
of engineering and maritime entities
in the United States.

Overall, this activity indicates that the group maintains an
extensive intrusion architecture and wide array of malicious tools,
and targets a large victim set, which is in line with typical
Chinese-based APT efforts. We expect this activity to provide the
Chinese government with widespread visibility into Cambodian elections
and government operations. Additionally, this group is clearly able to
run several large-scale intrusions concurrently across a wide range of
victim types.

Our analysis also strengthened our overall attribution of this
group. We observed the toolsets we previously attributed to this
group, their observed targets are in line with past group efforts and
also highly similar to known Chinese APT efforts, and we identified an
IP address originating in Hainan, China that was used to remotely
access and administer a command and control (C2) server.

TEMP.Periscope Background

Active since at least 2013, TEMP.Periscope has primarily focused on
maritime-related targets across multiple verticals, including
engineering firms, shipping and transportation, manufacturing,
defense, government offices, and research universities (targeting is
summarized in Figure 1). The group has also targeted
professional/consulting services, high-tech industry, healthcare, and
media/publishing. TEMP.Periscope overlaps in targeting, as well as
tactics, techniques, and procedures (TTPs), with TEMP.Jumper, a group
that also overlaps significantly with public reporting by Proofpoint
and F-Secure
on “NanHaiShu.”

Figure 1: Summary of TEMP.Periscope activity

Incident Background

FireEye analyzed files on three open indexes believed to be
controlled by TEMP.Periscope, which yielded insight into the group’s
objectives, operational tactics, and a significant amount of technical
attribution/validation. These files were “open indexed” and
thus accessible to anyone on the public internet. This TEMP.Periscope
activity on these servers extends from at least April 2017 to the
present, with the most current operations focusing on Cambodia’s
government and elections.

  • Two servers,
    chemscalere[.]com and scsnewstoday[.]com, operate as typical C2
    servers and hosting sites, while the third, mlcdailynews[.]com,
    functions as an active SCANBOX server. The C2 servers contained both
    logs and malware.
  • Analysis of logs from the three servers

    • Potential actor logins from an IP address
      located in Hainan, China that was used to remotely access and
      administer the servers, and interact with malware deployed at
      victim organizations.
    • Malware command and control
      check-ins from victim organizations in the education, aviation,
      chemical, defense, government, maritime, and technology sectors
      across multiple regions. FireEye has notified all of the victims
      that we were able to identify.
  • The malware
    present on the servers included both new families (DADBOD, EVILTECH)
    and previously identified malware families (AIRBREAK, EVILTECH,

Compromises of Cambodian Election Entities

Analysis of command and control logs on the servers revealed
compromises of multiple Cambodian entities, primarily those relating
to the upcoming July 2018 elections. In addition, a separate spear
phishing email analyzed by FireEye indicates concurrent targeting of
opposition figures within Cambodia by TEMP.Periscope.

Analysis indicated that the following Cambodian government
organizations and individuals were compromised by TEMP.Periscope:

  • National Election
    Commission, Ministry of the Interior, Ministry of Foreign Affairs
    and International Cooperation, Cambodian Senate, Ministry of
    Economics and Finance
  • Member of Parliament representing
    Cambodia National Rescue Party
  • Multiple Cambodians
    advocating human rights and democracy who have written critically of
    the current ruling party
  • Two Cambodian diplomats serving
  • Multiple Cambodian media entities

TEMP.Periscope sent a spear phish with AIRBREAK malware to
Monovithya Kem, Deputy Director-General, Public Affairs, Cambodia
National Rescue Party (CNRP), and the daughter of (imprisoned)
Cambodian opposition party leader Kem Sokha (Figure 2). The decoy
document purports to come from LICADHO (a non-governmental
organization [NGO] in Cambodia established in 1992 to promote human
rights). This sample leveraged scsnewstoday[.]com for C2.

Figure 2: Human right protection survey lure

The decoy document “Interview Questions.docx” (MD5:
ba1e5b539c3ae21c756c48a8b5281b7e) is tied to AIRBREAK downloaders of
the same name. The questions reference the opposition Cambodian
National Rescue Party, human rights, and the election (Figure 3).

Figure 3: Interview questions decoy

Infrastructure Also Used for Operations Against Private Companies

The aforementioned malicious infrastructure was also used against
private companies in Asia, Europe and North America. These companies
are in a wide range of industries, including academics, aviation,
chemical, maritime, and technology. A MURKYTOP sample from 2017 and
data contained in a file linked to chemscalere[.]com suggest that a
corporation involved in the U.S. defense industrial base (DIB)
industry, possibly related to maritime research, was compromised. Many
of these compromises are in line with TEMP.Periscope’s previous
activity targeting maritime and defense industries. However, we also
uncovered the compromise of a European chemical company with a
presence in Asia, demonstrating that this group is a threat to
business worldwide, particularly those with ties to Asia.

AIRBREAK Downloaders and Droppers Reveal Lure Indicators

Filenames for AIRBREAK downloaders found on the open indexed sites
also suggest the ongoing targeting of interests associated with Asian
geopolitics. In addition, analysis of AIRBREAK downloader sites
revealed a related server that underscores TEMP.Periscope’s interest
in Cambodian politics.

The AIRBREAK downloaders in Table 1 redirect intended victims to the
indicated sites to display a legitimate decoy document while
downloading an AIRBREAK payload from one of the identified C2s. Of
note, the hosting site for the legitimate documents was not
compromised. An additional C2 domain, partyforumseasia[.]com, was
identified as the callback for an AIRBREAK downloader referencing the
Cambodian National Rescue Party.

Redirect Site (Not Malicious) AIRBREAK Downloader AIRBREAK C2 TOP_NEWS_Japan_to_Support_the_Election.js

(3c51c89078139337c2c92e084bb0904c) [Figure 4]

chemscalere[.]com [pdf]Interview-Questions.pdf.js

(e413b45a04bf5f812912772f4a14650f) [docx]Interview-Questions.docx.js


unknown Interview_Questions.docx.js


scsnewstoday[.]com Philippines-draws-three-hard-new-lines-on-china


mlcdailynews[.]com CNR.Movement.mp4.js



Table 1: AIRBREAK downloaders

Figure 4: Decoy document associated with
AIRBREAK downloader file TOP_NEWS_Japan_to_Support_the_Election.js

SCANBOX Activity Gives Hints to Future Operations

The active SCANBOX server, mlcdailynews[.]com, is hosting articles
related to the current Cambodian campaign and broader operations.
Articles found on the server indicate targeting of those with
interests in U.S.-East Asia geopolitics, Russia and NATO affairs.
Victims are likely either brought to the SCANBOX server via strategic
website compromise or malicious links in targeted emails with the
article presented as decoy material. The articles come from
open-source reporting readily available online. Figure 5 is a SCANBOX
welcome page and Table 2 is a list of the articles found on the server.

Figure 5: SCANBOX welcome page

Copied Article Topic Article Source (Not Compromised)
Leaders confident yet nervous Khmer Times
Mahathir_ ‘We want to be friendly with
PM urges voters to support CPP for peace
CPP determined to maintain Kingdom’s peace and
Bun Chhay’s wife dies at 60
Crackdown planned on boycott callers
Further floods coming to Kingdom
Kem Sokha again denied bail
PM vows to stay on as premier to quash
Iran_ Don’t trust Trump Fresh News
Kim-Trump summit_ Singapore’s role
Trump’s North Korea summit may bring peace
declaration – but at a cost
U.S. pushes NATO to ready more forces to deter
Russian threat
Interior Minister Sar Kheng warns of dirty
Phnom Penh
Another player to enter market for cashless
Donald Trump says he has ‘absolute right’ to
pardon himself but he’s done nothing wrong – Donald Trump’s
ABC News
China-funded national road inaugurated in
The Cambodia Daily
Kim and Trump in first summit session in
Asia Times
U.S. to suspend military exercises with South
Korea, Trump says
U.S. News
Rainsy defamed the King_ Hun Sen BREAKING NEWS
cambodia-opposition-leader-denied-bail-again-in-treason-case Associated Press

Table 2: SCANBOX articles copied to server

TEMP.Periscope Malware Suite

Analysis of the malware inventory contained on the three servers
found a classic suite of TEMP.Periscope payloads, including the
signature AIRBREAK, MURKYTOP, and HOMEFRY. In addition, FireEye’s
analysis identified new tools, EVILTECH and DADBOD (Table 3).

Malware Function Details
  • EVILTECH is a
    JavaScript sample that implements a simple RAT with support
    for uploading, downloading, and running arbitrary
  • During the infection process, EVILTECH is
    run on the system, which then causes a redirect and possibly
    the download of additional malware or connection to another
    attacker-controlled system.
DADBOD Credential
  • DADBOD is a tool
    used to steal user cookies.
  • Analysis of this
    malware is still ongoing.

Table 3: New additions to the TEMP.Periscope
malware suite

Data from Logs Strengthens Attribution to China

Our analysis of the servers and surrounding data in this latest
campaign bolsters our previous assessment that TEMP.Periscope is
likely Chinese in origin. Data from a control panel access log
indicates that operators are based in China and are operating on
computers with Chinese language settings.

A log on the server revealed IP addresses that had been used to log
in to the software used to communicate with malware on victim
machines. One of the IP addresses,, is located in
Hainan, China. Other addresses belong to virtual private servers, but
artifacts indicate that the computers used to log in all cases are
configured with Chinese language settings.

Outlook and Implications

The activity uncovered here offers new insight into TEMP.Periscope’s
activity. We were previously aware of this actor’s interest in
maritime affairs, but this compromise gives additional indications
that it will target the political system of strategically important
countries. Notably, Cambodia has served as a reliable supporter of
China’s South China Sea position in international forums such as ASEAN
and is an important partner. While Cambodia is rated as Authoritarian
by the Economist’s Democracy Index, the recent surprise upset of the
ruling party in Malaysia may motivate China to closely monitor
Cambodia’s July 29 elections.

The targeting of the election commission is particularly
significant, given the critical role it plays in facilitating voting.
There is not yet enough information to determine why the organization
was compromised – simply gathering intelligence or as part of a more
complex operation. Regardless, this incident is the most recent
example of aggressive nation-state intelligence collection on election
processes worldwide.

We expect TEMP.Periscope to continue targeting a wide range of
government and military agencies, international organizations, and
private industry. However focused this group may be on maritime
issues, several incidents underscore their broad reach, which has
included European firms doing business in Southeast Asia and the
internal affairs of littoral nations. FireEye expects TEMP.Periscope
will remain a virulent threat for those operating in the area for the
foreseeable future.

Go to Source
Author: Scott Henderson

RIG Exploit Kit Delivering Monero Miner Via PROPagate Injection Technique


Through FireEye Dynamic Threat Intelligence (DTI), we observed RIG
Exploit Kit (EK) delivering a dropper that leverages the PROPagate
injection technique
to inject code that downloads and executes a
Monero miner (similar activity has been reported by Trend
). Apart from leveraging a relatively lesser known injection
technique, the attack chain has some other interesting properties that
we will touch on in this blog post.

Attack Chain

The attack chain starts when the user visits a compromised website
that loads the RIG EK landing page in an iframe. The RIG EK uses
various techniques to deliver the NSIS (Nullsoft Scriptable Install
System) loader, which leverages the PROPagate injection technique to
inject shellcode into explorer.exe. This shellcode executes the next
payload, which downloads and executes the Monero miner. The flow chart
for the attack chain is shown in Figure 1.

Figure 1: Attack chain flow chart

Exploit Kit Analysis

When the user visits a compromised site that is injected with an
iframe, the iframe loads the landing page. The iframe injected into a
compromised website is shown in Figure 2.

Figure 2: Injected iframe

The landing page contains three different JavaScripts snippets, each
of which uses a different technique to deliver the payload. Each of
these are not new techniques, so we will only be giving a brief
overview of each one in this post.

JavaScript 1

The first JavaScript has a function, fa, which returns a VBScript
that will be executed using the execScript function, as shown by the
code in Figure 3.

Figure 3: JavaScript 1 code snippet

The VBScript exploits CVE-2016-0189
which allows it to download the payload and execute it using the code
snippet seen in Figure 4.

Figure 4: VBScript code snippet

JavaScript 2

The second JavaScript contains a function that will retrieve
additional JavaScript code and append this script code to the HTML
page using the code snippet seen in Figure 5.

Figure 5: JavaScript 2 code snippet

This newly appended JavaScript exploits CVE-2015-2419
which utilizes a vulnerability in JSON.stringify. This script
obfuscates the call to JSON.stringify by storing pieces of the exploit
in the variables shown in Figure 6.

Figure 6: Obfuscation using variables

Using these variables, the JavaScript calls JSON.stringify with
malformed parameters in order to trigger CVE-2015-2419 which in turn
will cause native code execution, as shown in Figure 7.

Figure 7: Call to JSON.Stringify

JavaScript 3

The third JavaScript has code that adds additional JavaScript,
similar to the second JavaScript. This additional JavaScript adds a
flash object that exploits CVE-2018-4878,
as shown in Figure 8.

Figure 8: JavaScript 3 code snippet

Once the exploitation is successful, the shellcode invokes a command
line to create a JavaScript file with filename u32.tmp, as shown in
Figure 9.

Figure 9: WScript command line

This JavaScript file is launched using WScript, which downloads the
next-stage payload and executes it using the command line in Figure 10.

Figure 10: Malicious command line

Payload Analysis

For this attack, the actor has used multiple payloads and
anti-analysis techniques to bypass the analysis environment. Figure 11
shows the complete malware activity flow chart.

Figure 11: Malware activity flow chart

Analysis of NSIS Loader (SmokeLoader)

The first payload dropped by the RIG EK is a compiled NSIS
executable famously known as SmokeLoader. Apart from NSIS files, the
payload has two components: a DLL, and a data file (named ‘kumar.dll’
and ‘abaram.dat’ in our analysis case). The DLL has an export function
that is invoked by the NSIS executable. This export function has code
to read and decrypt the data file, which yields the second stage
payload (a portable executable file).

The DLL then spawns itself (dropper) in SUSPENDED_MODE and injects
the decrypted PE using process hollowing.

Analysis of Injected Code (Second Stage Payload)

The second stage payload is a highly obfuscated executable. It
consists of a routine that decrypts a chunk of code, executes it, and
re-encrypts it.

At the entry point, the executable contains code that checks the OS
major version, which it extracts from the Process Environment Block
(PEB). If the OS version value is less than 6 (prior to Windows
Vista), the executable terminates itself. It also contains code that
checks whether the executable is in debugged mode, which it extracts
from offset 0x2 of the PEB. If the BeingDebugged flag is set,
the executable terminates itself.

The malware also implements an Anti-VM check by opening the registry
key HKLMSYSTEMControlSet001ServicesDiskEnum with value 0.

It checks whether the registry value data contains any of the
strings: vmware, virtual, qemu, or xen.  Each of these strings is
indictative of virtual machines

After running the anti-analysis and environment check, the malware
starts executing the core code to perform the malicious activity.

The malware uses the PROPagate
injection method
to inject and execute the code in a targeted
process. The PROPagate method is similar to the SetWindowLong
injection technique. In this method, the malware uses the SetPropA
function to modify the callback for UxSubclassInfo and cause the
remote process to execute the malicious code.

This code injection technique only works for a process with lesser
or equal integrity level. The malware first checks whether the
integrity of the current running process is medium integrity level
(2000, SECURITY_MANDATORY_MEDIUM_RID). Figure 12 shows the code snippet.

Figure 12: Checking integrity level of
current process

If the process is higher than medium integrity level, then the
malware proceeds further. If the process is lower than medium
integrity level, the malware respawns itself with medium integrity.

The malware creates a file mapping object and writes the dropper
file path to it and the same mapping object is accessed by injected
code, to read the dropper file path and delete the dropper file. The
name of the mapping object is derived from the volume serial number of
the system drive and a XOR operation with the hardcoded value (Figure 13).

File Mapping Object Name = “Volume Serial Number” + “Volume Serial
Number” XOR 0x7E766791

Figure 13: Creating file mapping object name

The malware then decrypts the third stage payload using XOR and
decompresses it with RTLDecompressBuffer. The third stage payload is
also a PE executable, but the author has modified the header of the
file to avoid it being detected as a PE file in memory scanning. After
modifying several header fields at the start of decrypted data, we can
get the proper executable header (Figure 14).

Figure 14: Injected executable without
header (left), and with header (right)

After decrypting the payload, the malware targets the shell process,
explorer.exe, for malicious code injection. It uses GetShellWindow and
GetWindowThreadProcessId APIs to get the shell window’s thread ID
(Figure 15).

Figure 15: Getting shell window thread ID

The malware injects and maps the decrypted PE in a remote process
(explorer.exe). It also injects shellcode that is configured as a
callback function in SetPropA.

After injecting the payload into the target process, it uses
EnumChild and EnumProps functions to enumerate all entries in the
property list of the shell window and compares it with UxSubclassInfo

After finding the UxSubclassInfo property of the shell window, it
saves the handle info and uses it to set the callback function through SetPropA.

SetPropA has three arguments, the third of which is data. The
callback procedure address is stored at the offset 0x14 from the
beginning of data. Malware modifies the callback address with the
injected shellcode address (Figure 16).

Figure 16: Modifying callback function

The malware then sends a specific message to the window to execute
the callback procedure corresponding to the UxSubclassInfo property,
which leads to the execution of the shellcode.

The shellcode contains code to execute the address of the entry
point of the injected third stage payload using CreateThread. It then
resets the callback for SetPropA, which was modified by malware during
PROPagate injection. Figure 17 shows the code snippet of the injected shellcode.

Figure 17: Assembly view of injected shellcode

Analysis of Third Stage Payload

Before executing the malicious code, the malware performs
anti-analysis checks to make sure no analysis tool is running in the
system. It creates two infinitely running threads that contain code to
implement anti-analysis checks.

The first thread enumerates the processes using
CreateToolhelp32Snapshot and checks for the process names generally
used in analysis. It generates a DWORD hash value from the process
name using a custom operation and compares it with the array of
hardcoded DWORD values. If the generated value matches any value in
the array, it terminates the corresponding process.

The second thread enumerates the windows using EnumWindows. It uses
GetClassNameA function to extract the class name associated with the
corresponding window. Like the first thread, it generates a DWORD hash
value from the class name using a custom operation and compares it
with the array of hardcoded DWORD values. If the generated value
matches any value in the array, it terminates the process related to
the corresponding window.

Other than these two anti-analysis techniques, it also has code to
check the internet connectivity by trying to reach the URL: www.msftncsi[.]com/ncsi.txt.

To remain persistent in the system, the malware installs a scheduled
task and a shortcut file in %startup% folder. The scheduled task is
named “Opera Scheduled Autoupdate {Decimal Value of GetTickCount()}”.

The malware then communicates with the malicious URL to download the
final payload, which is a Monero miner. It creates a MD5 hash value
using Microsoft CryptoAPIs from the computer name and the volume
information and sends the hash to the server in a POST request. Figure
18 shows the network communication.

Figure 18: Network communication

The malware then downloads the final payload, the Monero miner, from
the server and installs it in the system.


Although we have been observing a decline in Exploit Kit activity,
attackers are not abandoning them altogether. In this blog post, we
explored how RIG EK is being used with various exploits to compromise
endpoints. We have also shown how the NSIS Loader leverages the lesser
known PROPagate process injection technique, possibly in an attempt to
evade security products.

FireEye MVX and the FireEye Endpoint Security (HX) platform detect
this attack at several stages of the attack chain.


We would like to thank Sudeep Singh and Alex Berry for their
contributions to this blog post.

Go to Source
Author: Sudhanshu Dubey

A Totally Tubular Treatise on TRITON and TriStation


In December 2017, FireEye’s Mandiant discussed an
incident response involving the TRITON
. The TRITON attack and many of the publicly discussed
ICS intrusions involved routine techniques where the threat actors
used only what is necessary to succeed in their mission. For both
INDUSTROYER and TRITON, the attackers moved from the IT network to the
OT (operational technology) network through systems that were
accessible to both environments. Traditional malware backdoors,
Mimikatz distillates, remote desktop sessions, and other
well-documented, easily-detected attack methods were used throughout
these intrusions.

Despite the routine techniques employed to gain access to an OT
environment, the threat actors behind the TRITON malware framework
invested significant time learning about the Triconex Safety
Instrumented System (SIS) controllers and TriStation, a proprietary
network communications protocol. The investment and purpose of the
Triconex SIS controllers leads Mandiant to assess the attacker’s
objective was likely to build the capability to cause physical consequences.

TriStation remains closed source and there is no official public
information detailing the structure of the protocol, raising several
questions about how the TRITON framework was developed. Did the actor
have access to a Triconex controller and TriStation 1131 software
suite? When did development first start? How did the threat actor
reverse engineer the protocol, and to what extent? What is the
protocol structure?

FireEye’s Advanced Practices Team was born to investigate adversary
methodologies, and to answer these types of questions, so we started
with a deeper look at the TRITON’s own Python scripts.


  • TRITON – Malware
    framework designed to operate Triconex SIS controllers via the
    TriStation protocol.
  • TriStation – UDP network protocol
    specific to Triconex controllers.
  • TRITON threat actor – The
    human beings who developed, deployed and/or operated TRITON.

Diving into TRITON’s Implementation of TriStation

TriStation is a proprietary network protocol and there is no public
documentation detailing its structure or how to create software
applications that use TriStation. The current TriStation UDP/IP
protocol is little understood, but natively implemented through the
TriStation 1131 software suite. TriStation operates by UDP over port
1502 and allows for communications between designated masters (PCs
with the software that are “engineering workstations”) and slaves
(Triconex controllers with special communications modules) over a network.

To us, the Triconex systems, software and associated terminology
sound foreign and complicated, and the TriStation protocol is no
different. Attempting to understand the protocol from ground zero
would take a considerable amount of time and reverse engineering
effort – so why not learn from TRITON itself? With the TRITON
framework containing TriStation communication functionality, we
pursued studying the framework to better understand this mysterious
protocol. Work smarter, not harder, amirite?

has a multitude of functionalities, but we started with
the basic components:

  • TS_cnames.pyc # Compiled
    at: 2017-08-03 10:52:33
  • TsBase.pyc # Compiled at:
    2017-08-03 10:52:33
  • TsHi.pyc # Compiled at: 2017-08-04
  • TsLow.pyc # Compiled at: 2017-08-03 10:46:51

TsLow.pyc (Figure 1) contains several pieces of code for error
handling, but these also present some cues to the protocol structure.

Figure 1: TsLow.pyc function print_last_error()

In the TsLow.pyc’s function for print_last_error we see error
handling for “TCM Error”. This compares the TriStation packet value at
offset 0 with a value in a corresponding array from TS_cnames.pyc
(Figure 2), which is largely used as a “dictionary” for the protocol.

Figure 2: TS_cnames.pyc TS_cst array.

From this we can infer that offset 0 of the TriStation protocol
contains message types. This is supported by an additional function,
tcm_result, which declares type, size = struct.unpack(‘<HH’,
data_received[0:4]), stating that the first two bytes should be
handled as integer type and the second two bytes are integer size of
the TriStation message. This is our first glimpse into what the threat
actor(s) understood about the TriStation protocol.

Since there are only 11 defined message types, it really doesn’t
matter much if the type is one byte or two because the second byte
will always be 0x00.

We also have indications that message type 5 is for all Execution
Command Requests and Responses, so it is curious to observe that the
TRITON developers called this “Command Reply.” (We won’t understand
this naming convention until later.)

Next we examine TsLow.pyc’s print_last_error function (Figure 3) to
look at “TS Error” and “TS_names.” We begin by looking at the ts_err
variable and see that it references ts_result.

Figure 3: TsLow.pyc function
print_last_error() with ts_err highlighted

We follow that thread to ts_result, which defines a few variables in
the next 10 bytes (Figure 4): dir, cid, cmd, cnt, unk, cks, siz =
struct.unpack(‘<, ts_packet[0:10]). Now things are heating up. What
fun. There’s a lot to unpack here, but the most interesting thing is
how this piece script breaks down 10 bytes from ts_packet into
different variables.

Figure 4: ts_result with ts_packet header
variables highlighted

Figure 5: tcm_result

Referencing tcm_result (Figure 5) we see that it defines type and
size as the first four bytes (offset 0 – 3) and tcm_result returns the
packet bytes 4:-2 (offset 4 to the end minus 2, because the last two
bytes are the CRC-16 checksum). Now that we know where tcm_result
leaves off, we know that the ts_reply “cmd” is a single byte at offset
6, and corresponds to the values in the TS_cnames.pyc array and
TS_names (Figure 6). The TRITON script also tells us that any integer
value over 100 is a likely “command reply.” Sweet.

When looking back at the ts_result packet header definitions, we
begin to see some gaps in the TRITON developer’s knowledge: dir, cid,
cmd, cnt, unk, cks, siz = struct.unpack(‘<, ts_packet[0:10]). We’re
clearly speculating based on naming conventions, but we get an
impression that offsets 4, 5 and 6 could be “direction”,
“controller ID” and “command”, respectively.
Values such as “unk” show that the developer either did not
know or did not care to identify this value. We suspect it is a
constant, but this value is still unknown to us.

Figure 6: Excerpt TS_cnames.pyc TS_names
array, which contain TRITON actor’s notes for execution command
function codes.

TriStation Protocol Packet Structure

The TRITON threat actor’s knowledge and reverse engineering effort
provides us a better understanding of the protocol. From here we can
start to form a more complete picture and document the basic
functionality of TriStation. We are primarily interested in message
type 5, Execution Command, which best illustrates the overall
structure of the protocol. Other, smaller message types will have
varying structure.

Figure 7: Sample TriStation
“Allocate Program” Execution Command, with color
annotation and protocol legend.

Corroborating the TriStation Analysis

Minute discrepancies aside, the TriStation structure detailed in
Figure 7 is supported by other public analyses. Foremost, researchers
from the Coordinated Science Laboratory (CSL) at University of
Illinois at Urbana-Champaign published a 2017 paper titled “Attack
Induced Common-Mode Failures on PLC-based Safety System in
Nuclear Power Plant”. The CSL team mentions that they used the
Triconex System Access Application (TSAA) protocol to reverse engineer
elements of the TriStation protocol. TSAA is a protocol developed by
the same company as TriStation. Unlike TriStation, the TSAA protocol
structure is described within official documentation. CSL assessed
similarities between the two protocols would exist and they leveraged
TSAA to better understand TriStation. The team’s overall research and
analysis of the general packet structure aligns with our
TRITON-sourced packet structure.

There are some awesome blog posts and whitepapers out there that
support our findings in one way or another. Writeups by Midnight
Blue Labs
, Accenture,
each explain how the TRITON framework relates to the TriStation
protocol in superb detail.

TriStation’s Reverse Engineering and TRITON’s Development

When TRITON was discovered, we began to wonder how the TRITON actor
reverse engineered TriStation and implemented it into the framework.
We have a lot of theories, all of which seemed plausible: Did they
build, buy, borrow, or steal? Or some combination thereof?

Our initial theory was that the threat actor purchased a Triconex
controller and software for their own testing and reverse engineering
from the “ground up”, although if this was the case we do
not believe they had a controller with the exact vulnerable firmware
version, else they would have had fewer problems with TRITON in
practice at the victim site. They may have bought or used a demo
version of the TriStation 1131 software, allowing them to reverse
engineer enough of TriStation for the framework. They may have stolen
TriStation Python libraries from ICS companies, subsidiaries or system
integrators and used the stolen material as a base for TriStation and
TRITON development. But then again, it is possible that they borrowed
TriStation software, Triconex hardware and Python connectors from
government-owned utility that was using them legitimately.

Looking at the raw TRITON code, some of the comments may appear
oddly phrased, but we do get a sense that the developer is clearly
using many of the right vernacular and acronyms, showing smarts on PLC
programming. The TS_cnames.pyc script contains interesting typos such
as ‘Set lable’, ‘Alocate network accepted’, ‘Symbol table ccepted’ and
‘Set program information reponse’. These appear to be normal human
error and reflect neither poor written English nor laziness in coding.
The significant amount of annotation, cascading logic, and robust
error handling throughout the code suggests thoughtful development and
testing of the framework. This complicates the theory of “ground
up” development, so did they base their code on something else?

While learning from the TriStation functionality within TRITON, we
continued to explore legitimate TriStation software. We began our
search for “TS1131.exe” and hit dead ends sorting through
TriStation DLLs until we came across a variety of TriStation utilities
in MSI form. We ultimately stumbled across a juicy archive containing
“Trilog v4.” Upon further inspection, this file installed
“TriLog.exe,” which the original TRITON executable mimicked,
and a couple of supporting DLLs, all of which were timestamped around
August 2006.

When we saw the DLL file description “Tricon Communications
Interface” and original file name “TricCom.DLL”, we
knew we were in the right place. With a simple look at the file
strings, “BAZINGA!” We struck gold.

File Name tr1com40.dll
MD5 069247DF527A96A0E048732CA57E7D3D
Size 110592
Compile Date 2006-08-23
File Description Tricon Communications Interface
Product Name TricCom Dynamic Link Library
File Version 4.2.441
Original File Name TricCom.DLL
Copyright Copyright © 1993-2006 Triconex Corporation

The tr1com40.DLL is exactly what you would expect to see in a custom
application package. It is a library that helps support the
communications for a Triconex controller. If you’ve pored over TRITON
as much as we have, the moment you look at strings you can see the
obvious overlaps between the legitimate DLL and TRITON’s own TS_cnames.pyc.

Figure 8: Strings excerpt from tr1com40.DLL

Each of the execution command “error codes” from
TS_cnames.pyc are in the strings of tr1com40.DLL (Figure 8). We see
“An MP has re-educated” and “Invalid Tristation I
command”. Even misspelled command strings verbatim such as
“Non-existant data item” and “Alocate network
accepted”. We also see many of the same unknown values. What is
obvious from this discovery is that some of the strings in TRITON are
likely based on code used in communications libraries for Trident and
Tricon controllers.

In our brief survey of the legitimate Triconex Corporation binaries,
we observed a few samples with related string tables.

Pe:dllname Compile Date Reference CPP Strings Code
Lagcom40.dll 2004/11/19 $Workfile:   LAGSTRS.CPP  $ $Modtime:   Jul 21
1999 17:17:26  $ $Revision:   1.0
Tr1com40.dll 2006/08/23 $Workfile:   TR1STRS.CPP  $ $Modtime:   May 16
2006 09:55:20  $ $Revision:   1.4
Tridcom.dll 2008/07/23 $Workfile:   LAGSTRS.CPP  $ $Modtime:   Jul 21
1999 17:17:26  $ $Revision:   1.0
Triccom.dll 2008/07/23 $Workfile:   TR1STRS.CPP  $ $Modtime:   May 16
2006 09:55:20  $ $Revision:   1.4
Tridcom.dll 2010/09/29 $Workfile:   LAGSTRS.CPP  $ $Modtime:   Jul 21
1999 17:17:26  $ $Revision:   1.0
Tr1com.dll 2011/04/27 $Workfile:   TR1STRS.CPP  $ $Modtime:   May 16
2006 09:55:20  $ $Revision:   1.4
Lagcom.dll 2011/04/27 $Workfile:   LAGSTRS.CPP  $ $Modtime:   Jul 21
1999 17:17:26  $ $Revision:   1.0
Triccom.dll 2011/04/27 $Workfile:   TR1STRS.CPP  $ $Modtime:   May 16
2006 09:55:20  $ $Revision:   1.4

We extracted the CPP string tables in TR1STRS and LAGSTRS and the
TS_cnames.pyc TS_names array from TRITON, and compared the 210, 204,
and 212 relevant strings from each respective file.

TS_cnames.pyc TS_names and tr1com40.dll share 202 of 220 combined
table strings. The remaining strings are unique to each, as seen here:

TS_cnames.TS_names (2017 pyc) Tr1com40.dll (2006 CPP)
Go to DOWNLOAD mode <200>
Not set <209>
Unk75 Bad message from module
Unk76 Bad message type
Unk77 Bad TMI version number
Unk78 Module did not respond
Unk79 Open Connection: Invalid SAP %d
Unk81 Unsupported message for this TMI version
Wrong command

TS_cnames.pyc TS_names and Tridcom.dll (1999 CPP) shared only 151 of
268 combined table strings, showing a much smaller overlap with the
seemingly older CPP library. This makes sense based on the context
that Tridcom.dll is meant for a Trident controller, not a Tricon
controller. It does seem as though Tr1com40.dll and TR1STRS.CPP code
was based on older work.

We are not shocked to find that the threat actor reversed legitimate
code to bolster development of the TRITON framework. They want to work
smarter, not harder, too. But after reverse engineering legitimate
software and implementing the basics of the TriStation, the threat
actors still had an incomplete understanding of the protocol. In
TRITON’s TS_cnames.pyc we saw “Unk75”, “Unk76”,
“Unk83” and other values that were not present in the
tr1com40.DLL strings, indicating that the TRITON threat actor may have
explored the protocol and annotated their findings beyond what they
reverse engineered from the DLL. The gaps in TriStation implementation
show us why the actors encountered problems interacting with the
Triconex controllers when using TRITON in the wild.

You can see more of the Trilog and Triconex DLL files on VirusTotal.

Item Name MD5 Description
Tr1com40.dll 069247df527a96a0e048732ca57e7d3d Tricom Communcations DLL e6a3c93a6d433cbaf6f573b6c09d76c4 Parent of Tr1com40.dll
Trilog v4.1.360R 13a3b83ba2c4236ca59aba679941c8a5 RAR Archive of TriLog
TridCom.dll 5c2ed617fdec4779cb33c89082a43100 Trident Communications


Seeing Triconex systems targeted with malicious intent was new to
the world six months ago. Moving forward it would be reasonable to
anticipate additional frameworks, such as TRITON, designed for usage
against other SIS controllers and associated technologies. If Triconex
was within scope, we may see similar attacker methodologies affecting
the dominant industrial safety technologies.

Basic security measures do little to thwart truly persistent threat
actors and monitoring only IT networks is not an ideal situation.
Visibility into both the IT and OT environments is critical for
detecting the various stages of an ICS intrusion. Simple detection
concepts such as baseline deviation can provide insight into abnormal activity.

While the TRITON framework was actively in use, how many traditional
ICS “alarms” were set off while the actors tested their exploits and
backdoors on the Triconex controller? How many times did the
TriStation protocol, as implemented in their Python scripts, fail or
cause errors because of non-standard traffic? How many TriStation UDP
pings were sent and how many Connection Requests? How did these
statistics compare to the baseline for TriStation traffic? There are
no answers to these questions for now. We believe that we can identify
these anomalies in the long run if we strive for increased visibility
into ICS technologies.

We hope that by holding public discussions about ICS technologies,
the Infosec community can cultivate closer relationships with ICS
vendors and give the world better insight into how attackers move from
the IT to the OT space. We want to foster more conversations like this
and generally share good techniques for finding evil. Since most of
all ICS attacks involve standard IT intrusions, we should probably
come together to invent and improve any guidelines for how to monitor
PCs and engineering workstations that bridge the IT and OT networks.
We envision a world where attacking or disrupting ICS operations costs
the threat actor their cover, their toolkits, their time, and their
freedom. It’s an ideal world, but something nice to shoot for.

Thanks and Future Work

There is still much to do for TRITON and TriStation. There are many
more sub-message types and nuances for parsing out the nitty gritty
details, which is hard to do without a controller of our own. And
although we’ve published much of what we learned about the TriStation
here on the blog, our work will continue as we continue our study of
the protocol.

Thanks to everyone who did so much public research on TRITON and
TriStation. We have cited a few individuals in this blog post, but
there is a lot more community-sourced information that gave us clues
and leads for our research and testing of the framework and protocol.
We also have to acknowledge the research performed by the TRITON
attackers. We borrowed a lot of your knowledge about TriStation from
the TRITON framework itself.

Finally, remember that we’re here to collaborate. We think most of
our research is right, but if you notice any errors or omissions, or
have ideas for improvements, please contact:

Recommended Reading

Appendix A: TriStation Message Type Codes

The following table consists of hex values at offset 0 in the
TriStation UDP packets and the associated dictionary definitions,
extracted verbatim from the TRITON framework in library TS_cnames.pyc.

Value at 0x0 Message Type
1 Connection Request
2 Connection Response
3 Disconnect Request
4 Disconnect Response
5 Execution Command
6 Ping Command
7 Connection Limit Reached
8 Not Connected
9 MPS Are Dead
10 Access Denied
11 Connection Failed

Appendix B: TriStation Execution Command Function Codes

The following table consists of hex values at offset 6 in the
TriStation UDP packets and the associated dictionary definitions,
extracted verbatim from the TRITON framework in library TS_cnames.pyc.

Value at 0x6 TS_cnames String
0 0: ‘Start download all’,
1 1: ‘Start download change’,
2 2: ‘Update configuration’,
3 3: ‘Upload configuration’,
4 4: ‘Set I/O addresses’,
5 5: ‘Allocate network’,
6 6: ‘Load vector table’,
7 7: ‘Set calendar’,
8 8: ‘Get calendar’,
9 9: ‘Set scan time’,
A 10: ‘End download all’,
B 11: ‘End download change’,
C 12: ‘Cancel download change’,
D 13: ‘Attach TRICON’,
E 14: ‘Set I/O address limits’,
F 15: ‘Configure module’,
10 16: ‘Set multiple point values’,
11 17: ‘Enable all points’,
12 18: ‘Upload vector table’,
13 19: ‘Get CP status ‘,
14 20: ‘Run program’,
15 21: ‘Halt program’,
16 22: ‘Pause program’,
17 23: ‘Do single scan’,
18 24: ‘Get chassis status’,
19 25: ‘Get minimum scan time’,
1A 26: ‘Set node number’,
1B 27: ‘Set I/O point values’,
1C 28: ‘Get I/O point values’,
1D 29: ‘Get MP status’,
1E 30: ‘Set retentive values’,
1F 31: ‘Adjust clock calendar’,
20 32: ‘Clear module alarms’,
21 33: ‘Get event log’,
22 34: ‘Set SOE block’,
23 35: ‘Record event log’,
24 36: ‘Get SOE data’,
25 37: ‘Enable OVD’,
26 38: ‘Disable OVD’,
27 39: ‘Enable all OVDs’,
28 40: ‘Disable all OVDs’,
29 41: ‘Process MODBUS’,
2A 42: ‘Upload network’,
2B 43: ‘Set lable’,
2C 44: ‘Configure system variables’,
2D 45: ‘Deconfigure module’,
2E 46: ‘Get system variables’,
2F 47: ‘Get module types’,
30 48: ‘Begin conversion table download’,
31 49: ‘Continue conversion table download’,
32 50: ‘End conversion table download’,
33 51: ‘Get conversion table’,
34 52: ‘Set ICM status’,
35 53: ‘Broadcast SOE data available’,
36 54: ‘Get module versions’,
37 55: ‘Allocate program’,
38 56: ‘Allocate function’,
39 57: ‘Clear retentives’,
3A 58: ‘Set initial values’,
3B 59: ‘Start TS2 program download’,
3C 60: ‘Set TS2 data area’,
3D 61: ‘Get TS2 data’,
3E 62: ‘Set TS2 data’,
3F 63: ‘Set program information’,
40 64: ‘Get program information’,
41 65: ‘Upload program’,
42 66: ‘Upload function’,
43 67: ‘Get point groups’,
44 68: ‘Allocate symbol table’,
45 69: ‘Get I/O address’,
46 70: ‘Resend I/O address’,
47 71: ‘Get program timing’,
48 72: ‘Allocate multiple functions’,
49 73: ‘Get node number’,
4A 74: ‘Get symbol table’,
4B 75: ‘Unk75’,
4C 76: ‘Unk76’,
4D 77: ‘Unk77’,
4E 78: ‘Unk78’,
4F 79: ‘Unk79’,
50 80: ‘Go to DOWNLOAD mode’,
51 81: ‘Unk81’,
53 83: ‘Unk83’,
64 100: ‘Command rejected’,
65 101: ‘Download all permitted’,
66 102: ‘Download change permitted’,
67 103: ‘Modification accepted’,
68 104: ‘Download cancelled’,
69 105: ‘Program accepted’,
6A 106: ‘TRICON attached’,
6B 107: ‘I/O addresses set’,
6C 108: ‘Get CP status response’,
6D 109: ‘Program is running’,
6E 110: ‘Program is halted’,
6F 111: ‘Program is paused’,
70 112: ‘End of single scan’,
71 113: ‘Get chassis configuration response’,
72 114: ‘Scan period modified’,
73 115: ‘<115>’,
74 116: ‘<116>’,
75 117: ‘Module configured’,
76 118: ‘<118>’,
77 119: ‘Get chassis status response’,
78 120: ‘Vectors response’,
79 121: ‘Get I/O point values response’,
7A 122: ‘Calendar changed’,
7B 123: ‘Configuration updated’,
7C 124: ‘Get minimum scan time response’,
7D 125: ‘<125>’,
7E 126: ‘Node number set’,
7F 127: ‘Get MP status response’,
80 128: ‘Retentive values set’,
81 129: ‘SOE block set’,
82 130: ‘Module alarms cleared’,
83 131: ‘Get event log response’,
84 132: ‘Symbol table ccepted’,
85 133: ‘OVD enable accepted’,
86 134: ‘OVD disable accepted’,
87 135: ‘Record event log response’,
88 136: ‘Upload network response’,
89 137: ‘Get SOE data response’,
8A 138: ‘Alocate network accepted’,
8B 139: ‘Load vector table accepted’,
8C 140: ‘Get calendar response’,
8D 141: ‘Label set’,
8E 142: ‘Get module types response’,
8F 143: ‘System variables configured’,
90 144: ‘Module deconfigured’,
91 145: ‘<145>’,
92 146: ‘<146>’,
93 147: ‘Get conversion table response’,
94 148: ‘ICM print data sent’,
95 149: ‘Set ICM status response’,
96 150: ‘Get system variables response’,
97 151: ‘Get module versions response’,
98 152: ‘Process MODBUS response’,
99 153: ‘Allocate program response’,
9A 154: ‘Allocate function response’,
9B 155: ‘Clear retentives response’,
9C 156: ‘Set initial values response’,
9D 157: ‘Set TS2 data area response’,
9E 158: ‘Get TS2 data response’,
9F 159: ‘Set TS2 data response’,
A0 160: ‘Set program information reponse’,
A1 161: ‘Get program information response’,
A2 162: ‘Upload program response’,
A3 163: ‘Upload function response’,
A4 164: ‘Get point groups response’,
A5 165: ‘Allocate symbol table response’,
A6 166: ‘Program timing response’,
A7 167: ‘Disable points full’,
A8 168: ‘Allocate multiple functions
A9 169: ‘Get node number response’,
AA 170: ‘Symbol table response’,
C8 200: ‘Wrong command’,
C9 201: ‘Load is in progress’,
CA 202: ‘Bad clock calendar data’,
CB 203: ‘Control program not halted’,
CC 204: ‘Control program checksum error’,
CD 205: ‘No memory available’,
CE 206: ‘Control program not valid’,
CF 207: ‘Not loading a control program’,
D0 208: ‘Network is out of range’,
D1 209: ‘Not enough arguments’,
D2 210: ‘A Network is missing’,
D3 211: ‘The download time mismatches’,
D4 212: ‘Key setting prohibits this
D5 213: ‘Bad control program version’,
D6 214: ‘Command not in correct sequence’,
D7 215: ‘<215>’,
D8 216: ‘Bad Index for a module’,
D9 217: ‘Module address is invalid’,
DA 218: ‘<218>’,
DB 219: ‘<219>’,
DC 220: ‘Bad offset for an I/O point’,
DD 221: ‘Invalid point type’,
DE 222: ‘Invalid Point Location’,
DF 223: ‘Program name is invalid’,
E0 224: ‘<224>’,
E1 225: ‘<225>’,
E2 226: ‘<226>’,
E3 227: ‘Invalid module type’,
E4 228: ‘<228>’,
E5 229: ‘Invalid table type’,
E6 230: ‘<230>’,
E7 231: ‘Invalid network continuation’,
E8 232: ‘Invalid scan time’,
E9 233: ‘Load is busy’,
EA 234: ‘An MP has re-educated’,
EB 235: ‘Invalid chassis or slot’,
EC 236: ‘Invalid SOE number’,
ED 237: ‘Invalid SOE type’,
EE 238: ‘Invalid SOE state’,
EF 239: ‘The variable is write protected’,
F0 240: ‘Node number mismatch’,
F1 241: ‘Command not allowed’,
F2 242: ‘Invalid sequence number’,
F3 243: ‘Time change on non-master TRICON’,
F4 244: ‘No free Tristation ports’,
F5 245: ‘Invalid Tristation I command’,
F6 246: ‘Invalid TriStation 1131 command’,
F7 247: ‘Only one chassis allowed’,
F8 248: ‘Bad variable address’,
F9 249: ‘Response overflow’,
FA 250: ‘Invalid bus’,
FB 251: ‘Disable is not allowed’,
FC 252: ‘Invalid length’,
FD 253: ‘Point cannot be disabled’,
FE 254: ‘Too many retentive variables’,
256: ‘Unknown reject code’

Go to Source
Author: Steve Miller

Shining a Light on OAuth Abuse with PwnAuth


Spear phishing attacks are seen as one of the biggest cyber threats
to an organization. It only takes one employee to enter their
credentials or run some malware for an entire organization to become
compromised. As such, companies devote significant resources to
preventing credential harvesting and payload-driven social engineering
attacks. Less attention, however, has been paid to a non-traditional,
but just as dangerous, method of social engineering: OAuth abuse. In
an OAuth abuse attack, a victim authorizes a third-party application
to access their account. Once authorized, the application can access
the user’s data without the need for credentials and bypassing any
two-factor authentication that may be in place.

Today, I’m releasing PwnAuth, a platform to
allow organizations and penetration testers an opportunity to test
their ability to detect and respond to OAuth abuse social engineering
campaigns. In releasing the tool, we hope to increase awareness about
this threat, improve the security community’s ability to detect it,
and provide countermeasures for defenders.

Head over to our GitHub to start using PwnAuth.

What is OAuth?

OAuth 2.0 is described as “An open protocol to allow secure
authorization in a simple and standard method from web, mobile and
desktop applications…” It has become the de facto protocol that
major Internet companies such as Amazon, Google, Facebook, and
Microsoft use to facilitate granting third-party applications access
to user data. An application that accesses your Microsoft OneDrive to
allow for easy file sharing is an example of an application that would
leverage OAuth.

Let’s use an application accessing OneDrive as an example to define
some roles in an OAuth authorization flow:

The Application, or “Client”

The third-party application that is requesting access. In this case,
the application that wishes to access your OneDrive files is the “Client.”

The API “Resource”

The target application the “Client” wishes to access. In
this case, the Microsoft OneDrive API endpoint is the “Resource.”

The “Resource Owner”

The person granting access to a portion of their account. In this
case, you.

The Authorization Server

The Authorization Server presents the interface that the Resource
Owner uses to give or deny consent. The server could be the same as
the API Resource or a different component. In this case, the Microsoft
login portal is the “Authorization Server”.


The Scope is defined as the type of access that the third-party
application is requesting. Most API Resources will define a set of
scopes that applications can request. This is similar to the
permissions that an Android phone application would request on
installation. In this example, the application may request access to
your OneDrive files and user profile.

OAuth 2.0 provides several different authorization “grant
types” to facilitate the different applications that we, as
users, interact with. For the purpose of this post, we are interested
in the “Authorization Code” grant type, which is used by web
applications implementing OAuth. The following is an example
authorization flow:

1.  A “Consent” link is created that directs the Resource
Owner to the Authorization Server with parameters identifying the
Application and the scopes requested.

2.  The Resource Owner will be presented with an authorization
prompt, stating the application name and requested scopes. The
Resource Owner has the option to approve or deny this authorization request.

3.  Upon approval, the Authorization Server will redirect back to
the Application with an authorization code.

HTTP/1.1 200
Content-Type: application/json
Pragma: no-cache


4.  The Application can then use the authorization code and request
an access token from the Authorization Server. Access tokens can be
used for a set duration of time to access the user’s data from the API
Resource, without any further action by the Resource Owner.

Room For Abuse

OAuth applications provide an ideal vector through which attackers
could compromise a target and harvest confidential data such as email,
contacts, and files. An attacker could create a malicious application
and use the obtained access tokens to retrieve victims’ account data
via the API Resource. The access tokens do not require knowledge of
the user’s password, and bypass any two-factor enforcement. Further,
the only way to remove an attacker’s access is to explicitly revoke
access to the OAuth application. In order to obtain OAuth tokens, an
attacker would need to convince a victim to click a “Consent
link” and approve the application via social engineering. Because
all victim interaction is on sites owned by the legitimate Resource
Provider (e.g. Microsoft), it can be hard for an untrained user to
differentiate between a legitimate OAuth application and a malicious one.

Though likely not the first instance of such campaigns, OAuth abuse
first came to the media’s attention during the 2016 presidential
election. FireEye wrote about APT28’s usage of OAuth abuse to gain
access to emails of U.S. politicians in our M-TRENDS
2017 report
. Since then, FireEye has seen the technique
spread to commodity worms
seeking to spread across Gmail.


PwnAuth is a web application framework I wrote to make it easier for
organizations to test their ability to detect and respond to OAuth
abuse campaigns. The web application provides penetration testers with
an easy-to-use UI to manage malicious OAuth applications, store
gathered OAuth tokens, and interact with API Resources. The
application UI and framework are designed to be easily extendable to
other API Resources through the creation of additional modules. While
any cloud environment that allows OAuth applications could be
targeted, currently PwnAuth ships with a module to support malicious
Office 365 applications that will capture OAuth tokens and facilitate
interaction with the Microsoft Graph API using those captured tokens.
The Office 365 module itself could be further extended, but currently
provides the following:

  • Reading mail
  • Searching the user’s mailbox
  • Reading the
    user’s contacts
  • Downloading messages and attachments
  • Searching OneDrive and downloading files
  • Sending
    messages on behalf of the user

The interface is designed to be intuitive and user-friendly. The
first step to using PwnAuth would be to create a Microsoft
Application. That information must then be entered into PwnAuth
(Figure 1).

Figure 1: Importing a Microsoft App into PwnAuth

Once configured, you can use the generated “Authorization
URL” to phish potential victims. When clicked, PwnAuth will
capture victim OAuth tokens for later use. An example victim listing
is shown in Figure 2.

Figure 2: Listing victim users in PwnAuth

Once PwnAuth has captured a victim’s OAuth token, you can begin to
access their data. Use PwnAuth to query the victim’s mailbox for all
messages containing the string “password”, for example
(Figure 3).

Figure 3: Searching the mailbox of a victim

See the GitHub
for more information on usage.


Our FireEye technology stack includes network-based signatures to
detect potentially malicious OAuth consent URLs. Attackers tend to
include certain scopes in malicious apps that can be detected and
flagged. Organizations with social engineering training programs can
add OAuth abuse scenarios to their existing programs to better educate
users about this attacker vector. Additionally, organizations can take
steps to limit the potential impact of malicious OAuth applications
and increase their detection capabilities. The options available to an
organization vary greatly depending on the API Resource, but, in
general, include:

  • Limit the API scopes
    third-party apps can request.
  • Disable third-party apps in
    an organization.
  • Implement a whitelist or blacklist for
  • Query an organization’s user base for all
    consented applications.
  • Log any user consent events and
    report suspicious activity.

Office 365 in particular offers some options for administrators:

I have created a collection of scripts to assist administrators in
hunting for
malicious OAuth applications
in cloud environments. Currently
there is a script to investigate Office 365 tenants with plans to add
other cloud environments.


OAuth abuse attacks are a dangerous and non-traditional phishing
technique that attackers can use to gain access to an organization’s
confidential data. As we move more services to the cloud,
organizations should be careful to lock down third-party application
access and ensure that their monitoring and detection strategy covers
application consent grants. Organizations and security professionals
can use PwnAuth to
test their ability to detect and respond to this new type of attack.

Head over to our GitHub and start using PwnAuth today.

Go to Source
Author: Douglas Bienstock

Metamorfo Campaigns Targeting Brazilian Users

FireEye Labs recently identified several widespread malspam (malware
spam) campaigns targeting Brazilian companies with the goal of
delivering banking Trojans. We are referring to these campaigns as
Metamorfo. Across the stages of these campaigns, we have observed the
use of several tactics and techniques to evade detection and deliver
the malicious payload. In this blog post we dissect two of the main
campaigns and explain how they work.

Campaign #1

The kill chain starts with an email containing an HTML attachment
with a refresh tag that uses a Google URL shortener as the
target. Figure 1 shows a sample email, and Figure 2 show the contents
of the HTML file.

Figure 1: Malicious Email with HTML Attachment

Figure 2: Contents of HTML File

When the URL is loaded, it redirects the victim to a cloud storage
site such as GitHub, Dropbox, or Google Drive to download a ZIP
file. An example is shown in Figure 3.

Figure 3: URL Shortener Redirects to
Github Link

The ZIP archive contains a malicious portable executable (PE) file
with embedded HTML application (HTA). The user has to unzip the
archive and double-click the executable for the infection chain to
continue. The PE file is a simple HTA script compiled into an
executable. When the user double-clicks the executable, the malicious
HTA file is extracted to %temp% and executed by mshta.exe.

The HTA script (Figure 4) contains VBS code that fetches a second
blob of VBS code encoded in base64 form from hxxp:///ilha/pz/logs.php.

Figure 4: Contents of HTA File

After the second stage of VBS is decoded (Figure 5 and Figure 6),
the script downloads the final stage from hxxp:///28022018/

Figure 5: Contents of Decoded VBS

Figure 6: More Contents of Decoded VBS

The downloaded ZIP file contains four files. Two are PE files. One
is a legitimate Windows tool, pvk2pfx.exe, that is abused
for DLL side-loading. One is the malicious banking Trojan as the DLL.

The VBS code unzips the archive, changes the extension of the
legitimate Windows tool from .png to .exe, and renames the malicious
DLL as cryptui.dll. The VBS code also creates a file in
C:UsersPublicAdministradorcar.dat with random strings. These
random strings are used to name the Windows tool, which is then
executed. Since this tool depends on a legitimate DLL named
cryptui.dll, the search order path will find the malicious Trojan with
the same name in the same directory and load it into its process space.

In Q4 of 2017, a similar malspam campaign delivered the same banking
Trojan by using an embedded JAR file attached in the email instead of
an HTML attachment. On execution, the Java code downloaded a ZIP
archive from a cloud file hosting site such as Google Drive, Dropbox,
or Github. The ZIP archive contained a legitimate Microsoft tool and
the malicious Trojan.

Banking Trojan Analysis

The Trojan expects to be located in the hardcoded directory
C:\Users\PublicAdministrador\ along with three other files to
start execution. As seen in Figure 7, these files are:

  • car.dat (randomly
    generated name given to Windows tool)
  • i4.dt (VBS script
    that downloads the same zip file)
  • id (ID given to
  • cryptui.dll (malicious Trojan)

Figure 7: Contents of ZIP Archive


The string found in the file
C:\Users\Public\Administrador\car.dat is extracted and used to add
the registry key
SoftwareMicrosoftWindowsCurrentVersionRun for persistence, as shown in Figure 8.

Figure 8: Reading from car.dat File

The sample also looks for a file named i4.dt in the same directory
and extracts the contents of it, renames the file to icone.vbs, and
creates a new persistent key (Figure 9) in
SoftwareMicrosoftWindowsCurrentVersionRun to open this file.

Figure 9: Persistence Keys

The VBS code in this file (Figure 10) has the ability to recreate
the whole chain and download the same ZIP archive.

Figure 10: Contents of VBS Script

Next, the Trojan searches for several folders in the Program Files
directories, including:

  • C:\Program
  • C:\Program Files\AVAST Software
  • C:\Program Files\Diebold\Warsaw
  • C:\Program
  • C:\Program Files\Java
  • C:\Program Files (x86)\scpbrad

If any of the folders are found, this information, along with the
hostname and Operating System version, is sent to a hardcoded domain
with the hardcoded User-Agent value “Mozilla/5.0 (Windows NT 6.1;
WOW64; rv:12.0) Gecko/20100101 Firefox/12.0” in the format shown in
Figure 11. The value of AT is “<host_name+OS&MD>=”.

Figure 11: Network Traffic for Host Enumeration

The sample iterates through the running processes, kills the
following, and prevents them from launching:

  • msconfig.exe
  • TASKMGR.exe
  • regedit.exe
  • ccleaner64.exe
  • taskmgr.exe
  • itauaplicativo.exe

Next, it uses GetForegroundWindow to get a handle to the window the
user is viewing and GetWindowText to extract the title of the window.
The title is compared against a hardcoded list of Brazilian banking
and digital coin sites. The list is extensive and includes major
organizations and smaller entities alike.

If any of those names are found and the browser is one of the
following, the Trojan will terminate that browser.

  • firefox.exe
  • chrome.exe
  • opera.exe
  • safari.exe

The folder C:UsersPublicAdministradorlogs is created to store
screenshots, as well as the number of mouse clicks the user has
triggered while browsing the banking sites (Figure 12). The
screenshots are continuously saved as .jpg images.

Figure 12: Malware Capturing Mouse Clicks

Command and Control

The command and control (C2) server is selected based on the string
in the file “id”:

  • al ->
  • gr -> ‘212.237.46[.]6’
  • pz
    -> ‘87.98.146[.]34’
  • mn -> ’80.211.140[.]235′

The connection to one of the hosts is then started over raw TCP on
port 9999. The command and control communication generally follows the
pattern <|Command |>, for example:

  • ‘<|dispida|>logs>SAVE<‘ sends the screenshots
    collected in gh.txt.
  • ” is sent from C2 to
    host, and ” is sent from host to C2, to keep the
    connection alive.
  • ‘<|INFO|>’ retrieves when the
    infection first started based on the file timestamp from car.dat
    along with ‘<|>’ and the host information.

There were only four possible IP addresses that the sample analyzed
could connect to based on the strings found in the file “id”. After
further researching the associated infrastructure of the C2 (Figure
13), we were able to find potential number of victims for this
particular campaign.

Figure 13: Command and Control Server Open Directories

Inside the open directories, we were able to get the following
directories corresponding to the different active campaigns. Inside
each directory we could find statistics with the number of victims
reporting to the C2. As of 3/27/2018, the numbers were:

  • al – 843
  • ap –
  • gr – 397
  • kk – 2,153
  • mn – 296
  • pz – 536
  • tm – 187

A diagram summarizing Campaign #1 is shown in Figure 14.

Figure 14: Infection Chain of Campaign #1

Campaign #2

In the second campaign, FireEye Labs observed emails with links to
legitimate domains (such as
or compromised domains (such
as hxxps://curetusu.-industria[.]site/) that use a
refresh tag with a URL shortener as the target.
The URL shortener redirects the user to an online storage site, such
as Google Drive, Github, or Dropbox, that hosts a malicious ZIP
file. A sample phishing email is shown in Figure 15.

Figure 15: Example Phishing Email

The ZIP file contains a malicious executable written in AutoIt
(contents of this executable are shown in Figur 16). When executed by
the user, it drops a VBS file to a randomly created and named
directory (such as C:mYPdrTkCJLQPXHwoCmYPdr.vbs) and fetches
contents from the C2 server.

Figure 16: Contents of Malicious AutoIt Executable

Two files are downloaded from the C2 server. One is a legitimate
Microsoft tool and the other is a malicious DLL:

  • https[:]//panel-dark[.]com/w3af/img2.jpg
  • https[:]//panel-dark[.]com/w3af/img1.jpg

Those files are downloaded and saved into random directories named
with the following patterns:

  • <5 random chars><8 random chars><4 random chars><5 random chars>.exe
  • <5 random chars><8 random chars><4 random chars>CRYPTUI.dll

The execution chain ensures that persistence is set on the affected
system using a .lnk file in the Startup directory. The .lnk file shown
in Figure 17 opens the malicious VBS dropped on the system.

Figure 17: Persistence Key

The VBS file (Figure 18) will launch and execute the downloaded
legitimate Windows tool, which in this case is Certmgr.exe. This tool
will be abused using the DLL side loading technique. The malicious
Cryptui.dll is loaded into the program instead of the legitimate one
and executed.

Figure 18: Contents of Dropped VBS File

Banking Trojan Analysis

Like the Trojan from the first campaign, this sample is executed
through search-order hijacking. In this case, the binary abused is a
legitimate Windows tool, Certmgr.exe, that loads Cryptui.dll. Since
this tool depends on a legitimate DLL named cryptui.dll, the search
order path will find the malicious Trojan with the same name in the
same directory and load it into its process space.

The malicious DLL exports 21 functions. Only DllEntryPoint contains
real code that is necessary to start the execution of the malicious
code. The other functions return hardcoded values that serve no real purpose.

On execution, the Trojan creates a mutex called
“correria24” to allow only one instance of it to run at a time.

The malware attempts to resolve “www.goole[.]com” (most likely a
misspelling). If successful, it sends a request to
hxxp://api-api[.]com/json in order to detect the external IP of the
victim. The result is parsed and execution continues only if the
country code matches “BR”, as shown in Figure 19.

Figure 19: Country Code Check

The malware creates an empty file in %appdata%Mariapeirura on first
execution, which serves as a mutex lock, before attempting to send any
collected information to the C2 server. This is done in order to get
only one report per infected host.

The malware collects host information, base64 encodes it, and sends
it to two C2 servers. The following items are gathered from the
infected system:

  • OS name
  • OS
  • OS architecture
  • AV installed
  • List
    of banking software installed
  • IP address
  • Directory
    where malware is being executed from

The information is sent to hxxp:// (Figure 20).

Figure 20: Host Recon Data Sent to First
C2 Server

The same information is sent to panel-dark[.]com/Contador/put.php
(Figure 21).

Figure 21: Host Recon Data Sent to Second
C2 Server

The malware alters the value of registry key
to 2710 in order to change the number of milliseconds a thumbnail is
showed while hovering on the taskbar, as seen in Figure 22.

Figure 22: ExtendedUIHoverTime Registry
Key Change

Like the Trojan from the first campaign, this sample checks if the
foreground window’s title contains names of Brazilian banks and
digital coins by looking for hardcoded strings.

The malware displays fake forms on top of the banking sites and
intercepts credentials from the victims. It can also display a fake
Windows Update whenever there is nefarious activity in the background,
as seen in Figure 23.

Figure 23: Fake Form Displaying Windows Update

The sample also contains a keylogger functionality, as shown in
Figure 24.

Figure 24: Keylogger Function

Command and Control

The Trojan’s command and control command structure is identical to
the first sample. The commands are denoted by the <|Command|> syntax.

  • <|OK|> gets a list
    of banking software installed on the host.

  • is sent from C2 to host, and ” is sent from host to C2,
    to keep connection alive.
  • <|dellLemb|> deletes the
    registry key SoftwareMicrosoftInternet Explorernotes.
  • EXECPROGAM calls ShellExecute to run the application given in
    the command.
  • EXITEWINDOWS calls ExitWindowsEx.
  • NOVOLEMBRETE creates and stores data sent with the command in
    the registry key SoftwareMicrosoftInternet Explorernotes.

Figure 25: Partial List of Victims

This sample contains most of the important strings encrypted. We
provide the following script (Figure 26) in order to decrypt them.

Figure 26: String Decryption Script


The use of multi-stage infection chains makes it challenging to
research these types of campaigns all the way through.

As demonstrated by our research, the attackers are using various
techniques to evade detection and infect unsuspecting
Portuguese-speaking users with banking Trojans. The use of public
cloud infrastructure to help deliver the different stages plays a
particularly big role in delivering the malicious payload. The use of
different infection methods combined with the abuse of legitimate
signed binaries to load malicious code makes these campaigns worth highlighting.

Indicators of Compromise

Campaign #1
MD5 860fa744d8c82859b41e00761c6e25f3 PE with Embedded HTA
MD5 3e9622d1a6d7b924cefe7d3458070d98 PE with Embedded HTA
MD5 f402a482fd96b0a583be2a265acd5e74 PE with Embedded HTA
MD5 f329107f795654bfc62374f8930d1e12 PE with Embedded HTA
MD5 789a021c051651dbc9e01c5d8c0ce129 PE with Embedded HTA
MD5 68f818fa156d45889f36aeca5dc75a81 PE with Embedded HTA
MD5 c2cc04be25f227b13bcb0b1d9811e2fe cryptui.dll
MD5 6d2cb9e726c9fac0fb36afc377be3aec id
MD5 dd73f749d40146b6c0d2759ba78b1764 i4.dt
MD5 d9d1e72165601012b9d959bd250997b3 VBS file with commands to create staging directories for
MD5 03e4f8327fbb6844e78fda7cdae2e8ad pvk2pfx.exe [Legit Windows Tool]
URL hxxp://
URL hxxp:// 
C2 ibamanetibamagovbr[.]org/virada/pz/logs.php
URL sistemasagriculturagov[.]org
URL hxxp://
Campaign #2
MD5 2999724b1aa19b8238d4217565e31c8e AutoIT Dropper
MD5 181c8f19f974ad8a84b8673d487bbf0d img1.jpg [lLegit Windows Tool]
MD5 d3f845c84a2bd8e3589a6fbf395fea06 img2.jpg [Banking Trojan]
MD5 2365fb50eeb6c4476218507008d9a00b Variants of Banking Trojan
MD5 d726b53461a4ec858925ed31cef15f1e Variants of Banking Trojan
MD5 a8b2b6e63daf4ca3e065d1751cac723b Variants of Banking Trojan
MD5 d9682356e78c3ebca4d001de760848b0 Variants of Banking Trojan
MD5 330721de2a76eed2b461f24bab7b7160 Variants of Banking Trojan
MD5 6734245beda04dcf5af3793c5d547923 Variants of Banking Trojan
MD5 a920b668079b2c1b502fdaee2dd2358f Variants of Banking Trojan
MD5 fe09217cc4119dedbe85d22ad23955a1 Variants of Banking Trojan
MD5 82e2c6b0b116855816497667553bdf11 Variants of Banking Trojan
MD5 4610cdd9d737ecfa1067ac30022d793b Variants of Banking Trojan
MD5 34a8dda75aea25d92cd66da53a718589 Variants of Banking Trojan
MD5 88b808d8164e709df2ca99f73ead2e16 Variants of Banking Trojan
MD5 d3f845c84a2bd8e3589a6fbf395fea06 Variants of Banking Trojan
MD5 28a0968163b6e6857471305aee5c17e9 Variants of Banking Trojan
MD5 1285205ae5dd5fa5544b3855b11b989d Variants of Banking Trojan
MD5 613563d7863b4f9f66590064b88164c8 Variants of Banking Trojan
MD5 3dd43e69f8d71fcc2704eb73c1ea7daf Variants of Banking Trojan
C2 https[:]//panel-dark[.]com/w3af/img2.jpg
C2 https[:]//panel-dark[.]com/w3af/img1.jpg

Go to Source
Author: Edson Sierra

SANNY Malware Delivery Method Updated in Recently Observed Attacks


In the third week of March 2018, through FireEye’s Dynamic Threat
Intelligence, FireEye discovered malicious macro-based Microsoft Word
documents distributing SANNY malware to multiple governments
worldwide. Each malicious document lure was crafted in regard to
relevant regional geopolitical issues. FireEye has tracked the SANNY
malware family since 2012 and believes that it is unique to a group
focused on Korean Peninsula issues. This group has consistently
targeted diplomatic entities worldwide, primarily using lure documents
written in English and Russian.

As part of these recently observed attacks, the threat actor has
made significant changes to their usual malware delivery method. The
attack is now carried out in multiple stages, with each stage being
downloaded from the attacker’s server. Command line evasion
techniques, the capability to infect systems running Windows 10, and
use of recent User Account Control (UAC) bypass techniques have also
been added.

Document Details

The following two documents, detailed below, have been observed in
the latest round of attacks:

MD5 hash: c538b2b2628bba25d68ad601e00ad150

Original Filename: РГНФ 2018-2019.doc

The document shown in Figure 1 discusses Eurasian geopolitics as
they relate to China, as well as Russia’s security.

Figure 1: Sample document written in Russian

MD5 hash: 7b0f14d8cd370625aeb8a6af66af28ac

Original Filename: Copy of communication from Security
Council Committee (1718).doc

The document shown in Figure 2 discusses sanctions on humanitarian
operations in the Democratic People’s Republic of Korea (DPRK).

Figure 2: Sample document written in English

Macro Analysis

In both documents, an embedded macro stores the malicious command
line to be executed in the TextBox property (TextBox1.Text) of the
document. This TextBox property is first accessed by the macro to
execute the command on the system and is then overwritten to delete
evidence of the command line.

Stage 1: BAT File Download

In Stage 1, the macro leverages the legitimate Microsoft Windows
certutil.exe utility to download an encoded Windows Batch (BAT) file
from the following URL: http://more.1apps[.]com/1.txt. The macro then
decodes the encoded file and drops it in the %temp% directory with the
name: 1.bat.

There were a few interesting observations in the command line:

  1. The macro copies the
    Microsoft Windows certutil.exe utility to the %temp% directory with
    the name: ct.exe. One of the reasons for this is to evade detection
    by security products. Recently, FireEye has observed other threat
    actors using certutil.exe for malicious purposes. By renaming
    “certutil.exe” before execution, the malware authors are attempting
    to evade simple file-name based heuristic detections.
  2. The
    malicious BAT file is stored as the contents of a fake PEM encoded
    SSL certificate (with the BEGIN and END markers) on the Stage 1 URL,
    as shown in Figure 3.  The “certutil.exe” utility is then leveraged
    to both strip the BEGIN/END markers and decode the Base64 contents
    of the file. FireEye has not previously observed the malware authors
    use this technique in past campaigns.

Figure 3: Malicious BAT file stored as an
encoded file to appear as an SSL certificate

BAT File Analysis

Once decoded and executed, the BAT file from Stage 1 will download
an encoded CAB file from the base URL: hxxp://more.1apps[.]com/. The
exact file name downloaded is based on the architecture of the
operating system.

  • For a 32-bit operating
    system: hxxp://more.1apps[.]com/2.txt
  • For a 64-bit
    operating system: hxxp://more.1apps[.]com/3.txt

Similarly, based on Windows operating system version and
architecture, the CAB file is installed using different techniques.
For Windows 10, the BAT file uses rundll32 to invoke the appropriate
function from update.dll (component inside

  • For a 32-bit operating
    system: rundll32 update.dll _EntryPoint@16
  • For a 64-bit
    operating system: rundll32 update.dll EntryPoint

For other versions of Windows, the CAB file is extracted using the
legitimate Windows Update Standalone Installer (wusa.exe) directly
into the system directory:

The BAT file also checks for the presence of Kaspersky Lab Antivirus
software on the machine. If found, CAB installation is changed
accordingly in an attempt to bypass detection:

Stage 2: CAB File Analysis

As described in the previous section, the BAT file will download the
CAB file based on the architecture of the underlying operating system.
The rest of the malicious activities are performed by the downloaded
CAB file.

The CAB file contains the following components:

  • install.bat – BAT file
    used to deploy and execute the components.
  • ipnet.dll – Main
    component that we refer to as SANNY malware.
  • ipnet.ini –
    Config file used by SANNY malware.
  • NTWDBLIB.dll – Performs
    UAC bypass on Windows 7 (32-bit and 64-bit).
  • update.dll –
    Performs UAC bypass on Windows 10.

install.bat will perform the following essential activities:

  1. Checks the current
    execution directory of the BAT file. If it is not the Windows system
    directory, then it will first copy the necessary components
    (ipnet.dll and ipnet.ini) to the Windows system directory before
    continuing execution:

  2. Hijacks a legitimate Windows system service,
    COMSysApp (COM+ System Application) by first stopping this service,
    and then modifying the appropriate Windows service registry keys to
    ensure that the malicious ipnet.dll will be loaded when the
    COMSysApp service is started:

  3. After the hijacked COMSysApp service is
    started, it will delete all remaining components of the CAB

ipnet.dll is the main component inside the CAB file that is used for
performing malicious activities. This DLL exports the following two functions:

  1. ServiceMain – Invoked
    when the hijacked system service, COMSysApp, is started.
  2. Post – Used to perform data exfiltration to the command and
    control (C2) server using FTP protocol.

The ServiceMain function first performs a check to see if it is
being run in the context of svchost.exe or rundll32.exe. If it is
being run in the context of svchost.exe, then it will first start the
system service before proceeding with the malicious activities. If it
is being run in the context of rundll32.exe, then it performs the
following activities:

  1. Deletes the module
    NTWDBLIB.DLL from the disk using the following command:

    cmd /c taskkill /im cliconfg.exe /f /t && del /f /q

  2. Sets the code page on the system
    to 65001, which corresponds to UTF-8:

    cmd /c REG ADD
    HKCUConsole /v CodePage /t REG_DWORD /d 65001 /f

Command and Control (C2) Communication

SANNY malware uses the FTP protocol as the C2 communication channel.

FTP Config File

The FTP configuration information used by SANNY malware is encoded
and stored inside ipnet.ini.

This file is Base64 encoded using the following custom character
set: SbVIn=BU/dqNP2kWw0oCrm9xaJ3tZX6OpFc7Asi4lvuhf-TjMLRQ5GKeEHYgD1yz8

Upon decoding the file, the following credentials can be recovered:

  • FTP Server:
  • Username: cnix_21072852
  • Password:

It then continues to perform the connection to the FTP server
decoded from the aforementioned config file, and sets the current
directory on the FTP server as “htdocs” using the
FtpSetCurrentDirectoryW function.

System Information Collection

For reconnaissance purposes, SANNY malware executes commands on the
system to collect information, which is sent to the C2 server.

System information is gathered from the machine using the following command:

The list of running tasks on the system is gathered by executing the
following command:

C2 Commands

After successful connection to the FTP server decoded from the
configuration file, the malware searches for a file containing the
substring “to everyone” in the “htdocs” directory. This file will
contain C2 commands to be executed by the malware.

Upon discovery of the file with the “to everyone” substring, the
malware will download the file and then performs actions based on the
following command names:

  • chip command: This
    command deletes the existing ipnet.ini configuration file from the
    file system and creates a new ipnet.ini file with a specified
    configuration string. The chip commands allows the attacker to
    migrate malware to a new FTP C2 server. The command has the
    following syntax:

  • pull command: This command is used for the
    purpose of data exfiltration. It has the ability to upload an
    arbitrary file from the local filesystem to the attacker’s FTP
    server. The command has the following syntax:

The uploaded file is compressed and
encrypted using the routine described later in the Compression and
Encoding Data section.

  • put command: This command
    is used to copy an existing file on the system to a new location and
    delete the file from the original location. The command has the
    following syntax:

  • default command: If the
    command begins with the substring “cmd /c”, but it is not followed
    by either of the previous commands (chip, pull, and put), then it
    directly executes the command on the machine using WinExec.
  • /user command: This
    command will execute a command on the system as the logged in user.
    The command duplicates the access token of “explorer.exe” and spawns
    a process using the following steps:

    1. Enumerates the running processes on the system to search for
      the explorer.exe process and obtain the process ID of
    2. Obtains the access token for the
      explorer.exe process with the access flags set to
    3. Starts the application (defined in the C2
      command) on the system by calling the CreateProcessAsUser
      function and using the access token obtained in Step 2.
C2 Command Purpose
chip Update the FTP server config file
pull Upload a file from the machine
put Copy an existing file to a new destination
/user Create a new process with explorer.exe access
default command Execute a program on the machine
using WinExec()

Compression and Encoding Data

SANNY malware uses an interesting mechanism for compressing the
contents of data collected from the system and encoding it before
exfiltration. Instead of using an archiving utility, the malware
leverages Shell.Application COM object and calls the CopyHere method
of the IShellDispatch interface to perform compression as follows:

  1. Creates an empty ZIP file
    with the name: in the %temp% directory.
  2. Writes the
    first 16 bytes of the PK header to the ZIP file.
  3. Calls the
    CopyHere method of IShellDispatch interface to compress the
    collected data and write to
  4. Reads the contents of to memory.
  5. Deletes from the disk.
  6. Creates an empty file, post.txt, in the %temp% directory.
  7. The file contents are Base64 encoded (using the same
    custom character set mentioned in the previous FTP Config File
    section) and written to the file: %temp%post.txt.
  8. Calls
    the FtpPutFileW function to write the contents of post.txt to the
    remote file with the format: “from

Execution on Windows 7 and User Account Control (UAC) Bypass

NTWDBLIB.dll – This component from the CAB file will be extracted to
the %windir%system32 directory. After this, the cliconfg command is
executed by the BAT file.

The purpose of this DLL module is to launch the install.bat file.
The file cliconfg.exe is a legitimate Windows binary (SQL Client
Configuration Utility), loads the library NTWDBLIB.dll upon execution.
Placing a malicious copy of NTWDBLIB.dll in the same directory as
cliconfg.exe is a technique known as DLL side-loading, and results in
a UAC bypass.

Execution on Windows 10 and UAC Bypass

Update.dll – This component from the CAB file is used to perform UAC
bypass on Windows 10. As described in the BAT File Analysis section,
if the underlying operating system is Windows 10, then it uses
update.dll to begin the execution of code instead of invoking the
install.bat file directly.

The main actions performed by update.dll are as follows:

  1. Executes the following
    commands to setup the Windows registry for UAC bypass:

  2. Leverages a UAC
    bypass technique
    that uses the legitimate Windows binary,
    fodhelper.exe, to perform the UAC bypass on Windows 10 so that the
    install.bat file is executed with elevated privileges:

  3. Creates an additional BAT file, kill.bat, in
    the current directory to delete evidence of the UAC bypass. The BAT
    file kills the current process and deletes the components update.dll
    and kill.bat from the file system:


This activity shows us that the threat actors using SANNY malware
are evolving their malware delivery methods, notably by incorporating
UAC bypasses and endpoint evasion techniques. By using a multi-stage
attack with a modular architecture, the malware authors increase the
difficulty of reverse engineering and potentially evade security solutions.

Users can protect themselves from such attacks by disabling Office
macros in their settings and practicing vigilance when enabling macros
(especially when prompted) in documents, even if such documents are
from seemingly trusted sources.

Indicators of Compromise

SHA256 Hash Original Filename
b0f30741a2449f4d8d5ffe4b029a6d3959775818bf2e85bab7fea29bd5acafa4 РГНФ 2018-2019.doc
e29fad201feba8bd9385893d3c3db42bba094483a51d17e0217ceb7d3a7c08f1 Copy of
communication from Security Council Committee (1718).doc
eb394523df31fc83aefa402f8015c4a46f534c0a1f224151c47e80513ceea46f 1.bat
a2e897c03f313a097dc0f3c5245071fbaeee316cfb3f07785932605046697170 (64-bit)
a3b2c4746f471b4eabc3d91e2d0547c6f3e7a10a92ce119d92fa70a6d7d3a113 (32-bit)

Go to Source
Author: Sudeep Singh

Fake Software Update Abuses NetSupport Remote Access Tool

Over the last few months, FireEye has tracked an in-the-wild campaign
that leverages compromised sites to spread fake updates. In some
cases, the payload was the NetSupport Manager remote access tool
(RAT). NetSupport Manager is a commercially available RAT that can be
used legitimately by system administrators for remotely accessing
client computers. However, malicious actors are abusing this
application by installing it to the victims’ systems without their
knowledge to gain unauthorized access to their machines. This blog
details our analysis of the JavaScript and components used in
instances where the identified payload was NetSupport RAT.

Infection Vector

The operator behind these campaigns uses compromised sites to spread
fake updates masquerading as Adobe Flash, Chrome, and FireFox updates.
When users navigate to the compromised website, the malicious
JavaScript file is downloaded, mostly from a DropBox link. Before
delivering the payload, the JavaScript sends basic system information
to the server. After receiving further commands from the server, it
then executes the final JavaScript to deliver the final payload. In
our case, the JavaScript that delivers the payload is named Update.js,
and it is executed from %AppData% with the help of wscript.exe. Figure
1 shows the infection flow.

Figure 1: Infection Flow

In-Depth Analysis of JavaScript

The initial JavaScript file contains multiple layers of obfuscation.
Like other malicious scripts, the first layer has obfuscation that
builds and executes the second layer as a new function. The second
layer of the JavaScript contains the dec function, which is
used to decrypt and execute more JavaScript code. Figure 2 shows a
snapshot of the second layer.

Figure 2: Second Layer of Initial
JavaScript File

In the second JavaScript file, the malware author uses a tricky
method to make the analysis harder for reverse engineers. The author
uses the caller and callee function code to get the key
for decryption. During normal JavaScript analysis, if an analyst finds
any obfuscated script, the analyst tries to de-obfuscate or beautify
the script for analysis. JavaScript beautification tools generally add
line breaks and tabs to make the script code look better and easier to
analyze. The tools also try to rename the local variables and remove
unreferenced variables and code from the script, which helps to
analyze core code only.

But in this case, since the malware uses the caller and
callee function code to derive the key, if the analyst adds or
removes anything from the first or second layer script, the script
will not be able to retrieve the key and will terminate with an
exception. The code snippet in Figure 3 shows this trick.

Figure 3: Anti-Analysis Trick Implemented
in JavaScript (Beautified Code)

The code decrypts and executes the JavaScript code as a function.
This decrypted function contains code that initiates the network
connection. In the decoded function, the command and control (C2) URL
and a value named tid are hard-coded in the script and
protected with some encoded function.

During its first communication to the server, the malware sends the
tid value and the current date of the system in encoded format,
and waits for the response from the server. It decodes the server
response and executes the response as a function, as shown in Figure 4.

Figure 4: Initial Server Communication
and Response

The response from the server is JavaScript code that the malware
executes as a function named step2.

The step2 function uses WScript.Network and Windows Management
Instrumentation(WMI) to collect the following system information,
which it then encodes and sends to the server:

Architecture, ComputerName, UserName, Processors, OS, Domain,
Manufacturer, Model, BIOS_Version, AntiSpywareProduct,
AntiVirusProduct, MACAddress, Keyboard, PointingDevice,
DisplayControllerConfiguration, ProcessList;

After sending the system information to the server, the response
from the server contains two parts: content2 and content3.

The script (step2 function) decodes both parts. The
decoded content3 part contains the function named as
step3, as shown in Figure 5.

Figure 5: Decrypting and Executing
Response step3

The step3 function contains code that writes decoded
content2 into a %temp% directory as Update.js. Update.js
contains code to download and execute the final payload. The
step3 function also sends the resulting data, such as
runFileResult and _tempFilePath, to the server, as shown
in Figure 6.

Figure 6: Script to Drop and Execute Update.js

The Update.js file also contains multi-layer obfuscation. After
decoding, the JavaScript contains code to drop multiple files in
%AppData%, including a 7zip standalone executable (7za.exe),
password-protected archive (Loglist.rtf), and batch script (Upd.cmd).
We will talk more about these components later.

JavaScript uses PowerShell commands to download the files from the
server. It sets the attribute’s execution policy to bypass and
window-style to hidden to hide itself from the end user.

Components of the Attack

Figure 7 shows the index of the malicious server where we have
observed the malware author updating the script content.

Figure 7: Index of Malicious Server

  • 7za.exe: 7zip standalone
  • LogList.rtf: Password-protected archive file
  • Upd.cmd: Batch script to install the NetSupport Client
  • Downloads.txt: List of IPs (possibly the infected systems)
  • Get.php: Downloads LogList.rtf

This file is a batch script that extracts the archive file and
installs the remote control tool on the system. The script is
obfuscated with the variable substitution method. This file was
regularly updated by the malware during our analysis.

After de-obfuscating the script, we can see the batch commands in
the script (Figure 8).

Figure 8: De-Obfuscated Upd.cmd Script

The script performs the following tasks:

  1. Extract the archive using
    the 7zip executable with the password mentioned in the script.
  2. After extraction, delete the downloaded archive file
  3. Disable Windows Error Reporting and App
  4. Add the remote control client executable to
    the firewall’s allowed program list.
  5. Run remote control
    tool (client32.exe).
  6. Add Run registry entry with the name
    “ManifestStore” or downloads shortcut file to Startup folder.
  7. Hide the files using attributes.
  8. Delete all the
    artifacts (7zip executable, script, archive file).

Note: While analyzing the script, we found some typos in the
script (Figure 9). Yes, malware authors make mistakes too. This script
might be in beta phase. In the later version of script, the author has
removed these typos.

Figure 9: Registry Entry Bloopers

Artifact Cleaning

As mentioned, the script contains code to remove the artifacts used
in the attack from the victim’s system. While monitoring the server,
we also observed some change in the script related to this code, as
shown in Figure 10.

Figure 10: Artifact Cleaning Commands

The highlighted command in one of the variants indicates that it
might drop or use this file in the attack. The file could be a decoy document.

Persistence Mechanism

During our analysis, we observed two variants of this attack with
different persistence mechanisms.

In the first variant, the malware author uses a RUN registry entry
to remain persistent in the system.

In the second variant, the malware author uses the shortcut file
(named desktop.ini.lnk), which is hosted on the server. It
downloads the shortcut file and places it into the Startup folder, as
shown in Figure 11.

Figure 11: Downloading Shortcut File

The target command for the shortcut file points to the remote
application “client32.exe,” which was dropped in %AppData%, to start
the application on startup.


Although the file extension is .rtf, the file is actually a 7zipped
archive. This archive file is password-protected and contains the
NetSupport Manager RAT. The script upd.cmd contains the password to
extract the archive.

The major features provided by the NetSupport tool include:

  • Remote desktop
  • File transfer
  • Remote inventory and system
  • Launching applications in client’s
  • Geolocation

This file contains a list of IP addresses, which could be
compromised systems. It has IPs along with User-agent. The IP
addresses in the file belong to various regions, mostly the U.S.,
Germany, and the Netherlands.


RATs are widely used for legitimate purposes, often by system
administrators. However, since they are legitimate applications and
readily available, malware authors can easily abuse them and sometimes
can avoid user suspicion as well.

The FireEye HX Endpoint platform successfully detects this attack at
the initial phase of the attack cycle.


Thanks to my colleagues Dileep Kumar Jallepalli, Rakesh Sharma and
Kimberly Goody for their help in the analysis.

Indicators of Compromise

Registry entries

:  ManifestStore

















Shortcut file

%AppData%RoamingMicrosoftWindowsStart MenuProgramsStartupdesktop.ini.lnk

Firewall program entry allowing the following application


Running process named “client32.exe” from the path “%AppData%ManifestStoreclient32.exe”


The following hashes are JavaScript files that use the same
obfuscation techniques described in the blog:























Go to Source
Author: Sudhanshu Dubey

Suspected Chinese Cyber Espionage Group (TEMP.Periscope) Targeting U.S.Engineering and Maritime Industries

Intrusions Focus on the Engineering and Maritime Sector

Since early 2018, FireEye (including our FireEye as a Service
(FaaS), Mandiant Consulting, and iSIGHT Intelligence teams) has been
tracking an ongoing wave of intrusions targeting engineering and
maritime entities, especially those connected to South China Sea
issues. The campaign is linked to a group of suspected Chinese cyber
espionage actors we have tracked since 2013, dubbed TEMP.Periscope.
The group has also been reported as “Leviathan
by other security firms.

The current campaign is a sharp escalation of detected activity
since summer 2017. Like multiple other Chinese cyber espionage actors,
TEMP.Periscope has recently re-emerged and has been observed
conducting operations with a revised toolkit. Known targets of this
group have been involved in the maritime industry, as well as
engineering-focused entities, and include research institutes,
academic organizations, and private firms in the United States.
FireEye products have robust detection for the malware used in this campaign.

TEMP.Periscope Background

Active since at least 2013, TEMP.Periscope has primarily focused on
maritime-related targets across multiple verticals, including
engineering firms, shipping and transportation, manufacturing,
defense, government offices, and research universities. However, the
group has also targeted professional/consulting services, high-tech
industry, healthcare, and media/publishing. Identified victims were
mostly found in the United States, although organizations in Europe
and at least one in Hong Kong have also been affected. TEMP.Periscope
overlaps in targeting, as well as tactics, techniques, and procedures
(TTPs), with TEMP.Jumper, a group that also overlaps significantly
with public reporting on “NanHaiShu.”

TTPs and Malware Used

In their recent spike in activity, TEMP.Periscope has leveraged a
relatively large library of malware shared with multiple other
suspected Chinese groups. These tools include:

    JavaScript-based backdoor also reported as “Orz” that retrieves
    commands from hidden strings in compromised webpages and actor
    controlled profiles on legitimate services.
    backdoor that is capable of modifying the file system, generating a
    reverse shell, and modifying its command and control (C2)
  • PHOTO: a DLL backdoor also reported publicly
    as “Derusbi”, capable of obtaining directory, file, and drive
    listing; creating a reverse shell; performing screen captures;
    recording video and audio; listing, terminating, and creating
    processes; enumerating, starting, and deleting registry keys and
    values; logging keystrokes, returning usernames and passwords from
    protected storage; and renaming, deleting, copying, moving, reading,
    and writing to files.
  • HOMEFRY: a 64-bit Windows password
    dumper/cracker that has previously been used in conjunction with
    AIRBREAK and BADFLICK backdoors. Some strings are obfuscated with
    XOR x56. The malware accepts up to two arguments at the command
    line: one to display cleartext credentials for each login session,
    and a second to display cleartext credentials, NTLM hashes, and
    malware version for each login session.
    uploader that can exfiltrate files to Dropbox.
    command-line reconnaissance tool. It can be used to execute files as
    a different user, move, and delete files locally, schedule remote AT
    jobs, perform host discovery on connected networks, scan for open
    ports on hosts in a connected network, and retrieve information
    about the OS, users, groups, and shares on remote hosts.
  • China Chopper: a simple code injection webshell that executes
    Microsoft .NET code within HTTP POST commands. This allows the shell
    to upload and download files, execute applications with web server
    account permissions, list directory contents, access Active
    Directory, access databases, and any other action allowed by the
    .NET runtime.

The following are tools that TEMP.Periscope has leveraged in past
operations and could use again, though these have not been seen in the
current wave of activity:

  • Beacon: a backdoor that
    is commercially available as part of the Cobalt Strike software
    platform, commonly used for pen-testing network environments. The
    malware supports several capabilities, such as injecting and
    executing arbitrary code, uploading and downloading files, and
    executing shell commands.
    a backdoor that obfuscates its communications as normal traffic to
    legitimate websites such as Github and Microsoft’s Technet portal.
    Used by APT17 and
    other Chinese cyber espionage operators.

Additional identifying TTPs include:

  • Spear phishing, including
    the use of probably compromised email accounts.
  • Lure
    documents using CVE-2017-11882 to drop malware.
  • Stolen code
    signing certificates used to sign malware.
  • Use of
    bitsadmin.exe to download additional tools.
  • Use of
    PowerShell to download additional tools.
  • Using
    C:WindowsDebug and C:Perflogs as staging directories.
  • Leveraging Hyperhost VPS and Proton VPN exit nodes to access
    webshells on internet-facing systems.
  • Using Windows
    Management Instrumentation (WMI)
    for persistence
  • Using Windows Shortcut files (.lnk)
    in the Startup folder that invoke the Windows Scripting Host
    (wscript.exe) to execute a Jscript backdoor for persistence.
  • Receiving C2 instructions from user profiles created by the
    adversary on legitimate websites/forums such as Github and
    Microsoft’s TechNet portal.


The current wave of identified intrusions is consistent with
TEMP.Periscope and likely reflects a concerted effort to target
sectors that may yield information that could provide an economic
advantage, research and development data, intellectual property, or an
edge in commercial negotiations.

As we continue to investigate this activity, we may identify
additional data leading to greater analytical confidence linking the
operation to TEMP.Periscope or other known threat actors, as well as
previously unknown campaigns.


x.js 3fefa55daeb167931975c22df3eca20a HOMEFRY, a 64-bit Windows password
mt.exe 40528e368d323db0ac5c3f5e1efe4889 MURKYTOP, a command-line
reconnaissance tool
com4.js a68bf5fce22e7f1d6f999b7a580ae477 AIRBREAK, a JavaScript-based
backdoor which retrieves commands from hidden strings in
compromised webpages

Historical Indicators

green.ddd 3eb6f85ac046a96204096ab65bbd3e7e AIRBREAK, a JavaScript-based
backdoor which retrieves commands from hidden strings in
compromised webpages
BGij 6e843ef4856336fe3ef4ed27a4c792b1 Beacon, a commercially available
msresamn.ttf a9e7539c1ebe857bae6efceefaa9dd16 PHOTO, also reported as
1024-aa6a121f98330df2edee6c4391df21ff43a33604 bd9e4c82bf12c4e7a58221fc52fed705 BADFLICK, backdoor that is capable
of modifying the file system, generating a reverse shell, and
modifying its command-and-control configuration

Go to Source
Author: FireEye

Iranian Threat Group Updates Tactics, Techniques and Procedures in SpearPhishing Campaign


From January 2018 to March 2018, through FireEye’s Dynamic Threat
Intelligence, we observed attackers leveraging the latest code
execution and persistence techniques to distribute malicious
macro-based documents to individuals in Asia and the Middle East.

We attribute this activity to TEMP.Zagros, an Iran-nexus actor that
has been active since at least May 2017. This actor has engaged in
prolific spear phishing of government and defense entities in Central
and Southwest Asia. The spear phishing emails and attached malicious
macro documents typically have geopolitical themes. When successfully
executed, the malicious documents install a backdoor we track as POWERSTATS.

One of the more interesting observations during the analysis of
these files was the re-use of the latest AppLocker bypass, and lateral
movement techniques for the purpose of indirect code execution. The IP
address in the lateral movement techniques was substituted with the
local machine IP address to achieve code execution on the system.

Campaign Timeline

In this campaign, the threat actor’s tactics, techniques and
procedures (TTPs) shifted after about a month, as did their targets. A
brief timeline of this activity is shown in Figure 1.

Figure 1: Timeline of this recently
observed spear phishing campaign

The first part of the campaign (From Jan. 23, 2018, to Feb. 26,
2018) used a macro-based document that dropped a VBS file and an INI
file. The INI file contains the Base64 encoded PowerShell command,
which will be decoded and executed by PowerShell using the command
line generated by the VBS file on execution using WScript.exe. The
process chain is shown in Figure 2.

Figure 2: Process chain for the first
part of the campaign

Although the actual VBS script changed from sample to sample, with
different levels of obfuscation and different ways of invoking the
next stage of process tree, its final purpose remained same: invoking
PowerShell to decode the Base64 encoded PowerShell command in the INI
file that was dropped earlier by the macro, and executing it. One such
example of the VBS invoking PowerShell via MSHTA is shown in Figure 3.

Figure 3: VBS invoking PowerShell via MSHTA

The second part of the campaign (from Feb. 27, 2018, to March 5,
2018) used a new variant of the macro that does not use VBS for
PowerShell code execution. Instead, it uses one of the recently
disclosed code execution techniques leveraging INF and SCT files,
which we will go on to explain later in the blog.

Infection Vector

We believe the infection vector for all of the attacks involved in
this campaign are macro-based documents sent as an email attachment.
One such email that we were able to obtain was targeting users in
Turkey, as shown in Figure 4:

Figure 4: Sample spear phishing email
containing macro-based document attachment

The malicious Microsoft Office attachments that we observed appear
to have been specially crafted for individuals in four countries:
Turkey, Pakistan, Tajikistan and India. What follows is four examples,
and a complete list is available in the Indicators of Compromise
section at the end of the blog.

Figure 5 shows a document purporting to be from the National
Assembly of Pakistan.

Figure 5: Document purporting to be from
the National Assembly of Pakistan

A document purporting to be from the Turkish Armed Forces, with
content written in the Turkish language, is shown in Figure 6.

Figure 6: Document purporting to be from
the Turkish Armed Forces

A document purporting to be from the Institute for Development and
Research in Banking Technology (established by the Reserve Bank of
India) is shown in Figure 7.

Figure 7: Document purporting to be from
the Institute for Development and Research in Banking Technology

Figure 8 shows a document written in Tajik that purports to be from
the Ministry of Internal Affairs of the Republic of Tajikistan.

Figure 8: Document written in Tajik that
purports to be from the Ministry of Internal Affairs of the Republic
of Tajikistan

Each of these macro-based documents used similar techniques for code
execution, persistence and communication with the command and control
(C2) server.

Indirect Code Execution Through INF and SCT

This scriptlet
code execution technique
leveraging INF and SCT files was
recently discovered and documented in February 2018. The threat group
in this recently observed campaign – TEMP.Zagros – weaponized their
malware using the following techniques.

The macro in the Word document drops three files in a hard coded
path: C:programdata. Since the path is hard coded, the execution will
only be observed in operating systems, Windows 7 and above. The
following are the three files:

  • Defender.sct – The malicious JavaScript based scriptlet
  • DefenderService.inf – The INF file that is used to
    invoke the above scriptlet file.
  • WindowsDefender.ini – The Base64 encoded and obfuscated
    PowerShell script.

After dropping the three files, the macro will set the following
registry key to achieve persistence:

= cmstp.exe /s c:programdataDefenderService.inf

Upon system restart, cmstp.exe will be used to execute the SCT file
indirectly through the INF file. This is possible because inside the
INF file we have the following section:


That section gets indirectly invoked through the
DefaultInstall_SingleUser section of INF, as shown in Figure 9.

Figure 9: Indirectly invoking SCT through
the DefaultInstall_SingleUser section of INF

This method of code execution is performed in an attempt to evade
security products. FireEye MVX and HX Endpoint Security technology
successfully detect this code execution technique.

SCT File Analysis

The code of the Defender.sct file is an obfuscated JavaScript. The
main function performed by the SCT file is to Base64 decode the
contents of WindowsDefender.ini file and execute the decoded
PowerShell Script using the following command line:

powershell.exe -exec Bypass -c
iex([System.Text.Encoding]::Unicode.GetString([System.Convert]::FromBase64String((get-content C:\ProgramData\WindowsDefender.ini)

The rest of the malicious activities are performed by the PowerShell Script.

PowerShell File Analysis

The PowerShell script employs several layers of obfuscation to hide
its actual functionality. In addition to obfuscation techniques, it
also has the ability to detect security tools on the analysis machine,
and can also shut down the system if it detects the presence of such tools.

Some of the key obfuscation techniques used are:

  • Character Replacement: Several instances of character
    replacement and string reversing techniques (Figure 10) make
    analysis difficult.

Figure 10: Character replacement and
string reversing techniques

  • PowerShell Environment Variables: Nowadays, malware authors
    commonly mask critical strings such as “IEX” using environment
    variables. Some of the instances used in this script are:

    • $eNv:puBLic[13]+$ENv:pUBLIc[5]+’x’
    • ($ENV:cOMsPEC[4,26,25]-jOin”)
  • XOR encoding: The biggest section of the PowerShell script is
    XOR encoded using a single byte key, as shown in Figure 11.

Figure 11: PowerShell script is XOR
encoded using a single byte key

After deobfuscating the contents of the PowerShell Script, we can
divide it into three sections.

Section 1

The first section of the PowerShell script is responsible for
setting different key variables that are used by the remaining
sections of the PowerShell script, especially the following variables:

  • TEMpPAtH =
    “C:ProgramData” (the path used for storing the temp
  • Get_vAlIdIP = (used to
    get the public IP address of the machine)
    WindowsDefender.ini (file used to store Powershell code)
  • PRIVAtE = Private Key exponents
  • PUbLIc = Public Key
  • Hklm = “HKLM:Software”
  • Hkcu =
  • ValuE =
  • DrAGon_MidDLe = [array
    of proxy URLs]

Among those variables, there is one variable of particular interest,
DrAGon_MidDLe, which stores the list of proxy URLs (detailed at
the end of the blog in the Network Indicators portion of the
Indicators of Compromise section) that will be used to interact with
the C2 server, as shown in Figure 12.

Figure 12: DrAGon_MidDLe stores the list
of proxy URLs used to interact with C2 server

Section 2

The second section of the PowerShell script has the ability to
perform encryption and decryption of messages that are exchanged
between the system and the C2 server. The algorithm used for
encryption and decryption is RSA, which leverages the public and
private key exponents included in Section 1 of the PowerShell script.

Section 3

The third section of the PowerShell script is the biggest section
and has a wide variety of functionalities.

During analysis, we observed a code section where a message written
in Chinese and hard coded in the script will be printed in the case of
an error while connecting to the C2 server:

The English translation for this message is: “Cannot connect to
website, please wait for dragon”.

Other functionalities provided by this section of the PowerShell
Script are as follows:

  • Retrieves the following
    data from the system by leveraging Windows Management
    Instrumentation (WMI) queries and environment variables:

    • IP
      Address from Network Adapter Configuration
    • OS Name
    • OS Architecture
    • Computer Name
    • Computer
      Domain Name
    • Username

All of this data is concatenated and
formatted as shown in Figure 13:

Figure 13: Concatenated and formatted
data retrieved by PowerShell script

  • Register the victim’s
    machine to the C2 server by sending the REGISTER command to the
    server. In response, if the status is OK, then a TOKEN is received
    from the C2 server that is used to synchronize the activities
    between the victim’s machine and the C2 server.

While sending to the C2 server, the
data is formatted as follows:

@{SYSINFO  = $get.ToString(); ACTION = “REGISTER”;}

  • Ability to take
  • Checks for the presence
    of security tools (detailed in the Appendix) and if any of these
    security tools are discovered, then the system will be shut down, as
    shown in Figure 14.

Figure 14: System shut down upon
discovery of security tools

  • Ability to receive
    PowerShell script from the C2 server and execute on the machine.
    Several techniques are employed for executing the PowerShell

    • If command starts with “excel”, then it leverages
      DDEInitiate Method of Excel.Appilcation to execute the
    • If the command starts with “outlook”, then it leverages
      Outlook.Application and MSHTA to execute the code: 
    • If the command starts with “risk”, then execution is
      performed through DCOM object: 
  • File upload
  • Ability to disable
    Microsoft Office Protected View (as shown in Figure 15) by setting
    the following keys in the Windows Registry:

    • DisableAttachmentsInPV
    • DisableInternetFilesInPV
    • DisableUnsafeLocationsInPV

Figure 15: Disabling Microsoft Office
Protected View

  • Ability to remotely
    reboot or shut down or clean the system based on the command
    received from the C2 server, as shown in Figure 16.

Figure 16: Reboot, shut down and clean commands

  • Ability to sleep for a
    given number of seconds.

The following table summarizes the main C2 commands supported by
this PowerShell Script.

C2 Command Purpose
reboot Reboot the system using shutdown command
shutdown Shut down the system using shutdown
clean Wipe the Drives, C:, D:, E:, F:
screenshot Take a screenshot of the System
upload Encrypt and upload the information from the
excel Leverage Excel.Application COM object for code
outlook Leverage Outlook.Application COM object for
code execution
risk Leverage DCOM object for code execution


This activity shows us that TEMP.Zagros stays up-to-date with the
latest code execution and persistence mechanism techniques, and that
they can quickly leverage these techniques to update their malware. By
combining multiple layers of obfuscation, they deter the process of
reverse engineering and also attempt to evade security products.

Users can protect themselves from such attacks by disabling Office
macros in their settings and also by being more vigilant when enabling
macros (especially when prompted) in documents, even if such documents
are from seemingly trusted sources.

Indicators of Compromise

Macro based Documents and Hashes
SHA256 Hash Filename Targeted Region
eff78c23790ee834f773569b52cddb01dc3c4dd9660f5a476af044ef6fe73894 na.doc


76e9988dad0278998861717c774227bf94112db548946ef617bfaa262cb5e338 Invest in Turkey.doc Turkey
6edc067fc2301d7a972a654b3a07398d9c8cbe7bb38d1165b80ba4a13805e5ac güvenlik yönergesi. .doc Turkey
009cc0f34f60467552ef79c3892c501043c972be55fe936efb30584975d45ec0 idrbt.doc


18479a93fc2d5acd7d71d596f27a5834b2b236b44219bb08f6ca06cf760b74f6 Türkiye Cumhuriyeti Kimlik
3da24cd3af9a383b731ce178b03c68a813ab30f4c7c8dfbc823a32816b9406fb Turkish Armed Forces.doc




3b1d8dcbc8072b1ec10f5300c3ea9bb20db71bd8fa443d97332790b74584a115 MVD-FORM-1800.doc Tajikistan
cee801b7a901eb69cd166325ed3770daffcd9edd8113a961a94c8b9ddf318c88 KEGM-CyberAttack.doc Turkey
1ee9649a2f9b2c8e0df318519e2f8b4641fd790a118445d7a0c0b3c02b1ba942 IL-1801.doc Turkey
aa60c1fae6a0ef3b9863f710e46f0a7407cf0feffa240b9a4661a4e8884ac627 kiyiemniyeti.doc Turkey
93745a6605a77f149471b41bd9027390c91373558f62058a7333eb72a26faf84 TCELL-S1-M.doc Tajikistan
c87799cce6d65158da97aa31a5160a0a6b6dd5a89dea312604cc66ed5e976cc9 egm-1.doc Turkey
2cea0b740f338c513a6390e7951ff3371f44c7c928abf14675b49358a03a5d13 Connectel .pk.doc Pakistan
18cf5795c2208d330bd297c18445a9e25238dd7f28a1a6ef55e2a9239f5748cd gßvenlik_yÜnergesi_.doc Turkey
153117aa54492ca955b540ac0a8c21c1be98e9f7dd8636a36d73581ec1ddcf58 MIT.doc Turkey
d07d4e71927cab4f251bcc216f560674c5fb783add9c9f956d3fc457153be025 Gvenlik Ynergesi.doc Turkey
af5f102f0597db9f5e98068724e31d68b8f7c23baeea536790c50db587421102 Gvenlik Ynergesi.doc Turkey
5550615affe077ddf66954edf132824e4f1fe16b3228e087942b0cad0721a6af NA Turkey
3d96811de7419a8c090a671d001a85f2b1875243e5b38e6f927d9877d0ff9b0c Anadolu Güneydoğu
Projesinde .doc

Network Indicators

List of Proxy URLs








































































































































































































































































































































































































































































Security Tools Checked on the Machine





























Go to Source
Author: Sudeep Singh