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

Tag: 0-day

Emotet v4 Analysis

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


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

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

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

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

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


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

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

Distribution sites found in dropper:


Main module:

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

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

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

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

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


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

Intercepted request:

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

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

After decoding, structure of request is described below:

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

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

Cryptography is based on Microsoft CryptoAPI mechanisms.

Key generation and public key import:

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

Request encryption:

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

Communication with C&C:

Received response is presented below:








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

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

Anyway, original protocol definitions were successfully reversed:

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

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

botId field

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

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

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

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

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

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


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

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


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

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

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

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

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

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

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

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


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

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

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

Credentials stealer:

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

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

Spam module:

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

Request structure presents as below:

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

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

Server response looks like below:

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

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

Message template example:

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

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

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

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


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

Additional informations


MD5 of fetched modules:

C&C list:


C&C public key:


Yara Rule:

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

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

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

You value our work? 

The Return of Qakbot Malware

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


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

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

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

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

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

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

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

Figure 1: Excerpt of Obfuscated JavaScript Update Script

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

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

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

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

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

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

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


Reviewing the samples:

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

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

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

•  2E6AC2290F1E3D80ABC8D0D6F736D965
•  651EF2DBA96011F47EED9B72BE7B4B8C
•  F3CAA54DDE4056FADD52A024CF6B82ED

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

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

•  7DBD0DF279062090C34F796EFC7DD239ECCD46B99B67AAC370D6048D5ADBB9EC
•   67F3BD674647CA0D294A894B6702362B6CFC4B6C2E147643E100903A6B4D715A

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

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

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

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

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

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

Unpacking Qakbot:

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

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

•   Set a breakpoint on VirtualProtect (Figure 3).

Figure 3: Set a Breakpoint on VirtualProtect Within x32dbg

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

Figure 4: Protection on Code Changed to PAGE_READWRITE

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

Figure 5: Protection on .text Section Changed to PAGE_EXECUTE_READ

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

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

Figure 6: Memory Map With Unpacked Code

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

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

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

Correlating Qakbot

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

Figure 8: Binary Diff of Unpacked Code From Two Samples

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

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

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

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


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


Indicators of Compromise (IoCs):

Sha-256 Hashes:




You value our work? 

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.