Marcos

We have it tracked as a bug. As soon as a fix is available, we will update this topic.

Although the best course of action (not only from the security POV) would be upgrading the server, not everyone can afford it or do it. We also have many even business users who run Windows XP which is no longer supported by Microsoft but we do our best to keep our products compatible with it.

Does temporarily disabling protocol filtering make a difference? Does the problem persist even if you switch to pre-release updates in the advanced update setup? If that doesn't help, enable advanced protocol filtering logging in the advanced setup -> Tools -> Diagnostics and try to access the website. Next disable logging and collect logs using ESET Log Collector (see my signature for instructions). When done, upload the output archive to a safe location and pm me a download link.

Hi Michael, We appreciate your response here. My understanding is that injecting a malicious dll into ekrn.exe (the core process running under the local system account) is not possible due to self-defense. This protection was implemented in v4.2 several years ago. What was possible (until yesterday and on systems where ekrn is not running as a protected service) was injecting a possibly malicious code into an unprotected process that communicates with ekrn, e.g. in order to disable protection or change settings. However, this cannot be done without administrator privileges. In my opinion, once an attacker gains administrator rights he or she can do virtually whatever they want; including disabling an AV or uninstalling it. Injecting a dll into a non-protected process seems to me like a redundant intermediate step requiring additional effort.

@janw The solution is to disable the option for activating Presentation mode when an application running in full-screen mode is detected.

Probably you'll find it in Power options as you can see at https://www.howtogeek.com/243901/the-pros-and-cons-of-windows-10s-fast-startup-mode/

You didn't mention what operating system is installed on clients. If Windows 10, it does not shut down in a standard way but performs a kinda hibernation (I reckon it's called fast boot). Only restarting the computer will cause new drivers to be loaded and Endpoint v6.5 to work properly.

Did you upgrade from an older version? If so, does installing EEA v6.5 from scratch solve the issue?

Unfortunately, files encrypted by Filecoder.Crysis (.wallet) cannot be decrypted. We recommend keeping them in case that decryption will be possible in the future. Were the encrypted files located in shares that other users (or everyone) can write to? Do you have ESET configured for maximum protection, ie. is LiveGrid enabled and working? You could provide me with logs collected by ESET Log Collector to review your ESET configuration.

Did you export the CA certificate from the former server? ( Export all Certification Authority Certificates from your ERA Server and save each CA certificate as a .der file.) Did you import it on the new one? ( Import all CAs exported from your old ERA Server. To do so, follow the instructions for importing a public key. )

The javascript used on the website is obfuscated in a way that malware authors obfuscate malicious scripts to evade detection which is why it's detected. For more information about why we don't recommend using this kind of obfuscation, see http://www.welivesecurity.com/2011/05/17/obfuscated-javascript-oh-what-a-tangled-web/. You can add this particular website to the list of URLs excluded from protocol filtering to avoid detection.

I still see this awful obfuscated code there: The owner of the website should replace it either with an image or non-obfuscated script.

According to your screen shot, you've picked a wrong product. Instead of "ESET File Security for Window Server (v6+)", you've picked "ESET Endpoint for Windows" which is why it's not applied on EFSW.

The padlock next to the LivveGrid setting means that it's enforced by a policy. Please check client details in the ERA console and check the policies that are applied. Make sure the setting is enabled.

1, In order to inject a fake verifier dll, one would have to modify values for ekrn.exe and egui.exe under IFEO but these have been protected by self-defense since v4.2. 2, We are aware that some non-crucial processes are not currently protected by self-defense, however, in order to modify the registry an attacker would have to gain admin rights. Even if that happened, it wouldn't make much sense to spend time injecting a malicious dll into an unprotected less important process just to disable protection for instance, as this could be done directly via gui once an attacker gains admin rigths. Needless to say, that in such case he or she can do much more damage to the system or data then just disabling the AV. 3, They claim: "Microsoft has provided a new design concept for antivirus vendors called Protected Processes. The new concept is specially designed for antivirus services. Antivirus processes can be created as “Protected Processes” and the protected process infrastructure only allows trusted, signed code to load and has built-in defense against code injection attacks. This means that even if an attacker found a new Zero-Day technique for injecting code, it could not be used against the antivirus as its code is not signed. Currently no antivirus (except Windows Defender) has implemented this design. Even though Microsoft made this design available more than 3 years ago." Really? On systems with ekrn running as a protected service, unprotected processes have no access to it.

