Monday, 30 October 2017

Targeted Attack on South Korea exploits CVE-2017-8291

Recently I discovered an HWP document in the wild which was weaponised to exploit the Vulnerability (CVE-2017-8291) in GhostScript Processor used in Hancom Office Word Processor Application. This document used the theme of Korean Day (celebrated on Oct 5th 2017) and the attack was targeted towards South Korean users.

Hancom Office is a Popular Word Processing application used in Korea and the Documents specific to this application have the file extension: "hwp".

MD5 hash: 3d0d71fdedfd8945d78b64cdf0fb11ed
Original Filename: 세계한인의 날 알아보기.hwp

It translates to: Korean Day

The contents of the Document are shown in Figures 1, 2 and 3. As can be seen, the content was clearly targeted towards South Korean users.

Figure 1

Figure 2

Figure 3

Extraction of Malicious PostScript

This HWP file has a compressed PostScript embedded inside it. As shown in Figure 4, we can see the Embedded PostScript.

Figure 4
Encrypted PostScript embedded inside PostScript

After extracting and decompressing the PostScript, we can see that it contains another layer of XOR encrypted PostScript as shown in Figure 5.

Figure 5
The XOR decryption loop is written in PostScript language and it uses a 4 byte XOR decryption key: 0xA3E6E7BB

After decrypting the above PostScript, we get another layer of PostScript as shown in Figure 6.

 Figure 6
PostScript used to Trigger Vulnerability

This PostScript contains the shellcode along with the malicious PostScript which is used to trigger the vulnerability in GhostScript.

The particular section of code which triggers the vulnerability as shown in Figure 7.

 Figure 7
There is a vulnerability in the way .eqproc instruction in GhostScript processes the parameters.

Shellcode Analysis

Let's take a look at the shellcode now. The shellcode entrypoint looks like shown in Figure 8.

Figure 8
It scans the contents of the shellcode for a marker, 0xAABBCCDD. This marker is followed by a 0x4 byte XOR key which is used later for decrypting the encrypted DLL embedded inside the PostScript.

In order to perform the decryption, the Shellcode scans all the Open File Handles corresponding to the Current Process.

The API sequence looks as shown below:

ZwQuerySystemInformation(0x10, <heap_address>, 0x10000, 0x0)
ZwQuerySystemInformation(0x10, <heap_address>, 0x20000, 0x0)
ZwQueryObject(object_handle, 0x2, <heap_address>, 0x1000, 0x0)
ZwQueryObject(object_handle, 0x1, <heap_address>, 0x1000, <address>)

As shown in Figure 9, it gets the handle information using ZwDuplicateObject() and ZwQueryObject(). Then the filename corresponding to this Handle is checked and if it ends with ".ps", then it indicates we have obtained the handle to PostScript loaded in memory of Hancom Office Application.

Figure 9
The filename check for the Handle is shown in Figure 10.

Figure 10
Once the handle to PostScript is obtained, it maps the entire PostScript into memory using: CreateFileMappingA() and MapViewOfFile()

Now, it searches the PostScript for the marker, "exec". The encrypted DLL is present right after this marker in the PostScript as shown in Figure 11.

Figure 11
The shellcode decryption routine is shown in Figure 12.

Figure 12
It uses a 0x4 byte XOR key (0xA3E6E7BB) which is present right after the marker, 0xAABBCCDD in the shellcode.

After decrypting the encrypted DLL, it will be injected into explorer.exe process. As a result of it, we can see that the DLL is never dropped on the disk and so it's a fileless malware.

MD5 hash of the decrypted DLL: d897b4b8e729a408f64911524e8647db

Below are the details of the Network Callbacks performed by the DLL: and port 5443 and port 443

I'll add more details of the payload in a follow up blog.

No comments:

Post a Comment