Microsoft Patch Tuesday — October 18: Vulnerability disclosures

Microsoft released its monthly security update today, disclosing a variety of vulnerabilities in several of its products. The latest Patch Tuesday covers 49 vulnerabilities, 12 of which are rated “critical,” 34 that are rated “important,” two that are considered to have “moderate” severity and one that’s rated as “low.”

The advisories cover bugs in the Chakra scripting engine, the Microsoft Edge internet browser and the Microsoft Office suite of products, among other software.

This update also includes a critical advisory that covers updates to the Microsoft Office suite of products.

Critical vulnerabilities

Microsoft has disclosed 12 critical vulnerabilities this month, which we will highlight below.

CVE-2018-8491CVE-2018-8460 and CVE-2018-8509 are memory corruption vulnerabilities in the Internet Explorer web browser. In both cases, an attacker needs to trick the user into visiting a specially crafted, malicious website that can corrupt the browser’s memory, allowing for remote code execution in the context of the current user. This class of vulnerabilities is especially dangerous since a spam campaign can be used to trick the user while hiding the attack from network protections with HTTPS.

CVE-2018-8473 is a remote code execution vulnerability in Microsoft Edge. The bug lies in the way the web browser accesses objects in memory. An attacker could trick a user into visiting a malicious website or take advantage of a website that accepts user-created content or advertisements in order to exploit this vulnerability.

CVE-2018-8513CVE-2018-8500CVE-2018-8511CVE-2018-8505 and CVE-2018-8510 are memory corruption vulnerabilities in the Chakra scripting engine that affects a variety of products. In all cases, an attacker could exploit these vulnerabilities to execute code on the system in the context of the current user and completely take over the system. This class of vulnerabilities is especially dangerous since a spam campaign can be used to trick the user while hiding the attack from network protections with HTTPS.

CVE-2018-8494 is a remote code execution vulnerability that exists when the MSXML parser in Microsoft XML Core Services processes user input. An attacker can exploit this bug by invoking MSXML through a web browser on a specially crafted website. The user also needs to convince the user to open the web page.

CVE-2018-8490 and CVE-2018-8489 are remote code execution vulnerabilities in the Windows Hyper-V hypervisor. The bugs lie in the way the host server on Hyper-V fails to properly validate input from an authenticated user on a guest operating system. An attacker could exploit these vulnerabilities by running a specially crafted application on a guest operating system that could cause the Hyper-V host operating system to execute arbitrary code.

Important vulnerabilities

There are also 34 important vulnerabilities in this release. We would like to specifically highlight 22 of them.

CVE-2018-8512 is a security feature bypass vulnerability in Microsoft Edge. The web browser improperly validates certain specially crafted documents in the Edge Content Security Policy (CSP), which could allow an attacker to trick a user into loading a malicious page.

CVE-2018-8448 is an elevation of privilege vulnerability in the Microsoft Exchange email server. The bug exists in the way that Exchange Outlook Web Access improperly handles web requests. An attacker could exploit this vulnerability by performing script or content injection attacks that trick the user into disclosing sensitive information. They could also trick the user into providing login credentials via social engineering in an email or chat client.

CVE-2018-8453 is an elevation of privilege vulnerability in the Windows operating system that occurs when the Win32k component improperly handles objects in memory. An attacker could obtain the ability to run arbitrary code in kernel mode by logging onto the system and then run a specially crafted application.

CVE-2018-8484 is an elevation of privilege vulnerability in the DirectX Graphics Kernel driver that exists when the driver improperly handles objects in memory. An attacker could log onto the system and execute a specially crafted application to exploit this bug and run processes in an elevated context.

CVE-2018-8423 is a remote code execution vulnerability in the Microsoft JET Database Engine that could allow an attacker to take control of an affected system. A user must open or import a specially crafted Microsoft JET Database Engine file on the system in order to exploit this bug. They could also trick a user into opening a malicious file via email.

CVE-2018-8502 is a security feature bypass vulnerability in Microsoft Excel when the software fails to properly handle objects in protected view. An attacker could execute arbitrary code in the context of the current user if they convince the user to open a specially crafted, malicious Excel document via email or on a web page. This bug cannot be exploited if the user opens the Excel file in just the preview pane.

