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

Tag: Malware


00Malware, Malware analysis, Phishing, TrojanTags: , , , , ,



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 


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? 

TrickBot Loader – inside the trojan

00Latest news, Malware, PhishingTags: , , ,


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

00Featured news, Latest news, Malware, Phishing, ReverseEngineeringTags: , , ,

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

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 🙂 

Transient Botnet – Exploring the P2P (SANS Diary)

00Malware, ReverseEngineeringTags: , ,


We recently deployed a high interaction honeypots expecting it to be compromised by a specific malware. But in the first few days, instead of getting infected by the expected malware, it received a variety of attacks ranging from SSH port forwarding to “Viagra and Cialis” SPAM to XORDDoS failed deployment attempts. By the third day, it was insistently hit and compromised by Rakos, a Linux/Trojan.

Based on the expected Rakos behavior reported last December by ESET [1], our honeypot was recruited to a botnet and immediately began attempting connections to other hosts on the Internet, both to “call home” and to search for new victims. Although it wasn’t our initial plan, we noticed that this sample didn’t behave like the one ESET described, which got us curious and made us analyze it here at Morphus Labs.

After analyzing and exploiting this botnet’s communication channel and employing Crawling and Sensor Injection enumeration methods, we did find a network floating around 8,300 compromised devices per day spread over 178 countries worldwide. Considering the recent DDoS attack reported by Incapsula [2] against a US College, originated from 9,793 bots, which was able to generate 30,000 requests per second during 54 hours, we may infer how potentially threatening is Rakos botnet.

2. Botnet C&C channel analysis

To better understand this P2P Transient botnet behavior and its C&C protocol, we listened to its traffic for 24 hours, and after analyzing it, we noticed two kinds of communications: one between bots through HTTP and, the other, between bots and C&C servers through TLS/SSL. In this section, we detail the commands we mapped.

Some definitions before start:

  • Checker: An infected machine (“bot”) that is part of the botnet.
  • Skaro: C&C server

A particular node may play both roles.

2.1 Communication between Checkers and Skaros

The connections between Checkers and Skaros are made through SSL/TLS encrypted sessions. It was necessary to intercept the traffic using a classic man-in-the-middle attack to access the messages. See in Table 1 the list of captured commands and its descriptions.

Table 1 – C&C between Checkers and Skaros
Command Description
POST /ping HTTP/1.1 This command is used by Checkers to inform a Skaro its information and stats. It includes: system architecture, operating system, a “checker” port number (used for bot to bot communication) and machine load (CPU and Memory). In the response, it receives the SSL certificate files (CA, CERT and KEY), a list of up to 30 Skaros addresses and 50 Checkers
GET /upgrade/up HTTP/1.1 Command issued by the Checker to get a new list of username/password combinations from a Skaro.
GET /upgrade/vars.yaml HTTP/1.1 Issuing this command, a Checker receives a response like the initial parameters. It’s a kind of configuration refresh.
GET /upgrade/linux-armv5 HTTP/1.1 This command is used to get a new version of the malware binary file.

2.2. Communication between Checkers

The communication between Checkers is essential to discover their own public IP address. The bots reach each other through HTTP requests using the high random TCP port they bind to.

See in Table 2 the list of commands and its descriptions.

Table 2 – C&C between Checkers
Command Description
GET /  HTTP/1.1 One bot querying another to discover its own IP address.
GET /love HTTP/1.1 Like the previous command; one bot uses “/love” to query another for its own IP address and PTR (the reverse name associated with that IP address). There is a “zen” parameter we didn’t realize its function.

3. Sizing the botnet

Now that we better understand the C&C channel, let’s move on to the intelligence gathering phase. The objective here is to enumerate the population of this botnet, classify its nodes into Skaros and Checker groups and get as much information as possible about them. To this end we implemented two standard approaches to size P2P botnets, Crawling and Sensor Injection [3]

3.1. Crawling

This strategy consists of visiting as many nodes as possible and collecting information about them. The crawler starts by requesting the neighbor list from a seed node and iteratively requests neighbor lists from every newly discovered and active node until all bots are discovered [4].

To maximize our chances of finding an ‘always available and responsive’ seed node, we investigated the lists of Skaros we collected during the man-in-the-middle process and the “/ping” commands we collected to discover prevalent IP addresses. Doing this, we found a group of three IPs both present in the section “skaro” in response to the C&C command “/upgrade/vars.yaml” and in the section “proxies” in response to the C&C command “/ping”, which could make them good seed node candidates.

To validate this, we queried them manually issuing “/ping” commands. As a result, two didn’t respond, and the other answered with an SSL error message, as seen in Figure 1.

At this moment, we realized that the bots authenticate via the SSL certificate found in the C&C command responses. Using it, we issued another “/ping” to the same Skaro that, this time, answered with the expected results, including a list of up to 30 Skaros and 50 Checkers. This botnet protection/authentication mechanism indicated to us the importance of this node to the botnet and made us choose it to be our seed node. We decided to call them “Super Skaros”.

Finally, we wrote a script to automate the crawling process. The script, written in Python, iteratively requests the seed node for the Skaros it knows. Then is asks these Skaros for the Skaros they know and so on until there is no new Skaro to request. The script also creates a graph of the botnet while discovering it to make it easy to further analyze the nodes and its interconnections.

3.1. Sensor Injection

The second strategy is to inject fake nodes into the botnet as sensor nodes [5]. The objective is to offer the network fake nodes to be contacted by the others while enumerating them.

Given the restricted number of Skaros and Checkers returned by each query, the crawling approach may give us just a limited view of the whole botnet. Even when we tried to repeat the query for the same Skaro, the returned list usually included just a small number of new nodes.

To overcome this problem and to improve que quality of our enumeration process, we decided to apply the Sensor Injection method, which, for this research, consists in inserting fake nodes (Skaros and Checkers) into the botnet and collecting information about the nodes that contact them.

To insert the Checker Sensor, we basically ran the malware binary on a controlled environment preventing it from establishing any SSH outgoing connections and monitored the network traffic to enumerate all bots that contacted it. As the communication between Checkers isn’t encrypted, this strategy could give us the possibility to inspect any content posted to or from our sensor.

