Eset NOD32 Antivirus and Eset Smart Security version 9

Created a new thread as recent one just refers to the beta and official version is now out. Mods delete this one if you do not agree.

Observations; running Antivirus together with HitManPro.Alert3 and feeling no performance hit at all. Although I have a license for ESS, I found the standalone AV a little lighter and I still cannot use ESS's Banking Protection with HMPA which was reported with the beta.

Compared to other AVs, the retail price for Eset here in the UK is IMHO, ridiculously high; £40/$61 for ESS and £30/$46 for NOD32 with an annual license. But I have returned to Eset after 9 years after finding a much cheaper educational license;http://www.antivirusonline.co.uk/eset/buy-online/1002

 

Eset ver. 9 - The Good, The Bad, and The Ugly

Installed it yesterday.

The Good

Installed over ver. 8 with no issues. However, uninstalled and installed fresh trying to correct issues noted below.

The online banking protection much to my surprise looks pretty solid. Your browser will open under ekrn.exe and appears to be pretty locked down with the limited testing I did. For example, Process Explorer is locked out from displaying any browser dll details and the like.

The Bad

Online banking would not function for my bank site at all when I had my browser set to disable all active content i.e. IE 11's Internet zone highest settings. Had to reduce settings to medium high level. I originally had my bank site listed in IE's Trusted zone with that level set at medium high level. Appears Eset's online banking ignored that setting entirely and just used the Internet zone settings.

SSL protocol scanning is buggy and doesn't work right. Sometimes the same HTTPS site will show the Eset root cert., other times it does not. Eset hasn't responded to my questions on this yet.

Hate the Metro GUI. Although functionally it works like ver. 8, settings are displayed differently and make updating firewall and HIPS rules more difficult.

The Ugly

If you had a bunch of custom rules created under ver. 8, you can just throw them all away under ver. 9. If you do an on top of ver. 8 install, all your existing allow and block rules will become a jumbled mess as shown by the below screen shot. In ver. 8, all allow rules preceded all block rules and executed top to bottom. Worse in ver. 9, new rules are added always below existing rules regardless of allow or block status. In others words, what Eset has done with this ver. is make the creating custom rules worthless for all practical purposes.

Overall what I observe is an untested product that removed one of it's strongest features; the ability to create effective custom HIPS rules.

 

I have been running ver. 9 HIPS in learning mode for two days. Thought I would do that and then switch to interactive mode after a while since I can no longer create meaningful custom rules with this version.

Guess what? In learning mode, the HIPS has started creating duplicate rules! And yes, I did verify that they were indeed duplicates. So eventually switching to interactive mode after the learning period is worthless since I will be getting constant alerts for processes that were already defined.

So it is obvious no one at Eset has ever tested all the features of the HIPS prior to this release.

 

A couple other observations.

Appears that the browser is locked down outside of banking mode also. I cannot access DLL info using Process Explorer. Interesting.

Very strange behavior for Eset's hook in this release. I didn't mention this in my above review but Eset's taskbar GUI, equi.exe, now runs under ekrn.exe versus explorer.exe in ver. 8. Well, the hook process now is being started from a spawned rundll32.exe process by equi.exe. Very strange indeed. Possibly a way to monitor tampering with the eplgHooks.dll in processes where it has been injected. Also dispels the crap Eset told me previously that the hook was set dynamically by ekrn.exe implying it was also dynamically monitoring it.

Looks like there is a mass exodus from ver. 9 back to ver. 8 based on the comments in the Eset Smart Security forum. I too will soon be joining that crowd since ver. 9 is so buggy, I can't trust its protection.

 

Are these rules related to direct disk access and other file rules? I got similar in v.8 when I had to create two rules for same target (I created rules in Interactive mode).

 

No. When I reinstalled ver. 9, everything was set at defaults. So HIPS was set to Auto with no rules present. I then switched to learning mode. One dup rule was for a Nvidia program; forgot what the other one was for.

And yes, learning mode will create multiple rules for the same program if different functions are used; one for start another process; one for modify another process; etc.. The dup. rules that were created on my build were identical in every way.

 

Using the concept that "a picture is worth a 1000 words", below is a screen shot of hook monitoring in action. Must say it is the craziest approach I have seen in a while. That is using rundll32.exe to run eplghooks.dll in a loop to do the monitoring. Also of note is that the monitoring hook is the 32 bit version versus the 64 bit dll version that is injected into select 64 bit processes.

Again, no rhyme or reason to when the hook is set as was the case in ver. 8. I have seen it set off at cold boot, then set on after to a system restart. I have also seen it set at least once so far at cold boot time. Only Eset knows the magic behind this one .................

 

We have had a few instances where v9 will not activate. One each now on Win7, 8.1 and 10.

 

Make sure the firewall is not blocking an inbound connection from port 443 IP address 137.135.12.16. Also the log will probably show it was for svchost - DHCP as crazy as that sounds. Just resolved this one over in the Eset forums and Marcos confirmed connection was from Eset for product activation checking.

-EDIT-
I assume you're aware of this. But this might be a license key issue? If these people don't have a key, they can get one by converting Eset user id and password to a key here: https://my.eset.com/convert

 

Good Evening! My Eset S.S. license expires next month...the question is how long will V8 be available...because my own impression with the new V9 was less than favourable...so I'll stick to version 8...but when will V9 become ready for Prime time? Sincerely...Securon

 

judging by the fact that Eset still have version 3 installers on their website I doubt version 8 is going anywhere fast.

 

