Eset NOD32 Antivirus and Eset Smart Security version 9

I forgot you were also using EMET.

With EMET installed, you will not get accurate Surfright Exploit test tool results from Eset. The problem is that EMET will intercept all tests prior to Eset's handling of them. EMET installs deeply into the OS. As you observed, EMET fails a lot of the tool tests; primarily the heapspray ones. Disabling all EMET protections in its GUI will not help either as far as the test results go due to the way EMET works; it will still interfere with Eset's exploit protection.

If you use Eset's exploit protection, you should uninstall EMET. I did and have never regretted it. Also my system is greatly improved performance wise since EMET will cause system performance degradation.

Finally, I use Eset HIPS rules to protect critical processes from disk and memory based injection, global hooking, and the like to supplement Eset's exploit protection since it only protects Internet facing apps for the most part.

 

I never tested eset exploit blocker, as I had guessed it conflicts with emet and as such disabled it.
My plan moving forward now is to keep it disabled but use hit man pro alert for those type of exploits. EMET may stay installed but will wipe all the app mitigations and only use for testing or if hitman pro alert cannot enable mitigation (have discovered flaws in adding protection to apps woth hitman pro alert).

Ironically that little free app called private firewall which I still have on my laptop blocks all those exploit tests as it asks for authorisation every time to run calc.exe.

I have kept the hips rules I added in place tho, on that other post where you gave me your rules, was that your entire ruleset?

Quick ammendment, going forward EMET will be used alongside Hitman pro alert as hitman doesnt harden system processes such as svchost.exe and doesnt detect various apps like everything ion my system tray such as dropbox and pidgin, so EMET is used on those, and hitman pro on all the mainstream apps. I will be keeping exploit blocker and advanced memory scanner disabled on eset due to possible conflicts and that I dont know how they work.

The rules you provided for HIPS and a couple of my own I am keeping active.

Regarding EMET conflicts, if you leave apps listed in its apps configuration page even with all boxes unticked yes it will still hook to those binaries and cause possible conflicts but if apps are removed, then it wont hook onto them, so an EMET e.g. with no apps configured is just a empty shell that only serves to configure and show the OS wide settings.

 

What makes Eset exploit protection unique is that it will leave the browser alone and just block the test tool exploit activity. Does so silently and browser is still functional.

When the browser attempts to spawn calc.exe, it alert on that activity.

No.

My entire rule set is extensive. It is also customized for Win 7 and my higher level of desired protection. As such, there will be alerts for existing rules by design. Posting all rules via screen shots would take a while and consume a bit of Wilders disk space. If you plan on using HMP-A and configure a few system processes in it such as explorer, svchost.exe, etc., it will give the same process modification protection my Eset HIPS rules do.

 

hitman pro it seems cannot add processes that dont have an app window, it has no function to manually add exe files and requires apps to be detected which are only detected when they in the foreground. Since things like svchost dont have their own window it cannot be added, currently I have svchost hardened by emet. (explorer cannot be added also).

I would appreciate seeing your rules even if you sent them in private due to concern of the public eye, as I would guess someone who has worked long and hard on it like you have probably has quite a good result from it,. I seen your previous posts and you seem knowledgable on this sort of thing.

 

Interesting. That is what I suspected since it is not a HIPS,

Best I can do is PM you an export of my existing Eset config.. I assume you have something that will allow viewing of an XML formatted file? Will do so when I get a chance.

 

Yeah I will worry about the XML viewing, thank you very much.

 

@chrcol Did you get your LiveGrid cloud lookup working properly at the AMTSO website yet ? I just assume it was you that said it didn't work at the ESET forum, as the members nickname on the ESET forum is similar to yours

 

Here is what the alert should look like from Eset:

 

I did but i am disappointed.

It seems eset's cloud lookups only work on http scanning not on any file scanning on the system like other cloud a/v vendors do. So basically I had to enable http scanning, it didnt do the cloud check when I downloaded the file without it.
Sadly I disabled it again yesterday as web browsing was getting really slow even with some sites not finishing loading. So I guess I need to report my http scanning issues to eset at some point.

Also then there is the issue that I wont enable https scanning due to the issues associated with intercepting https traffic. So I really hope eset remove the dependency of needing to scan http,https trafffic for livegrid to be used.

Note I am leaving the protocol filtering enabled at all times.

 

Strange ........ SSL protocol scanning will slow down HTTPS web site rendering a bit. But HTTP scanning has zip performance impact on my build - WIN 7 and IE11. Might be something else you have installed that is interfering with Eset filtering. As I recall you have EMET plus HMP-A installed?