To insert the Skaro Sensor, we prepared a “/ping” command with manipulated “available”, “running” and “addr” parameters pointing to the IP address to one of our honeypots and sent it to a valid Skaro. Next, we issued a new “/ping” command to the same Skaro and confirmed that our Sensor Node appeared in the returned Skaro list, as seen in Figure 2

To receive and handle those HTTPS connections, we deployed a Nginx server and configured it with the botnet default SSL certificates. With this setup up and running, we started receiving POST and GET requests coming from Checkers, as seen in Figure 3.

To capture and store the data posted to the Skaro Sensor, we created a simple PHP script to append to a file the received HTTP POST parameters. In Figure 4 there is an example of a Checker posted data using the “/ping” C&C command, as always, full of information about the victim, include credentials in clear text.

Finally, to maintain our Skaro Sensor alive on the botnet, we could continually send the manipulated “/ping” command to the Skaros on the network. To implement this, we just configured the “/ping” request of the Crawling method with the appropriate values. As the Crawling would periodically visit all active Skaros, our Sensor Node would always be propagated.

3.3. Experiment environment setup

After defining the methodology and tuning the scripts, it was time to create the environment to execute the experiments, detailed in this section.

As we were dealing with a P2P botnet, distributing the Sensor Nodes in different parts of the world could give us a better view of the botnet, especially if it imposed any kind of communication restriction or load balancing based on geographic regions or IP addresses.

Thus, we distributed 5 Sensor Nodes in the following locations:

  • North America: Oregon
  • South America: São Paulo
  • Europe: Ireland
  • Southeast Asia: Singapore
  • Oceania: Australia

In each location, we installed a honeypot with the configurations and scripts necessary to run the Crawling and Sensor Injection experiments, which include:

  • Network packet capture: to capture all inbound and outbound connections;
  • A Nginx HTTPS server: to be our Skaro Sensor;
  • The Crawling Script: to run the crawling process while enumerating all Skaros and Checkers and to create graphs;
  • A Rakos binary: to be our Checker Sensor;
  • Outbound filter: all the outgoing connections on TCP port 22 (SSH) were blocked to avoid our honeypot from scanning the Internet for victims.

3.4. Running the experiments

Finally, we put our plan into action. The experiments were started simultaneously in all honeypots. Shortly after, the Crawling Process was already querying 30 to 60 Skaros and the Sensor Nodes were receiving connections from the botnet. All as expected.

After 72 hours (or 3 days), we stopped the experiment and started processing all the collected data. The results are shown in the next section.

4. Results

The experiments generated approximately 5 GB of data amongst PCAP files, HTTP requests, crawled data and graph files that were handled and inserted into an Elastic Stack [6] and Gephi [7] platforms for querying and visualization purposes. The results of both enumeration methods are summarized in Table 3.


Table 3: Results Summary
CHECKERS 498 24782 24967
SKAROS 281 239 299
>UNIQUE NODES 779 24839 25084

As we expected, the crawling strategy gave us just a small view of the whole picture. In fact, it accounted for just 3,15% of the total number of discovered nodes. The other part, 96,84% or 24,839 nodes, was found by the Sensor Nodes.

Each sensor discovered an average of 5,000 unique Checkers and 48 unique Skaros during the whole experiment. Comparing to the Crawling method, it’s interesting that although Sensor Injection could discover 50 times more Checkers, it discovered 15% less Skaros. It is also worth mentioning that the efficacy of Sensor Nodes depends on the continuous “/ping” to maintain the Sensor Nodes “alive”.

To make it easy to represent the botnet and its interconnections, we produced graphs for each crawler.  One of those graphs, as seen in Figure 5, shows in green the discovery path from the seed node to the Checkers, in lilac, passing through Skaros, in orange. In summary, each node is connected just to the node from which it was discovered by during the crawling process.

The other graph shows the real interconnection between nodes, as seen in Figure 6. Here we can see a very thick botnet where virtually all Checkers know all Skaros.

Now, plotting the discovery path graph on the world map, as seen in Figure 7, we may have an idea of the botnet worldwide. To geolocalize the nodes, we used MaxMind database [8].

Figure 8 represents all the connections received by “São Paulo” sensor. The big yellow node represents the sensor node. In lilac are the Checkers and in orange, the Skaros.

The graph for the other sensor nodes look very much like these differing basically by the geographic position of the sensor node.

The worldwide botnet distribution is shown in Figure 9. It’s clearly perceived a high node concentration in Europe, highlighting France, Italy and Spain.

The Top 10 countries are shown in Figure 10.

Another interesting finding of this research is related to the victims’ devices as seen in Figure 11. At least 45% of them are Raspberry PI followed by OpenELEC with 21.79% – which are usually deployed on Raspberries. Next, with 16,74%, comes UBNT, wireless access points devices from Ubiquiti.

This botnet relies basically on default or easy guessable passwords that devices owners fail to manage. None the less, Open ELEC systems do not even offer an easy way for users to change the default password, as shown in Figure 12 The text was extracted from Open ELEC’s website [9].

5. Indicators of Compromise

In this section are the IoCs (Indicators of Compromise) that could be used to search for this malware in your environment.

5.1. Binary hashes

Table 4: Rakos binary hashes
Linux i386 4d08072825eb9e32b9736988c57050eb 7328e81a67419bba42d204a82db311db1a033c1c37d454f7adc3e1ebd635e976
Linux ARM abf87f358d265a072d3ee4a4e1ddc16f 519c236f9974279e1db3c973b2d3c4e561307cfb52dcca4b77d19004b506157d
Linux MIPS f6eed5ce7e92f4d34de98d6d262a869b f5dc3cb4d884012b8f255a4946c2914d9ecaa3382f556125124480c3c47be07e
Linux x86-64 b5cc4d3e6188cbb6a6f725b53fbf3c6b 3e538db81365c3a64af78f53cb64fd58c7843ffa690ec0996b7556fc43a876df
FreeBSD x86-64 8e9f0211e0e6448e587aaa979f311ac1 9d476b8b4326be1207e3064f0aa0e01646277722c50c8e9a61c8c87f53416075

