# In depth analysis of malware exploiting CVE-2017-11826

**gradiant.org/noticia/analysis-malware-cve-2017/**

15/12/2017

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](https://www.gradiant.org/technologies/seguridad-y-privacidad/)
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.](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11826)
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](https://en.wikipedia.org/wiki/Heap_spraying)
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](https://en.wikipedia.org/wiki/Return-oriented_programming)_
protections, for example: non-executable memory regions and code signing protections)
[since this library has disabled DEP y](https://en.wikipedia.org/wiki/Executable_space_protection#Windows) [ASLR protections.](https://en.wikipedia.org/wiki/Address_space_layout_randomization)

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)%4]))

pe_decoded+=chr(ord(pe_encoded[pos+1])^ord(DECODE_KEY[(pos+2)%4]))

pe_decoded+=chr(ord(pe_encoded[pos+2])^ord(DECODE_KEY[(pos+1)%4]))

pe_decoded+=chr(ord(pe_encoded[pos+3])^ord(DECODE_KEY[pos%4]))

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](https://cdn1.mymyawady.com/x4/dll/logo.jpg) Malicious CAB file

[https://cdn2.mymyawady.com/x4/dll/readme.txt](https://cdn2.mymyawady.com/x4/dll/readme.txt) Malicious CAB file

[https://cdn3.mymyawady.com/x4/dll/info.php](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](https://technet.microsoft.com/es-es/library/cc722332(v=ws.10).aspx)
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_


-----