Note that with HTTP scanning turned off, you are very much at an increased risk from web based malware. All of Eset's front end protection is done via the network filter it installs.

 

Yeah and I think thats the flaw that might make me drop nod32 after all these years.

I am not the only one thats told them to abandon their idea of intercepting https traffic which is a growing issue due to the move of the modern web to https only traffic. Eset need to find a way to scan everything without needing to scan the live traffic. Other vendors dont have a dependency on http scanning for cloud technology.

So the issues are the disk based scanning from eset is weaker than their http scanning due to not using livegrid, and that they have not implemented a way to scan web data (thats only in ram) without http scanning.

Eset also have no whitelisting system as well, whereby it should consider everything untrusted until its whitelisted by the cloud.

EMET now doesnt hook onto any of my browsers.

HMPA hooks but I believe it doesnt scan http/https traffic, its Browser basic protection is related to checking if addons in the browser are safe and its exploit protection is all memory stuff to block memory hijack type attacks.

HMPA does slow down browsers a bit as is expected (EMET and MBAE do also), but it never actually affected web page downloading and rendering speeds.

 

LiveGrid is part of the ThreatSense realtime scan engine. When you open Web Access Protection, the first option you see is the ability to configure ThreatSense options that only apply to WAP. Unlike many AVs that only scan web traffic using reputation criteria or IP blacklisting, Eset uses its full realtime engine to to so. I have had WAP catch a number of Trojans on web sites using signatures from the ThreatSense engine. Also note that advanced heuristics with sandboxing is also part of the ThreatSense engine.

Again, I stress the importance of leaving HTTP filtering enabled. Additonally, I recommend you enable outbound firewall protection and only allow your browser to connect to ports configured in HTTP filtering. By default, those are ports 80, 8080, and 3128. Of course, will also have to allow port 443 for HTTPS traffic.

Eset does have whitelisting. You run the HIPS in "policy" mode. Any activity for which an existing HIPS allow rule does not exist will be blocked.

 

I too don't use https/SSL scanning for various reasons. But disabling http scanning which is very effective as it works both ways in/out, and is the first layer against online threats, is not good. I would probably stop using ESET if I felt the need to disable http scanning. It has been one of the reasons why I like the products so much as it works independently of what browser I happen to use, relying solely on URL and IP blacklists to block access to whole websites just doesn't cut it.(ESET use that in the products too) There is no more effective way to block threats at the source than this, and I like to stop whatever I encounter as early as possible and not let it in my system in the first place. And I talk about http scanning only, not https. Even though the use of https increases day by day, but that's another matter. And after that you have the other layers and features in ESET that comes into play incase something slips by the first layer.

Yes there is, well, not as you describe, but LiveGrid is used as a whitelist, blacklist and more...

Note, ESET does not use file reputation data from LiveGrid like some other vendors e.g to detect files with low reputation/few users, as they feel it could cause too many FP cases, i.e a file with 5 users does not automatically mean it's bad and the user should be prompted with a detection notification cause of that.

Not sure what you guys think or want with ESET exactly. But I wrote a feature request in 2014 that I know some users would find useful, which could be enabled by the user, and which should NOT be based on file reputation/how many users have this file, at all. Instead the user would be prompted for all files that are not "known good/green tagged" in LiveGrid.
https://forum.eset.com/topic/51-future-changes-to-eset-smart-security/?p=17761

And considering ESET has over 100 million users, I suspect it would work seamlessly for most users expect for the "wilders"-type of users that may try to execute files that most people would never come across and that LiveGrid has never seen and processed before.

And like itman, I don't have any slowdown due to the http scanning/web access protection. Must be something in your system, combination of your sec apps perhaps. The more sec apps one have installed and use, the more troubleshooting one has to do when problems arise.

 

http scanning may be over important on eset but it isnt on everything. I wont enable something thats broken, and as already pointed out what happens to https traffic (which I definitely wont enable https scanning).

Rather than spitting out eset marketing jargon you failed to address the lack of cloud scanning on the real time file system module, that should have the same level of protection as the http scanning.

The problem is you see the problem as me instead of how eset have programmed their software.

If eset is so crippled without http/https scanning then thats a problem they need to fix.

"Yes there is, well, not as you describe, but LiveGrid is used as a whitelist, blacklist and more."

So I just told you livegrid is not used on file scanning and then you make a false claim?

On the cloud test if livegrid is used on file scanning it should detect the test signature when its written to disk but doesnt.
Also there is no whitelisting on livegrid, I can make a new executable, put it on webspace and download it with no warning from livegrid even with http scanning enabled, if it was a whitelist system I would expect a prompt to alert me its an unknown file.