5.2. Yara Rules


            $ = “upgrade/vars.yaml”

            $ = “upgrade/up”

            $ = “/tmp/init”

            $ = “dalek”

            $ = “skaro”


            4 of them

5.3. URL Filtering

GET /love

User-Agent: Go-http-client/1.1

6. Final Words

This research revealed a network of controlled devices we defined as a “Transient Botnet”. The term transient refers to the non-persistence aspect of Rakos malware which means that a single bot remains on the network after a reboot only if it gets compromised again, just like Mirai. In other words, we are dealing with a threat that, like many others, counts on the certainty of the abundance of victims and that most them will remain vulnerable – even though this vulnerability could be avoided by a password change.

This transient aspect was reflected in the results we found. During the experiments, the number of nodes floated during the period with peaks of 1,700 new IP addresses which could be existing victims we didn’t know yet or simply new infected or re-infected nodes. Considering this fluctuation, from the 25084 unique nodes discovered in 72 hours, we may consider an average of 8362 bots per 24 hours which certainly represents risks if they were used together in DDoS attacks, for example.

This individual problem that potentially leads to a global threat reminds us the difficult adoption of BCP 38 (Best Current Practices) [10] that specifies how Internet Services Provides (ISPs) could individually cooperate by configuring its routers to defeat DDoS amplification attacks over the Internet. The difference is that in password vulnerability problems we don’t have a guideline or an imposed rule; it involves much more devices and, especially, people.

Finally, it’s worth mentioning that during the 30 days we analyzed this botnet, we didn’t notice any malicious actions other them the SSH brute-force scanner itself. It seems that someone is preparing it to be sold or to offer “services” using it when it gets in the right size. Thinking this way, the innocuous-looking may be a strategy to fly under the radar.

7. References



[3] Rossow, Christian, et al. “Sok: P2pwned-modeling and evaluating the resilience of peer-to-peer botnets.” Security and Privacy (SP), 2013 IEEE Symposium on. IEEE, 2013.

[4] J. Kang and J.-Y. Zhang. Application Entropy Theory to Detect New Peer-to-Peer Botnets with Multi-chart CUSUM. In Proceedings of the 2nd International Symposium on Electronic

[5] Karuppayah, Shankar, et al. “On advanced monitoring in resilient and unstructured P2P botnets.” Communications (ICC), 2014 IEEE International Conference on. IEEE, 2014.

Fake – update your mailbox phishing scam

00Featured news, Latest news, Malware, PhishingTags: ,

We see lots of phishing attempts for email credentials. This one is slightly different than many others. It pretends to be a message from Email Support to Update Your Mailbox. Of course these don’t come from Microsoft or but are spoofed to appear to come from them.

They use email addresses and subjects that will scare, persuade or  entice a user to read the email and follow the link. A very high proportion are being targeted at small and medium size businesses, with the hope of getting a better response than they do from consumers.

Remember many email clients, especially on a mobile phone or tablet, only show the Name in the From: and not the bit in < >. That is why these scams and phishes work so well.

The email looks like this:

From: Email Support <>

Date: Mon 08/05/2017 02:58

Subject: E-mail Account Update

Body content:

Update Your Mailbox

Within 24 hours, if you do not update your mailbox, your email will be disabled. Failure to update your e-mail account, It will be permanently terminated.
Update Your MailBox
Copyright ©  E-mail Support Service. 2017

email support phishing email

Email Headers:

IP Hostname City Region Country Organisation US AS4181 TDS TELECOM Ankara Ankara TR AS9121 Turk Telekomunikasyon Anonim Sirketi

Received: from ([]:53623)
by with esmtp (Exim 4.89)
(envelope-from <>)
id 1d7Xv1-0006IL-AO
for; Mon, 08 May 2017 02:57:03 +0100
Received: from (unknown [])
by (Postfix) with ESMTPSA id 322F3C4921F
for <>; Sun,  7 May 2017 21:56:34 -0400 (EDT)
From: Email Support <>
Subject: E-mail Account Update
Date: 08 May 2017 04:57:31 +0300
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/html;
Content-Transfer-Encoding: quoted-printable

If you follow the link inside the email  you see a webpage looking like this: hxxp://   ( where the email address the email was sent to is automatically inserted)


After you input your  password, you first get get told “checking details” then “incorrect details” and forwarded to an almost identical looking page where you can put it in again and each time it goes round the same saga.

We all get very blaze about phishing and think we know so much that we will never fall for a phishing attempt. Don’t assume that all attempts are obvious. Watch for any site that invites you to enter ANY personal or financial information. It might be an email that says “you have won a prize” or “sign up to this website for discounts, prizes and special offers”.

Kazuar: Multiplatform Espionage Backdoor with API Access

00MalwareTags: , , , , ,

Unit 42 researchers have uncovered a backdoor Trojan used in an espionage campaign. The developers refer to this tool by the name Kazuar, which is a Trojan written using the Microsoft .NET Framework that offers actors complete access to compromised systems targeted by its operator. Kazuar includes a highly functional command set, which includes the ability to remotely load additional plugins to increase the Trojan’s capabilities. During our analysis of this malware we uncovered interesting code paths and other artifacts that may indicate a Mac or Unix variant of this same tool also exists. Also, we discovered a unique feature within Kazuar: it exposes its capabilities through an Application Programming Interface (API)  to a built-in webserver.

Recently, we received data shared in confidence that may link the Kazuar tool to the Turla threat actor group (also known as Uroburos and Snake), who have been reported to have compromised embassies, defense contractors, educational institutions, and research organizations across the globe. A hallmark of Turla operations is iterations of their wools and code lineage in Kazuar can be traced back to at least 2005. If the hypothesis is correct and the Turla threat group is using Kazuar, we believe they may be using it as a replacement for Carbon and its derivatives. Of the myriad of tools observed in use by Turla Carbon and its variants were typically deployed as a second stage backdoor within targeted environments and we believe Kazuar may now hold a similar role for Turla operations.

