Information Security




In January 2016 Forcepoint Security Labs reported an email campaign delivering the Ursnif banking Trojan which used the ‘Range’ feature within its initial HTTP requests to avoid detection.

In July 2017 we discovered a malicious email sample delivering a new variant of Ursnif, attached within an encrypted Word document with the plaintext password within the email body. As recorded in several other Ursnif campaigns reported since April 2017, this Word document contains several obfuscated VBS files which load malicious DLLs through WMI.

However, these samples appear to exhibit new features including anti-sandboxing features that use a combination of mouse position and file timestamps to decode their internal data and the ability to steal data from the Thunderbird application.



A sample lure email for this campaign is shown below:

Once decrypted, it shows three OLE document icons with the extension “docx”, which will lure users to double click them directly (see below):

In fact, their file properties show they are three identical VBS scripts, including same highly obfuscated code padded with lots of garbage scripts to cover up normal logic.

Once triggered, it tries to download malware from ‘hxxp://46.17.40[.]22/hyey.pnj’. If this fails, a second attempt will be made to another site: ‘hxxp://inshaengineeringindustries[.]com/head.pkl’. These files are in fact DLL files which have been designed to be loaded through WMI:

rundll32 [malwarepath] DllRegisterServer

This malicious DLL is packed and again padded with lots of garbage code to hamper static analysis attempts. During execution, it will drop a second DLL file, map this new DLL to the current address, fix the Import Address Table and Relocation Table, then finally jump into the entry point to execute.

The dropped DLL first does self-checking on integrity and then:

  • Performs anti-sandboxing checks
  • Performs anti-VM checks
  • Implements persistence through an autorun registry key
  • Injects itself into the ‘explorer.exe’ process

The remainder of this analysis will focus on the new mouse-based anti-sandboxing/decryption capabilities.

Anti-Sandboxing Checks

The algorithm used by this sample uses the difference between the current and previous recorded mouse coordinates to detect mouse movement and avoid sandbox environments where the mouse is not usually moved. It further uses the value generated by this process to ‘brute force’ its own decryption key.

Step One – Key Generation

Firstly, the malware calculates the D-Value (delta) between the x- and y-coordinates of the last and current mouse position. It then selects the sum of the .BSS section’s Relative Virtual Address (RVA) and ‘SizeOfRawData’ value as a base seed.

It XORs the base seed with the file creation time (in this case ‘Apr 11 2017’) to get a value which is added to the lowest 5 bits of the mouse D-Value to get the decryption key.

Step Two – Decode .BSS Section

The malware loops through the .BSS section of the DLL one DWORD at a time, XORing the current DWORD data with the last DWORD data. This value is then XORed with the decryption key generated above and right-rotated by the loop count. The ‘current’ DWORD is then replaced.

Step Three – Verify The Deciphering Key

After .BSS section data is decoded, three values are acquired from offsets 0x61d, 0x619, and 0x625 in the .BSS section, and their sum compared with checksum ‘0EE553B4E’. If this matches, it will execute the rest of the code, otherwise it has to restore the encrypted .BSS section raw data and try to re-calculate new key for another attempt at the decryption and verification operation.

If run in sandbox environment, since the D-value based on the mouse movement always is 0, the ‘BSS’ section is always inaccurately decoded and will loop execution of same code. While in a realistic environment, due to only using the lowest 5 bits of D-value rather than the full 32 bits, it is more likely to get correct value to decode section data.

The decryption key itself is an important global constant which will be used in subsequent code to decode APIs, a hidden PE file (DLL file in this variant), synchronous objects, Registry data, URLs, etc.

In addition, the decoding operations are implemented at run time, preventing memory analysers from dumping the whole plaintext string stream of malware memory, e.g.

Decoding Windows APIs used for further injection operations:

With the aid of the decryption key, an additional embedded PE file (a 3rd DLL file) can be safely extracted from data section of the second DLL file, released to a temporary buffer, and injected into the ‘explore.exe’ process.



Ursnif spreads itself through emails provided with a plaintext password for an attached encrypted document. In general, this method is used by senders when the attached documents contain sensitive content. In recent years, this method is widely leveraged by threat actors, who want to ensure their payload successfully bypasses IDS detection and to deceive recipients to firmly believe that the mail may contain important information.

Overall, Ursnif is well concealed: it communicates with C2 servers via Tor, limiting its traceability, and is equipped with anti-sandbox and anti-VM techniques.

You value our work? Please support us 


Alert: Microsoft Tech-Support Scammers using WannaCry attack to lure victims

Action Fraud UK has received the first reports of Tech-Support scammers claiming to be from Microsoft who are taking advantage of the global WannaCry ransomware attack.

