from FireEye Blog
We recently encountered some exploits from Angler Exploit Kit (EK) that are completely evading Microsoft’s Enhanced Mitigation Experience Toolkit (EMET). This is something we are seeing for the first time in the wild, and we only observed it affecting systems running Windows 7.
Angler EK uses complex multi-layered code obfuscation and leverages multiple exploits, as seen in Figure 1 and Figure 2. These capabilities make Angler EK one of the more sophisticated exploit kits in use at this time.
Figure 1: An excerpt of obfuscated javascript implemented by Angler EK is provided
Figure 2: Angler JavaScript Obfuscation
Within the deobfuscated JavaScript, which an attacker might inject into a webpage, we found that objects were being created for Flash (Figure 3) and Silverlight (Figure 4) to exploit vulnerabilities in those plugins.
While exploiting Flash and other third party frameworks is common practice, we identified that Angler EK has implemented exploits that are successfully evading EMET.
Evasion:
EMET consists of many exploit mitigations that thwart modern exploit kit attempts. These exploit mitigations include:
- ASR
- EAF
- EAF+
- Caller Check
- SimExecFlow
- StackPivot
- MemProt
Modern exploit kits may contain VBScript, Flash, Silverlight and even Internet Explorer exploits. Out of these, VBScript exploits are mitigated by ASR check and there is no evasion for that as of now, since EMET simply restricts vbscript.dll from being loaded.
The ability of Angler EK to evade EMET mitigations and successfully exploit Flash and Silverlight is fairly sophisticated in our opinion. These exploits do not utilize the usual return oriented programming to evade DEP. Data Execution Prevention (DEP) is a mitigation developed to prevent the execution of code in certain parts of memory. The Angler EK uses exploits that do not utilize common return oriented programming (ROP) techniques to evade DEP. Instead, they use Flash.ocx and Coreclr.dll’s inbuilt routines to call VirtualProtect and VirtualAlloc, respectively, with PAGE_EXECUTE_READWRITE, thus evading DEP and evading return address validation-based heuristics.
DEP Evasion:
As seen in Figure 5, the Silverlight exploit uses coreclr.dll’s routines to evade DEP before shellcode is executed.
Figure 5: VirtualAlloc stub in coreclr.dll, helps mitigate DEP without ROP
The Flash exploit uses Flash.ocx’s routines to call VirtualProtect for DEP evasion before shellcode is executed, as seen in Figure 6. The same routine is then used to jump to shellcode.
Figure 6: flash.ocx
Since return address validation heuristics are evaded by utilizing these inbuilt functions from within ActionScript and Silverlight Engine, ROP checks by EMET’s DEP capability are not effective. EMET provides other protections, however, which Angler EK is also evading. Export Address Table Filtering (EAF) and EAF+ are two capabilities that seek to protect the contents of memory and prevent exploit code from identifying where things are loaded.
The following is the working chain of the payload after successfully evading DEP mitigations. Note that the APIs will differ for both fileless and process oriented infections. However the evasion code was found and executed in both the cases successfully evading EMET.
Evasion of EAF in Silverlight Exploit:
As we can see in Figure 7, Silverlight JIT code transfers control to shellcode.
Figure 7: Call Shellcode
After that, the shellcode queries User32 Import Address Table (IAT) to pull API addresses, thus evading EAF. We can see the same in Figure 8.
Figure 8: Shellcode reads IAT
The memory address of the GetProcAddress function also gets resolved by using IAT of user32.dll. After that, the APIs seen in Figure 9 get resolved from GetProcAddress.
Figure 9: List of APIs
Once the API addresses are resolved, EMET has no validation on API calls with regard to where they are coming from, thus resulting in the successful execution of the malicious program.
Note that Silverlight exploits are not subjected to EAF+ because “coreclr.dll” and other required dlls are not present in the default EMET configuration.
Evasion of EAF+ in Flash exploit:
- Flash uses arbitrary read and write to read memory and finds base address of “flash.ocx”.
- It finds Import Directory Table of flash.ocx and loops through ModuleName until it reaches “kernel32.dll”.
- Reads the content of RvaImportLookupTable and RvaImportAddressTable, to locate the APIs that will be useful later along with VirtualAlloc, which will be used in first stage.
After identifying the required addresses, ActionScript code fills those values in already existing buffer of shellcode, performs ROPless VirtualProtect on the shellcode region to evade the DEP, and then transfers the control to the malicious shellcode.
As we can see in Figure 10, the first stage shellcode will call VirtualAlloc and copy the second stage shellcode to that memory, transferring the control to that code.
Figure 10: Call VirtualAlloc and second stage shellcode
As seen in Figure 11, in the second stage shellcode, the API resolution is again based on the IAT reading, which evades EAF. Additionally, several calls to GetProcAddress are performed, which go completely unscrutinized. As stated before, API calls have no validation from EMET with regard to where they are coming from, validation is only performed through EAT hardware breakpoints.
Figure 11: Shellcode reads IAT
Afterwards, the exploit shellcode launches the TeslaCrypt process under normal exploitation context. In the case of fileless infections, the shellcode does not launch anything, but changes the protection constant of kernel32!ExitProcess to RWX for 5 bytes, then overwrites it with an inline jump to ntdll!RtlExitUserThread. This ensures the process stays alive even after closing the tab or closing the Internet Explorer window. In either of above cases, the attacker has full control over shellcode and it can pretty much execute anything it wants without EMET doing anything.
In Figure 12 and Figure 13, we can see the successful execution of TeslaCrypt ransomware with the latest version of EMET installed on the system. Please note that we have tested this only on Windows 7.
Figure 12: EMET v5.5
Figure 13: EMET bypass - Successful execution of TeslaCrypt binary
Conclusion
The level of sophistication in exploits kit has increased significantly throughout the years. Where obfuscation and new zero days were once the only additions in the development cycle, evasive code has now been observed being embedded into the framework and shellcode.
Remediation guidance:
Although there are no quick solutions for the DEP, EAF, and EAF+ evasion techniques, organizations can mitigate this threat through a robust vulnerability management program for end user systems, which includes the installation of security updates for third party software. Applications such as Adobe Flash, web browsers, and Oracle Java should be patched routinely, prioritizing critical patches, or removed if possible. Because the web browser plays an important role in the infection process, disabling browser plugins for Flash or Silv