Kazuar is a fully featured backdoor written using the .NET Framework and obfuscated using the open source packer called ConfuserEx.  We used a combination of tools such as NoFuserEx, ConfuserEx Fixer, ConfuserEx Switch Killer, and de4d0t in order to deobfuscate the code for in depth analysis.  We then used dnSpy to export the code to a Microsoft Visual Studio project, so that we could rename the random method names to better understand the flow of the code. We will describe how Kazuar works and what capabilities it offers threat actors.


The malware initializes by gathering system and malware filename information and creates a mutex to make sure only one instance of the Trojan executes on the system at a time. Kazuar generates its mutex by using a process that begins with obtaining the MD5 hash of a string “[username]=>singleton-instance-mutex”. The Trojan then encrypts this MD5 hash using an XOR algorithm and the serial number of the storage volume. Kazuar uses the resulting ciphertext to generate a GUID that it appends to the string “Global\\” to create the mutex.

An interesting artifact that we found within the mutex creation process is that if the code cannot obtain the system’s storage serial number, it will use a static integer of 16456730 as a key to encrypt the MD5 hash. The hexadecimal representation of 16456730 is 0xFB1C1A, which appears to be included by the malware author as a potential reference to the United States’ FBI and CIA organizations.

The Trojan then creates a set of folders on the system to store various files created during its execution. Kazuar creates its folders using group names, which logically organize the files contained within the folder. Folder layout:

Folder Group Files Description
base Parent folder that contains the following folder groups below
sys Files that Kazuar uses for configuration settings, such as the ‘serv’ item that stores the C2 server locations
log Files contain debug messages
plg Files are plugins used to extend the functionality of Kazuar
tsk Files that Kazuar will process as commands and their arguments
res Files contain the results of the successfully processed tasks

Kazuar’s folder group names and the files stored within

The Trojan uses a similar process to create these folder and file names as it uses to generate its mutex, generating an MD5 hash of the name, using XOR on each byte using the volume serial number as a key and generating a GUID based on the ciphertext. The resulting GUIDs are used as file and folder names, which are combined with the local system path to the %LOCALAPPDATA% folder to create Kazuar’s folders.

Throughout its code, Kazuar verbosely logs its activities by writing debug messages to log files stored within the “log” folder. Kazuar encrypts the debug messages saved in these log files using the Rijndael cipher. We decrypted the initial entry that was added to the log files during the execution of the Trojan. This entry reveals the following information:

The log message above shows that the malware author refers to the Trojan as “Kazuar”. Interestingly, the word “Kazuar” appears in several languages, such as Polish, Hungarian and Slovenian, and is the ASCII form of the Russian word “казуар”. The word “Kazuar” and казуар translates to Cassowary, which is a large flightless bird native to New Guinea and Australia.

After initial setup, the method at the main entry point of the malware, as seen in Figure 2 may follow one of four main paths of execution. The main entry point contains a relatively simple set of if statements that determine the execution path of the malware. Interestingly, one of the paths appears to be for execution on a Mac or Unix host.


Figure 2: Main entry point shows if statements that control the flow of execution

The four possible paths of execution taken by Kazuar’s main entry point are as follows:

  1. If the malware was executed with the “install” command-line argument, which uses .NET Framwork’s InstallHelper method to install the malware as a service.
  2. If the malware is started in a non-user interactive environment (no user interface), the malware installs itself as a service.
  3. If no arguments are provided and the malware determines it is running in a Windows environment, it saves a DLL to the system that it injects into the explorer.exe process. The injected DLL executable loads the malware’s executable and runs it within memory of the explorer.exe process.
  4. If the malware was executed with the “single” command-line argument or the malware determines its running in a Mac or Unix environment, it runs the method containing Kazuar’s functional code and will limit certain Windows specific functionality if a Mac or Unix environment is detected.

The flow of execution is carefully guided by its operating environment, which is determined using the .NET Framework Environment.OSVersion.Platform.PlatformID enumeration, as seen in the function in Figure 3 that is responsible for gathering system specific information. Interestingly, we see a specific boolean variable for a PlatformID value of Unix that suggests that Kazuar might be used against Mac or Unix targets that return True for that API.


Figure 3. The getsysinfo() function provides various environment enumeration capabilities for Kazuar.

After enumerating the operating environment, Kazuar will attempt to establish persistent access to the system. Kazuar uses the method displayed in Figure 4 within its Autorun class to set up persistence on Windows systems, which has multiple options including:

  1. Adding a shortcut (lnk file) to the Windows startup folder
  2. Adding a sub-key to the following paths in the current user (HKCU) hive:
    • SOFTWARE\Microsoft\Windows\CurrentVersion\Run
    • SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce
    • SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
    • SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell
    • SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\load


Figure 4. Kazuar’s Autorun class is a Windows specific method that contains multiple options for persistence using the startup folder and registry.

Command and Control (C2)

The Kazuar Trojan initially relies on its command and control channel to allow actors to interact with the compromised system and to exfiltrate data. Kazuar has the capabilities to use multiple protocols, such as HTTP, HTTPS, FTP or FTPS, determined by the prefixes of the hardcoded C2 URLs. So far, we have only observed HTTP used as the C2 protocol in our sample set. All of the known Kazuar C2 servers appear to be compromised WordPress blogs, suggesting that the threat group using Kazuar in attacks also locates and exploits vulnerable WordPress sites as part of their playbook.

To interact with its C2 server, Kazuar begins its communication by creating an HTTP GET request to use as a beacon. The beacon, generated by the code seen in Figure 5 contains a cookie that has an “AuthToken” value that is a base64 encoded GUID used to uniquely identify the compromised system. Kazuar refers to this GUID as an “agent” identifier.


Figure 5. The createGET and getWebRequest classes define the construction of the HTTP request used for command and control communication.

During our analysis, we observed the beacon seen in Figure 6 sent via HTTP from a Kazuar sample to its C2 server. The initial HTTP beacon shows the base64 encoded AuthToken value within the Cookie field that we believe the C2 server uses to uniquely identify and track individual compromised hosts.


Figure 6.  Wireshark snippet of a fully constructed HTTP GET request which shows the base64 encoded GUID within the Cookie header.

