HIPS and Exploit Blocker Protection For Abode Reader

[itman 1,659]

I created a HIPS rule to protect it from modification. Using Process Explorer checked to see if any Eset .dlls injected indicating that it is indeed protected. Zip, Nada, nothing present. Eset .dlls have been injected into everything else where I created a HIPS rule for them. Ieplorer, explorer, etc. have Eset .dlls injected. Emsisoft Anti-malware and EMET have their .dlls injected into Adobe Reader.

 

Just how is Eset protecting Abode Reader?

Edited June 13, 2015 by itman

[itman 1,659]

I created a HIPS rule to protect it from modification. Using Process Explorer checked to see if any Eset .dlls injected indicating that it is indeed protected. Zip, Nada, nothing present. Eset .dlls have been injected into everything else where I created a HIPS rule for them. Ieplorer, explorer, etc. have Eset .dlls injected. Emsisoft Anti-malware and EMET have their .dlls injected into Adobe Reader.

 

Just how is Eset protecting Abode Reader?

Update.

 

I have been doing some intensive testing since I last posted. The good news is the HIPS works great. Feature wise it is something out of the stone age but it is very responsive and accurate as far as created rules.

 

As far as the exploit protection, the only thing I saw where Eset .dll injection is occurring is upon the start up of a new explorer.exe instance. It was not like this at Eset installation; I saw Eset .dlls being injected into IE10 up until recently. I also did reset the HIPS to it's default setting; no help. The best I can determine is the recent IE 10 and Adobe reader updates have broke it.  

[itman 1,659]

Update 2.

 

Just completed testing SS 8 exploit protection using Surfright's Exploit Test Tool. SS 8's protection about equal to that provided by EMET 5.2 as far as IE10 browser protection goes. This confirmed by recent AV lab tests showing both in the 80% range as far as exploit detection goes. Both failed heapspray tests miserably. So it appears SS 8 memory protection more akin to vaporware. So, .dll injection not utilized or needed by SS 8 exploit protection. 

 

Only thing I did not like about SS 8 exploit protection is zip alerts or logging occurred when it stopped an exploit. At least some recording of the activity should be given to the user.

[itman 1,659]

Looks like I was initially right all along. Eset does indeed not inject its hook .dll, eplgHooks.dll, into Adobe Reader.

 

Appears I might have been preventing the loading of eplgHooks.dll into IE10 and explorer.exe; most likely by one of the HIPS rules I have created. In any case, the Eset hook injection is now working properly; at least for everything except Adobe Reader.

 

Strongly suspect that Eset hasn't been able to find away around Reader's sandboxing option. This doesn't appear to be a problem for EMET or Emsisoft though; both inject their hook .dlls without issue.