BitDam Blog

Roy Rashti
Roy Rashti
3 minutes & 54 seconds read · July 1, 2018

The Hawk in the NET (CVE 2017-11882) – Part 1

A few days ago, BitDam’s engine detected a malicious file named “PO.docx” (sha1 – ee77856ae686ad6e638f4ec05d3b70dd31e9adc4).

At the time of detection, the file was not publicly published nor existed on VirusTotal.

Although a week has passed, we still don’t see the payload published. It seems that whoever wrote this attack was very careful not to over-spread it and did their best to protect their assets.

We think that this might be the new variant of HawkEye trojan. Among their mutual characteristics we see the persistence mechanism, .NET payload, penetration through documents, creating and injecting to VBC.exe, and more.


Attack Highlights

  • The attack vector is very complex and sophisticated. Seems as if a lot of thought and work was put into it
  • Attack starts with a .docx file exploiting CVE 2017-8570.
  • The server sends the next chain of the attack only to certain IP addresses
  • RTF file is fetched. The RTF file exploits CVE 2017-11882 which uses a non-standard and very sophisticated way to avoid detections.
  • Equation Editor is launched. A buffer overflow leads to fetch and execute a .NET executable.
  • The executable dynamically drops and compiles an executable on the victim machine
  • The executable dynamically decrypts a resource (PNG file) into an assembly and loads it
  • That assembly dynamically decrypts a resource into an assembly, loads an exported type out of it and invokes it.
  • The new assembly’s code is used to set the persistency mechanism using scheduled tasks, creates ‘vbc.exe’ process and injects code into it to communicate with what seems to be the CNC server.
  • The payload shows many mutual characteristics with HawkEye Trojan

Attack Overview Diagram


Detailed Analysis

The file is very unique and differs from the majority of attacks we’re used to see in that vector. Docx file contains “rels” file, which is an xml that defines relationships within the document. The attackers used a logical exploit, in which they had a relationship file containing the record seen in figure 1.

Figure 1

An embedded OLE object where the source is an external document (that would be fetched from http://abatii.web[.]id/isupa/PO.doc).

When I tried to fetch that document, the server returned “ERROR 502”. That caught my mind since I didn’t expect the server to be down as the dropper is being sent. Since the attack was aimed to harm a Europe-based company, I thought that the attackers wish to limit access to the infector and filter it by the IP address.

I tried to get “PO.doc” from the very same server from a different IP address, and gladly – it served the document.

The received document is an rtf file (SHA1-2f45ba716f96e0cdb4162ba874b1a39d52321e87).

Looking at the RTF file, we can see that the attackers tried to evade static checks made by many security vendors. We concluded (looking at the CLSID of the embedded OLE) that the target is EQNEDT32.exe (Equation Editor).

A well known OLE embedding that targets EQNEDT32.exe (as shown in Figure2).

Figure 2

The RTF’s OLE data (Figure3)

Figure 3

Linking the CLSID to the registry mapping, reinsures our hypothesis that it is indeed Equation Editor (shown in Figure 4).

Figure 4

The vulnerability that is being exploited in this case is CVE-2017-11882, which is a stack overflow vulnerability caused by an unchecked memcpy.

Moreover, the EQNEDT32.exe binary was compiled long before Windows XP SP2 (March 2003 according to the metadata). Windows XP SP2 was released in August 25, 2004 – that’s where DEP was first introduced to Windows.

Figure5 shows that the binary have no DEP and of course no ASLR (that was added after the Vista release)


Figure 5

That, of course, makes the vulnerability much easier to exploit.

The attackers ran their payload from the stack by returning to the payload’s location (as shown in Figure 6)

Figure 6

Briefly, the shellcode decrypts 0x36D bytes of itself and jumps to the decrypted part (see Figure 7)

Figure 7

(It decrypts itself in 0x36D / 4 iterations and jumps to the decrypted part when finished).

As the decrypted code is evaluated, the shellcode finds kernel32.dll, gets LoadLibrary and GetProcAddress addresses, and using these abilities it can now:

  • Load urlmon.dll
  • Get the base address of shell32.dll
  • Load all the following functions:
    • kernel32! ExitProcessImplementation
    • kernel32! ExpandEnvironmentStringsW
    • urlmon! URLDownloadToFileW
    • shell32! ShellExecuteW
  • Expands the string “%TMP%\mahshhdkkdlidjujddj.exe” (Figure8)

    Figure 8

  • Download a file from hxxp://abatii[.]web[.]id/isupa/PO.exe to the temp directory (Figure9)

    Figure 9

  • Use ShellExecuteW to execute the downloaded executable
  • Exit EQNEDT32.exe using ExitProcess

Further overview and drilldown to the payload will be published soon. See cont’ here.

Leon Berlin & Roy Rashti


Schedule a Demo

Enter your email to get a free trial invitation