Kazuar will read the response from the C2 server and attempt to parse the response as XML formatted data. The XML formatted data will contain what Kazuar refers to as a “task”, which is comprised of an action identifier and specific arguments for each action. Figure 7 below shows the code responsible for receiving the response to the HTTP request and using a long integer stored in the “num” variable as the action identifier.


The response parser listens for new tasks to be received from the command and control server.

The action identifier is directly related to the command which the actor wishes to run on the compromised system. Surprisingly, Kazuar also contains methods for each command to equate the action identifier to a string that describes the command, which makes determining the purpose of each command much easier. Table 2 shows a list of available commands within Kazuar, specifically each action identifier, command string and a description.

Action ID Commands Description
1 log Logs a specified debug message
2 get Upload files from a specified directory. It appears the actor can specify which files to upload based on their modified, accessed and created timestamps as well.
3 put Writes provided data (referred to as ‘payload’) to a specified file on the system.
4 cmd Executes a specified command and writes the output to a temporary file. The temporary file is uploaded to the C2 server
5 sleep Trojan sleeps for a specified time
6 upgrade Upgrades the Trojan by changing the current executable’s file extension to “.old” and writing a newly provided executable in its place
7 scrshot Takes a screenshot of the entire visible screen. The screenshot is saved to a specified filename or using a filename with the following format: [year]-[month]-[day]-[hour]-[minute]-[second]-[milisecond].jpg. The file is uploaded to the C2 server
8 camshot Creates a Window called “WebCapt” to capture an image from an attached webcam, which it copies to the clipboard and writes to a specified file or a file following the same format from the “scrshot” command. The file is uploaded to the C2 server
9 uuid Sets the unique agent identifier by providing a specific GUID
10 interval Sets the transport intervals, specifically the minimum and maximum time intervals between C2 communications.
11 server Sets the C2 servers by providing a list of URLs
12 transport Sets the transport processes by providing a list of processes that Kazuar will inject its code and execute within.
13 autorun Sets the autorun type as discussed earlier in this blog. Kazuar will accept the following strings for this command: DISABLED, WINLOGON, POLICIES, HKCURUN, RUNONCE, LOADKEY, STARTUP
14 remote Sets a remote type. We are only aware of one remote type that instructs Kazuar to act as an HTTP server and allow the threat actor to interact with the compromised system via inbound HTTP requests.
15 info Gathers system information, specifically information referred to as: Agent information, System information, User information, Local groups and members, Installed software, Special folders, Environment variables, Network adapters, Active network connections, Logical drives, Running processes and Opened windows
16 copy Copies a specified file to a specified location. Also allows the C2 to supply a flag to overwrite the destination file if it already exists.
17 move Moves a specified file to a specified location. Also allows the C2 to supply a flag to delete the destination file if it exists.
18 remove Deletes a specified file. Allows the C2 to supply a flag to securely delete a file by overwriting the file with random data before deleting the file.
19 finddir Find a specified directory and list its files, including the created and modified timestamps, the size and file path for each of the files within the directory.
20 kill Kills a process by name or by process identifier (PID)
21 tasklisk List running processes. Uses a WMI query of “select * from Win32_Process” for a Windows system, but can also running “ps -eo comm,pid,ppid,user,start,tty,args” to obtain running processes from a Unix system.
22 suicide We believe this command is meant to uninstall the Trojan, but it is not currently implemented in the known samples.
23 plugin Installing plugin by loading a provided Assembly, saving it to a file whose name is the MD5 hash of the Assembly’s name and calling a method called “Start”.
24 plugout Removes a plugin based on the Assembly’s name.
25 pluglist Gets a list of plugins and if they are “working” or “stopped”
26 run Runs a specified executable with supplied arguments and saves its output to a temporary file. The temporary file is up loaded to the C2 server.

Table 2: Kazuar’s command handler, including action identifier, command string and description.


As can be seen from the Table 2 above, Kazuar has an extensive command set, many of which are similar in functionality as other backdoor Trojans. However, a few commands specific to Kazuar appear to be unique and are worth further discussion.

First, several of these commands contain checks to determine the environment in order to use appropriate paths or commands. The ‘tasklist’ command will use a WMI query or the “ps” command, which allows Kazuar to obtain running processes from both Windows and Unix systems. Also, Kazuar’s ‘cmd’ command will run commands using “cmd.exe” for Windows systems and “/bin/bash” for Unix systems. These two commands provide evidence that the authors of Kazuar intended to use this malware as a cross-platform tool to target both Windows and Unix systems.

Kazuar contains three commands related to plugins: plugin, plugout and pluglist. These three commands allow an actor to administer a framework that allows Kazuar to use additional plugins. This plugin framework provides Kazuar potentially endless functionality, as its operators can provide additional .NET applications that Kazuar can load and execute.

Kazuar’s Remote API:

While many backdoor Trojans have extensive command handlers and plugin frameworks, Kazuar’s ‘remote’ command provides a functionality that is rarely seen in backdoors used in espionage campaigns. This command instructs the Trojan to start a thread to listen for inbound HTTP requests, which effectively turns Kazuar into a webserver. This functionality provides an API for the Trojan to run commands on the compromised system. Figure 8 shows the code within Kazuar that provides this functionality.


Figure 8 HTTP method handler used by Kazuar to provide threat actors with API access

To initiate this functionality, the actor will issue the ‘remote’ command and provide a list of URI prefixes that Kazuar’s HTTP listener will process and respond to. The URI prefix supplied by the actor would be added to the “Prefixes” property of the HttpListener class, which requires a schema, a host, an optional port and optional path. The actor would then issue HTTP requests to URLs that match these URI prefixes using specific methods, specifically OPTIONS, POST, GET and PUT methods to interact with the compromised system using Kazuar’s command set seen in Table 3.

This functionality flips the communication flow between the Trojan and the C2 server. Instead of the Trojan initiating communications with its C2 server, the C2 server sends requests directly to the Trojan. This communications flow is important if the compromised system is a remotely accessible server that may raise flags when initiating outbound requests. Also, by creating this type of API access, the threat actors could use one accessible server as a single point to dump data to and exfiltrate data from.