Good Evening! Just re-installed S S V8...what an amazing improvement...going back to the future provides. Sincerely...Securon

 

So much for online banking keylogger protection.

It failed SpyShelter's AntiTest keylogger test. Interestingly, Eset would not allow SurfRight's test tool keylogger test to run. Advise others to run additional keylogger tests against Eset's online banking keylogger protection.

-Correction-

Downloaded latest ver. of AntiTest issued 10/1/2015. Eset passed its keylogger test. All input was scrambled. Eset did fail screen capture tests but I don't believe they claim protection against that.

 

Good Evening! To paraphrase an old Sixties Radio Jingo! And the Hits just keep on Coming! Sincerely...Securon

 

Don't you mean 'misses'
Seems many a ball has been dropped with this version 9, thanks all for the info

 

Below is an example of just how screwed up SSL protocol scanning is in ver. 9.

What I believe is happening is Eset attempted to create logic that would dynamically create a list of HTTPS web sites that are safe. Most likely using LiveGrid cloud processing for verification. SSL protocol scanning would then bypass those sites when it came scanning those sites.

One possibility for the erratic behavior I and others have observed is that the "dynamic" scanning is supposed to done once per browser session. The first time you enter a new HTTPS site, Eset uses its root cert. Any return to the same site during the same browser session, Eset uses the web site's actual root cert.

Whatever Eset is trying to do at this point is screwed up. To make matters worse, Eset characteristically is mum on what actual it is trying to accomplish with this revision in SSL protocol scanning.

Here is a screen shot that shows Eset's root cert. is used on this web page:

https://forum.eset.com/uploads/post-6784-0-57169800-1445952353.png

However in reality, it is not as shown in this screen shot of the actual certificate path to the root:

https://forum.eset.com/uploads/post-6784-0-71488000-1445952404.png

 

Just got done restoring back to ver. 8 from an image backup I took prior to installing ver. 9. So I won't be commenting anymore on all the glitches in this abomination of a release.

Must say I haven't seen a snafu in a security product release update like this in many moons. I suggested to Eset they just add online banking to ver. 8 and re-release it as ver. 9 after scaping the existing ver. 9 release. In any case if ver. 9 remains essentially as is, I won't be renewing my subscription since creating meaningful custom HIPS rules is impossible. I will either go with Comodo or Outpost Pro firewall. Those are about the only two left on the consumer site with user configurable HIPS.

 

I had the same problem with version 8. I have not tried learning mode with version 9 yet, but I expect to see the same results.

 

I have an application on my machine that constantly attempts outbound access. ESS version 8 notified me of the outbound request within a few minutes after switching to interactive mode. I uninstalled version 8, and installed version 9. I did not receive any prompt about this application's outbound request for a much longer period of time. I'm not confident the firewall is functioning correctly. Has anyone else noticed similar behavior? I wonder if it's just me.

edited 10/27 @3:26 pm

 

I believe the firewall is buggy also. I noticed a few instances that were suspect. I had my hands full with SSL protocol scanning and HIPS issues so didn't have the time to actually record the suspect activity.

Again, the whole release is a MCF.

 

I forgot about another "zinger" I found that might help people that are experience slow boots after installing ver. 9.

In ver. 8, there are two default "Automatic startup file check" scans done. The first one is for "files run after user logon" i.e. startup programs. The second one is triggered by "successful update of virus sigs." and I believe the access was for "frequently used files" with a low scan priority.

In ver. 9, there are also two default "Automatic startup file check" scans done. Both however do the same thing! They both scan commonly used files and no priority is specified - assume it is high priority. Since the successful update of virus sigs. scan at cold boot time occurs right after the startup file check scan, the second scan is scanning all the same files the first scan did except for perhaps a few new sigs. in use.

With all the normal system startup activities also occurring at the same time all these scans are going on, PC lock up is inevitable.

 

I rolled back to version 8. I will treat version 9 as a beta until a large update has been released to iron out the bugs. I reported a few problems/major dislikes during the beat period that were not fixed . I figured version 9 would be buggy for a while due to the change in the GUI. I hope Eset users send plenty of bug reports, and feedback. They rarely take any of my recommendations.

 

Still, thanks to added banking protection they are probably going to start collecting the MRG Effitas Online Banking / Browser Security award from now on, which is the biggest gain, marketing wise. Bugs rarely matter in award season

 

Good point.

Let's not forget the time Eset spent on making sure they passed every Virus Bulletin test- "ESET are the only vendor to have never missed an ‘In the Wild’ virus over 15 years of Virus Bulletin testing".

So another possible award to add to their long list; http://www.eset.co.uk/Why-ESET/Awards

 

Boy, you hit the nail on the head with that comment!

A-V Comparatives just started testing for AV self-protection. But overall, the labs just test for sig and in-the-wild malware protection without running a functionality test on the security software itself.

Case in point is SSL protocol scanning done by Eset, Kapersky, BitDefender, and Avast. It has been shown to violate one or more SSL browser security mechanisms in third party tests. It does not support the new security protocols such as HSTS. Or, does the browser isolation done by online banking protection actually break built in browser protection mechanisms?

I have never seen tests that zero in on the effectiveness of AV scanning at boot time; a critical function for malware hiding in registry run keys. Etc., etc..

The bottom line is if the security software has bugs, those will eventually impact the overall effectiveness of the product. The bugs I have seen in Smart Security ver. 9 are serious enough for me not to trust its protection.