I just tested it on avast.

It is detected with and without http scanning enabled, the only difference is that with http scanning enabled it is detected earlier.

 

I just duplicated your testing of LiveGrid using the clouldcar file. I disabled HTTP filtering. I downloaded the clouldcar file. Eset's Threatsense realtime scan engine did not detect it upon execution or by context scanning. Does that mean there is a problem with either LiveGrid reputation scanning or realtime processing? I don't think so using the following reasoning.

The cloudcar.exe file is not malicious so it is reasonable that Eset does not have a signature for the file. Additionally, this is a test of its reputation scanner i.e. LiveGrid.

As far as the issue of LiveGrid not detecting the file upon execution by reputation criteria; the file is not a not signed, is unknown, etc., do the following:

1. Open up Process Explorer.
2. Then startup up the cloudcar.exe file in explorer.exe by opening it.

Do you see it running in Process Explorer? Does it even load in Process Explorer? The answer to both questions is no. There are two possible explainations:

1. Clouldcar.exe is just a dummy file with an .exe extension. As such, the realtime scanning engine and LiveGrid processing was never activated.
2. Eset did block clouldcar.exe from execution but failed to alert or log the activity. If so, then this is an issue to be raised with Eset.

To test Livegrid processing using the realtime scan engine outside of HTTP filtering, you will have to use a real .exe that is truly unknown.

As far as Avast and also Emsisoft which I have also installed detecting the cloudcar.exe upon execution, they both have signatures for that file. Again we are testing reputation detection capability, not signature capability.

 

You still dont understand, the issue is the livegrid isnt working when files are checked by the real time file module, so if it detects on http it should also detect on storage. Cloud doesnt mean internet traffic scanning it means cloud data is utilised when scanning.

If I disable the cloud in avast it does not detect it, if I enable the cloud it detects it, simple.

 

Let me begin with making a correction to my previous statement that Avast and Emsisoft detect cloudcar.exe by signature. That is not true. They detect via clould lookup at either file download, access, or execution depending on AV capability and user settings.

Pertaining to Eset, Live Grid cloud reputation scan is always performed at file execution time. This can be verified by using the "Running Processes" option:



Again, you cannot verify this for cloudcar.exe since it is not a real executable.

With Eset's HTTP Filtering disabled, LiveGrid processing will not be performed at file download time. If you wish to verify the file manually prior to executing it, you will have to do so using an explorer.exe context scan. Select "Advanced Options" under the "Scan with Eset Smart Security" heading, Then select "Check file reputation using Eset Live Grid." The result for the clouldcar.exe file is:



Note that the context scan option could also be utilized for files that would be created on your PC by means other than downloading e.g. copied from external media, etc..

Finally as far as I am aware of, Eset never made a claim that Live Grid lookup processing is employed during schedule, on demand, etc. AV scans. Those are all signature based as far as I am aware of. Another example of protection enabled at program execution is Advanced Hueristics.

 

You still dont get it.

cloudcar.exe was created speficially for diagnosing if the a/v vendor cloud detection is working properly. (with me so far?)
To vendors listed on the download page have detection routines for that executable on their cloud servers but not on virus signatures installed locally on the pc. (still with me?)
This test is specifically to test when cloud checks are carried out, the test has confirmed to me that eset on my machine (might be a bug possibly) is only checking cloud when http scanning is enabled, it is not doing cloud lookups on local scanning. (understand?)
On avast if I disable "enable reputation services" it isnt recognised as a problem, this is 100% expected behaviour, avast's http module is not required for it to be recognised, again expected behaviour. (agree?)
I have noticed the real time file scanner on nod32 does have a tickbox for "eset live grid", this box is ticked, but on my system its not working. If it was working then when I try to write the file or run it then nod32 should be doing a lookup in the cloud which its failing to do. (I know you dont agree on this)

I have reported the bug now to eset tech support. If eset say its intended behaviour then I will contact amtso and ask them to remove eset from the listed vendors.

I think you trying to tell me I should not be worried about the cloud test failing because its only a test not real malware, when eset is listed as a vendor part of that test.

Also to add I monitored tcp connections to eset, there is no cloud connections to eset when I run or write new files. Which is logical evidence for the lack of cloud testing, whilst avast maintains a constant connection to its cloud server. Cloud connections do occur to eset when I have http scanning on and start browsing sites. Currently its on again but the pages been displayed in chunks is happening again.