HTTP Method Description of Functionality
OPTIONS No functionality, just responds with an HTTP “OK” status
POST Actor provides XML formatted data that Kazuar will use to create a new task. Uses the exact same method (‘readResponse0’ seen in Figure 7) to parse the XML data obtained in the initial C2 communications channel discussed earlier. Kazuar writes the results of the task to a log file that it references as “res” within a folder referenced as “tsk”.
GET Provides the contents of the results of the previous task created via the HTTP POST request that is stored in the “res” file.
PUT Actor provides XML formatted data that Kazuar will use to create a new task. This method is similar to the POST method, however, instead of saving the results of the command to a “res” file it responds to the HTTP PUT request with the results of the command.

Table 3 HTTP methods and the functionality they provide in Kazuar’s API

This functionality flips the communication flow between the Trojan and the C2 server. Instead of the Trojan initiating communications with its C2 server, the C2 server sends requests directly to the Trojan. This communications flow is important if the compromised system is a remotely accessible server that may raise flags when initiating outbound requests. Also, by creating this type of API access, the threat actors could use one accessible server as a single point to dump data to and exfiltrate data from.


While yet another fully featured backdoor alone is not particularly novel, the existence of a code path for Unix, combined with the portability of .NET Framework code makes the Kazuar Trojan an interesting tool to keep an eye on. Another interesting portion of this malware is its remote API that allows actors to issue commands to the compromised system via inbound HTTP requests. Based on our analysis, we believe that threat actors may compile Windows and Unix based payloads using the same code to deploy Kazuar against both platforms. Palo Alto Networks AutoFocus subscribers can explore additional samples using the Kazuar AutoFocus tag.

Indicators of Compromise:










File Activity:



%USERPROFILE%\Start Menu\Programs\Startup\*.lnk

RSA Keys:



Decrypted Log and Error Messages:

‘{0}’ autorun algorithm is not supported!

‘{0}’ request method isn’t supported.

Accessed date mismatch in get command!

Accessed date mismatch in list command!

Action with identifier {0} is not implemented.

Autorun command requeres autorun type to be set!

Autorun failed due to {0}

Cmd command requires actual commands list!

Commiting suicide…

Control server address ‘{0}’ is invalid.

Copy command requires destination path!

Copy command requires source path!

Copying file from {0} to {1}…

Created date mismatch in get command!

Created date mismatch in list command!

Directory listing for {0}

Executing command with {0}…

Failed to create agent due to {0}

Failed to create channel due to {0}

Failed to create injector due to {0}

Fatal failure due to {0}

Getting file query {0}…

Getting system information…

Going to sleep for {0}…

Got ‘{0}’ command from {1}.

Got new ‘{0}’ command.

Got new task #{0} from {1}.

HTTP listening isn’t supported.

IPC channel is not ready.

Injected into explorer.

Injected into {0} [{1}].

Injecting into explorer…

Injecting into {0} [{1}]…

Injection failed due to {0}

Installing plugin…

Invalid FTP server status ({0}).

Invalid last contact time.

Invalid or unknown action format ({0})!

Invalid sender interval.

Kazuar’s {0} started in process {1} [{2}] as user {3}/{4}.

Killing processes…

List command requires file query string!


Listing plugins…

Listing processes…

Max interval value is less than min value!

Max interval value is more than supported!

Min interval value is less than supported!

Modified date mismatch in get command!

Modified date mismatch in list command!

Move command requires destination path!

Move command requires source path!

Moving file from {0} to {1}…

Mozilla/5.0 (Windows NT {0}.{1}; rv:22.0) Gecko/20130405 Firefox/23.0

Mozilla/5.0 (X11; {0} {1}; rv:24.0) Gecko/20100101 Firefox/24.0

New plugin {0} was installed.

No servers available now.

Plugin command requires payload!

Plugin installed.

Plugin removed.

Plugin {0} was removed.

Plugin {0} was started.

Plugout command requires plugin name string!

Proc kill command requires name or pid to be set!

Process {0} [{1}] exited with {2} code.

Process {0} [{1}] impersonated.

Put command requires correct file path!

Put command requires payload!

Putting file to {0}…

Remote control failed due to {0}

Remote failed due to {0}

Remote iteration failed due to {0}

Remote request from {0} failed due to {1}

Remove command requires file path!

Removing file {0}…

Removing plugin…

Request was sent to {0}.

Result #{0} was sent to {1}.

Result #{0} was taken by {1}.

Run command requires executable path!

Run-time error {0}:{1:X8}.

Run-time error {0}:{1}.

Scheme ‘{0}’ is not supported!

Searching file query {0}…

Send iteration failed due to {0}

Sending request to {0}…

Sending result #{0} to {1}…

Server command requires at least one server!

Setting agent id to {0}…

Setting autorun type to {0}…

Setting remote type to {0}…

Setting transport interval to [{0} – {1}]…

Setting transport processes:

Setting transport servers:

Shellcode error {0:X16}.

Sleep interval is longer than supported!

Solving task #{0}…

Startup path is empty.

Taking screen shot…

Taking webcam shot…

Task #{0} execution finished.

Task #{0} execution started:

Task #{0} failed due to {1}

Task #{0} solved.

Transport command requires at least one process name!

Transport process name ‘{0}’ is invalid.

Transport processes

Unable to create capture window.

Unable to delete task #{0} file due to {1}

Unable to execute command due to {0}

Unable to execute task #{0} due to {1}

Unable to get last contact time due to {0}

Unable to get task from {0} due to {1}

Unable to impersonate {0} [{1}] due to {2}

Unable to return logs due to {0}

Unable to send result #{0} to {1} due to {2}

Unable to start plugin {0} due to {1}

Unable to stop plugin {0} due to {1}

Unable to store agent id due to {0}

Unable to store autorun type due to {0}

Unable to store interval due to {0}

Unable to store remote type due to {0}

Unable to store servers due to {0}

Unable to store transports due to {0}

Unhandled exception {0}

Upgrade command requires payload!

Upgrading agent…

Using default agent id due to {0}

Using default autorun type due to {0}

Using default interval due to {0}

