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.
implemented by Angler EK is provided
into a webpage, we found that objects were being created for Flash
(Figure 3) and Silverlight (Figure 4) to exploit vulnerabilities in
Figure 3: Flash Object usage in deobfuscated content
Figure 4: Silverlight Object usage in
While exploiting Flash and other third party frameworks is common
practice, we identified that Angler EK has implemented exploits that
are successfully evading EMET.
EMET consists of many exploit mitigations that thwart modern exploit
kit attempts. These exploit mitigations include:
- Caller Check
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.
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
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
- 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
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.
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
Silverlight may also reduce the browser attack surface.
This is a Security Bloggers Network syndicated blog post authored by Nick Harbour. Read the original post at: Threat Research Blog