CVE-2018-8501 is a security feature bypass vulnerability in Microsoft PowerPoint. The bug exists when the software improperly handles objects in protected view. An attacker can execute arbitrary code in the context of the current user if they convince the user to open a specially crafted PowerPoint file. This bug cannot be exploited if the user only opens the file in preview mode.

CVE-2018-8432 is a remote code execution vulnerability that lies in the way Microsoft Graphics Components handles objects in memory. A user would have to open a specially crafted file in order to trigger this bug.

CVE-2018-8504 is a security feature bypass vulnerability in the Microsoft Word word processor. There is a flaw in the way the software handles objects in protected view. An attacker could obtain the ability to arbitrarily execute code in the context of the current user if they convince the user to open a malicious Word document. The bug cannot be triggered if the user opens the file in preview mode.

CVE-2018-8427 is an information disclosure vulnerability in Microsoft Graphics Components. An attacker could exploit this vulnerability by tricking the user into opening a specially crafted file, which would expose memory layout.

CVE-2018-8480 is an elevation of privilege vulnerability in the Microsoft SharePoint collaborative platform. The bug lies in the way the software improperly sanitizes a specially crafted web request to an affected SharePoint server. An attacker could exploit this vulnerability by sending a specially crafted request to an affected SharePoint server.

CVE-2018-8518CVE-2018-8488 and CVE-2018-8498 are elevation of privilege vulnerabilities in the Microsoft SharePoint Server. An attacker can exploit these bugs by sending a specially crafted request to an affected SharePoint server, allowing them to carry out cross-site scripting attacks and execute code in the context of the current user.

CVE-2018-8333 is an elevation of privilege vulnerability in Filter Management that exists when the program improperly handles objects in memory. An attacker needs to log onto the system and delete a specially crafted file in order to exploit this bug, which could lead to them gaining the ability to execute code in the context of an elevated user.

CVE-2018-8411 is an elevation of privilege vulnerability that exists when the NFTS file system improperly checks access. An attacker needs to log onto the system to exploit this bug and then run a specially crafted application, which could lead to the attacker running processes in an elevated context.

CVE-2018-8320 is a security feature bypass vulnerability that exists in the DNS Global Blocklist feature. An attacker who exploits this bug could redirect traffic to a malicious DNS endpoint.

CVE-2018-8492 is a security bypass vulnerability in the Device Guard Windows feature that could allow an attacker to inject malicious code into Windows PowerShell. An attacker needs direct access to the machine in order to exploit this bug, and then inject malicious code into a script that is trusted by the Code Integrity policy. The malicious code would then run with the same access level as the script, and bypass the integrity policy.

CVE-2018-8329 is an elevation of privilege vulnerability in Linux on Windows. The bug lies in the way Linux improperly handles objects in memory. An attacker can completely take control of an affected system after logging onto the system and running a specially crafted application.

CVE-2018-8497 is an elevation of privilege vulnerability that exists in the way the Windows Kernel handles objects in memory. A locally authenticated attacker can exploit this bug by running a specially crafted application.

CVE-2018-8495 is a remote code execution vulnerability that exists in the way Windows Shell handles URIs. An attacker needs to convince the user to visit a specially crafted website on Microsoft Edge in order to exploit this vulnerability.

CVE-2018-8413 is a remote code execution vulnerability that exists when “Windows Theme API” improperly decompresses files. A victim can exploit this bug by convincing the user to open a specially crafted file via an email, chat client message or on a malicious web page, allowing the attacker to execute code in the context of the current user.

Other important vulnerabilities:

Moderate vulnerabilities

Of the two moderate vulnerabilities disclosed by Microsoft, Talos believes one is worth highlighting.

CVE-2010-3190 is a remote code execution vulnerability in the way that certain applications built using Microsoft Foundation Classes handle the loading of DLL files. An attacker could take complete control of an affected system by exploiting this vulnerability. At the time this bug was first disclosed, Exchange Server was not identified as an in-scope product, which is why this release highlights a flaw from 2010.

The other moderate vulnerability is CVE-2018-8533.

Low vulnerability

There is also one low-rated vulnerability, which Talos wishes to highlight.

CVE-2018-8503 is a remote code execution vulnerability in the way that Chakra scripting engine handles objects in memory in the Microsoft Edge web browser. An attacker needs to convince a user to visit a malicious website or malicious content on a web page that allows user-created content or advertisements in order to exploit this bug.

Go to Source
Author: Talos Group

Microsoft Patch Tuesday – September 2018

