Analysis and Exploitation of an ESET Vulnerability

Perhaps all of these "off topic" posts should be placed inside a separate thread.

Yes, and when you use these advanced exploits on a large scale, it will attract too much attention.

 

Grrrrrrrrrr. I finally found a way to test the Eset exploit and memory protection in the Eset network filter using the SurfRight exploit test tool.

The issue is the exploit test tool executes so fast, the browser never has a chance to fully establish a network connection. This procedure works for IE; I assume it work for other browsers.

1. Exclude any other security software you have running with exploit/behavior blocking capability.
2. Open IE and minimize it.
2. Start the exploit test tool and select IE as your browser.
3. Run the exploit individual tests.

What this does is force the iexplorer.exe instance the exploit test tool launches to be placed under the existing IE stub that is currently executing thereby ensuring instant network connectivity.

Results

Eset's exploit/memory network based protection blocks the test exploit payload in every instance.

The instance of IE launched by the exploit test tool remains running but fully displayed on the desktop. Again w/o doing before/after browser memory snap shots, it can not be determined if any memory injection actually occurred.

No alerts or log entries generated from Eset.

-EDIT- I suspect the above behavior by the Surfright exploit test tool is by design to make other security software using network based protection appear not to be protecting against exploits.

Additionally, there is no correlation between eplghooks.dll injection and Eset's network based exploit protection. What the hook is used for is still somewhat of a mystery. It might be used for nothing more than to support the Eset toolbar icon inserted in to the browser for a supported Eset e-mail client; Outlook, MSMail, etc.. The string data present in the .dll allude to this.-END EDIT-

I also finally was able to nail down the subtle change Emsisoft made to the behavior blocker in ver. 10. And frankly, I don't like it. All the BB monitoring is now being conditioned by whether a process has a valid cert. and if the cloud OKs it with a "good" rep.. I actually renamed the exploit test tool to xyzmalware.exe and tuned off cloud rep. scanning in EAM settings. The bugger somehow still ended up with a "good" BB rep. setting; probably because it still had a valid cert. associated with it.

Next I created a custom monitoring rule in EAM BB for the renamed exploit test tool. Bingo! The minute the test tool started up, EAM caught it and displayed an alert.

Bottom line - exploit malware with a valid signature will only be partially caught by EAMs BB. And the mitigation will be dangerous in itself since as I showed in my prior testing, the target of the exploit is still running undetected as a zombie.

-EDIT-

Case in point about trusting signed code:

Evading blocking technologies
Blocking technologies include AntiVirus and EndPoint software, IDS/IPS, Proxy/Web Filtering, Firewalls with deep packet inspection etc. Regarding AntiVirus evasion techniques we will make a dedicated blog post soon.

• Encapsulate any traffic between you and the target over Secure Sockets Layer (SSL) to avoid packet inspection. Prefer SSL certificates signed by a trusted certificate authority over self-signed ones. This applies to trojan communication, phishing websites and trojan delivery by any means.
• Use Code Signing Certificates for any piece of code that is delivered to the target (Java applets, trojans, macros in Word files etc.). Although Code Signing will not evade any detected signatures in the code or behavioral triggering, it will help significantly versus certain checks, especially score-based blocking rulesets.
• Do not use IP addresses or dynamic dns names for any type of reverse connection. Register a domain name instead and use hostname calls.
• To evade egress filtering, use HTTP(S) reverse payloads and make the trojan proxy aware using WinINet API.

ref.: http://www.hackinsight.org/news,243.html

 

I said I would post back when I received a resolution on the eplghooks.dll issue from Eset.

Well, Eset customer/tech support and I went back and forth for quite a while and the issue was never resolved; at least as far as I am concerned. Eset basically said as far as they were concerned, there was not a problem. This doesn't surprise me since my dealings with AV vendors when it comes to "iffy" issues is deny, deny, and deny again.

So I will give my take on this. Despite my best efforts, Eset would not disclose exactly what eplghooks.dll is used for other than that I have already posted. One thing I will agree with Eset on is this hook is set dynamically by ekrn.exe. Also in agreement is that normally you will not see eplghooks.dll injected into anything.

Eset unlike other behavior blocker and HIPS software does not need to hook pre-selected processes at boot or process start up to monitor their activities. Rather it appears Eset will start hooking processes after it detects some abnormal activity on your PC. Note I said abnormal and not malicious or suspected malware activities. For example, I have been running for some time now without seeing any eplghooks.dll injection activity. Yesterday I downloaded the latest ver. of Process Explorer from MS TechNet to replace the 4 year old ver. I had been using. This latest ver. does some very strange activities on a x64 OS. It spawns procexp64.exe as did the old ver., but not in the same directory as where the download resides. Rather, it is spawned into the AppData\Temp directory. That set off all kinds of HIPS alerts since I monitor the AppData directories for program start ups to catch crypto malware, etc.. This morning's cold boot showed that low and behold, here was eplghooks.dll injecting explorer.exe and related processes.

Bottom line. Appears Eset's advanced heuristics, etc. etc. must have some type of ranking behavior built into it. When a deviation from norm is detected, Eset will activate more detailed process monitoring via .dll hooking mechanism. This also explains why I was seeing hooking behavior after a clean install of Eset for a while which subsequently disappeared with continual use.

 

Sounds interesting. SpyShelter doesn't use API hooking at all, they do all the monitoring with the driver if I'm correct.