Since this will need a deeper analysis, I'd recommend contacting your local customer care and providing them with: - advanced personal firewall pcapng log - the output from ESET Log Collector tool To generate an advanced personal firewall pcapng log, open the advanced setup and temporarily enable it under Tools -> Diagnostics. When done, restart the computer, reproduce the duplicate IP address detection and then disable logging. Next collect logs using ESET Log Collector (will also include the pcapng log) and provide the output to Customer care for further analysis.

If you enable LiveGrid manually, does it stay enabled? Also could you confirm that you installed ESET File Security or ESET Mail Security 6.5 on the server?

Please clarify what problem you have with querying ESET cloud servers with hashes of files and urls. Apologize, I misread your initial post.

HIPS is a critical protection feature similar to real-time protection in terms of importance. Disabling HIPS also disables: - Self-defense - Advanced Memory Scanner - Exploit Blocker - Anti-ransowmare protection (currently present only in home version 10 but the plan is to get it to Endpoint too) That said, by disabling HIPS you substantially reduce protection capabilities of ESET Endpoint and expose the computers at risk when it comes to new borne malware. Doing so causes Endpoint to be more dependent on definition updates, creating a gap during which computers are more vulnerable to malware attacks. Nevertheless, if you want to take the risk you can disable changing the protection status if HIPS is disabled under User interface -> Application statuses.

The version of your ESET NOD32 Antivirus or ESET Smart Security matters. As I wrote, if you use v7 or older, once these versions reach end of life further updates will not be guaranteed by ESET. With v8 installed, the upgrade notification window can be suppressed for the next few months until some time before the end of its end of life which is likely to happen next year. The main reason why users should use the latest version of a security program is that only this way they can be protected to the maximum extent against newly emerging threats. Needless to say that new versions bring other fixes and improvements under the hood, such as much lower memory consumption and performance improvements introduced in v10.

Unfortunately, you didn't mention what version of EAV/ESS you have currently installed. For instance, according to http://support.eset.com/kb3678, v7 will be discontinued towards the end of this year and no further definition and module updates will be issued. Currently only v10 provides maximum protection against newly emerging threats and especially against ransomware (Filecoders).

What actual issues are you having with upgrade? The records in the HIPS log are probably normal and not a sign of issues. Diagnostic HIPS logging should only be enabled for a limited time to troubleshoot HIPS-related issues.

You can exclude particular network-aware applications from modification detection, you can do so in the advanced setup as show in the screen shot below.

That's not possible. Device Control allows for blocking removable media based on parameters, such as vendor, model and serial number. What's the use case? Do you want restrict users to access only data files, images, etc. on removable media?

LiveGrid is a crucial protection functionality. By default, checking file or url hashes against both the local LiveGrid dabatase and cloud LiveGrid servers is enabled in ESET's products. Disabling LiveGrid completely (ie. even checking hashes against the local and cloud LiveGrid database) has adverse effect on protection and substantially deteriorates detection and protection capabilities of the ESET product when it comes to newly emerging threats. Disabling LiveGrid completely will cause that a detection of a particular malware (e.g. ransomware encrypting files) will be added with the delay of several hours instead of ESET being able to detect and protect you from it virtually instantly. In environments with a strict policy where no submission of statistics or files is allowed, the following policy is recommended: As for submission of samples, this setting should be kept enabled in order for automated systems or malware analysts to generate smart detections for suspicious (malicious) files and to improve cleaning. Sensitive files, such as documents, are excluded from submission by default. Even if you decide to turn off LiveGrid completely (not recommended) and take the risk, you can disable changing of the protection status in the Applications statuses setup in the Tools section.