Zero-day exploit (CVE-2018-8453) used in targeted attacks
13.1.18 Kaspersky Exploit  Vulnerebility

Yesterday, Microsoft published their security bulletin, which patches CVE-2018-8453, among others. It is a vulnerability in win32k.sys discovered by Kaspersky Lab in August. We reported this vulnerability to Microsoft on August 17, 2018. Microsoft confirmed the vulnerability and designated it CVE-2018-8453.

In August 2018 our Automatic Exploit Prevention (AEP) systems detected an attempt to exploit a vulnerability in Microsoft Windows operating system. Further analysis into this case led us to uncover a zero-day vulnerability in win32k.sys. The exploit was executed by the first stage of a malware installer to get necessary privileges for persistence on the victim’s system. The code of the exploit is of high quality and written with the aim of reliably exploiting as many different MS Windows builds as possible, including MS Windows 10 RS4.

So far, we detected a very limited number of attacks using this vulnerability. The victims are located in the Middle East.

Kaspersky Lab products detected this exploit proactively through the following technologies:

Behavioral detection engine and Automatic Exploit Prevention for endpoints
Advanced Sandboxing and Anti Malware engine for Kaspersky Anti Targeted Attack Platform (KATA)
Kaspersky Lab Verdicts for the artifacts in this campaign are:

HEUR:Exploit.Win32.Generic
HEUR:Trojan.Win32.Generic
PDM:Exploit.Win32.Generic
More information about this attack is available to customers of Kaspersky Intelligence Reports. Contact: intelreports@kaspersky.com

Technical details
CVE-2018-8453 is a Use-After-Free inside win32kfull!xxxDestroyWindow that resembles an older vulnerability — CVE-2017-0263. CVE-2017-0263 was originally deployed by the Sofacy APT, together with a PostScript exploit, back in 2017.

For technical analysis of the vulnerability, we completely reverse-engineered the ITW exploit sample obtained and rewrote it into a full Proof of Concept.

The exploitation of this vulnerability depends on a sequence of events that are performed from hooks set on three usermode callback functions – fnDWORD, fnNCDESTROY, and fnINLPCREATESTRUCT. The exploit installs these hooks by replacing the function pointers in the KernelCallbackTable:

Hooked functions in the Kernel Callback Table

Inside the fnINLPCREATESTRUCT hook, the exploit initializes a “SysShadow” window by explicitly assigning a position to it:

Usermode hook on fnINLPCREATESTRUCT initializes SysShadow

When processing the WM_LBUTTONDOWN message, the fnDWORD hook executes the DestroyWindow function on the parent, which results in the window being marked as free and subsequently freed by the garbage collector.

The issue lies inside the fnNCDESTROY hook that is performed during execution of the DestroyWindow function. This hook executes the NtUserSetWindowFNID syscall, which contains a flawed logic to change the fnid status of the window without properly checking if it is set to FNID_FREED.

Vulnerable code inside NtUserSetWindowFNID

The fnid status of the window is located at offset 0x02a in the tagWND structure:

kd> dt win32k!tagWND
…
+0x02a fnid : Uint2B

When the scrollbar is initially created, it has the value FNID_SCROLLBAR (0x029A).

The next diagram shows the value of fnid prior and after execution of the NtUserSetWindowFNID syscall:

Scrollbar fnid prior and after execution of NtUserSetWindowFNID syscall

We can check what the new fnid value is by verifying it against the ReactOS source code:

/* FNIDs for NtUserSetWindowFNID, NtUserMessageCall */
#define FNID_SCROLLBAR 0x029A
…
#define FNID_BUTTON 0x02A1
…
#define FNID_FREED 0x8000 /* Window being Freed… */

This action results in the first scrollbar being destroyed, while the system still maintains a reference to a “SysShadow” class, as the scrollbar fnid is no longer marked as FNID_FREED, but as FNID_BUTTON instead.

To successfully reclaim the freed memory pool, the exploit contains a number of different feng shui tactics. The spray procedure is dependent on the exploited Windows version, and because the exploit targets a wide range of operating systems, it includes five separate functions for spraying:

Heap spraying procedures supported in the exploit

For the latest supported version (Windows 10 RS4), the spray tactic is quite complicated. The kernel is sprayed with bitmap objects of different size. This is required to exhaust the memory allocator to eventually bypass the Low Fragmentation Heap security mitigations that were significantly improved in the latest Windows builds:

Heap Feng Shui technique for Windows RS4 17134

This leads to the following memory layout, where USERTAG_SCROLLTRACK is the freed pool allocation:

Freed scrollbar heap allocation

When another scrollbar is allocated, the SysShadow class memory reference is reused, but its contents are attacker-controlled, because the freed Usst (ffffee30044b2a10) and Gpbm (ffffee30044b2a90) pools were merged into a single block:

Freed allocation is merged with the following pool

This results in a powerful arbitrary kernel Read\Write using GDI Bitmap primitives that works even on the latest Windows versions.

Following successful exploitation, a slightly modified Token-stealing payload is used to swap the current process Token value with the one from the SYSTEM EPROCESS structure:

Modified Token-stealing payload process

So far, we’ve observed the usage of this exploit in a small number of targeted attacks, when the exploit is packaged in a malware installer. The installer requires system privileges to install its payload. The payload is a sophisticated implant, used by the attackers for persistent access to the victims’ machines. Some of its main characteristics include:

Encrypting the main payload using AES-256-CBC with the SHA-1 of the SMBIOS UUID (this makes it impossible to decrypt the payload on machines other than the victim, if the SMBIOS UUID is not known)
Using Microsoft BITS (Background Intelligent Transfer Service) for communicating with its C&C servers, an unusual technique
Storing the main payload in a randomly named file on disk; the loader contains a hash of the filename and attempts to find the payload by comparing the filename hash for all files in the Windows directory
More details on this malware and the APT behind it are available to customers of Kaspersky Intelligence Reporting. Contact: intelreports@kaspersky.com

Victims
The distribution of the attack seems to be highly targeted, affecting less than a dozen victims in the Middle East region, according to our telemetry.

Attribution
During our investigation, we discovered the attackers were using a PowerShell backdoor that has previously been seen exclusively used by the FruityArmor APT. There is also an overlap in the domains used for C2 between this new set of activity and previous FruityArmor campaigns. That makes us assess with medium confidence that FruityArmor is responsible for the attacks leveraging CVE-2018-8453.

Conclusion
Even when deploying 0-days seems to be more frequent than it used to be, this would be the second time we have spotted FruityArmor using one of them to distribute its malware. This points to the resources and sophistication of this actor, along with the advanced final-stager they distribute.

So far, this campaign has been extremely targeted, affecting a very low number of victims in the Middle East region, probably persons of interest for the attackers. However, the victimology is not clear, especially with such a small number of victims involved.

We believe that although FruityArmor´s activity has been slowly increasing during the last two years, the extremely targeted nature of the attacks helps them fly below the radar.

Appendix I – Indicators of compromise:
Domains:
weekendstrips[.]net
shelves-design[.]com