Marcos

In order for SSL/TLS to work, make sure that the appropriate application (browser) is added in the list of SSL-filtered applications. If it's not there, add it manually:

Please do the following in safe mode: - rename "C:\Program Files\ESET\ESET Security\Drivers" to Drivers_bak - rename: C:\Windows\System32\drivers\eamonm.sys C:\Windows\System32\drivers\ehdrv.sys C:\Windows\System32\drivers\epfw.sys C:\Windows\System32\drivers\epfwwfp.sys Afterwards reboot Windows to normal mode and check if the issue still occurs. If so, please provide me with fresh ELC logs so that I can check if none of the above drivers is running. At the end of testing, C:\Program Files\ESET\ESET Security\Drivers_bak will have to be renamed back to Drivers.

I have already posted my findings above, although not related to your issue.

Not at all. Even if extensive logging was enabled, Web Control logs would be transferred to the ESMC server only when agent connects to it. As I wrote, I suspect DNS issues which may cause delays in browsing when Web Control is enabled. In such case, you might want to change the DNS server to Google DNS for instance, ie. 8.8.8.8 or 8.8.4.4 and see if it makes a difference.

From the yellow alert window you can exclude it as follows: It will be then added to the exclusion list in this form (the detection name may differ on your machine): When adding an exlusion manually, you don't need to use the "@TYPE=..." attribute.

Such files are not scanned by ESET. Should that be the issue, renaming both instances of eamonm.sys in safe mode would make the problem go away.

Does temporarily disabling Web Control make a difference? If there are issues with DNS resolutions, loading websites may take long with Web Control enabled. Also I've noticed that you have HIPS disabled which means that all the following features are disabled as well and the machines are not protected using modern techniques against new borne malware: - Self-defense - Ransomware shield - Exploit Blocker - Behavior Monitor Please re-enable HIPS and reboot the machines as soon as possible to make them protected to the full extent. Also I'd suggest the following to gain maximum protection: - upgrade to Endpoint 7.1 - set password to protect settings - enable detection of potentially unsafe applications (if any that you use on purpose is detected, exclude it by its detection name) - enable Botnet protection - enable Network attack protection - remove the exclusion C:\pagefile.sys, it's useless (the file is never scanned since it's exclusively used by the OS) - enable LiveGrid feedback system (submission of detected and suspicious files), if possible.

One thing is upgrade of ERA to ESMC and upgrading Endpoint 6.6 to v7.1 is another thing. You can install Endpoint 7.1 even without upgrading to ESCM for now by sending a software install task with Endpoint 7.1 installer to clients. I'd suggest upgrading in batches, ie. sending the task only to a few clients and verifying that everything works alright, then upgrade another group of machines and finally the rest. Of course, in order to take advantage of all features and to be able to use other new products that we have recently introduced, such as ESET Dynamic Threat Defense for instant analysis of suspicious files in cloud and ESET Enterprise Inspector (an EDR solution) for monitoring your network for suspicious activities and responding to them, upgrade to ESMC is inevitable.

Is there any reason why you haven't upgraded Endpoint to the latest version 7.1?

Are you having a problem with Internet banking in the secured browser or when you are redirected from an e-shop to a payment gateway? If you open the secured browser via the icon on your desktop and then perform transcations in it, does it work fine?

Does Endpoint on the machine update from ESET's update servers through http proxy in the internal network? If so, please make sure that the following setting is enabled in the Proxy server setup (advanced setup -> Tools -> Proxy server). We can check your configuration if you collect logs with ESET Log Collector and provide us with the generated archive. I'd suggest: - enabling advanced network protection logging and advanced update engine logging in the advanced setup -> Tools -> Diagnostics - reproducing the error - disabling logging - collecting logs with ESET Log Collector.

Please refer to How do I report a false positive or whitelist my software with ESET? or Please read this before you post. Having said that, we'll draw this topic to a close.

Ignore this. The file was indeed suspicious for some reason but it was not detected. Actually you're using a very old version of EFSW 4.5 which already reached its end of life in 2016 according to https://support.eset.com/kb3592/#efsw. While module updates are still provided, EFSW 4.5 cannot protect you from new borne malware effectively enough. Moreover, it was made long before Windows Server 2008 R2 was available so it doesn't natively support it and you may run into issue. I strongly recommend uninstalling EFSW 4.5 and installing EFSW v7 from scratch.

When detected, unfold advanced options in the alert window, select "Exclude signature from detection" and click "No action".

Yes, as I mentioned, ehdrv.sys must not be renamed since it would result in BSOD if not unregistered properly from the registry. Since eelam.sys cannot have any effect on issues, it's actually another driver which doesn't need to be renamed. However, renaming it shouldn't cause BSOD I'd say.

The detection is correct. Also some other AVs detect the malicious script:

The system of license expiration notifications is made to route users who click the notification to the seller from whom they purchased the license. I would suggest contacting the authorized ESET distributor in your country in this regard. We'll need to check particular licenses if everything is alright on files.

Then Then the customer care should have asked you to rename drivers, one by one (except edevmon.sys) in safe mode. There are two instances of each driver, one in C:\Windows\System32\drivers and the other one in "C:\Program Files\ESET\ESET Security\Drivers" and both need to be renamed. Customer care should then reach out to ESET HQ for further assistance. Forums do not work as CRM systems where we could track the development of cases and ensure timely response.

I was unable to download the tool since authentication is required. Please narrow it down by disabling protocol filtering, real-time protection and HIPS (requires a computer restart). Then open a ticket for your local customer care and provide them with: - step-by-step instructions to reproduce the issue - ELC logs - information about the protection module or setting you had to disable for the issue to go away.

The application served by the blocked address is detected as Win64/SystemRequirementsLab PUA so the PUA block is ok and it's not a false positive. The question is why on earth RadeonSettings.exe attempt to access that url.

How did you solve it? Because having 5 active license is not a reason for getting the said message.

It's been always like that.

Rules are evaluated in the order in which appear in the list. That said, instagram.com is blocked because the first rule blocks access to social networks and instagram.com falls into that category. The second allowing rule is not evaluated because the first one was already matched. If you want to allow access to Instagram and block access to other social networks, put the second rule on top.

Module updates are fully automatic. Once released, clients will get it automatically without your intervention. Since it will be released in batches, it may happen that some clients will get it a bit earlier than the others.

You can re-activate ESET by sending a Product activation task with the appropriate license selected while creating it.