Aug 17, 2014
Breaking News: Sed ut perspiciatis, unde omnis iste natus error sit voluptatem accusantium doloremque laudantium

Category: Zero-Day

Emotet v4 Analysis

01Latest news, Malware, ReverseEngineering, Zero-DayTags: , , ,


Emotet is a modular Trojan horse, which was firstly noticed in June 2014 by Trend Micro. This malware is related to other types like Geodo, Bugat or Dridex, which are attributed by researches to the same family.

Emotet was discovered as an advanced banker – it’s first campaign targeted clients of German and Austrian banks. Victims’ bank accounts were infiltrated by a web browser infection which intercept communication between webpage and bank servers. In such scenario, malware hooks specific routines to sniff network activity and steal information. This technique is typical for modern banking malware and is widely known as Man-in-the-Browser attack.

Next, modified release of Emotet banker (v2) has taken advantage of another technique – automation of stealing money from hijacked bank accounts using ATSs (Automated Transfer Systems, more informations on page 20 of CERT Polska Report 2013). This technology is also used in other bankers. Good examples are ISFB (Gozi) or Tinba.

At the beginning of April 2017, we observed wide malspam campaign in Poland, distributing fraudulent mails. E-mails were imitating delivery notifications from DHL logistics company and contained malicious link, which referred to brand-new, unknown variant of Emotet.

Malware distributed in this campaign differed from previously known versions. Behavior and communication methods were similar, but malware used different encryption and we noticed significant changes in its code. Thus we called this modification version 4.


Links from the phishing campaign pointed to a dropper, which downloaded and executed malware. Dropper was written in Javascript and wasn’t highly obfuscated. It was fairly easy to notice, that strings with distribution site URLs were just reversed.

