In depth analysis of malware exploiting CVE-2017-11826
Among the most common malware entry paths, SPAM campaigns have been identified as some of the principals. Normally, these campaigns usually incorporate a malicious link or an attached file (usually, an office document that contains a malicious macro).
On this occasion, Gradiant’ Security and Privacy team has obtained and analysed a sample of an office document that, instead of incorporating a malicious macro, exploits the 0-day vulnerability identified as CVE-2017-11826 whose patch was published on October 17, 2017. The use of this exploit allows the attacker to execute malicious code without the need of any user interaction.
Although it is always difficult to attribute an attack, the evidence suggests that it is probably a Russian botnet hosted on a US server.
Vulnerability analysis
| SAMPLE DATA | |
| Filename | 2.doc |
| Size | 664KiB (680268 bytes) |
| Type | RTF |
| Description | Rich Text Format data, version 1, unknown character set |
| S.O. | WINDOWS |
| SHA256 | cb3429e608144909ef25df2605c24ec253b10b6e99cbb6657afa6b92e9f32fb5 |
First, the OLE objects embedded in the RTF file attached to the mail of the SPAM campaign have been listed:
Specifically, the exploit lies in the file “./word/document.xml” belonging to the last object OLE in the previous figure (object id =2).
After analyzing the contents of the file, exploited vulnerability has been classified as type confusion since it takes place in the unexpected object idmap located just after the opening of the label font producing the error in the OOXML analyzer. Additionally, it has been observed that vulnerability requires special conditions that the attacker has taken into account, that is, has declared an object OLEObject just before the label font and added an attribute name with the large enough content (greater or equal to 32 Bytes after the conversion that takes place on it from UTF-8 to Unicode).
In order to analyze how the attacker exploits the vulnerability, the bytes of the font’s name attribute have been observed, obtaining the following hexadecimal representation:
Which, transformed to unicode and represent them in big endian as it happens in the OOXML’s analyzer, result in the following memory address: 0x088888EC
As you can see in the following image, when the type confusion happens, a pointer is dereferenced by obtaining the contents of said memory address, to which the program adds 4 units and the execution flow is transferred to the address resulting from said sum:
Exploit analysis. Arbitrary code execution
To control the contents of the memory address 0x088888EC the attackers have used the technique heap spraying which consists of filling a large proportion of the memory with the repetition of a sequence of bytes (called spray), so as to maximize the probabilities of finding that sequence of bytes in memory when your position can not be predicted accurately. In this case, the implementation of this technique has consisted of a large set of objects ActiveX wich imports the spray stored in the file activeX1.bin.
As you can see in the following image that shows part of the content of activeX1.bin, the attacker has made heap spraying of two memory addresses: to which the attacker wants the dereferenced pointer to point (0x088888EC) and the content that he wants in that memory location (0x729440CB) which is an address belonging to the library msvbvm60.dll Decreased by 4 units to compensate for the increase in 4 units accomplished by the vulnerable OOXML parser code.
The attackers loads the library “msvbvm60.dll” by its CLSID code as highlighted in the following image. In addition, it has been observed that said library is only loaded in order to make “ROP” about her (ROP is a software exploitation technique that allows to evade certain protections, for example: non-executable memory regions and code signing protections) since this library has disabled DEP y ASLR protections.
By using “msvbvm60.dll” library existing “ROP Gadgets” (grupos de instrucciones que permiten llevar a cabo la técnica ROP) the attacker gets to give execution permissions to the “shellcode” and redirect the execution flow to the beginning of it.
It has been observed that the shellcode simply decrypts and executes the embedded malware (a Portable Executable library) and consists of two phases: The first is what is known as “egg hunter”, that means, a code that locates and executes another code. In this case, the “egg hunter” locates the second part of the shellcode in Memory, decipher it and jump to said deciphered second part. The second part looks for the label 0xBABABABA (which is the marker that the attacker has used to indicate the direction in which the malware starts) and it applies a XOR decryption over all the DWORDs that make it up using the key 0xCAFEBABE until it reaches the end tag of malware labeled with 0xBBBBBBBB. By last, it uses the key 0xBAADF00D to decipher the document that will replace the original one.
As often happens in Portable Executable files, it contains many zeros. So, when encrypting these zeros with the key, the key is reflected in the encrypted text itself.
As you can see in the previous image, there are multiple appearances of the little endian 0xBEBAFECA DWORD, so this implies that, 0xCAFEBABE is the XOR key.
Making use of this information, a script which performs the extraction and decryption of the embedded file allowing the later static analysis has been developed.
————————————————– START CODE ———————————————–
#!/usr/bin/env python
# -*- coding: utf-8 -*-
DECODE_KEY=»CAFEBABE».decode(«hex»)
PE_START_TAG=»BA»*6
PE_END_TAG=»BB»*6
INPUT_FILE=»2.doc»
OUTPUT_FILE=»decoded.vir»
#It reads the document bytes
f=open(INPUT_FILE,»rb»)
bytes_doc=f.read()
f.close()
#It extracts the embebbed bynary file
pe_encoded=bytes_doc.split(PE_START_TAG.decode(«hex»))[1].split(PE_END_TAG.decode(«hex»))[0]
#It decrypts the embebbed file bytes
pe_decoded=»»
for pos in range(0,len(pe_encoded), 4):
try:
pe_decoded+=chr(ord(pe_encoded[pos])^ord(DECODE_KEY[(pos+3
pe_decoded+=chr(ord(pe_encoded[pos+1])^ord(DECODE_KEY[(pos+2
pe_decoded+=chr(ord(pe_encoded[pos+2])^ord(DECODE_KEY[(pos+1
pe_decoded+=chr(ord(pe_encoded[pos+3])^ord(DECODE_KEY[po
except IndexError:
pass
#It saves the embedded malware after its decryption
f=open(OUTPUT_FILE,»wb»)
f.write(pe_decoded)
f.close()
————————————————– END CODE ———————————————–
Malware analysis
Next we analyze the resulting malware.
| DLL EMBEDDED | |
| Filename | decoded.vir |
| Size | 277KiB (282950 bytes) |
| Type | PE (Portable Executable) |
| Compiled | Thu Sep 21 08:21:08 2017 |
| Arch. | x86 |
| S.O. | WINDOWS |
| SHA256 | d6990b2d82680a03ab57cee21e52843872fa770ddf8cfec2e15cf6bef068a61b |
First, three hardcoded URL directions which belong to the mymyawady.com domain have been identified:
| URL | FUNCTIONALITY |
| https://cdn1.mymyawady.com/x4/dll/logo.jpg | Malicious CAB file |
| https://cdn2.mymyawady.com/x4/dll/readme.txt | Malicious CAB file |
| https://cdn3.mymyawady.com/x4/dll/info.php | Gate of the C&C |
Then, a whois query has been made over the attacking domain, identifying that it is of russian origin and It was created during the month before the compilation of the document embedded library file.
In addition, a DNS historical domain has been obtained, detecting that the day after the creation of the same it pointed to an US IP address (45.77.46.81) from a provider of various cloud services (hxxps://www.vultr.com/) that the attackers used to host the malicious load of this malware.
It has been observed that the malware tries to download the two malicious CAB files hosted in the command and control server (C&C) under the names: logo.jpg and readme.txt using the following function:
Which keeps in temporary paths:
And decompress in the same directory using the system tool “expand.exe” by using the parameters that are observed in the image:
By last, the execution of an avgdate.exe file which the malware expects, it was created as result of the CAB decompression has been identified.
Further, the library is kept in a loop that runs in a 23 seconds frequency until it manages to download one of these two CAB malwares:
In each iteration, the malicious code collects the following system information.
It access the Windows registry to obtain the user’s SID.
Which subsequently builds on the format string: “aSidUserSCompu”:
For example, in the following image you can see an instance of the malware that has filled this string with the information of one of our laboratory machines by including whether or not it has been able to download and run C&C hosted malware samples. All of this formatted information will be sent to the “gate” by sending a “POST” request over the “news” parameter which the user’s SID is passed.
On the next screen you can see the “gate” URL address previously mentioned:
Conclusions
Our team have noticed a slight increase in the number of malicious office documents that do not use macros. That is why, it is important to keep the software always up to date.
It is recommended to consult only those documents and links that are trusted and, in case of doubt, contact the sender by using a secure communication media.
IOCs
- cb3429e608144909ef25df2605c24ec253b10b6e99cbb6657afa6b92e9f32fb5
- 9209946f3012a37509cb703f55c58b552361f76507acc4786f7b73f6c5092eae
- c6de846128c9ee10e7894af47c2855e1dc3c7c19f1db0c960f882ab60f522a2e
- cd4679c14349744b0e2bfa4d385afe49c9cb8540196f893f52c8f50c47cddbec
- hxxps://cdn1.mymyawady.com/x4/dll/logo.jpg
- hxxps://cdn2.mymyawady.com/x4/dll/readme.txt
- hxxps://cdn3.mymyawady.com/x4/dll/info.php
Author: David Alvarez-Perez, researcher at Gradiant’ Security and Privacy team