By the way, the manual check works like in your screenshot, but its supposed to be working on the real time file scanner, you can see the option exists in the file scanner module options.

You may remember a while back I posted that eset forced an update out and my a/v updated itself without my approval, i then observed afterwards the system was slower which made me downgrade again, I now suspect that update fixed cloud scanning and thats why it got slower, so I am going to upgrade again (not on the latest 8.x currently due to that performance issue) and retest.

So I apologise to SweX also, what he posted is probably how eset is supposed to work and how he believes it to work, but I believe due to a bug its not working on my system.

 

After a lot of searching, I finally found some detail on Live Grid processing that I am posting below.

Pertaining to the cloudcar.exe detection, it appears that HTTP filtering and content-menu are detecting it via blacklisting. It also appears that Live Grid processing is executed prior to any AV scan engine processing for HTTP Filtering.

As you have pointed out, the real-time AV scan engine is not detecting cloudcar.exe. The best explanation I can give is the file is not a valid executable. Because it is not a valid executable - advanced heuristics would have determined that - the AV scan engine never bothered to submit it to Live Grid for analysis is one possible explanation. Whether this violates the AMTSO guidelines for this type of testing, I guess you will find out since you are contacting them.

Live Grid Excerpt

Moreover, it implements a reputation system that helps to improve the overall efficiency of our anti-malware solutions. When an executable file or archive is being inspected on user’s system, its hash tag is first compared against a database of white- and blacklisted items.

If it is found on the whitelist, the inspected file is considered clean and also flagged to be excluded from future scans. If it is on the blacklist, appropriate actions are taken – based on the nature of the threat. Only if no match was found, the file is scanned thoroughly. Based on results of this scan the file becomes a candidate to extend the corresponding list. This approach has a significant positive impact on scanning performance.

Ref.: https://www.eset.sg/home/test/

 

Exactly. There is no local "signatures" for LiveGrid detections AFAIK. What happens when you click on the link at the AMTSO website to test against cloudcar.exe is that there is a "rule/signature" (whatever one should call it) in LiveGrid to detect it. The same can happen when one tries to download a file from somewhere.com, and if there is malware in that file, but no signature has been created & delivered via the normal VSD update channel yet, there is a chance it will be detected in real-time when you try to download the file from the website IF LiveGrid is working properly. That's one of LiveGrids purposes, to close the gap even further.

What the detection popup could look like, as you can see in the screenshots in the following post:https://forum.eset.com/topic/1209-what-are-these-detections/?p=6589
They don't have a "threat name" yet because they are detected by rules/signatures in LiveGrid, and then you'll see "suspicious object" (like the AMTSO cloud test) or "blocked object" = blocked by/in LiveGrid.

Keep httpS/SSL scanning disabled if you like (I already said I have it disabled too, and will keep having it disabled for a while) but just don't keep Web Access Protection disabled altogether. But again, do as you like, each to their own, at your own risk...and all that, itman has explained all that needs to be explained as far as I am concerned.

 

Another point to remember is that even with HTTP Filtering enabled, Live Grid will not catch all malicious downloads. Again, Live Grid is only examining executables that can be identified as such; not all file downloads. Downloads can be encrypted, obfuscated, you name it. Case in point is the following browser download that was caught by the real-time scan engine:

1/16/2016 2:26:21 PM

Real-time file system protection file C:\Users\xxx\AppData\Local\Microsoft\Windows\Temporary Internet Files\Low\Content.IE5\1ARTGYTD\url[1].htm

HTML/Refresh.BC trojan cleaned by deleting xxx-PC\xxx.

Event occurred on a new file created by the application: C:\Program Files\Internet Explorer\iexplore.exe.

 

Yes of course, and I think he knows that. But by having all these essential features disabled he don't give the product a chance to detect anything before "it" has downloaded. And he also don't give AMS the chance to detect threats in memory after execution since he have Advanced Memory Scanner disabled as well...."in nod32 a/v I keep exploit blocker and advanced memory scanner off as I dont know what they do."

I don't see the point in using a product if the goal is to cut its wings off as much as possible. But again, each to their own

 

I also think there is confusion over what Live Grid actual is used for.

If one thoroughly reviews the Eset description I posted in reply #120, it is fairly evident that Live Grid's primary purpose is to assist in the real-time scanning by the AV engine. Elaborating, it will upload "suspicious" activity detected by the real-time scan engine to Eset for "futher analysis." I presume that activity would have been detected by one of the protections provided by Eset; exploit blocker, advanced memory scanning, or advanced heuristics with sandboxing. I also presume at that time, the .exe in question is added Live Grid's blacklist as "suspicious" and an alert issued indicating such status. After analysis by Eset, Live Grid will be utilized to either whitelist the .exe if it is not malicious or change its existing blacklist status to malicious.