Microsoft released its monthly set of security updates today for a variety of its products that address a variety of bugs. The latest Patch Tuesday covers 61 vulnerabilities, 17 of which are rated “critical,” 43 that are rated “important” and one that is considered to have “moderate” severity.

The advisories cover bugs in the Internet Explorer web browser, Jet Database Engine and the Chakra scripting engine, among other products and software.

This update also includes two critical advisories, one of which covers security updates to Adobe Flash, and another that deals with a denial-of-service vulnerability in the Microsoft Windows operating system.


Microsoft released coverage for 17 critical bugs. Cisco Talos believes 16 of these are of special importance and need to be addressed by users immediately.

CVE-2018-0965 is a remote code execution vulnerability in the Windows Hyper-V hypervisor. An attacker can exploit this vulnerability by running a specially crafted application on a guest system that would cause the system operating Hyper-V to execute arbitrary code. The flaw lies in the way that Hyper-V validates inputs from an authenticated user on a guest OS.

CVE-2018-8367 is a remote code execution vulnerability in the Chakra scripting engine. The engine improperly handles objects in memory in the Microsoft Edge web browser that could allow an attacker to corrupt the system’s memory and execute arbitrary code with the user’s credentials.

CVE-2018-8420 is a remote code execution vulnerability in Microsoft XML Core Services MSXML. An attacker could trick the user into visiting a specially crafted, malicious website designed to invoke MSXML through a web browser, allowing the attacker to eventually run code and take control of the user’s system.

CVE-2018-8461 is a remote code execution vulnerability in Internet Explorer that exists when the web browser improperly accesses objects in memory. This bug could corrupt memory in a way that an attacker could execute arbitrary code with the same rights as the current user. A user would need to visit a specially crafted, malicious website to trigger this vulnerability.

CVE-2018-8475 is a remote code execution vulnerability in Windows OS, which exists due to the image-loading functionality improperly handling malformed image files. An attacker could exploit this bug by convincing a user to load a malformed image file from either a web page, email or other method.

CVE-2018-8332 is a remote code execution vulnerability in the Windows font library. There are multiple ways in which an attacker could exploit this flaw, including convincing the user to click on a malicious web page or providing the user with a specially crafted, malicious document.

CVE-2018-8391 is a remote code execution vulnerability in the Chakra scripting engine. An attacker can exploit this flaw if a user is logged on with an administrative account.

CVE-2018-8439 is a remote code execution vulnerability in the Windows Hyper-V hypervisor. The bug exists in Hyper-V’s validation on a host server. An attacker can exploit this flaw by running a specially crafted application on a guest operating system that could lead to the machine running Hyper-V executing arbitrary code.

CVE-2018-8447 is a remote code execution vulnerability in Internet Explorer. An attacker could exploit this vulnerability by tricking a user into visiting a specially crafted web page while using the Internet Explorer browser, or by taking advantage of a compromised website through advertisements or attachments that the user would have to click on.

CVE-2018-8456 and CVE-2018-8459 are remote code execution vulnerabilities that exist in the Chakra scripting engine’s handling of objects in memory. This bug could corrupt memory in a way that an attacker could execute arbitrary code with the same rights as the current user.

CVE-2018-8457 is a remote code execution vulnerability that exists in the way Microsoft web browsers’ scripting engines handle objects in memory. An attacker could host a specially crafted website to exploit this vulnerability, and then convince the user to visit the website while using a Microsoft web browser, or they could embed an ActiveX control that is marked “safe for initialization” in a Microsoft Office file or an application that hosts the browser’s rendering engine.

CVE-2018-8464 is a remote code execution vulnerability in Microsoft Edge’s PDF reader that exists in the way the reader handles objects in memory. An attacker could exploit this bug by convincing a user to click on a web page that contains a malicious PDF, or by hosting the PDF on websites that host user-provided content.

CVE-2018-8465CVE-2018-8466 and CVE-2018-8467 are remote code execution vulnerabilities in the Chakra scripting engine that lie in the way it handles objects in memory in the Microsoft Edge web browser. An attacker can exploit these bugs by tricking the user into opening a malicious web page, or an advertisement that is hosted on a website that allows user-provided content.

The other critical vulnerability is:


There is also coverage for 43 important vulnerabilities, 11 of which we wish to highlight.

