# Windows 0-day exploit CVE-2019-1458 used in Operation WizardOpium **[securelist.com/windows-0-day-exploit-cve-2019-1458-used-in-operation-wizardopium/95432](https://securelist.com/windows-0-day-exploit-cve-2019-1458-used-in-operation-wizardopium/95432)** [Research](https://securelist.com/category/research/) [Research](https://securelist.com/category/research/) 10 Dec 2019 minute read ----- Authors AMR GReAT [In November 2019, Kaspersky technologies successfully detected a Google Chrome 0-day](https://securelist.com/chrome-0-day-exploit-cve-2019-13720-used-in-operation-wizardopium/94866/) exploit that was used in Operation WizardOpium attacks. During our investigation, we discovered that yet another 0-day exploit was used in those attacks. The exploit for Google Chrome embeds a 0-day EoP exploit (CVE-2019-1458) that is used to gain higher privileges on the infected machine as well as escaping the Chrome process sandbox. The EoP exploit consists of two stages: a tiny PE loader and the actual exploit. After achieving a read/write primitive in the renderer process of the browser through vulnerable JS code, the PE exploit corrupts some pointers in memory to redirect code execution to the PE loader. This is done to bypass sandbox restrictions because the PE exploit cannot simply start a new process using native WinAPI functions. ----- The PE loader locates an embedded DLL file with the actual exploit and repeats the same process as the native Windows PE loader – parsing PE headers, handling imports/exports, etc. After that, a code execution is redirected to the entry point of the DLL – the DllEntryPoint function. The PE code then creates a new thread, which is an entry point for the exploit itself, and the main thread simply waits until it stops. _EoP exploit used in the attack_ The PE file encapsulating this EoP exploit has the following header: The compilation timestamp of Wed Jul 10 00:50:48 2019 is different from the other binaries, indicating it has been in use for some time. Our detailed analysis of the EoP exploit revealed that the vulnerability it used belongs to the win32k.sys driver and that the EoP exploit was the 0-day exploit because it works on the latest (patched) versions of Windows 7 and even on a few builds of Windows 10 (new ----- Windows 10 builds are not affected because they implement measures that prevent the normal usage of the exploitable code). The vulnerability itself is related to windows switching functionality (for example, the one triggered using the Alt-Tab key combination). That’s why the exploit’s code uses a few WinAPI calls (GetKeyState/SetKeyState) to emulate a key press operation. At the beginning, the exploit tries to find the operating system version using ntdll.dll’s RtlGetVersion call that’s used to find a dozen offsets needed to set up fake kernel GDI objects in the memory. At the same time, it tries to leak a few kernel pointers using wellknown techniques to leak kernel memory addresses (gSharedInfo, PEB’s GdiSharedHandleTable). After that, it tries to create a special memory layout with holes in the heap using many calls to CreateAcceleratorTable/DestroyAcceleratorTable. Then a bunch of calls to CreateBitmap are performed, the addresses to which are leaked using a handle table array. ----- _Triggering exploitable code path_ After that, a few pop-up windows are created and an undocumented syscall NtUserMessageCall is called using their window handles. In addition, it creates a special window with the class of a task switch window (#32771) and it’s important to trigger an exploitable code path in the driver. At this step the exploit tries to emulate the Alt key and then using a call to SetBitmapBits it crafts a GDI object which contains a controllable pointer value that is used later in the kernel driver’s code (win32k!DrawSwitchWndHilite) after the exploit issues a second undocumented call to the syscall (NtUserMessageCall). That’s how it gets an arbitrary kernel read/write primitive. _Achieving primitives needed to get arbitrary R/W_ This primitive is then used to perform privilege escalation on the target system. It’s done by overwriting a token in the EPROCESS structure of the current process using the token value for an existing system driver process. ----- _Overwriting EPROCESS token structure_ Kaspersky products detect this exploit with the verdict PDM:Exploit.Win32.Generic. These kinds of threats can also be detected with our Sandbox technology. This detection [component is a part of our KATA and Kaspersky Sandbox products. In this particular attack](https://media.kaspersky.com/en/business-security/enterprise/Kaspersky-Sandbox-product-brief-en.pdf) sandbox solution can analyze URL/malicious payload in isolated environment and detect the EPROCESS token manipulation. [Microsoft Windows](https://securelist.com/tag/microsoft-windows/) [Vulnerabilities and exploits](https://securelist.com/tag/vulnerabilities-and-exploits/) [Zero-day vulnerabilities](https://securelist.com/tag/zero-day-vulnerabilities/) Authors AMR ----- GReAT Windows 0-day exploit CVE-2019-1458 used in Operation WizardOpium Your email address will not be published. Required fields are marked * GReAT webinars 13 May 2021, 1:00pm ## GReAT Ideas. Balalaika Edition 26 Feb 2021, 12:00pm 17 Jun 2020, 1:00pm 26 Aug 2020, 2:00pm 22 Jul 2020, 2:00pm From the same authors ## IT threat evolution in Q1 2022. Non-mobile statistics ----- ## The Verizon 2022 DBIR Evaluation of cyber activities and the threat landscape in Ukraine ----- ## New ransomware trends in 2022 APT trends report Q1 2022 Subscribe to our weekly e-mails The hottest research right in your inbox ----- -----