One victim fell for the scam after calling a ‘help’ number advertised on a pop up window. The window which wouldn’t close said the victim had been affected by WannaCry Ransomware.

The victim granted the fraudsters remote access to their PC after being convinced there wasn’t sufficient anti-virus protection. The fraudsters then installed Windows Malicious Software Removal Tool, which is actually free and took £320 as payment.

It is important to remember that Microsoft’s error and warning messages on your PC will never include a phone number.

Additionally Microsoft will never proactively reach out to you to provide unsolicited PC or technical support. Any communication they have with you must be initiated by you.

How to protect yourself

  • Don’t call numbers from pop-up messages.
  • Never allow remote access to your computer.
  • Always be wary of unsolicited calls. If you’re unsure of a caller’s identity, hang up.
  • Never divulge passwords or pin numbers.
  • Microsoft or someone on their behalf will never call you.

If you believe you have already been a victim

  • Get your computer checked for any additional programmes or software that may have been installed.
  • Contact your bank to stop any further payments being taken.

You value our work? 

Webinar – Defending against the next attack

Lessons From WannaCry & How To Build Towards a Secure Future
Webinar Thursday, June 1st, at 11 AM EDT

WannaCry attacked 300,000 machines across 100+ countries on May 12th. The fallout has been massive, prompting companies across the globe to take stock of their security infrastructure and think hard about the motivations of the attackers. They are professionals with resources, who will continue to adapt and get better.

Join our webinar to hear Cybereason’s Chief Product Officer, and former CISO and CTO of Arbor, discuss the different types of attackers traversing the web and how their mindset and philosophies are evolving to become more agile and resilient. You will hear Sam’s vision for security in 2018, and where he thinks companies should be investing their time, energy and dollars.

You will also see a brief overview of Cybereason’s EDR platform (which stopped Wannacry), and qualify for an exclusive offer reserved only for registrants of this webinar: up to 90 days free of Cybereason.


    Sam Curry, Chief Product Officer

     Blaine Connaughton, Sales Engineer


You can register here:

Enjoy 🙂


You value our work? 

Emotet v4 Analysis


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


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? 

TrickBot Loader – inside the trojan


According to Limor Kessem, executive security advisor at IBM Security, “unlike its predecessor, Dyre, TrickBot has “dabbled” in malvertising, leveraging the RIG exploit kit, malicious email attachments and poisoned Office macros coming through the “Godzilla loader”. That behaviour suggests that the group behind TrickBot is after specific business accounts. They have been sending malware-laden spam to companies, not just indiscriminate waves of email.” This is another new feature which Dyre did not contain.

Experts agree that although there are quite a few similarities, TrickBot has been rewritten with a different coding style and minor changes have been made to upgrade the code rather than reinvent the wheel. Similarities include, loaders and custom encryptors, similar hashing features, and an upgraded command and control encryption tool.

TrickBot contains more C++ code, compared to Dyre, which mostly used C. The new Trojan also uses the Microsoft CryptoAPI instead of built-in functions for AES and SHA-256 hashing algorithm (a kind of unique signature for a text or data file – also used by Bitcoin). Dyre ran commands directly, whereas TrickBot links with the Task Scheduler through the COM standard for more impact.

TrickBot has made its way into the banking sector over recent months by using a malvertising campaign, involving Rig Exploit Kit to disseminate its payload.

Behavioural analysis

Once deployed, TrickBot copies itself into %APPDATA% and deletes the original sample. No changes are made to the initial name of the executable file (in the below example the sample was named “trick.exe”).

Figure 1: Sourced from Malwarebytes Labs

The first thing the bot does, is drop two additional files: client_id and group_tag, which are generated locally and used to identify the individual bot and the campaign to which it belongs. There is no encryption – both files contains text in Unicode.

client_id contains: the name of the attacked machine, the version of the operating system, and an arbitrarily generated string.

In the same folder, a config.conf file is also present. This file is downloaded via Command & Control (C&C) and stored in encrypted form.

Note: Command & Control (C&C or C2) is used by attackers to maintain communications with compromised systems within a target network.

A folder, called Modules, is created in %APPDATA%. More files, called injectDll32 (the banker module, injecting DLLs into target browsers to enable theft of credentials) and systeminfo32 (used for gathering general system info), are downloaded into the same location via C&C. They are also encrypted and a list of the attacked browser is hardcoded in the injectDll32.dll.

Figure 2: Sourced from Malwarebytes Labs

Sometimes these files have an equivalent folder that stores the configurations (as seen in the diagram above). Details of the attacked target (i.e. the bank’s URL) are stored in this folder.

The bot is able to remain effective by adding itself as a task in Windows Task Scheduler. No effort is made to try and hide the task under a legitimate name – as you can see in the example, it’s simply called “Bot”.