CVE-2018-8354 is a remote code execution vulnerability that exists in the way the scripting engine handles objects in memory in the Microsoft Edge web browser. A user would need to visit a specially crafted, malicious website in order to trigger this vulnerability.

CVE-2018-8392 and CVE-2018-8393 are buffer overflow vulnerabilities in the Microsoft Jet Database Engine. To exploit these bugs, a user must open a specially crafted Excel file while using an at-risk version of Windows. An attacker could exploit these vulnerabilities to execute code on the victim’s machine at an administrator’s level.

CVE-2018-8430 is a remote code execution vulnerability in Microsoft Word 2013 and 2016. An attacker can exploit this by tricking a user into opening a specially crafted, malicious PDF.

CVE-2018-8447 is an elevation of privilege vulnerability that lies in the way Windows processes calls to Advanced Local Procedure Call (ALPC). An attacker would need to log onto the system directly in order to exploit this vulnerability, and then run a specially crafted application.

CVE-2018-8331 is a remote code execution vulnerability in Microsoft Excel that exists when the software fails to correctly handle objects in memory. A user could trigger this bug by opening a specially crafted, malicious file in an email or on a web page.

CVE-2018-8315 is an information disclosure vulnerability in Microsoft’s scripting engine that could expose uninitialized memory if exploited. An attacker could access this information by convincing a user to visit a malicious website and then leveraging the vulnerability to obtain privileged data from the browser process.

CVE-2018-8335 is a denial-of-service vulnerability in the Microsoft Server Block Message (SMB). An attacker can send a specially crafted request to the server to trigger this vulnerability.

CVE-2018-8425 is a spoofing vulnerability in the Microsoft Edge web browser. The bug lies in the way the browser handles specific HTML content. If an attacker correctly exploits this bug, a user could be tricked into thinking they are visiting a legitimate website when they are actually on a malicious page.

CVE-2018-8440 is an elevation of privilege vulnerability that occurs when Windows incorrectly handles calls to Advanced Local Procedure Call (APLC). An attacker needs to log onto the system directly to exploit this vulnerability, and then run a specially crafted application to take over the system. This vulnerability has been spotted in the wild as part of several pieces of malware.

The other vulnerabilities that are rated “important” are:

Go to Source
Author: Talos Group

Suspected Iranian Influence Operation Leverages Network of InauthenticNews Sites & Social Media Targeting Audiences in U.S., UK, LatinAmerica, Middle East

FireEye has identified a suspected influence operation that appears
to originate from Iran aimed at audiences in the U.S., U.K., Latin
America, and the Middle East. This operation is leveraging a network
of inauthentic news sites and clusters of associated accounts across
multiple social media platforms to promote political narratives in
line with Iranian interests. These narratives include anti-Saudi,
anti-Israeli, and pro-Palestinian themes, as well as support for
specific U.S. policies favorable to Iran, such as the U.S.-Iran
nuclear deal (JCPOA). The activity we have uncovered is significant,
and demonstrates that actors beyond Russia continue to engage in and
experiment with online, social media-driven influence operations to
shape political discourse.

What Is This Activity?

Figure 1 maps the registration and content promotion connections
between the various inauthentic news sites and social media account
clusters we have identified thus far. This activity dates back to at
least 2017. At the time of publication of this blog post, we continue
to investigate and identify additional social media accounts and
websites linked to this activity. For example, we have identified
multiple Arabic-language, Middle East-focused sites that appear to be
part of this broader operation that we do not address here.

Figure 1: Connections among components of
suspected Iranian influence operation

We use the term “inauthentic” to describe sites that are not
transparent in their origins and affiliations, undertake concerted
efforts to mask these origins, and often use false social media
personas to promote their content. The content published on the
various websites consists of a mix of both original content and news
articles appropriated, and sometimes altered, from other sources.

Who Is Conducting this Activity and Why?

Based on an investigation by FireEye Intelligence’s Information
Operations analysis team, we assess with moderate confidence that this
activity originates from Iranian actors. This assessment is based on a
combination of indicators, including site registration data and the
linking of social media accounts to Iranian phone numbers, as well as
the promotion of content consistent with Iranian political interests.
For example:

  • Registrant emails for the sites ‘Liberty Front Press’ and
    ‘Instituto Manquehue’ are associated with advertisements for website
    designers in Tehran and with the Iran-based site gahvare[.]com,
  • We have identified multiple Twitter accounts
    directly affiliated with the sites, as well as other associated
    Twitter accounts, that are linked to phone numbers with the +98
    Iranian country code.
  • We have observed inauthentic social
    media personas, masquerading as American liberals supportive of U.S.
    Senator Bernie Sanders, heavily promoting Quds Day, a holiday
    established by Iran in 1979 to express support for Palestinians and
    opposition to Israel.

