Bypass Export address table Address Filter (EAF)

[Dwarner]

In the early hours of September this year Microsoft came out with their Enhanced Mitigation Experience Toolkit v2.0 (EMET), that contains a fresh “pseudo”-mitigation named as an Export address table Address Filter (EAF). I decisive to cover that how this mitigation tried to avoid exploits from ensuing and how an attacker’s capacity to bypass it. For folks who bear from tl;dr syndrome. It is my conclusion that EAF should be made-up to be helpful at preventing mainly present shellcode from executing and as a result a helpful mitigation. Though, it is comparatively easy to bypass. Look forward to that if EAF becomes a ordinary mitigation, attackers will modernize their shellcodes to bypass it. I cannot imagine of several efficient way in which EAF can be updated that would not be relatively simple to bypass as well.

[Vandam]

EAF works by locating a hardware breakpoint on the export address tables of the ntdll.dll and kernel32.dll modules in a process. When the breakpoint is executed, EAF determines if the code that is trying to contact an export address table is legitimate code for that practice or malevolent code inserted into the process through an exploit. Mainly exploits will at several point insert and run shellcode into the target process.

[Steyn]

One of the primary thing that majority shellcodes do is decide where certain functions are overloaded in memory. This is frequently and simplest done by going from the end to end list of the previously loaded modules and reading their export address tables. When shellcode reads the export address tables of ntdll.dll and/or kernel32.dll, EAF recognizes the shellcode and ends the process, securing the exploit from running successfully.

[Jacques25]

According to me, EAF protection is not the latest one– well possibly excluding the latest implementation that utilizes the debug breakpoint. Nevertheless the techniques are analogous. They described for installing an EAF mitigation, EMET desires to generate a fresh thread in the process first, which means the mitigation is disabled initially. Possibly they had troubles with modifying the context of previously running thread? Foremost to all, I haven’t experienced EMET up till now but i think for to securing all the latest and previously running threads they had to clasp does not continue and re-set the memory breakpoints there.

[Shreevats]

I am not so comfy with windows security however I was shocked as there are just four hardware breakpoints so what will happen with the shellcode before trying to use an EAT managed in order to reset/change the breakpoints addresses? If the GD ia not set on the DR7 then anyone would be able to access the hardware debug registers. Now you can change then for accessing an EAT without debug handler of EAF noticing anything about the same.