Figure 3: Sourced from Malwarebytes Labs

If an attempt is made to kill the process, it is automatically restarted by the Task Scheduler Engine.

Network communication

The Trick Bot connects to several servers. It initially connects to a valid server, so that it gets the visible IP. Strangely, it uses its own User Agent (“BotLoader” or “TrickLoader”) and makes no attempt to disguise itself as a legitimate browser. Most of the Bot’s communication with C&C is SSL encrypted, however, some is left unencrypted.

In the URL of a POST request, group_id and client_id are used – which are the same names given to the files seen early. The command id follows after that. This was a characteristic of Dyreza.

An additional payload is downloaded (for example 47d9e7c464927052ca0d22af7ad61f5d) without encrypting the traffic. C&Cs are set up on hacked wireless routers, i.e. MikroTik, which is another feature of TrickBot that is the same as its predecessor, Dyreza.

There is absolutely no attempt made to imitate legitimate-looking names for HTTPs certificates either – they contain completely random data. For example:

Inside TrickBot

TrickBot is made up of many layers.

Figure 4: Sourced from Malwarebytes Labs


The first layer is generally the protective layer, containing the encrypted payload that tries to hide from AV software.


The second layer is the main bot loader, which selects whether to deploy 32-bit or 64-bit payload. New PE files are encrypted and stored in resources. Again, no attempt is made to hide the purpose of the resources. The names are easy to decode.

Figure 5: Sourced from Malwarebytes Labs

To start with, the application acquires information about victim’s operating system, so that the appropriate path can be chosen. Depending on the environment, a suitable payload is selected from resources, decrypted by a basic algorithm and validated. This method is slightly different to how Dyreza worked. Next, a dedicated function is used to map the unpacked bot to the memory and deploy it.

The 32-bit bot uses self-injection to map the new module inside its own memory, before redirecting execution, whereas for the 64-bit payload, the additional executable (64bit PE loader) is first unpacked and run, and then it loads the core, malicious bot. In contrast to Dyreza – where the main modules were DLLs – TrickBot uses EXEs.

In Summary

Trick Bot has a lot in common with its predecessor, Dyreza, although it does not have as many features (possibly designed that way to make distribution quicker). From comparing the code of both bots, it is clear that the offspring does not just contain a few tweaks – it has been completely rewritten and it is highly likely to gain as much fame as the former champion.

You find the info useful? 

Nemucod Evolves Delivery and Obfuscation Techniques to Harvest Credentials

Recently the Unit 42 research team have been investigating a wave of Nemucod downloader malware that uses weaponized documents to deploy encoded, and heavily obfuscated JavaScript, ultimately leading to further payloads being delivered to the victim. From a single instance of the encoded JavaScript discovered in one version of this malware, we pivoted on the Command and Control (C2) IPv4 address discovered during static analysis and deobfuscation, using our Threat Intelligence Service AutoFocus, unearthed many more versions of the malware and found that the versions seen to date were delivering a credential-stealing Trojan as the final payload.

Over the past five months they have tracked this campaign of Nemucod malware in various industry sectors across multiple countries with Europe amassing the highest number of attacks, followed by the United States of America and then Japan (as can be seen in Figure 1).


Figure 1: Nemucod Destination Countries by session volume.


Figure 2: Target Industries by session volume.

Spain was the single most affected country, as shown in Figure 1, with the Professional and Legal Services sector, as shown in Figure 2, contributing the most towards that and also towards Belgium’s total volume as well. Utilities was next, almost exclusively in France; Healthcare was primarily made up again from volume seen in Spain; Energy, towards the end of the list of Top 10 industries shown in Figure 3, was mostly due to activity in the United Kingdom; the Securities and Investments sector was mostly made up from traffic in the United States of America, United Kingdom and Norway. Malicious traffic seen in Japan was due to attacks seen in High Tech industries.


Figure 3: European Countries by session volume.

Much of the malware arrived by email (using SMTP, POP3 and IMAP applications) as shown in Figure 4, the vast majority of which originated from Poland or at least using source email addresses with Polish domain names. Recipient email addresses varied but many seem valid based on names and linked-in account details. A small proportion of the sessions seen were over the web-browsing application being downloaded from websites resolving to IP addresses in Moldova, which will be discussed in more detail later.


Figure 4: Nemucod network application by session volume

The remainder of this blog describes the evolution of the malware since that time, as well as other topics:

  • Weaponized document evolution.
  • Insight into the possible workflow and setup of the attackers, including their infrastructure.
  • Obfuscation and social engineering techniques used.
  • The credential theft payload.

EPS Processing Zero-Days Exploited by Multiple Threat Actors

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 🙂