We limit our assessment regarding Iranian origins to moderate
confidence because influence operations, by their very nature, are
intended to deceive by mimicking legitimate online activity as closely
as possible. While highly unlikely given the evidence we have
identified, some possibility nonetheless remains that the activity
could originate from elsewhere, was designed for alternative purposes,
or includes some small percentage of authentic online behavior. We do
not currently possess additional visibility into the specific actors,
organizations, or entities behind this activity. Although the
Iran-linked APT35 (Newscaster) has previously used inauthentic news
sites and social media accounts to facilitate espionage, we have not
observed any links to APT35.

Broadly speaking, the intent behind this activity appears to be to
promote Iranian political interests, including anti-Saudi,
anti-Israeli, and pro-Palestinian themes, as well as to promote
support for specific U.S. policies favorable to Iran, such as the
U.S.-Iran nuclear deal (JCPOA). In the context of the U.S.-focused
activity, this also includes significant anti-Trump messaging and the
alignment of social media personas with an American liberal identity.
However, it is important to note that the activity does not appear to
have been specifically designed to influence the 2018 U.S. midterm
elections, as it extends well beyond U.S. audiences and U.S. politics.


The activity we have uncovered highlights that multiple actors
continue to engage in and experiment with online, social media-driven
influence operations as a means of shaping political discourse. These
operations extend well beyond those conducted by Russia, which has
often been the focus of research into information operations over
recent years. Our investigation also illustrates how the threat posed
by such influence operations continues to evolve, and how similar
influence tactics can be deployed irrespective of the particular
political or ideological goals being pursued.

Additional Details

FireEye will be releasing additional details on this operation that
will lay out the clusters of influence activity identified so far, the
links between these, and how our observations support our attribution
assessment. Submit your name and email address in the box at the top
right of the page to receive the report when it is available.

Go to Source
Author: FireEye Intelligence

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

Vulnerability Spotlight: Foxit PDF Reader JavaScript Remote Code Execution Vulns


Discovered by Aleksandar Nikolic of Cisco Talos.

Talos is disclosing a pair of vulnerabilities in Foxit PDF Reader. Foxit PDF Reader is a popular free program for viewing, creating, and editing PDF documents. It is commonly used as an alternative to Adobe Acrobat Reader and has a widely used browser plugin available.


TALOS-2018-0588 / CVE-2018-3924 is an exploitable user-after-free vulnerability that exists in the JavaScript engine of Foxit’s PDF Reader. As a complete feature-rich PDF reader Foxit supports JavaScript for interactive documents and dynamic forms. When executing embedded JavaScript code a document can be cloned, which frees a lot of used objects, but the JavaScript can continue to execute, potentially leading to a user-after-free condition. This particular vulnerability lies in invoking the ‘mailForm’ method of the active document resulting in arbitrary code execution.

A specially crafted PDF file could trigger this vulnerability. There are a couple of different ways an adversary could leverage this attack including tricking a user to opening a malicious PDF or, if the browser plugin is enabled, simply viewing the document on the Internet could result in exploitation. Full details of the vulnerability can be found here.


TALOS-2018-0606 / CVE-2018-3939 is an exploitable use-after-free vulnerability found in the Javascript engine that can result in remote code execution.  As a complete feature-rich PDF reader Foxit supports JavaScript for interactive documents and dynamic forms. When executing embedded JavaScript code a document can be closed, which frees a lot of used objects, but the JavaScript can continue to execute, potentially leading to a user-after-free condition. This particular vulnerability lies in invoking the ‘createTemplate’ method of the active document resulting in arbitrary code execution.

A specially crafted PDF file could trigger this vulnerability. There are a couple of different ways an adversary could leverage this attack including tricking a user to opening a malicious PDF or, if the browser plugin is enabled, simply viewing the document on the Internet could result in exploitation. Full details of the vulnerability can be found here.

Go to Source

Author: Talos Group

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

Smoking Guns – Smoke Loader learned new tricks