Bottom line here is that Live Grid is not a cloud based reputation scanner whose purpose is to determine if the .exe is "known" per se and block execution if "unknown." Such type of cloud "rep" scanners exist in other AV products such as Avast, Emsisoft, and other AV products. Eset's approach is prevent an unknown .exe run from running only if it displays known or detected malware or suspicious behavior.

And you are correct Swex, disabling any of the above mentioned Eset protection mechanisms will have an impact on Eset's overall effectives in detecting and mitigating malware detection. Disabling HTTP Filtering will block the use of Live Grid's blacklisting by Eset's network based filter. This will allow previously detected malware or suspect .exe's to download. In theory, the real-time scan engine should detect these upon execution. But it is a given that the desired action is to block a payload at its point of origin rather than to that a risk that the AV scan engine might not detect it latter due to misconfiguration or other factors.

-Continued-

Now lets talk specifically on why the Eset's real-time scan engine does not detect the AMTSO cloudcar.exe file in a non-HTTP filtering mode. What I said previously that it didn't detect the file because it is not malicious doesn't fully explain what is going on. So let's get into the nitty gritty details. When Eset's real-time scan engine scans a file, it looks to see if it's on Live Grid's whitelist. If so, it allows the file. Next, it looks to see if the file is on Live Grid's blacklist and marked as malicious. If so, it alerts and blocks the file from execution. If the file is on the blacklist and marked as suspicious but not user allowed, it will alert. If the suspicious file is user allowed, it will then analyze the file for any known i.e. signature based malware activity. If clean, it will terminate processing for that file. An alert will not be issued. You say "what the .................?" Eset's real-time scan engine will not re-alert for the following reason. If a previous user allowed suspicious file physically exists on the PC, Eset's real-time scan engine assumes the file is safe. If the real-time scan engine did otherwise, the user would be constantly alerted every time the file was scanned by the real-time engine. I believe you're not getting an alert for the clouldcar.exe file because Eset has special cased that file as safe as far as the real-time scan engine is concerned i.e. it is marked allowed in the local copy of the LiveGrid blacklist - see the below last paragraph. Remember the file is not malicious; it is not even a valid executable.

So you ask, how does HTTP filtering detect the cloudcar.exe file? Because the real-time scan engine always uses the Cloud for file downloads. When the real-time scan engine finds a matching hash for clouldcar.exe on Live Grid's Cloud blacklist, it will issue a suspicious file alert and ask the user what he wants to do; allow the download or quarantine the file. If the download is allowed, it will be flagged as suspicious but allowed.

Other AVs do not use this approach. Emsisoft as an example which I have also installed does not have a network filter. So its malware analysis can only be performed after the download has been physically created on the HDD. EAM will detect clouldcar.exe upon file creation or access/execution depending on AV settings used. Thereafter assuming the download is allowed, EAM will detect the cloudcar.exe file for any type of AV scan employed. Ditto for any other "suspect" file the user might have downloaded. EAM categorizes such files as "riskware", allows the files, logs the event, and shows it in the scan results display.

So it's up to the user to decide which approach he's more comfortable with - be constantly alerted for previously user allowed suspicious files or not - and chose his AV software accordingly.

As best as I can determine, the AMTSO Cloudcar test is just a verification that some type of malware analysis is done on an Internet download prior to physical creation on the HDD. Eset accomplishes it by accessing the Live Grid blacklist via the clould(HTTP Filtering or context-scan), then performing further malware analysis on packets as they enter the network filter.

Sorry, one last important point and I am done. Chrcol stated:

Cloud lookup is a somewhat loosely used term. Eset maintains LiveGrid's white and blacklists on it servers. However, doing a network connection for each file scanned would have a major impact on scan times, especially full HDD scans, and network broadband use. I believe Eset maintains a copy of these lists on each PC and refreshes them on a periodic basis. I believe the frequency is significantly greater than that for signature updates. They also could be refreshed at the beginning of each major scan request. So your covered for scanning for files that might be created on your PC other than by Internet download.

 

what do you mean by all these features?

The only feature I have off that is on by default is http scanning. One feature.
Or if you referring to the vaguely termed exploit blocker. (which is off by default when I installed it).

Funny enough eset have accepted it as a bug as they have told me live grid is not tied to http scanning and should work if enabled in the real time scanning module, so seems their developers disagree with both of you.