Angler EK exploit kit specializes in circumventing EMET security mechanisms

FireEye specialists reported finding 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 circumventing the EMET security mechanisms used to block malicious actions of exploits in memory. Exploits bypass the DEP, EAF and EAF + settings in the newest version of EMET 5.5.



We have already written many times about EMET [ 1 , 2 , 3 , 4 , 5 , 6 , 7 ]. This tool is positioned by Microsoft as a free and effective means to protect against RCE-exploits, that is, those exploits that are used by attackers for remote code execution. The newest version of EMET also contains a function to counter LPE-exploits, which exploit vulnerabilities in the win32k.sys driver to elevate their privileges to the SYSTEM level.
')
EMET enforces DEP for processes by blocking exploits from attempting to use RW memory pages to execute program code. The exploits use ROP methods to bypass the 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 the call to the VirtualProtect API function, which can be used to remove the NX bit from the necessary memory page.

A feature of one of the exploits discovered by FireEye is that it does not use ROP to bypass DEP. Instead, they use built-in functions in the Flash.ocx and Coreclr.dll libraries (Silverlight), which are used to call VirtualProtect and VirtualAlloc with the constant PAGE_EXECUTE_READWRITE. The figure below shows a Silverlight exploit that uses the coreclr.dll code to bypass DEP.


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

In turn, the Flash exploit uses the flash.ocx module functions to call VirtualProtect to bypass the DEP before executing the shellcode.


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

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

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

Silverlight's 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. Being called from Silverlight coreclr.dll, the shellcode accesses the user32.dll import table to further obtain the GetProcAddress API address, through which it then receives the addresses of the remaining functions, bypassing the EAF. Since the shellcode uses the legitimate GetProcAddress call, EMET perceives the code access in the EAT module as legitimate ( FireEye data ).


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

Operation and EAF bypass in the case of a Flash exploit looks like this.

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

Next, control is transferred to the first-level shellcode , which calls VirtualAlloc and copies the second-level shellcode to the selected buffer.


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

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


Fig. The shellcode reads IAT flash.ocx.

After completing the operation, the exploit launches the TeslaCrypt extortionist dropper. It also provides for a variant of 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 on the ntdll function ! RtlExitUserThread . This helps the exploit to make sure that the Internet Explorer web browser process is not complete after closing its tabs. Below in the screenshot you can see a demonstration of the successful operation of the exploit, which TeslaCrypt launches for execution when EMET 5.5 is enabled in the system.





See also.

EMET 5.5 released
habrahabr.ru/company/eset/blog/276311

EMET 5.5 went into beta
habrahabr.ru/company/eset/blog/268165

EMET, prevention of operation and non-obvious settings
habrahabr.ru/company/eset/blog/221129

EMET v4 Release
habrahabr.ru/company/eset/blog/184428

Microsoft has added another exploit protection feature in Windows 10
habrahabr.ru/company/eset/blog/281481