Cisco Talos has been tracking a new version of Smoke Loader — a malicious application that can be used to load other malware — for the past several months following an alert from Cisco Advanced Malware Protection’s (AMP) Exploit Prevention engine. AMP successfully stopped the malware before it was able to infect the host, but further analysis showed some developments in the Smoke Loader sample resulting from this chain of malware that intrigued us. This includes one of the first uses of the PROPagate injection technique in real-world malware. Besides a report released at the end of last week describing a different RIG Exploit Kit-based campaign, we haven’t seen real-world malware using this.

Talos is very familiar with Smoke Loader. For example, it was used as a downloader for a cyberattack that was launched using the official website of Ukraine-based accounting software developer Crystal Finance Millennium (CFM) in January.

Similar to many other campaigns, the initial infection vector was an email with a malicious Microsoft Word document attached. The victims were tricked into opening the attachment and enabling the embedded macros. This started the malware-downloading chain, down to the final Smoke Loader infection and its plugins.

Smoke Loader is primarily used as a downloader to drop and execute additional malware like ransomware or cryptocurrency miners. Actors using Smoke Loader botnets have posted on malware forums attempting to sell third-party payload installs. This sample of Smoke Loader did not transfer any additional executables, suggesting that it may not be as popular as it once was, or it’s only being used for private purposes.

The plugins are all designed to steal sensitive information from the victim, specifically targeting stored credentials or sensitive information transferred over a browser — including Windows and Team Viewer credentials, email logins, and others.



As mentioned above, the infection chain started with an email and an attached malicious Word document (b98abdbdb85655c64617bb6515df23062ec184fe88d2d6a898b998276a906ebc). You can see the content of this email below.

Fig. 1 – Phishing Email

The attached Word document had an embedded macro that initiated the second stage and downloaded the Trickbot malware. (0be63a01e2510d161ba9d11e327a55e82dcb5ea07ca1488096dac3e9d4733d41).

Fig. 2 – Email attachment: IO08784413.doc

This document downloads and executes the Trickbot malware from hxxp://5[.]149[.]253[.]100/sg3.exe, or hxxp://185[.]117[.]88[.]96/sg3.exe as %TEMP%\[a-zA-Z]{6-9}.exe. These URLs have served up multiple malicious executables in the past, including samples of Trickbot.

In our Trickbot cases, the malware finally downloaded the Smoke Loader trojan (b65806521aa662bff2c655c8a7a3b6c8e598d709e35f3390df880a70c3fded40), which installed five additional Smoke Loader plugins. We are describing these plugins in detail later in the plugins section of this report.



Smoke Loader has often dropped Trickbot as a payload. This sample flips the script, with our telemetry showing this Trickbot sample dropping Smoke Loader. This is likely an example of malware-as-a-service, with botnet operators charging money to install third-party malware on infected computers. We haven’t analysed the Trickbot sample further, but for your reference, we are providing the Trickbot configuration here (IP addresses redacted with bracketed dots for security reasons.):


<module name=”systeminfo” ctl=”GetSystemInfo”/>
<module name=”injectDll”/>


Malware frequently iterates through process lists to find a process to inject. Security researchers know this process well and have created many tools to track the Windows APIs used in this technique, like CreateToolhelp32Snapshot. This Smoke Loader sample avoids iterating through process lists by calling the Windows API GetShellWindow to get a handle to the shell’s desktop window, then calling GetWindowThreadProcessId to get the process ID of Explorer.exe.

Smoke Loader then uses standard injection API to create and write two memory sections in Explorer, one for shellcode and another for a UxSubclassInfo structure to be used later for PROPagate injection.

GetShellWindow -> GetWindowThreadProcessId -> NtOpenProcess -> NtCreateSection -> NtMapViewOfSection x2 -> NtUnmapViewOfSection

The window handle retrieved from the previous call to GetShellWindow has a second purpose. Smoke Loader uses EnumChildWindows to iterate through each of the handle’s child windows to find one containing the property UxSubclassInfo, which indicates it is vulnerable to PROPagate injection.

PROPagate injection was first described by a security researcher in late 2017, though there were no public POCs available when Smoke Loader started using it. The Smoke Loader developers likely used publicly available notes on PROPagate to recreate the technique.

Fig. 3 – PROPagate Injection