Using default remote type due to {0}

Using default servers due to {0}

Using default transports due to {0}

Uuid command requires identifier!

Waiting for shellcode failed.

Waiting for window ‘{0}’ failed.

explorer.exe, {0}

ERROR: {0}

Plugin {0}

{0} doesn’t exist!

{0} was skipped.

proc – {0} [{1}]

time – {0}

user – {0}/{1} ({2})


Iranian Fileless Attack Infiltrates Israeli Organizations

00Latest news, Malware, OilRigTags: , , , ,


From April 19-24, 2017, a politically-motivated, targeted campaign was carried out against numerous Israeli organizations. Morphisec researchers began investigating the attacks on April 24 and continue to uncover more details. Initial reports of the attacks, published April 26 (in Hebrew) by the Israel National Cyber Event Readiness Team (CERT-IL) and The Marker, confirm that the attack was delivered through compromised email accounts at Ben-Gurion University and sent to multiple targets across Israel. Ironically, Ben-Gurion University is home to Israel’s Cyber Security Research Center. Investigators put the origin of the attack as Iranian; Morphisec’s research supports this conclusion and attributes the attacks to the same infamous hacker group responsible for the OilRig malware campaigns.

The attack was delivered via Microsoft Word documents that exploited a former zero-day vulnerability in Word, CVE-2017-0199, to install a fileless variant of the Helminth Trojan agent. Microsoft released the patch for the vulnerability on April 11, but many organizations have not yet deployed the update. The attackers actually based their attack on an existing Proof-of-Concept method that was published by researchers after the patch release.

By hunting through known malware repositories, Morphisec identified matching samples uploaded by Israeli high-tech development companies, medical organizations and education organizations, indicating that they were victims of the attack. For security purposes, Morphisec is not revealing these names.

The delivery was executed by compromising the email accounts of a few high-profile individuals at Ben-Gurion University. The Word document was sent as a reply to legitimate emails sent from those accounts and was propagated to more than 250 individuals in different Israeli companies, according to CERT-IL.

Upon deeper investigation into the installed Helminth fileless agent, we identified a near perfect match to the OilRig campaign executed by an Iranian hacker group against 140 financial institutions in the Middle East last year, as analyzed by FireEye , Palo Alto Networks and Logrhythm. This group has become one of the most active threat actors, with noteworthy abilities, resources and infrastructure; speculations indicate the hacking organization to be sponsored by the Iranian government. In other recent attacks (January 2017), the group used a fake Juniper Networks VPN portal and fake University of Oxford websites to deliver malware as described by ClearSky.

Our report presents the technical details of the attack, emphasizing differences from last year’s attack. In particular, there are several enhancements to different evasive mechanisms and some modifications in the communications protocol, which delivers PowerShell commands from the C&C.

The most important difference is that the use of macros was exchanged with a vulnerability exploit. With their ability to set up the attack in a relatively short time, the threat actors could correctly speculate that their window of opportunity between patch release and patch rollout was still open.

At the time of publication, the C&C servers are still active and will be listed herein as all other signatures and indicators of compromise.


Word Delivery:

The different delivered documents, as shown below, are generally named with some random number <random number>.doc.

Cyberattack on Israel_01.png

Morphisec identified the following set of documents:

Name SHA256
13.doc a9bbbf5e4797d90d579b2cf6f9d61443dff82ead9d9ffd10f3c31b686ccf81ab
558.doc, 2.doc 2869664d456034a611b90500f0503d7d6a64abf62d9f9dd432a8659fa6659a84
1.doc 832cc791aad6462687e42e40fd9b261f3d2fbe91c5256241264309a5d437e4d8
3.doc d4eb4035e11da04841087a181c48cd85f75c620a84832375925e6b03973d8e48

CVE-2017-0199 Vulnerability Exploit

The most notable difference from last year’s OilRig campaign is the way the attack was delivered. In the previous campaign, the Iranian group sent specially crafted Excel and Word files, which contained macros that targeted individuals were convinced to enable.

In this campaign, no macros were required. Each document utilized the vulnerability by an embedded link that delivers an .hta file (html executable).

Cyberattack on Israel_02.png

Morphisec identified the following delivered test<number>.hta file with the same signature delivered from the following domains:

Name Delivery Server
test4.hta hxxp://comonscar[.]in  (
test1.hta reserved

SHA256: 5ac61ea5142d53412a251eb77f2961e3334a00c83da9087d355a49618220ac43

The .hta file is immediately executed by mshta.exe, the Windows process which executes html executables. As a result, the user is usually shown a warning message, despite the fact that the HTA is still executed even if the user chooses “No”:

Cyberattack on Israel_03.png

The .hta file in this attack is much more sophisticated than in previous versions, and actually disables this message by sending an “Enter” command to the warning window. This is covered in the next section.

HTA Execution and Persistency:

The HTA execution goes through the following steps:

  1. Before installing the agent, the .hta file sends the “Enter” key into the Word application to remove the warning message and minimize any appearance of suspicious execution. It is done by creating and executing a 1.vbs script.

Cyberattack on Israel_04.png

  1. The next step writes and executes the 0011.ps1 PowerShell script, which is described in the following section.

Cyberattack on Israel_05.png

  1. The last step kills the original process that activated the .hta file, to remove any suspicion.

Helminth Trojan Installation and Persistency:

0011.ps1 script, which is activated by the .hta file, is in charge of generating the Helminth Trojan PowerShell and VBS files.

Name SHA256
0011.ps1 042F60714E9347DB422E1A3A471DC0301D205FFBD053A4015D2B509DB92029D1
1.vbs BE7F1D411CC4160BB221C7181DA4370972B6C867AF110C12850CAD77981976ED

Morphisec identified the following structure:

Cyberattack on Israel_06.png

This structure matches the attack structure from October 2016, as described by Logrhythm:

Cyberattack on Israel_07.png

Aside the unique generation of the files, the structure and the functionality of the trojan is very similar to the previous campaign:

  1. The PowerShell script ps1 creates similar variants of Helminth trojan PowerShell and VBS files templates (DnS1.Ps1, DnE1.Ps1, backup1.vbs). Those templates are regenerated on the infected computer by replacement of all variables and function names to random names in order to slow down detection and remediation.

