Marcos

I can't think of a reason why a policy would not be applied. What settings are set by the policy? Did you try to enforce the settings by selecting the red flash icon instead of the blue dot?

There are differences between EDTD and LiveGuard.
More details would be needed, including some screenshots for clarification.

We don't use MOTW and this was confirmed by developers. LiveGuard proactive protection is described at https://help.eset.com/edtd/en-US/proactive_protection.html

As far as I know, this was already requested and adding 2FA is on the to-do list.

Yes, it's safe to restore it.

It is not a false alarm, the attack attempts are real. Currently it is not possible to have the communication evaluated by Windows firewall, however, we will consider improving this and allow and admin to create exceptions to reduce logging.

Couldn't it be that Endpoint is connecting via Apache http proxy to the Internet? If so, you will probably need to configure it as per https://help.eset.com/protect_deploy_va/90/en-US/?enable_apache_http_proxy.html:
1.Create a configuration file reqtimeout.conf:
sudo touch /etc/httpd/conf.d/reqtimeout.conf
2.Open the file in a text editor:
nano /etc/httpd/conf.d/reqtimeout.conf
3.Type this setting into the file:
RequestReadTimeout header=0 body=0
4.Save the changes a close the file:
CTRL+X > type Y > press Enter
5.Open the httpd.conf file:
nano /etc/httpd/conf/httpd.conf
6.Add the following line at the end:
IncludeOptional conf.d/reqtimeout.conf
7.Save the changes a close the file:
CTRL+X > type Y > press Enter
8.Restart the Apache HTTP Proxy service:
systemctl restart httpd

The detection has been already re-enabled today and now should detected only actually malicious files.

You can find the setting in the advanced setup:

I've just checked the sample and found out that LiveGuard blocked it in LiveGrid on
2022-01-08, 03:05 CEST

The detection has been already re-enabled today and now should detected only actually malicious files.

The authorization error occurred due to delays in data replication that have occurred recently. We are working hard on implementing improvements to prevent it in the future. We apologize for the inconvenience.

It seems there was an issue during the night, causing a delay of a couple of minutes before new licenses started to work. It's being investigated. We apologize for the inconvenience.

It was a simple batch file that executed wget followed by a malicious url that had already been blocked before. That also means users could not download the payload with WAP enabled.
I assume that the triviality of the batch file might have contributed to the fact that an automated detection was not generated. We manually analyzed and created the detection yesterday.

Thanks for the heads-up. This is a known issue which will be fixed in the next service release of ESET PROTECT / ESET PROTECT Cloud.
P_EP-25800

That's correct. Eicar is detected only if it meets its definition:
https://www.eicar.org/?page_id=3950
Any anti-virus product that supports the EICAR test file should detect it in any file providing that the file starts with the following 68 characters, and is exactly 68 bytes long.
The above file is longer and contains additional characters, breaking the definition of eicar.

Please check if the detection is still being triggered. Today the detection was fine-tuned to avoid certain false positives.

That's correct. Eicar is detected only if it meets its definition:
https://www.eicar.org/?page_id=3950
Any anti-virus product that supports the EICAR test file should detect it in any file providing that the file starts with the following 68 characters, and is exactly 68 bytes long.
The above file is longer and contains additional characters, breaking the definition of eicar.

That's correct. Eicar is detected only if it meets its definition:
https://www.eicar.org/?page_id=3950
Any anti-virus product that supports the EICAR test file should detect it in any file providing that the file starts with the following 68 characters, and is exactly 68 bytes long.
The above file is longer and contains additional characters, breaking the definition of eicar.

You can use WinDirStat to find out which folder contains files that occupy most disk space. Knowing what files they are should give a clue as how to proceed further.

It's typically a result of having adapters with identical IP addresses in the network. Check your firewall log if it contains records about detected identical IP addresses.

The service is supposed to be running.

Not sure why it's running, I recollect it used to not run. The point is to have it registered as a service. I will inquire devs about this.

It does: G7xx-xxxx-xxxx-xxxx-xx2D

If you don't buy a license ESET will stop updating and Windows Defender will activate instead when the engine becomes old. Only this could cause possible performance issues.