Angler EK exploit suite specializes in EMET security bypass / ESET NOD32 Blog

esetnod32 June 6, 2016 at 15:26

Angler EK exploit suite specializes in EMET security bypass

FireEye specialists reported the discovery of a new modification of the Angler Exploit Kit, which uses special techniques to bypass EMET. We are talking about several exploits for Adobe Flash and MS Silverlight, which use non-standard methods of bypassing the EMET security mechanisms used to block malicious exploit actions in memory. Exploits bypass DEP, EAF, and EAF + settings in the latest version of EMET 5.5.

We have written many times about EMET [ 1 , 2 , 3 , 4 , 5 , 6 , 7]. This tool is positioned by Microsoft as a free and effective tool for protection against RCE exploits, that is, those exploits that are used by attackers to remotely execute code. The latest version of EMET also contains a feature to counter LPE exploits that exploit vulnerabilities in the win32k.sys driver to elevate their privileges to SYSTEM.

EMET enforces DEP for processes, blocking exploit attempts to use RW memory pages to execute program code. Exploits use ROP methods to bypass DEP, while they rely on special code gadgets and pass control to them using the call stack. To bypass DEP, you must at least get to calling the VirtualProtect API function, with which you can remove the NX bit from the desired memory page.

One feature of one of the exploits FireEye has discovered is that it does not use ROP to bypass DEP. Instead, the built-in functions in the Flash.ocx and Coreclr.dll (Silverlight) libraries are used, using which VirtualProtect and VirtualAlloc are called with the constant PAGE_EXECUTE_READWRITE. The following illustration shows a Silverlight exploit that uses the coreclr.dll library code to bypass DEP.

Fig. Call VirtualAlloc in the coreclr.dll library, which helps bypass DEP without ROP ( FireEye data ).

In turn, the Flash exploit uses the functions of the flash.ocx module to invoke VirtualProtectto bypass DEP before executing shellcode.

Fig. Code calling VirtualProtect in flash.ocx ( FireEye data ).

Since such code manipulations are carried out in the built-in ActionScript and Silverlight functions, EMET is not able to effectively use its checks of return addresses of called functions on the stack, which is used to detect ROP (EMET Caller Check, SimExecFlow, StackPivot settings).

Another tweak that the exploit bypasses is called EAF, as well as its extended modification of EAF +. The EAF (Export Address Table Filtering) setting is used by EMET to block unauthorized access to memory pages that contain the kernel32.dll and ntdll.dll system library export table. EMET distinguishes between code that attempts to access such pages and, if it detects an unidentified source, displays a warning. EAF + extends EAF by adding to the blacklist the dynamic libraries that are most commonly used for maintenance. By default, EAF + includes a blacklist from the libraries mshtml.dll, flash * .ocx, jscript * .dll, vbscript.dll, vgx.dll.

The Silverlight exploit JIT code takes advantage of a framework library called coreclr.dll. Since this library is not included in the EAF + blacklist, access to the system library export tables through it is not a violation of the EMET security policy.

Fig. Calling shellcode via Silverlight coreclr.dll ( FireEye data ).

Fig. When called from corelight silverclr.dll, the shellcode gets access to the user32.dll import table to further obtain the GetProcAddress API address , through which it then obtains the addresses of other functions bypassing EAF. Since the shell code uses a legitimate call to GetProcAddress , EMET perceives code access in the EAT of the module as legitimate ( FireEye data ).

Fig. List of API functions received by the exploit ( FireEye data ).

The operation and bypass of EAF in the case of the Flash exploit is as follows.

At the first stage, ActionScript code finds in memory the address of the beginning of the flash.ocx module. After that, he searches for the address of the import directory flash.ocx (Import Directory Table) and finds the import directory element for kernel32.dll. Next, the exploit reads the contents of the RvaImportLookupTable and RvaImportAddressTable buffers to obtain the addresses of the required API functions and writes these addresses to a separate buffer for use by the shell code. After preparatory actions, the ActionScript exploit code calls VirtualProtect from flash.ocx (see above).

Next, control is transferred to the shell code of the first level, which calls VirtualAlloc and copies the shell code of the second level to the selected buffer.

Fig. Call VirtualAlloc to copy the second part of the shell code ( FireEye data ).

As you can see in the figure below, the second-level shellcode is again trying to get the GetProcAddress API via the IAT import table, thus bypassing the EAF checks. After receiving the GetProcAddress address , this function is used to obtain other API addresses, which also allows you to bypass EAF, legitimizing this process.

Fig. The shellcode reads IAT flash.ocx.

After completing all the operations, the exploit launches the TeslaCrypt ransomware dropper. It also provides an option for its execution without launching the executable file of the malicious program for execution. then modifies the first five bytes of the kernel32! ExitProcess function with an inline hook to the ntdll! RtlExitUserThread function . This helps the exploit make sure that the Internet Explorer browser process will not be completed after closing its tabs. Below in the screenshot you can see a demonstration of the successful exploit that TeslaCrypt launches when EMET 5.5 is enabled on the system.