Cyberattack on Israel_08.png

  1. All the scripts are installed in the Public\Libraries\RecordedTV\ folder.
  2. As in the previous campaign, persistency is achieved by adding a schedule task with a similar name to the Google update task (“GoogleUpdateTasksMachineUI), which executes vbs every 3 minutes:

Cyberattack on Israel_09.png

  • Note: All the parameters in the 0011.ps1 script can be reconfigured, therefore some of the names could be different for the tasks and locations.

 Communication Protocol:

We will focus here on the DnE1.Ps1 file because all other files are almost identical to the previous campaign. This file executes some of the same commands executed by VBS script in the previous campaign, but there are differences as well. The script connects to a C&C server – vpsupdate[.]tk. At the time of this report’s publication, the C&C server is still live; the server was first registered on April 16, 2017. The goal of the script is to:

  • Download bat script
  • Execute it and upload the results back to the C&C
  • Clear traces

Cyberattack on Israel_10.png

At each new activation (first) activation of the download command (GET request), the infected computer receives a bat script for activation from the C&C:

  • vpsupdate[.]tk/index.aspx?id=<random character><randomnumber>[b] (the “b” is for download)

The file name of the bat script is then delivered through the response headers, and the content of the bat script is delivered through the response. Both of them are encoded in base 64.

Cyberattack on Israel_11.png

The name of the file is default.bat (decoded from Content-Disposition property in the header) and it is saved temporary in the dn folder (described in the next section).

Note: Morphisec identified several other samples of communication with different C&C servers (“alenupdate[.]info” and “maralen[.]tk”) in which a more advanced customized version of Mimikatz was sent to specific users, and an additional agent was installed in the “C:\Program Files (x86)\Microsoft Idle\” directory:

Cyberattack on Israel_12.png

Cyberattack on Israel_13.png

Back to the popular variant of the protocol: As soon as the file executes and the result output is written to default.bat.txt (similarly to the previous campaign), the resulting file is uploaded back to the C&C using the following URL command (POST request):

  • vpsupdate[.]tk/index.aspx?id=<random character><randomnumber>[u] (the “u” is for upload)

Cyberattack on Israel_14.png

At the same time, the DnE1.Ps1 is executed. The DnS1.Ps1 is also executed and communicates with the C&C using DNS exchange queries (the same as in the previous campaign). This kind of communication is very hard to block since DNS is a basic functionality required in any organization.

Delivered Commands:

The bat script is a customized version of Mimikatz (with slight modification from the last campaign). Its goal is to gather information from the computer and the network:

Cyberattack on Israel_15.png

The added commands are chcp to handle non-ASCII characters (e.g. Hebrew) and the validation of the scheduled task (which should have been added by the persistency mechanism).

As mentioned in the previous section, Morphisec identified an advanced version of the same bat script communicating with the alenupdate[.]info C&C. In that case, the information that is gathered includes A.V., Firewall and AntiSpy product information. The persistent tasks are slightly different as well, “Google Update Core” and “Google Sync Core”.

Cyberattack on Israel_16.png


  1. The scheduled task “GoogleUpdateTasksMachineUI” should be removed. Note that regular Google update tasks look like GoogleUpdateTask[Machine|User]* without the “s” in Tasks).
    1. In case “Google Update Core” or “Google Sync Core” exists, those need to be removed as well.
  2. Access Public\Libraries\RecordedTV folder. Note that the Libraries folder in Public is hidden, and you should delete the folder and not the RecordedTV icon – if you have only the icon, then the agent is not installed.
  3. If the following directory exists, remove it: “Program Files(x86)\Microsoft Idle”
  4. If the following directory contains “WinInit.lnk” or “SyncInit.lnk” files, remove those files: “%userprofile%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup”


Every few years, a new “logic bug” CVE in OLE object linking is identified; the previous one was three years ago (CVE-2014-4114 and CVE-2014-6352). This kind of vulnerability is rare but powerful. It allows attackers to embed OLE objects (or links in the case of CVE-2017-0199) and bypass Microsoft validation of OLE execution without warning. In essence, it is the same as playing animation in PowerPoint.


Such vulnerabilities should be patched immediately.

It is significant to note how the Iranian threat actors advanced their abilities in such a short time:

  • Utilizing a vulnerability PoC immediately after its publication
  • Setting up the required infrastructure with multiple domains and delivery servers
  • Increasing the sophistication of the delivered Helminth agent, including regeneration of its signatures on the infected computer
  • Improving the customized information gathering Mimikatz version

With many organizations taking high-risk vulnerabilities seriously and patching them as quickly as possible, attackers can no longer exploit them for an extended period of time. We therefore expect that threat actors will return to macro-based campaigns like Hancitor.

Indicators of Compromise (IOCs)

Document delivery:

Name SHA256
13.doc a9bbbf5e4797d90d579b2cf6f9d61443dff82ead9d9ffd10f3c31b686ccf81ab
558.doc, 2.doc 2869664d456034a611b90500f0503d7d6a64abf62d9f9dd432a8659fa6659a84
1.doc 832cc791aad6462687e42e40fd9b261f3d2fbe91c5256241264309a5d437e4d8
3.doc d4eb4035e11da04841087a181c48cd85f75c620a84832375925e6b03973d8e48

HTA delivery servers:

hxxp://comonscar[.]in  (

 HTA files:

Name SHA256
test4.hta, test5.hta 5ac61ea5142d53412a251eb77f2961e3334a00c83da9087d355a49618220ac43

 Helminth Trojan Installers:

Name SHA256
0011.ps1 042F60714E9347DB422E1A3A471DC0301D205FFBD053A4015D2B509DB92029D1
1.vbs BE7F1D411CC4160BB221C7181DA4370972B6C867AF110C12850CAD77981976ED




Task Name
Google Update Core
Google Sync Core

Appendix: CERT-IL has listed additional IoCs that are not mentioned in this list, which include the January campaign that involved malicious Juniper Networks VPN and fake Oxford registration form executables and their C&C domain server. Full article HERE.