For each child window, the injector calls EnumPropsA to iterate through window properties until it finds UxSubclassInfo. This function also showcases some of the anti-analysis techniques employed by this sample’s packer. There are several unnecessary jumps for control flow obfuscation, including simple opaque predicates leading to junk code.

“Deobf_next_chunk” takes arguments for size and offset for the next chunk of code to deobfuscate and execute, so the bulk of the malicious code is deobfuscated as needed, and can be obfuscated again once the next chunk is loaded. The obfuscation method is a simple one-byte XOR with the same hardcoded value for every piece.
These anti-analysis techniques are accompanied by anti-debugging and anti-VM checks, as well as threads dedicated to scanning for processes and windows belonging to analysis tools. These features complicate forensics, runtime AV scanners, tracing, and debugging.

Fig. 4 – Trigger malicious event handler via WM_NOTIFY and WM_PAINT

Once the shellcode and UxSubclassInfo data are written to the remote process, the injector calls SetPropA to update the property for the window, then sends WM_NOTIFY and WM_PAINT messages to the target window to force it to trigger the malicious event handler that executes the injected shellcode.


Smoke Loader received five interesting plugins instead of additional payloads. Each plugin was given its own Explorer.exe process to execute in, and the malware used older techniques to inject each plugin into these processes. Each Explorer.exe process is created with the option CREATE_SUSPENDED, the shellcode is injected, then executed using ResumeThread. This is noisy and leaves six Explorer.exe processes running on the infected machine.


As mentioned above, the plugins are all designed to steal sensitive information from the victim, explicitly targeting stored credentials or sensitive information transferred over a browser. Each plugin uses the mutex “opera_shared_counter” to ensure multiple plugins don’t inject code into the same process at the same time.

Plugin 1:

This is the largest plugin with approximately 2,000 functions. It contains a statically linked SQLite library for reading local database files.

  • It targets stored info for Firefox, Internet Explorer, Chrome, Opera, QQ Browser, Outlook, and Thunderbird.
  • Recursively searches for files named logins.json which it parses for hostnameencryptedUsername, and encryptedPassword.
  • vaultcli.dll – Windows Credential Manager
  • POP3, SMTP, IMAP Credentials

Plugin 2:

This plugin recursively searches through directories looking for files to parse and exfiltrate.

The Bat!

Plugin 3:

This one injects into browsers to intercept credentials and cookies as they are transferred over HTTP and HTTPS.

  • If “fgclearcookies” is set, kills browser processes and deletes cookies.
  • iexplore.exe and microsoftedgecp.exe 
    • HttpSendRequestA 
    • HttpSendRequestW 
    • InternetWriteFile 
    • firefox.exe
  • PR_Write in nspr4.dll or nss3.dll
  • chrome.exe 
    • unknown function inside chrome.dll
  • opera.exe 
    • unknown function inside opera_browser.dll or opera.dll

Plugin 4:

This hooks ws2_32!send and ws2_32!WSASend to attempt to steal credentials for ftp, smtp, pop3, and imap

Plugin 5:

This one injects code into TeamViewer.exe to steal credentials


B98abdbdb85655c64617bb6515df23062ec184fe88d2d6a898b998276a906ebc (IO08784413.doc)
0be63a01e2510d161ba9d11e327a55e82dcb5ea07ca1488096dac3e9d4733d41 (Trickbot)
b65806521aa662bff2c655c8a7a3b6c8e598d709e35f3390df880a70c3fded40 (Smoke Loader)

Mutex: opera_shared_counter

Trickbot IPs:

Smoke Loader domains:

Dropped File: %appdata%\Microsoft\Windows\[a-z]{8}\[a-z]{8}.exe

Scheduled Task: Opera scheduled Autoupdate [0-9]{1-10}


We have seen that the trojan and botnet market is constantly undergoing changes. The players are continuously improving their quality and techniques. They modify these techniques on an ongoing basis to enhance their capabilities to bypass security tools. This clearly shows how important it is to make sure all our systems are up to date. Organizations can utilize a multi-layered defensive approach to detect and protect against these kinds of threats. Talos continues to monitor these campaigns as they evolve to ensure that defenses protect our customers. We strongly encourage users and organizations to follow recommended security practices, such as installing security patches as they become available, exercising caution when receiving messages from unknown third parties, and ensuring that a robust offline backup solution is in place. These practices will help reduce the threat of a compromise, and should aid in the recovery of any such attack.

Go to Source
Author: Talos Group

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