Action Fraud UK has received the first reports of Tech-Support scammers claiming to be from Microsoft who are taking advantage of the global WannaCry ransomware attack.
One victim fell for the scam after calling a ‘help’ number advertised on a pop up window. The window which wouldn’t close said the victim had been affected by WannaCry Ransomware.
The victim granted the fraudsters remote access to their PC after being convinced there wasn’t sufficient anti-virus protection. The fraudsters then installed Windows Malicious Software Removal Tool, which is actually free and took £320 as payment.
It is important to remember that Microsoft’s error and warning messages on your PC will never include a phone number.
Additionally Microsoft will never proactively reach out to you to provide unsolicited PC or technical support. Any communication they have with you must be initiated by you.
How to protect yourself
Don’t call numbers from pop-up messages.
Never allow remote access to your computer.
Always be wary of unsolicited calls. If you’re unsure of a caller’s identity, hang up.
Never divulge passwords or pin numbers.
Microsoft or someone on their behalf will never call you.
If you believe you have already been a victim
Get your computer checked for any additional programmes or software that may have been installed.
Contact your bank to stop any further payments being taken.
Lessons From WannaCry & How To Build Towards a Secure Future
Webinar Thursday, June 1st, at 11 AM EDT
WannaCry attacked 300,000 machines across 100+ countries on May 12th. The fallout has been massive, prompting companies across the globe to take stock of their security infrastructure and think hard about the motivations of the attackers. They are professionals with resources, who will continue to adapt and get better.
Join our webinar to hear Cybereason’s Chief Product Officer, and former CISO and CTO of Arbor, discuss the different types of attackers traversing the web and how their mindset and philosophies are evolving to become more agile and resilient. You will hear Sam’s vision for security in 2018, and where he thinks companies should be investing their time, energy and dollars.
You will also see a brief overview of Cybereason’s EDR platform (which stopped Wannacry), and qualify for an exclusive offer reserved only for registrants of this webinar: up to 90 days free of Cybereason.
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.
if (typeof$uaU$Fh71K_E6TQAdMPz.list[n] ==“string“) return$uaU$Fh71K_E6TQAdMPz.list[n].split(““).reverse().join(““);
“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“ ];
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.
GET / HTTP/1.1
User-Agent: Mozilla/5.0 (compatible; MSIE 8.0; Windows NT 5.1; SLCC1; .NET CLR 1.1.4322)
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:
asymmetrically encrypted 128-bit AES key used for request encryption
SHA1 hash of plaintext request body
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_CryptGenKey(cryptCtx->hProv, CALG_AES_128, CRYPT_MODE_CBC, &cryptCtx->hCryptAES) )
if ( fn_CryptCreateHash(cryptCtx->hProv, CALG_SHA1, 0, 0, &cryptCtx->hCryptSHA1) )
if ( !fn_CryptDuplicateHash(cryptCtx->hCryptSHA1, 0, 0, &hHash) )
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:
Registration request contains command id (16) and some information about host operating system. Each field of RegistrationRequestBody structure has been described below:
This field provides information about values specific to victim’s machine and probably is meant to be unique between bot instances.
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.
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
Content-Type: text/html; charset=UTF-8
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.
required int32 type = 1;
required bytes blob = 2;
repeatedModulemodules = 1 [packed=true];
requireduint32timestamp = 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.
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:
Store in %TEMP% and execute with -U argument
Like ‘1’, but without arguments
Download and execute file from URL specified ‘blob’
Use own internal loader – load and execute PE file from ‘blob’
Uninstall – delete related ‘.lnk’ from Startup folder
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
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:
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.
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:
requiredstringbotId = 1;
requiredint32flags = 2 [default = 3];
requiredstringadditionalData = 3;
requiredint32command = 1 [default = 18];
optionalSpamRequestBodyspamRequest = 2;
Fields flags and additionalData specify, which data has been received from server and which we’re expecting in C&C answer.
This e-mail was sent by <span style=”text-transform: uppercase;”><>
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.
—–BEGIN PUBLIC KEY—–
—–END PUBLIC KEY—–
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:
Brief behavioral analysis revealed the code reaches out to the following URLs:
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:
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:
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 identifiedfunctions 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.
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.
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):
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.
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.
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.
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:
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.
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.
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.
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:
forall_proc array is created with a single element of the restore proc
The EPS state is saved to eps_state
uaf_array is created after the save
The forall operator loops over the elements of the uaf_array calling forall_proc for each element
The first element of uaf_array is passed to a call of restore_proc, the procedure contained in forall_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
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.
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.
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.
Table 1: Source Exploit Documents
Table 2: CVEs related to these attacks
You find the article useful? Help us out as well 🙂
Security researchers say exploiting the vulnerability requires little technical expertise, and can result in a hacker taking full control of an affected PC.
A vulnerability in Intel chips that went undiscovered for almost a decade allows hackers to remotely gain full control over affected Windows PCs without needing a password.
The “critical”-rated bug, disclosed by Intel last week, lies in a feature of Intel’s Active Management Technology (more commonly known as just AMT), which allows IT administrators to remotely carry out maintenance and other tasks on entire fleets of computers as if they were there in person, like software updates and wiping hard drives. AMT also allows the administrator to remotely control the computer’s keyboard and mouse, even if the PC is powered off.
To make life easier, AMT was also made available through the web browser — accessible even when the remote PC is asleep — that’s protected by a password set by the admin.
The problem is that a hacker can enter a blank password and still get into the web console, according to independent technical rundowns of the flaw by two security research labs.
Embedi researchers, credited with finding the bug, explained in a whitepaper posted Friday that a flaw in how the default “admin” account for the web interface processes the user’s passwords effectively lets anyone log in by entering nothing at the log-on prompt.
“No doubt it’s just a programmer’s mistake, but here it is: keep silence when challenged and you’re in,” said the researchers.
Intel’s advisory said that systems — including desktops, laptops, and servers — dating back as early as 2010 and 2011 and running firmware 6.0 and later are affected by the flaw.
But Embedi warned that any affected internet-facing device with open ports 16992 and 16993 are at risk. “Access to ports 16992/16993 are the only requirement to perform a successful attack,” said the Embedi researchers.
Intel so far hasn’t said how many devices are affected.
However, a search on Shodan, the search engine for open ports and databases, shows more than 8,500 devices are vulnerable at the time of writing, with almost 3,000 in the US alone — but there could be thousands more devices at risk on internal networks.
In a statement, Intel said that it’s working with its hardware partners to address the problem, and “expect computer-makers to make updates available beginning the week of May 8 and continuing thereafter.”
So far, Dell, Fujitsu, HP, and Lenovo have all issued security advisories and have issued guidance on when they will roll out fixes to their customers. Consumer devices aren’t affected by the bug.
The chipmaker has also published a discovery tool to determine if machines are affected.
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 Live.com 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 <domain.com >. That is why these scams and phishes work so well.
The email looks like this:
From: Email Support <email@example.com>
Date: Mon 08/05/2017 02:58
Subject: E-mail Account Update
Update Your Mailbox
Received: from mail.addonusa.com ([126.96.36.199]:53623)
by knight.knighthosting.co.uk with esmtp (Exim 4.89)
for firstname.lastname@example.org; Mon, 08 May 2017 02:57:03 +0100
Received: from live.com (unknown [188.8.131.52])
by mail.addonusa.com (Postfix) with ESMTPSA id 322F3C4921F
for <email@example.com>; Sun, 7 May 2017 21:56:34 -0400 (EDT)
From: Email Support <firstname.lastname@example.org>
Subject: E-mail Account Update
Date: 08 May 2017 04:57:31 +0300
If you follow the link inside the email you see a webpage looking like this: hxxp://email@example.com ( 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”.