FireEye’s Innovation and Custom Engineering (ICE) team released a
tool today called GoCrack that allows red
teams to efficiently manage password cracking tasks across multiple
GPU servers by providing an easy-to-use, web-based real-time UI
(Fig…
Executive Summary
On Oct. 24, 2017, coordinated strategic web compromises started to
distribute BADRABBIT ransomware to unwitting users. FireEye appliances
detected the download attempts and blocked our user base from
infection. During our inves…
I (Matthew Haigh) recently contributed to FLARE’s FakeNet-NG
network simulator by adding content-based protocol detection and
configuration. This feature is useful for analyzing malware that uses
a protocol over a non-standard port; for example, …
Introduction
Exploit kit (EK) use has been on the decline since late 2016;
however, certain activity remains consistent. The Magnitude Exploit
Kit is one such example that continues to affect users, particularly
in the APAC region.
In Figure 1,…
Another year, another successful Flare-On Challenge. I’d first like
to thank our challenge authors for their hard work developing each of
the challenges, and also for writing up their solutions:
Our popularity and participation continued to swell, with a 57
percent increase in total players (3240) and a 304 percent increase in
the number of players who solved at least one challenge (2617) over
last year. The overall difficulty also appears to have increased this
year, with only 4.3 percent of players (140 total) completing the
challenge, a decrease from the 6 percent who completed last
year’s challenge.
The following graph shows the total number of players who solved
each stage of the challenge:
The 140+ players who completed the challenge will have their names
forever listed on our hall of fame, and they will receive a prize. The
prize this year is this massive Flare pin that measures nearly 4
inches across:
This pin is a great item to sport on your backpack or affix to your
lanyard. The above is a mock-up from the manufacturer – we expect to
receive them in the next few weeks and will begin shipping them to the
winners soon after.
All the binaries from this year’s challenge are now posted on the Flare-On
website (password: flare), and here are the solutions written by
each challenge author:
We can confirm that FireEye devices detected and stopped spear
phishing emails sent on Sept. 22, 2017, to U.S. electric companies by
known cyber threat actors likely affiliated with the North Korean
government. This activity was early-stage recon…
We observed several high-volume FormBook malware distribution
campaigns primarily taking aim at Aerospace, Defense Contractor, and
Manufacturing sectors within the U.S. and South Korea during the past
few months. The attackers involved in these email campaigns leveraged
a variety of distribution mechanisms to deliver the information
stealing FormBook malware, including:
The PDF and DOC/XLS campaigns primarily impacted the United States
and the Archive campaigns largely impacted the Unites States and South Korea.
FormBook is a data stealer and form grabber that has been advertised
in various hacking forums since early 2016. Figure 1 and Figure 2 show
the online advertisement for the malware.
Figure 1: FormBook advertisement
Figure 2: FormBook underground pricing
The malware injects itself into various processes and installs
function hooks to log keystrokes, steal clipboard contents, and
extract data from HTTP sessions. The malware can also execute commands
from a command and control (C2) server. The commands include
instructing the malware to download and execute files, start
processes, shutdown and reboot the system, and steal cookies and local passwords.
One of the malware’s most interesting features is that it reads
Windows’ ntdll.dll module from disk into memory, and calls its
exported functions directly, rendering user-mode hooking and API
monitoring mechanisms ineffective. The malware author calls this
technique “Lagos Island method” (allegedly originating from
a userland rootkit with this name).
It also features a persistence method that randomly changes the
path, filename, file extension, and the registry key used for persistence.
The malware author does not sell the builder, but only sells the
panel, and then generates the executable files as a service.
FormBook is a data stealer, but not a full-fledged banker (banking
malware). It does not currently have any extensions or plug-ins. Its
capabilities include:
FormBook can receive the following remote commands from the C2 server:
The C2 domains typically leverage less widespread, newer generic
top-level domains (gTLDs) such as .site, .website, .tech, .online, and .info.
The C2 domains used for this recently observed FormBook activity
have been registered using the WhoisGuard privacy protection service.
The server infrastructure is hosted on BlazingFast.io, a Ukrainian
hosting provider. Each server typically has multiple FormBook panel
installation locations, which could be indicative of an affiliate model.
Our analysis in this blog post is based on the following
representative sample:
|
Filename |
MD5 Hash |
Size (bytes) |
Compile Time |
|
Unavailable |
CE84640C3228925CC4815116DDE968CB |
747,652 |
2012-06-09 |
Table 1: FormBook sample details
The malware is a self-extracting RAR file that starts an AutoIt
loader. The AutoIt loader compiles and runs an AutoIt script. The
script decrypts the FormBook payload file, loads it into memory, and
then executes it.
The FormBook malware copies itself to a new location. The malware
first chooses one of the following strings to use as a prefix for its
installed filename:
ms, win, gdi, mfc, vga, igfx, user, help, config, update, regsvc,
chkdsk, systray, audiodg, certmgr, autochk, taskhost, colorcpl,
services, IconCache, ThumbCache, Cookies
It then generates two to five random characters and appends those to
the chosen string above
followed by one of the following file extensions:
If the malware is running with elevated privileges, it copies itself
to one of the following directories:
If running with normal privileges, it copies itself to one of the
following directories:
The malware uses the same aforementioned string list with a random
string to create a prefix, appends one to five random characters, and
uses this value as the registry value name.
The malware configures persistence to one of the following two
locations depending on its privileges:
The malware creates two 16-byte mutexes. The first mutex is the
client identifier (e.g., 8-3503835SZBFHHZ). The second mutex value is
derived from the C2 information and the username (e.g., LL9PSC56RW7Bx3A5).
The malware then iterates over a process listing and calculates a
checksum value of process names (rather than checking the name itself)
to figure out which process to inject. The malware may inject itself
into browser processes and explorer.exe. Depending on the target
process, the malware installs different function hooks (see
the Function Hooks section for further detail).
The malware uses several techniques to complicate malware analysis:
The results of these tests are then placed into a 16-byte array, and
a SHA1 hash is calculated on the array, which will be later used as
the decryption key for subsequent strings (e.g. DLL names to load).
Failed checks may go unnoticed until the sample tries to load the
supporting DLLs
(kernel32.dll and advapi32.dll).
The correct 16-byte array holding the result of the checks is:
Having a SHA1 value of:
After completing all anti-analysis checks, the sample manually maps
ntdll.dll from disk into memory and uses its exported functions
directly in the code. All API functions will have a small stub
function in the code that looks up the address of the API in the
mapped ntdll.dll using the CRC32 checksum of the API name, and sets up
the parameters on the stack.
This will be followed by a direct register call to the mapped
ntdll.dll module. This makes regular debugger breakpoints on APIs
inoperable, as execution will never go through the system mapped ntdll.dll.
The sample loops through all the running processes to find
explorer.exe by the CRC32 checksum of its process name. It then
injects into explorer.exe using the following API calls (avoiding more
commonly identifiable techniques such as WriteProcessMemory and CreateRemoteThread):
The injected code in the hijacked instance of explorer.exe randomly
selects and launches (as a suspended process) a built-in Windows
executable from the following list:
The original process reads the randomly selected executable from the
memory of explorer.exe and migrates into this new process via
NtMapViewOfSection, NtSetContextThread, and NtQueueUserAPC.
The new process then deletes the original sample and sets up
persistence (see the Persistence section for more detail). It
then goes into a loop that constantly enumerates running processes and
looks for targets based on the CRC32 checksum of the process name.
Targeted process names include, but are not limited to:
After injecting into any of the target processes, it sets up
user-mode API hooks based on the process.
The malware installs different function hooks depending on the
process. The primary purpose of these function hooks is to log
keystrokes, steal clipboard data, and extract authentication
information from browser HTTP sessions. The malware stores data in
local password log files. The directory name is derived from the C2
information and the username (the same as the second mutex created above: LL9PSC56RW7Bx3A5).
However, only eight bytes from this value are used as the directory
name (e.g., LL9PSC56). Next, the first three characters from the
derived directory name are used as a prefix for the log file followed
by the string log. Following this prefix are names corresponding to
the type of log file. For example, for Internet Explorer passwords,
the following log file would be created:
The following are the password log filenames without the prefix:
One additional file that does not use the .INI file extension is a
screenshot file:
Keylog/clipboard monitoring:
Browser hooks:
The browser hooks look for certain strings in the content of HTTP
requests and, if a match is found, information about the request is
extracted. The targeted strings are:
The malware communicates with the following C2 server using HTTP requests:
As seen in Figure 3, FormBook sends a beacon request (controlled by
a timer/counter) using HTTP GET with an “id” parameter in
the URL.
Figure 3: FormBook beacon
The decoded “id” parameter is as follows:
Where:
The malware sends HTTP requests using hard-coded HTTP header values.
The HTTP headers shown in Figure 4 are hardcoded.
Figure 4: Hard-coded HTTP header values
Messages to the C2 server are sent RC4 encrypted and Base64 encoded.
The malware uses a slightly altered Base64 alphabet, and also uses the
character “.” instead of “=” as the pad character:
The RC4 key is created using an implementation of the SHA1 hashing
algorithm with the C2 URL. The standard SHA1 algorithm reverses the
DWORD endianness at the end of the algorithm. This implementation does
not, which results in a reverse endian DWORDs. For example, the SHA1
hash for the aforementioned URL
is “9b198a3cfa6ff461cc40b754c90740a81559b9ae,” but when
reordering the DWORDs, it produces the correct RC4
key: 3c8a199b61f46ffa54b740cca84007c9aeb95915. The first DWORD
“9b198a3c” becomes “3c8a199b.”
Figure 5 shows an example HTTP POST request.
Figure 5: Example HTTP POST request
In this example, the decoded result is:
When a command is sent by the C2 server, the HTTP response body has
the format shown in Figure 6.
Figure 6: FormBook C2 server response
with command
The data begins with the magic bytes “FBNG,” and a
one-byte command code from hex bytes 31 to 39 (i.e., from
“1” to “9”) in clear text. This is then followed
by the RC4-encoded command data (where the RC4 key is the same as the
one used for the request). In the decrypted data, another occurrence
of the magic FBNG bytes indicates the end of the command data.
The malware accepts the commands shown in Table 2.
|
Command |
Parameters |
Purpose |
|
‘1’ (0x31) |
<pe_file_data>FBNG |
Download and execute file from |
|
‘2’ (0x32) |
<pe_file_data>FBNG |
Update bot on host machine |
|
‘3’ (0x33) |
FBNG |
Remove bot from host machine |
|
‘4’ (0x34) |
<command_string>FBNG |
Launch a command via |
|
‘5’ (0x35) |
FBNG |
Clear browser cookies |
|
‘6’ (0x36) |
FBNG |
Reboot operating system |
|
‘7’ (0x37) |
FBNG |
Shutdown operating system |
|
‘8’ (0x38) |
FBNG |
Collect email/browser passwords and create a |
|
‘9’ (0x39) |
<zip_file_data>FBNG |
Download and unpack ZIP archive into |
Table 2: FormBook accepted commands
FireEye researchers observed FormBook distributed via email
campaigns using a variety of different attachments:
The PDF campaigns leveraged FedEx and DHL shipping/package delivery
themes (Figure 7 and Figure 8), as well as a document-sharing theme.
The PDFs distributed did not contain malicious code, just a link to
download the FormBook payload.
The staging servers (shown in Table 3) appeared to be compromised websites.
Figure 7: Example PDF campaign email lure
with attachment
Figure 8: Example PDF campaign attachment
|
Sample Subject Lines |
Shorted URLs |
Staging Servers |
|
<Recipient’s_Name> – You have a <Recipient’s_Name> |
tny[.]im/9TK tny[.]im/9Uw tny[.]im/9G1 tny[.]im/9Q6 tny[.]im/9H1 tny[.]im/9R7 tny[.]im/9Tc tny[.]im/9RM tny[.]im/9G0 tny[.]im/9Oq tny[.]im/9Oh |
maxsutton[.]co[.]uk solderie[.]dream3w[.]com lifekeeper[.]com[.]au brinematriscript[.]com jaimagroup[.]com |
Table 3: Observed email subjects and download
URLs for PDF campaign
Based on data from the tny.im-shortened links, there were a total of
716 hits across 36 countries. As seen in Figure 9, most of the
malicious activity from the PDF campaign impacted the United States.
Figure 9: Geolocation statistics from
tny.im URL shortener
The email campaigns distributing DOC and XLS files relied on the use
of malicious macros to download the executable payload. When the
macros are enabled, the download URL retrieves an executable file with
a PDF extension. Table 4 shows observed email subjects and download
URLs used in these campaigns.
|
Sample Subject Lines |
Staging Server |
URL |
|
61_Invoice_6654 ACS PO 1528 NEW NEW ORDER – PO#074 REQUEST FOR URGENT PURCHASE ORDER 1800027695 |
sdvernoms[.]ml |
/oc/runpie.pdf /sem/essen.pdf /drops/microcore.pdf /damp/10939453.pdf /sem/essentials.exe /oc/runpie.pdf /sem/ampama.pdf /js/21509671Packed.pdf /sem/essen.pdf |
Table 4: Observed email subjects and download
URLs for the DOC/XLS campaign
FireEye detection technologies observed this malicious activity
between Aug. 11 and Aug. 22, 2017 (Figure 10). Much of the activity
was observed in the United States (Figure 11), and the most targeted
industry vertical was Aerospace/Defense Contractors (Figure 12).
Figure 10: DOC/XLS campaign malicious
activity by date
Figure 11: Top 10 countries affected by
the DOC/XLS campaign
Figure 12: Top 10 industry verticals
affected by the DOC/XLS campaign
The Archive campaign delivered a variety of archive formats,
including ZIP, RAR, ACE, and ISO, and accounted for the highest
distribution volume. It leveraged a myriad of subject lines that were
characteristically business related and often regarding payment or
purchase orders:
|
Sample Subject Lines |
|
HSBC MT103 PAYMENT CONFIRMATION Our Ref: MT103 PAYMENT CONFIRMATION Our Ref: Fwd: INQUIRY RFQ-18 Fw: Remittance Confirmation NEW ORDER FROM PO. NO.: 10701 – Re: bgcqatar project Re: Purchase Order #234579 purchase order for August017 |
FireEye detection technologies observed this campaign activity
between July 18 and Aug. 17, 2017 (Figure 13). Much of the activity
was observed in South Korea and the United States (Figure 14), with
the Manufacturing industry vertical being the most impacted (Figure 15).
Figure 13: Archive campaign malicious
activity by date
Figure 14: Top 10 countries affected by
the Archive campaign
Figure 15: Top 10 industry verticals
affected by the Archive campaign
While FormBook is not unique in either its functionality or
distribution mechanisms, its relative ease of use, affordable pricing
structure, and open availability make FormBook an attractive option
for cyber criminals of varying skill levels. In the last few weeks,
FormBook was seen downloading other malware families such as NanoCore.
The credentials and other data harvested by successful FormBook
infections could be used for additional cyber crime activities
including, but not limited to: identity theft, continued phishing
operations, bank fraud and extortion.
Event tracing for Windows (ETW) is a lightweight
logging facility first introduced with Windows 2000. Originally
intended as a software diagnostic, troubleshooting and performance
monitoring tool, it was greatly expanded in Windows Vista to create a
lightweight
debugging mechanism.
The basic architecture of ETW has three discrete components:
providers, controllers, and consumers. The providers supply the trace
data, controllers control capture sessions, and the consumers process
the data returned from the providers. Figure 1 shows an overview of
this architecture.
Figure 1: ETW Architecture
Windows 7 has more than 600 providers installed by default, many of
which provide verbose trace data. ETW data can be used to conduct
research into almost any area of the OS without the need for a
debugger. A default Windows installation ships with all the tools
needed to capture ETW data, but these tools are somewhat inflexible.
Another drawback is that a different tool is usually needed when
analyzing the captured data.
Prior to making the decision to create an entirely new project,
research was conducted to see if there was an existing project that
would work. Several projects were found, with KrabsETW from
Microsoft and Google’s pyetw
looking the most promising. Neither of these were quite right,
however, since KrabsETW is not written in Python and therefore not
compatible with existing projects, and pyetw is no longer maintained.
We found simple programmatic access to ETW using Python was missing.
Pywintrace is a
Python package developed by the FireEye Innovation and Custom
Engineering (ICE) team to fill the need for a flexible wrapper around
Windows APIs to accelerate ETW research. Using Python’s ctypes, the
team created a module that can create and control a capture session,
as well as process trace events. The package contains three main classes:
Using pywintrace is simple, and it can be extended as needed to fit
nearly any desired capture scenario. Typically, a user would create an
instance of the ETW class to begin capturing data. Figure 2 shows a
simple example of this.
Figure 2: Simple capture script
In Figure 2, the ETW provider “Some Provider” with GUID
“11111111-1111-1111-1111-111111111111” is being captured, and the
resultant message data is written to the console. The run function in
Figure 2 is a helper function that will process the messages returned
by the system. If desired, a user may specify their own callback
function and process the messages however they choose.
The example in Figure 2 is simple, but shows how easy pywintrace is
to use. For more examples, see the examples directory of the
pywintrace package.
While there are many interesting providers to investigate, a blog
published by Microsoft demonstrated the usefulness of the Microsoft-Windows-WinINet
provider on Windows 7. Another interesting WinInet provider, Microsoft-Windows-WinINet-Capture,
was added with Windows 10. Using pywintrace the ICE team was easily
able to perform an ETW capture using both. Since the ETW messages are
delivered chronologically by the system, there is no need for
special processing when using multiple providers. Figure 3 shows some
of this capture data.
Figure 3: ETW traffic capture
At a minimum, each message contains a message ID, an associated
event type name, description, task name, and an EventHeader. In Figure
3 the first message (ID 108), a Microsoft-Windows-WinINet provider
message, shows a request handle being created for the server at
‘www.google.com’. Of note is that domain specific information is
returned, and is emitted from several other providers as well –
without the need for a Layered Service Provider (LSP) or driver.
In the second message (ID 2001), a Microsoft-Windows-WinINet-Capture
provider message, shows the request data being sent to the server. The
‘payload’ field of this message is a hex stream of the plaintext
traffic. The decoded data is shown in Figure 4.
Figure 4: Decoded HTTPS traffic
It should be noted that this capture was performed on a Windows 10
machine using the Edge browser. Other browser and OS combinations may
provide different results. This information can be very useful,
however, since it could be used to detect malicious activity that
would normally be masked by a layer of encryption.
Figure 5 shows a snippet of a WinINet capture of traffic generated
by a malware sample in a controlled environment.
Figure 5: Malicious traffic
Here the malware is seen beaconing out to its command and control
(C2) server and requesting a web page. This single message shows the
URL of the page being requested as well as the Process ID and Thread
ID that originated the malicious activity. From this message, the URL
could be used to determine if the request was malicious and the
process / thread information could be used to track down the malware –
especially in cases of process hollowing or DLL injection.
ETW provides a very powerful lightweight trace mechanism
conveniently baked into Windows. Among other things it can be used to
potentially detect malicious activity on an endpoint. Using pywintrace
to capture ETW data is simpler than using multiple tools to do the
same job, and since it is written in Python it is easy to modify for
whatever is needed. This makes the job of slogging through the
hundreds of ETW providers much easier, and accelerates efforts to find
interesting providers.
Download pywintrace today!
Special thanks to the entire ICE team. ICE is a small, highly
trained, team of engineers that incubate and deliver capabilities that
matter to our products, our clients and our customers. ICE is always
looking for exceptional candidates interested in solving challenging
problems quickly.
Also, thanks to Microsoft for their extensive blog posts and
documentation on ETW.
Manual dynamic analysis is an important concept. It enables us to
observe the behavior of a sophisticated malware sample or exploit by
executing it in a controlled environment. The information gathered
through this process is often crucial in gai…
FireEye recently detected a malicious Microsoft Office RTF document
that leveraged CVE-2017-8759,
a SOAP WSDL
parser code injection vulnerability. This vulnerability allows a
malicious actor to inject arbitrary code during the parsing of SOAP
WSDL definition contents. FireEye analyzed a Microsoft Word document
where attackers used the arbitrary code injection to download and
execute a Visual Basic script that contained PowerShell commands.
FireEye shared the details of the vulnerability with Microsoft and
has been coordinating public disclosure timed with the release of a
patch to address the vulnerability and security guidance, which can be
found here.
FireEye email, endpoint and network products detected the malicious documents.
The malicious document, “Проект.doc” (MD5:
fe5c4d6bb78e170abf5cf3741868ea4c), might have been used to target a
Russian speaker. Upon successful exploitation of CVE-2017-8759, the
document downloads multiple components (details follow), and
eventually launches a FINSPY payload (MD5: a7b990d5f57b244dd17e9a937a41e7f5).
FINSPY malware, also reported as FinFisher or WingBird,
is available for purchase as part of a “lawful intercept” capability.
Based on this and previous use of FINSPY,
we assess with moderate confidence that this malicious document was
used by a nation-state to target a Russian-speaking entity for cyber
espionage purposes. Additional detections by FireEye’s Dynamic Threat
Intelligence system indicates that related activity, though
potentially for a different client, might have occurred as early as
July 2017.
A code injection vulnerability exists in the WSDL parser module
within the PrintClientProxy method (http://referencesource.microsoft.com/
– System.Runtime.Remoting/metadata/wsdlparser.cs,6111). The
IsValidUrl does not perform correct validation if provided data that
contains a CRLF sequence. This allows an attacker to inject and
execute arbitrary code. A portion of the vulnerable code is shown in
Figure 1.
Figure 1: Vulnerable WSDL Parser
When multiple address definitions are provided in a SOAP
response, the code inserts the “//base.ConfigureProxy(this.GetType(),”
string after the first address, commenting out the remaining
addresses. However, if a CRLF sequence is in the additional addresses,
the code following the CRLF will not be commented out. Figure 2 shows
that due to lack validation of CRLF, a
System.Diagnostics.Process.Start method call is injected. The
generated code will be compiled by csc.exe of .NET framework, and
loaded by the Office executables as a DLL.
Figure 2: SOAP definition VS Generated code
The attacks that FireEye observed in the wild leveraged a Rich Text
Format (RTF) document, similar to the CVE-2017-0199
documents we previously reported on. The malicious sampled contained
an embedded SOAP monikers to facilitate exploitation (Figure 3).
Figure 3: SOAP Moniker
The payload retrieves the malicious SOAP WSDL definition from an
attacker-controlled server. The WSDL parser, implemented in
System.Runtime.Remoting.ni.dll of .NET framework, parses the content
and generates a .cs source code at the working directory. The csc.exe
of .NET framework then compiles the generated source code into a
library, namely http[url path].dll. Microsoft Office then loads the
library, completing the exploitation stage. Figure 4 shows an example
library loaded as a result of exploitation.
Figure 4: DLL loaded
Upon successful exploitation, the injected code creates a new
process and leverages mshta.exe to retrieve a HTA script named
“word.db” from the same server. The HTA script removes the source
code, compiled DLL and the PDB files from disk and then downloads and
executes the FINSPY malware named “left.jpg,” which in spite of the
.jpg extension and “image/jpeg” content-type, is actually an
executable. Figure 5 shows the details of the PCAP of this malware transfer.
Figure 5: Live requests
The malware will be placed at
%appdata%\Microsoft\Windows\OfficeUpdte-KB[ 6 random numbers ].exe.
Figure 6 shows the process create chain under Process Monitor.
Figure 6: Process Created Chain
The “left.jpg” (md5: a7b990d5f57b244dd17e9a937a41e7f5) is a variant
of FINSPY. It leverages heavily obfuscated code that employs a
built-in virtual machine – among other anti-analysis techniques – to
make reversing more difficult. As likely another unique anti-analysis
technique, it parses its own full path and searches for the string
representation of its own MD5 hash. Many resources, such as analysis
tools and sandboxes, rename files/samples to their MD5 hash in order
to ensure unique filenames. This variant runs with a mutex of “WininetStartupMutex0”.
CVE-2017-8759 is the second zero-day vulnerability used to
distribute FINSPY uncovered by FireEye in 2017. These exposures
demonstrate the significant resources available to “lawful intercept”
companies and their customers. Furthermore, FINSPY has been sold to
multiple clients, suggesting the vulnerability was being used against
other targets.
It is possible that CVE-2017-8759 was being used by additional
actors. While we have not found evidence of this, the zero day being
used to distribute FINSPY in April 2017, CVE-2017-0199 was
simultaneously being used by a financially motivated actor. If the
actors behind FINSPY obtained this vulnerability from the same source
used previously, it is possible that source sold it to additional actors.
Thank you to Dhanesh Kizhakkinan, Joseph Reyes, FireEye Labs Team,
FireEye FLARE Team and FireEye iSIGHT Intelligence for their
contributions to this blog. We also thank everyone from the Microsoft
Security Response Center (MSRC) who worked with us on this issue.