$uaU$Fh71K_E6TQAdMPz = function(n) {
if (typeof $uaU$Fh71K_E6TQAdMPz.list[n] == string) return $uaU$Fh71K_E6TQAdMPz.list[n].split().reverse().join();
return $uaU$Fh71K_E6TQAdMPz.list[n];
$uaU$Fh71K_E6TQAdMPz.list = [
tamroF eliF detroppuS toN,
.)dedoced yltcerroc t’nsaw dna tnemhcatta liame na sa tnes saw ti ,elpmaxe rof( deriaper eb ton dluoc dna degamad si elif ehT .tnemucod siht gninepo rorre na saw erehT ];

Distribution sites found in dropper:


Main module:

An interesting thing in Emotet is its modular structure. Main module dropped by script doesn’t contain anything harmful and is used only to download another modules from C&C, which perform specific tasks. Sample dropped by script is protected using some generic packer to avoid recognition by AV software.

After unpacking, malware loads libraries and resolves WinAPI routines used in encryption and communication with C&C. Names of specific functions are obfuscated and stored as array of hashes. Emotet uses simple sdbm hash function for this purpose. To make hashes more varied, values are additionally XORed with some constant specified in binary.

int hashValue = 0;
for ( char c = *libraryName; *libraryName; c = *(++libraryName) )
hashValue = c + 65599 * hashValue;
hashValue = xorKey ^ hashValue;

Strings that are distinctive for Emotet are also encoded using 4-byte XOR key, different for each string.

Main executable file contains also a list of IP addresses of C&C servers. Similar to previous versions, sample communicates with Command&Control using plain HTTP.


The most significant change in new version is usage of different encryption algorithm. In previous releases, communication was encrypted using RC4. In fourth version, Emotet switched to 128-bit AES in CBC mode.

Intercepted request:

GET / HTTP/1.1
Cookie: DD29=e8fd7YpIy2Ui+U7bz1/cQD9bH4KHshzaN2SpKoPEnC1D85K4Zrwdb6dBoHoDC5GgvcgecLN20kpk1lQxus6AJEiutWK4hBSWFbQUmtyr3LxI+/3MFdKn1lo7nWyEw+sCzKL6y34njzJwoDwd3I5BJD0NqUL+iEnbB1EWXQhxcXihFeFS+TlRsuMxOl3Xmyo2p0FuHX+hyGoO19dzLpEMK1LhXGkCkha+kPGFqfxECUoQndFLiMRgXAj4Omw/Ywc6Ba+9d5fyZNLEKbtkxsfO3KmQSLoE4TkITRri1kSMCqnNlb7PTroCQmoJvRHBiEGla6VzgmCQ5tsspBIuaWc2ct9hX9c4SLZbTnW6mPjLIh4VeDJ7gNpwhedyLHcnr3GWjILLwFPk7RmgHglXXI2qEOXcwbRhtaNuI8RrkMQj37Rov147wEGBtt+GlQR9/9oFXoBXH9f6m5K4ULP3CEnDGGJVEtfkgt7yZ082wAIfVzow1szvMF4bF7MFaCPbHA9hygyf9Uc8GwDjM4CndFxUwROWmEgQKjIk24PIj5Y+oz4jF
User-Agent: Mozilla/5.0 (compatible; MSIE 8.0; Windows NT 5.1; SLCC1; .NET CLR 1.1.4322)
Connection: Keep-Alive
Cache-Control: no-cache

Request body is passed in Cookie header. Cookie’s key is random 16-bit hexadecimal number, with Base64-encoded binary blob as value.

After decoding, structure of request is described below:

Offset Field name
0..95 asymmetrically encrypted 128-bit AES key used for request encryption
96..115 SHA1 hash of plaintext request body
116..x Request body, AES-128-CBC encrypted

Before sending, malware performs key generation. In the first stage, Emotet loads 768-bit RSA public key, stored in executable. Then, AES symmetric key is generated using cryptographically secure PRNG (CryptGenKey). Finally, generated key is encrypted using previously loaded public key and attached to the request using PKCS#1v2.0 (OAEP) padding.

Cryptography is based on Microsoft CryptoAPI mechanisms.

Key generation and public key import:

if ( fn_CryptAcquireContextW(cryptCtx->hProv, 0, 0, PROV_RSA_AES, 0xF0000040) )
if ( fn_CryptDecodeObjectEx(
&prsaKeyLen) )
v2 = fn_CryptImportKey(cryptCtx->hProv, prsaKey, prsaKeyLen, 0, 0, &cryptCtx->hCryptRSA);
if ( v2 )
if ( fn_CryptGenKey(cryptCtx->hProv, CALG_AES_128, CRYPT_MODE_CBC, &cryptCtx->hCryptAES) )
if ( fn_CryptCreateHash(cryptCtx->hProv, CALG_SHA1, 0, 0, &cryptCtx->hCryptSHA1) )
return 1;
fn_CryptReleaseContext(cryptCtx->hProv, 0);

Request encryption:

if ( !fn_CryptDuplicateHash(cryptCtx->hCryptSHA1, 0, 0, &hHash) )
goto ERROR;
memmove(pRequest, req->bufPtr, req->bufLen);
if ( fn_CryptEncrypt(cryptCtx->hCryptAES, hHash, 1, 0, pRequest, &dwRequestLen, dwBufLen) )
if ( fn_CryptExportKey(cryptCtx->hCryptAES, cryptCtx->hCryptRSA, 1, CRYPT_OAEP, encKey, &encKeyLen) )
memmove(encReq, encKey, 96)
if ( fn_CryptGetHashParam(hHash, HP_HASHVAL, encReq + 96, &shaLen, 0) )
result = 1;
// …

Communication with C&C:

Received response is presented below:








Communication protocol is based on Google Protocol Buffers. Protocol Buffers is a mechanism, which allows developers to simply build own protocols using set of message structure declarations, written in a specific protobuf language. Protocol Buffers generates parsing and serializing modules, which can be directly used in developed solution. Protobuf supports wide set of languages, including Python, Java, PHP or C++. Using this kind of mechanisms isn’t something new in malware, protobuf-based protocols can be found for example in Gootkitmalware.

Unfortunately, Emotet’s case is a bit different. Protobuf code inside malware is slightly modified and provides additional type of encoding, which is not specified in the original Protocol Buffers documentation. Because of this small difference, response can’t be properly decoded using generic protobuf parsers e.g. protoc with –decode_raw argument fails.

Anyway, original protocol definitions were successfully reversed:

syntax = “proto2”;
message RegistrationRequest {
message RegistrationRequestBody {
required string botId = 1;
required fixed32 osVersion = 2;
required string procList = 3;
required string mailClient = 4;
required int32 command = 1 [default = 16];
optional RegistrationRequestBody registrationRequest = 2;

Registration request contains command id (16) and some information about host operating system. Each field of RegistrationRequestBody structure has been described below:

botId field

This field provides information about values specific to victim’s machine and probably is meant to be unique between bot instances.

e.g. CERTCERT_PL_32122958
    • host_name – contains only chars from 0..9a..zA..Z- charset, another chars are replaced by ‘?’
    • locale – contains information about locale settings. In this case, dash ‘-‘ is also forbidden
    • host_id – 32-bit hexadecimal value of sdbm hash (used also by API resolver) from current user login xored by Windows drive serial number.

osVersion field:
32-bit field, which describes version of Windows running on infected host. It’s a bit field, where each groups of bits contains specific value of OSVERSIONINFOEX structure.

Bits Description
0..3 dwMajorVersion
4..7 dwMinorVersion
8..11 wServicePackMajor
12..15 wServicePackMinor
16..19 wProductType
20..23 SYSTEM_INFO.wProcessorArchitecture

procList field:
Contains comma-separated list of currently running process names.

mailClient field:
Provides information about used mail client (read from “HKLM\Software\Clients\Mail” registry key value). If it’s Microsoft Outlook and it’s MAPI DLL is 64-bit, name is followed by ” x64″ suffix.


If a registration request was received, C&C server returns a list of Emotet modules. HTTP status response is always 404 Not Found, regardless of the fact whether request was built properly or not. In this case, response body contains encrypted response.

HTTP/1.1 404 Not Found
Server: nginx
Content-Type: text/html; charset=UTF-8
Content-Length: 728740
Connection: keep-alive


Structure of encrypted response is quite similar to the request structure. Encrypted payload starts at 116-byte of received message. Response is encrypted using the same AES key, which was passed in request. After successful decryption, we obtain protobuf-like message with list of MZ binaries or URLs.

message Module
required int32 type = 1;
required bytes blob = 2;
message ModuleResponse {
repeated Module modules = 1 [packed=true];
required uint32 timestamp = 2;

In this case, malware uses non-standard encoding. Field repeated Module modules = 1 [packed=true]; is illegal in protobuf language, because packed attribute can be used only for primitive numeric type of repeated fields. Surprisingly, list of modules is encoded like packed list of Message objects.

Here is a low-level C&C response description, using Protocol Buffers encoding primitives:

Type Name Comment
TAG tag 0x0a
VARINT length of ‘modules’ list
Module (repeated)
VARINT length of Module element
TAG ‘type’ field tag 0x08
TAG ‘blob’ field type 0x12
VARINT length of ‘blob’
RAW ‘blob’ content

It should be noted that elements of Modules are repeated without Module message tag, which is specific to packed encoding,

type field:
This field defines type of blob content and specifies method of module execution. Type field can be one of the following values:

Value Description
1 Store in %TEMP% and execute with -U argument
2 Like ‘1’, but without arguments
3 Download and execute file from URL specified ‘blob’
4 Use own internal loader – load and execute PE file from ‘blob’
5 Uninstall – delete related ‘.lnk’ from Startup folder
default Do nothing


In previous versions, Emotet modules were providing the following set of functionalities:

    • Stealing money from bank accounts (Man-in-the-Browser attack)
    • Spreading by sending spam e-mails
    • Stealing mails and credentials to mail accounts
    • DDoS module
    • Stealing browsing history and passwords from web browser

In version 4 distributed in the last campaign, we didn’t observe banking module, which is somewhat unusual for this type of malware. Behavior of other modules was quite similar to previous versions. During analysis, we successfully dropped two types of modules, described below:

Credentials stealer:

In server response, we found two similar modules, which purpose was to steal credentials from web browser and mail client. Both modules have embedded NirSoft password recovery software inside:

Recovery software was embedded as XOR-encoded static blob, using 32-bit key (similar to strings). On module startup, software was decoded and stored in %TEMP%, and then executed with /scomma [temp file name] parameter, which leads to dump all passwords into file contained in %TEMP% folder (name generated using GetTempFileNameW). Stealed data were sent to C&C server for malware spreading purpose.

Spam module:

Second type of module was spam module, used for malware spreading. Firstly, module asks C&C for message template, list of recipients and list of hijacked accounts, which will be used to spam distribution.

Request structure presents as below:

message SpamRequest {
message SpamRequestBody {
required string botId = 1;
required int32 flags = 2 [default = 3];
required string additionalData = 3;
required int32 command = 1 [default = 18];
optional SpamRequestBody spamRequest = 2;

Fields flags and additionalData specify, which data has been received from server and which we’re expecting in C&C answer.

Server response looks like below:

message EmailAccount {
required int32 id = 1;
required string mail_server = 2;
required int32 port = 3;
required string login = 4;
required string password = 5;
required string email = 6;
message EmailRecipient {
required int32 id=1;
required string to_email=2;
optional string to_name=3;
required string from_email=4;
required string from_name=5;
message EmailResponse {
message Template {
required string from = 1 ;
required string subject = 2;
required string unk1 = 3;
required string content_type = 4;
required string msg = 5;
required string unk2 = 6;
optional Template template = 1;
repeated EmailAccount accounts = 2 [packed=true];
optional EmailRecipient recipients = 3 [packed=true];
required uint32 timestamp = 4;

E-mails are not sent using local account. Distribution is performed using previously scrapped mail accounts, which are sent to each spambot.

Message template example:

Hello <span style=”text-transform: uppercase;”>&lt;&gt;</span>

Thank you for your order. The details can be found below.

Invoice attached: <a href=””>;&gt;</a>

This e-mail was sent by <span style=”text-transform: uppercase;”>&lt;&gt;


Basic functionality of Emotet in last campaign was just stealing credentials and spreading. Even though, malware is still active and also actively developed. Because of lack of few important modules, Emotet will be probably extended in future. In case of infection, we recommend changing passwords to all accounts, which credentials were stored in mail client or web browser.

Additional informations


MD5 of fetched modules:

C&C list:


C&C public key:


Yara Rule:

rule emotet4_basic: trojan
author = “psrok1/mak”
module = “emotet”
$emotet4_rsa_public = { 8d ?? ?? 5? 8d ?? ?? 5? 6a 00 68 00 80 00 00 ff 35 [4] ff 35 [4] 6a 13 68 01 00 01 00 ff 15 [4] 85 }
$emotet4_cnc_list = { 39 ?? ?5 [4] 0f 44 ?? (FF | A3)}
all of them

rule emotet4: trojan
author = “psrok1”
module = “emotet”
$emotet4_x65599 = { 0f b6 ?? 8d ?? ?? 69 ?? 3f 00 01 00 4? 0? ?? 3? ?? 72 }
any of them and emotet4_basic

rule emotet4_spam : spambot
$login=”LOGIN” fullword
$startls=”STARTTLS” fullword
$mailfrom=”MAIL FROM:”
all of them and emotet4_basic

You value our work? 

The Return of Qakbot Malware

00Latest news, Malware, ReverseEngineering, Zero-DayTags: , , , , ,


The Cylance Threat Guidance team continuously looks for interesting trends and challenges that incite organizations to engage with us. Recently, an influx of thousands of Qakbot (aka Qbot) infections have brought people to us to discuss how to block this malware from gaining access to corporate systems.

This malware is well-known for its ability to steal credentials and quickly spread through an enterprise over network shares. Given its age, it might seem logical that security controls would have this threat on lockdown. However, the occasional functional enhancements combined with its multiple layers of obfuscation and server-side polymorphism periodically breathe new life into this seemingly immortal malware.

While it’s unclear why so many systems have suddenly fallen victim to Qakbot, it’s possible that updated exploit kits play a role. After all, there is no shortage of new vulnerabilities and exploits for attackers to use to their advantage.

Since the core functionality of Qakbot has remained fairly consistent over the years and is well documented, we will not rehash that information here. Instead, we’ll evaluate several samples from the recent surge in infections and explore how to correlate unique binaries.

As highlighted at the beginning of this article, the polymorphic nature of this threat is of great interest given its goal of evading detection. Prior versions of Qakbot configured a scheduled task to request updates, and the recent wave of infections was no different. For example, we observed a sample that configured the following command to run on a weekly basis:

cmd.exe /C “start /MIN C:\windows\system32\cscript.exe //E:javascript “C:\Users\<USER>\AppData\Local\Microsoft\<5-8 random alphabetical characters>.wpl””

As described in the command line, the WPL file contains JavaScript. Just in case the cryptic code isn’t convincing enough, the header of the target file makes it all too clear the JavaScript is obfuscated (Figure 1).

Figure 1: Excerpt of Obfuscated JavaScript Update Script

Brief behavioral analysis revealed the code reaches out to the following URLs:

•  hxxp://
•  hxxp://projects.montgomerytech(dot)com/TealeafTarget.php
•  hxxp://n.abcwd0.seed.fastsecureservers(dot)com/TealeafTarget.php

Like earlier versions of Qakbot, a request to these update servers returns an encrypted payload, where the first 20 bytes serve as the RC4 key to decrypt the data. Once decrypted, the first 20 bytes represent a SHA1 hash of the executable, and the remaining bytes are the file contents.

To mimic Qakbot’s update process in a controlled manner, we created a Python script to send HTTP requests to each of the three URLs over a 24-hour period. At the time of this writing, requests for the first listed URL returned an HTTP 404 Not Found error, but requests for the remaining two URLs returned the expected payload.

The script was executed from both a Windows 10 64-bit and Windows 10 32-bit OS for more than 24 hours from 5/16/17 to 5/17/17, and the scripts were running simultaneously across both operating systems during much of that time.

Although the script was configured to send HTTP requests to each of the two working URLs every 30 seconds, most requests resulted in pulling the same binary. In other words, the update server did not provide a new file with each request.

Files with a unique hash were only supplied approximately every 10 minutes. In total, we collected 245 files across the two machines. However, because the servers supplied the same file to each machine at a given time (i.e., they appeared to be in sync), the resulting unique set of files was much smaller, totaling 141 files.


Reviewing the samples:

All 141 downloaded files were 32-bit Windows executables. Searching public repositories for these files revealed that only one had been previously logged, and that was within the previous 12 hours.

Across the 141 files, all have unique compile timestamps, and the earliest one occurred on May 15, 2017.

While all 141 files have unique sha-256 file hashes, there are some similarities to consider. First, calculating the import hashes across the files showed three distinct groups:

•  2E6AC2290F1E3D80ABC8D0D6F736D965
•  651EF2DBA96011F47EED9B72BE7B4B8C
•  F3CAA54DDE4056FADD52A024CF6B82ED

Although import hashes are often used to correlate malware over long periods of time, the earliest compile timestamp we discovered for a file with any of the above import hashes was 5/15/17. Given the polymorphic capabilities of this threat, this observation is not surprising.

Let’s briefly take a look at two files that have the same import hash (2E6AC2290F1E3D80ABC8D0D6F736D965) but different file hashes:

•  7DBD0DF279062090C34F796EFC7DD239ECCD46B99B67AAC370D6048D5ADBB9EC
•   67F3BD674647CA0D294A894B6702362B6CFC4B6C2E147643E100903A6B4D715A

Both files are 458,752 bytes, and they consist of the following PE sections:

•  .text
•  .code
•  .rdata
•  .data
•  .CRT
•  .exp
•  .code (yes, again)
•  .rsc
• .reloc

Among these, all section hashes match except those for .text, .rdata, and .data. A different .text section may indicate a change in executable code. To investigate this observation, we can use diaphora, a binary diffing tool compatible with IDA Pro. Performing a code comparison presents the following results (excerpt in Figure 2).

Figure 2: Binary Diff of Two Qakbot Samples With the Same Import Hash

Diaphora concludes all 27 identified functions are a 100% match.

While we could investigate individual variations across the three PE sections mentioned earlier, it makes more sense to unravel any layers of obfuscation and compare the underlying code.

Unpacking Qakbot:

To unpack recent Qakbot samples, the below approach worked reliably. All instructions assume use of x32dbg, but similar steps can be performed with a debugger of your choice.

•   Load the sample into x32dbg (we’ll be working with the file that has sha-256 hash 7DBD0DF279062090C34F796EFC7DD239ECCD46B99B67AAC370D6048D5ADBB9EC) .

•   Set a breakpoint on VirtualProtect (Figure 3).

Figure 3: Set a Breakpoint on VirtualProtect Within x32dbg

•   Execute the code. On the first call to VirtualProtect, the protection on all sections owned by the process will be modified to 0x04, or PAGE_READWRITE (see red box in Figure 4).

Figure 4: Protection on Code Changed to PAGE_READWRITE

•   As the code executes, those sections in memory will be manually overwritten using loops. Let the breakpoint hit two more times, and on the second hit notice that protection on the .text section is changed to 0x20, or PAGE_EXECUTE_READ (see red box in Figure 5).

Figure 5: Protection on .text Section Changed to PAGE_EXECUTE_READ

•   Allow the call to complete and return back to user code so that the permissions change takes effect.

•   Next, browse to the Memory Map and choose to disassemble the .text section (Figure 6).

Figure 6: Memory Map With Unpacked Code

•   Once there, set a “Hardware on Execution” breakpoint to catch when this new code is executed (Figure 7).

Figure 7: Hardware Breakpoint on Original Entry Point (OEP)

• Run the code until the hardware breakpoint is triggered. You can then dump the process using a plugin like OllyDumpEx and fix the import table using Scylla.

Correlating Qakbot

Following the above process for both files produced two process dumps of the same size (418,304 bytes) and different file hashes. Turning again to diaphora revealed that most of the 227 functions identified matched 100%. Only nine functions did not match 100% (see excerpt in Figure 8).

Figure 8: Binary Diff of Unpacked Code From Two Samples

A review of these nine functions showed that each referenced the file name and/or location of the file on disk. Since each file tested did indeed have a different filename and location, we can explain this discrepancy. Therefore, despite variations in the sections across the code, the resulting unpacked binary contains identical functionality.

To further explore correlation between deobfuscated samples, we can apply the same unpacking process to a sample with a different import hash. For example, the file with hash 8891524E468BE1BD44723385C9238017090B536F922CCC007D8AC47C66802E3C is 450,560 bytes and has the import hash 651EF2DBA96011F47EED9B72BE7B4B8C. It is 8,192 bytes smaller than the previous two files and has only six sections (no section hashes match when compared to previous samples):

•   .text
•   .code
•   .rdata
•   .data
•   .rsrc
•   .reloc

The unpacking approach outlined above results in another dumped 418,304 byte file with a different file hash. However, a code diff confirms that most of the 227 identified functions match 100%, and the nine functions that do not only differ by the filename and path, as described earlier.


Qakbot continues to be a significant threat due to its credential collection capabilities and polymorphic features. Unhindered, this malware family can rapidly propagate through network shares and create an enterprise-wide incident. In this post, we explored how to dissect, unpack, and compare multiple downloaded samples.


Indicators of Compromise (IoCs):

Sha-256 Hashes:




You value our work? 

EPS Processing Zero-Days Exploited by Multiple Threat Actors

00Featured news, Latest news, Malware, ReverseEngineering, Vulnerability, Zero-DayTags: , , , ,

In 2015, FireEye published details about two attacks exploiting vulnerabilities in Encapsulated PostScript (EPS) of Microsoft Office. One was a zero-day and one was patched weeks before the attack launched.

Recently, FireEye identified three new zero-day vulnerabilities in Microsoft Office products that are being exploited in the wild.

At the end of March 2017, we detected another malicious document leveraging an unknown vulnerability in EPS and a recently patched vulnerability in Windows Graphics Device Interface (GDI) to drop malware. Following the April 2017 Patch Tuesday, in which Microsoft disabled EPS, FireEye detected a second unknown vulnerability in EPS.

FireEye believes that two actors – Turla and an unknown financially motivated actor – were using the first EPS zero-day (CVE-2017-0261), and APT28 was using the second EPS zero-day (CVE-2017-0262) along with a new Escalation of Privilege (EOP) zero-day (CVE-2017-0263). Turla and APT28 are Russian cyber espionage groups that have used these zero-days against European diplomatic and military entities. The unidentified financial group targeted regional and global banks with offices in the Middle East. The following is a description of the EPS zero-days, associated malware, and the new EOP zero-day. Each EPS zero-day is accompanied by an EOP exploit, with the EOP being required to escape the sandbox that executes the FLTLDR.EXE instance used for EPS processing.

The malicious documents have been used to deliver three different payloads. CVE-2017-0261 was used to deliver SHIRIME (Turla) and NETWIRE (unknown financially motivated actor), and CVE-2017-0262 was used to deliver GAMEFISH (APT28). CVE-2017-0263 is used to escalate privileges during the delivery of the GAMEFISH payload.

FireEye email and network products detected the malicious documents.

FireEye has been coordinating with the Microsoft Security Response Center (MSRC) for the responsible disclosure of this information. Microsoft advises all customers to follow the guidance in security advisory ADV170005 as a defense-in-depth measure against EPS filter vulnerabilities.

CVE-2017-0261 – EPS “restore” Use-After-Free

Upon opening the Office document, the FLTLDR.EXE is utilized to render an embedded EPS image, which contains the exploit. The EPS file is a PostScript program, which leverages a Use-After-Free vulnerability in “restore” operand.

From the PostScript Manual: “Allocations in local VM and modifications to existing objects in local VM are subject to a feature called save and restore, named after the operators that invoke it. save and restore bracket a section of a PostScript language program whose local VM activity is to be encapsulated. restore deallocates new objects and undoes modifications to existing objects that were made since the matching save.”

As the manual described, the restore operator will reclaim memory allocated since the save operator. This makes a perfect condition of Use-After-Free, when combined with forall operator. Figure 1 shows the pseudo code to exploit the save and restore operation.

Figure 1: Pseudo code for the exploit

The following operations allow the Pseudo code to leak metadata enabling a read/write primitive:

  1. forall_proc array is created with a single element of the restore proc
  2. The EPS state is saved to eps_state
  3. uaf_array is created after the save
  4. The forall operator loops over the elements of the uaf_array calling forall_proc for each element
  5. The first element of uaf_array is passed to a call of restore_proc, the procedure contained in forall_proc
  6. restore_proc
    • restores the initial state freeing the uaf_array
    • The alloc_string procedure reclaims the freed uaf_array
    • The forall_proc is updated to call leak_proc
  7. Subsequent calls by the forall operator call the leak_proc on each element of the reclaimed uaf_array which elements now contain the result of the alloc_string procedure

Figure 2 demonstrates a debug log of the uaf_array being used after being reclaimed.

Figure 2: uaf_array reclaimed debug log

By manipulating the operations after the save operator, the attacker is able to manipulate the memory layouts and convert the Use-After-Free to create a read/write primitive. Figure 3 shows the faked string, with length set as 0x7fffffff, base as 0.

Figure 3: Faked String Object

Leveraging the power of reading and writing arbitrary user memory, the EPS program continues by searching for gadgets to build the ROP chain, and creates a file object. Figure 4 demonstrates the faked file object in memory.

Figure 4: Fake File Object, with ROP

By calling closefile operand with the faked file object, the exploit pivots to the ROP and starts the shellcode. Figure 5 shows part of the disassembler of closefile operand handler.

Figure 5: Stack Pivot disassembler of closefile

Once execution has been achieved, the malware uses the ROP chain to change the execution protection of the memory region containing the shellcode.  At this point, the shellcode is running within a sandbox that was executing FLTLDR.EXE and an escalation of privilege is required to escape that sandbox.

FireEye detected two different versions of the EPS program exploiting this vulnerability.  The first, st07383.en17.docx, continues by utilizing 32 or 64 bit versions of CVE-2017-0001 to escalate privileges before executing a final JavaScript payload containing a malware implant known as SHIRIME. SHIRIME is one of multiple custom JavaScript implants used by Turla as a first stage payload to conduct initial profiling of a target system and implement command and control. Since early 2016, we have observed multiple iterations of SHIRIME used in the wild, having the most recent version (v1.0.1004) employed in this zero-day

The second document, Confirmation_letter.docx, continues by utilizing 32 or 64 bit versions of CVE-2016-7255 to escalate privilege before dropping a new variant of the NETWIRE malware family. Several versions of this document were seen with similar filenames.

The EPS programs contained within these documents contained different logic to perform the construction of the ROP chain as well as build the shellcode.  The first took the additional step of using a simple algorithm, shown in Figure 6, to obfuscate sections of the shellcode.

Figure 6: Shellcode obfuscation algorithm

CVE-2017-0262 – Type Confusion in EPS

The second EPS vulnerability is a type confused procedure object of forall operator that can alter the execution flow allowing an attacker to control values onto the operand stack. This vulnerability was found in a document named “Trump’s_Attack_on_Syria_English.docx”.

Before triggering the vulnerability, the EPS program sprays the memory with predefined data to occupy specific memory address and facilitate the exploitation. Figure 7 demonstrates the PostScript code snippet of spraying memory with a string.

Figure 7: PostScript code snippet of spray

After execution, the content of string occupies the memory at address 0x0d80d000, leading to the memory layout as shown in Figure 8. The exploit leverages this layout and the content to forge a procedure object and manipulate the code flow to store predefined value, in yellow, to the operator stack.

Figure 8: Memory layout of the sprayed data

After spraying the heap, the exploit goes on to call a code statement in the following format: 1 array 16#D80D020 forall. It creates an Array object, sets the procedure as the hex number 0xD80D020, and calls the forall operator. During the operation of the forged procedure within forall operator, it precisely controls the execution flow to store values of the attacker’s choices to operand stack. Figure 9 shows the major code flow consuming the forged procedure.

Figure 9: Consuming the forged procedure

After execution of forall, the contents on the stack are under the attacker’s control. This is s shown in Figure 10.

Figure 10: Stack after the forall execution

Since the operand stack has been manipulated, the subsequent operations of exch defines objects based on the data from the manipulated stack, as shown in Figure 11.

Figure 11: Subsequent code to retrieve data from stack

The A18 is a string type object, which has a length field of 0x7ffffff0, based from 0. Within memory, the layout as shown in Figure 12.

Figure 12: A18 String Object

The A19 is an array type object, with member values all purposely crafted. The exploit defines another array object and puts it into the forged array A19. By performing these operations, it puts the newly created array object pointer into A19. The exploit can then directly read the value from the predictable address, 0xD80D020 + 0x38, and leak its vftable and infer module base address of EPSIMP32.flt. Figure 13 shows code snippets of leaking EPSIMP32 base address.

Figure 13: Code snippet of leaking module base

Figure 14 shows the operand stack of calling put operator and the forged Array A19 after finishing the put operation.

Figure 14: Array A19 after the put operation

By leveraging the RW primitive string and the leaked module base of EPSIMP32, the exploit continues by searching ROP gadgets, creating a fake file object, and pivoting to shellcode through the bytesavailable operator. Figure 15 shows the forged file type object and disassembling of pivoting to ROP and shellcode.

Figure 15: Pivots to ROP and Shellcode

The shellcode continues by using a previously unknown EOP, CVE-2017-0263, to escalate privileges to escape the sandbox running FLTLDR.EXE, and then drop and execute a GAMEFISH payload. Only a 32-bit version of CVE-2017-0263 is contained in the shellcode.

CVE-2017-0263 – win32k!xxxDestroyWindow Use-After-Free

The EOP Exploit setup starts by suspending all threads other than the current thread and saving the thread handles to a table, as shown in Figure 16.

Figure 16: Suspending Threads

The exploit then checks for OS version and uses that information to populate version specific fields such as token offset, syscall number, etc. An executable memory area is allocated and populated with kernel mode shellcode as wells as address information required by the shellcode. A new thread is created for triggering the vulnerability and further control of exploitation.

The exploit starts by creating three PopupMenus and appending menus to them, as shown in Figure 17. The exploit creates 0x100 windows with random classnames. The User32!HMValidateHandle trick is used to leak the tagWnd address, which is used as kernel information leak throughout the exploit.

Figure 17: Popup menu creation

RegisterClassExW is then used to register a window class “Main_Window_Class” with a WndProc pointing to a function, which calls DestroyWindow on window table created by EventHookProc, explained later in the blog. This function also shows the first popup menu, which was created earlier.

Two extra windows are created with class name as “Main_Window_Class”. SetWindowLong is used to change WndProc of second window, wnd2, to a shellcode address. An application defined hook, WindowHookProc, and an event hook, EventHookProc, are installed by SetWindowsHookExW and SetWinEventHook respectively. PostMessage is used to post 0xABCD to first window, wnd1.

The EventHookProc waits for EVENT_SYSTEM_MENUPOPUPSTART and saves the window’s handle to a table. WindowHookProc looks for SysShadow classname and sets a new WndProc for the corresponding window. Inside this WndProc, NtUserMNDragLeave syscall is invoked and SendMessage is used to send 0x9f9f to wnd2, invoking the shellcode shown in Figure 18.

Figure 18: Triggering the shellcode

The Use-After-Free happens inside WM_NCDESTROY event in kernel and overwrites wnd2’s tagWnd structure, which sets bServerSideWindowProc flag. With bServerSideWindowProc set, the user mode WndProc is considered as a kernel callback and will be invoked from kernel context – in this case wnd2’s WndProc is the shellcode.

The shellcode checks whether the memory corruption has occurred by checking if the code segment is not the user mode code segment. It also checks whether the message sent is 0x9f9f. Once the validation is completed, shellcode finds the TOKEN address of current process and TOKEN of system process (pid 4). The shellcode then copies the system process’ token to current process, which elevates current process privilege to SYSTEM.


EPS processing has become a ripe exploitation space for attackers.

FireEye has discovered and analyzed two of these recent EPS zero-days with examples seen before and after Microsoft disabled EPS processing in the April 2017 Patch Tuesday.  The documents explored utilize differing EPS exploits, ROP construction, shellcode, EOP exploits and final payloads. While these documents are detected by FireEye appliances, users should exercise caution because FLTLDR.EXE is not monitored by EMET.

Russian cyber espionage is a well-resourced, dynamic threat

The use of zero-day exploits by Turla Group and APT28 underscores their capacity to apply technically sophisticated and costly methods when necessary. Russian cyber espionage actors use zero-day exploits in addition to less complex measures. Though these actors have relied on credential phishing and macros to carry out operations previously, the use of these methods does not reflect a lack of resources. Rather, the use of less technically sophisticated methods – when sufficient – reflects operational maturity and the foresight to protect costly exploits until they are necessary.

CVE-2017-0261’s use by multiple actors is further evidence that cyber espionage and criminal activity exist in a shared ecosystem. Nation state actors, such as those leveraging CVE-2017-0199 to distribute FINSPY, often rely on the same sources for exploits as criminal actors. This shared ecosystem creates a proliferation problem for defenders concerned with either type of threat.

CVE-2017-0261 was being used as a zero-day by both nation state and cyber crime actors, and we believe that both actors obtained the vulnerability from a common source. Following CVE-2017-0199, this is the second major vulnerability in as many months that has been used for both espionage and crime.

MD5 Filename C2 Host
2abe3cc4bff46455a945d56c27e9fb45 Confirmation_letter.docx.bin

e091425d23b8db6082b40d25e938f871 Confirmation_letter.docx

006bdb19b6936329bffd4054e270dc6a Confirmation_letter_ACM.docx

15660631e31c1172ba5a299a90938c02 st07383.en17.docx

f8e92d8b5488ea76c40601c8f1a08790 Trump’s_Attack_on_Syria_English.docx


Table 1: Source Exploit Documents

Table 2: CVEs related to these attacks

You find the article useful? Help us out as well 🙂 

Intel chip vulnerability lets hackers easily hijack fleets of PCs

00Latest news, Vulnerability, Zero-DayTags: , ,

Security researchers say exploiting the vulnerability requires little technical expertise, and can result in a hacker taking full control of an affected PC.

A vulnerability in Intel chips that went undiscovered for almost a decade allows hackers to remotely gain full control over affected Windows PCs without needing a password.

The “critical”-rated bug, disclosed by Intel last week, lies in a feature of Intel’s Active Management Technology (more commonly known as just AMT), which allows IT administrators to remotely carry out maintenance and other tasks on entire fleets of computers as if they were there in person, like software updates and wiping hard drives. AMT also allows the administrator to remotely control the computer’s keyboard and mouse, even if the PC is powered off.

To make life easier, AMT was also made available through the web browser — accessible even when the remote PC is asleep — that’s protected by a password set by the admin.

The problem is that a hacker can enter a blank password and still get into the web console, according to independent technical rundowns of the flaw by two security research labs.

Embedi researchers, credited with finding the bug, explained in a whitepaper posted Friday that a flaw in how the default “admin” account for the web interface processes the user’s passwords effectively lets anyone log in by entering nothing at the log-on prompt.

“No doubt it’s just a programmer’s mistake, but here it is: keep silence when challenged and you’re in,” said the researchers.

(Image: Intel)

Tenable researchers confirmed the findings in a detailed analysis of the flaw, also posted Friday, saying it was relatively easy to remotely exploit.

Intel’s advisory said that systems — including desktops, laptops, and servers — dating back as early as 2010 and 2011 and running firmware 6.0 and later are affected by the flaw.

But Embedi warned that any affected internet-facing device with open ports 16992 and 16993 are at risk. “Access to ports 16992/16993 are the only requirement to perform a successful attack,” said the Embedi researchers.

Since the disclosure, monitors have seen a spike in port probing activity on the two affected ports.

(Image: Sans Institute)

Intel so far hasn’t said how many devices are affected.

However, a search on Shodan, the search engine for open ports and databases, shows more than 8,500 devices are vulnerable at the time of writing, with almost 3,000 in the US alone — but there could be thousands more devices at risk on internal networks.

(Screenshot via Shodan)

In a statement, Intel said that it’s working with its hardware partners to address the problem, and “expect computer-makers to make updates available beginning the week of May 8 and continuing thereafter.”

So far, Dell, Fujitsu, HP, and Lenovo have all issued security advisories and have issued guidance on when they will roll out fixes to their customers. Consumer devices aren’t affected by the bug.

The chipmaker has also published a discovery tool to determine if machines are affected.