Marcos

We kindly ask you to not report blocked websites here unless it's an urgent block that may affect a really big number of users. Please read this before you post reads: Do not report blocked websites After cleaning a website from malware and taking measures to prevent further re-infection, request a re-check as per the instructions in the FAQ. This forum does not serve as a channel for requesting website re-check or disputing blocks or detections. Your website has been recently compromised and phishing was planted there. It's been cleaned and is not blocked any more. Having said that, we'll draw this topic to a close.

It's just a scam, just ignore it and delete it. You can check if your account password leaked in a breach at https://haveibeenpwned.com/ and if so, change the password to prevent any further misuse. I've checked your forum registration email address and that account wasn't compromised: Good news — no pwnage found!

We will definitely discuss it, however, the test script should be widely accepted by other AVs as a test script. Otherwise it could happen that if such test file gets into test sets, especially in amateurish tests vendors would have no chance to raise objections if they missed it.

Since Banking and payment protection is part of ESET Internet Security and ESET Smart Security Premium, a desktop shortcut to a secure browser is created on the desktop during installation of the products. In previous versions there was a problem with redirection to sites that utilized HTTP/2 which was not supported by BPP. Support for HTTP/2 in BPP was added in v12.2. As for chase.com, I was able to reproduce the issue but I don't see any reason why redirection shouldn't work. I've reported it to developers so that they will look into it.

I see now. I overlooked that and thought you wanted to report it as missed malware or whatever. I'll reach out to a colleague who is in touch with people from AMTSO to find out if other AV vendors would agree with using the script for testing AMSI functionality. A detection should be agreed by all AV vendors like it's with eicar and other test files. As far as I know, even test files are protected with copyright and the maker of them must give permissions for detection or putting the test files on other websites that are not owned by the maker.

As I wrote, the script merely downloads an encrypted string, decrypts it and displays it (" 'AMSI Test Sample: 7e72c3ce-861b-4339-8740-0ac1484c1386'"). You can also see in the url in the screen shot that Defender detects it as a test file Win32/Mptest!ams. Normally it would be a false positive triggered on an innocuous script but since it's recognized by Defender as a test file, I'm ok with the detection as they make it clear to users, however, it may not be obvious at the first glance.

What code are you referring to? I was referring to this one:

There's nothing to detect since the script merely prints "'AMSI Test Sample: 7e72c3ce-861b-4339-8740-0ac1484c1386'". It doesn't do anything else. As you understand, this is not harmful and thus the script is not subject to detection.

If you have v12.2 and want to receive notifications about module updates, then yes, the above setting must be enabled.

During installation you are asked if you want to participate in Customer experience improvement program. If you later decide to not participate, you can disable it in the advanced setup. There you will also find a web link with information about what data is collected.

You are right. It's definitely a bug, I've reported it to developers.

That's because your former license expired in Jan 2019 and now you've purchased a renewal. Therefore it took some time to sync your license data across all ESET's servers. You can prevent this by: - purchasing a renewal on time - purchasing a new license instead of a renewal if a longer time has passed since the previous license expired.

You could simply reinstall ESET to get the shortcut back. Anyways, it starts "C:\Program Files\ESET\ESET Security\ecmd.exe" /startprotectedbrowser As for the problem opening certain websites in the secure browser, please provide a few of them so that we can check them out.

If you have a multi-device license, uninstall ESET from the mobile phone and install the appropriate ESET product on the pc.

Please provide me with your public license ID so that I can check your credentials.

Since this is an English forum, we kindly ask you to post in English so that the other can understand you and respond. You are the first user to have reported such issue; we didn't encounter it either. Please contact your local customer care for further troubleshooting due to the language barrier and because further logs will be needed for perusal.

Change the default browser in Windows to Firefox.

Don't know what password you used, however, attackers can perform brute-force dictionary attacks and try dozens of thousands of commonly used passwords within a relatively short time. Therefore it's important to use a lockout policy, 2FA, limit RDP connections to specific IP addresses on a firewall, etc. Ideally use VPN for connections from outside and allow RDP only within your local network.

The communication is either on port 443 or 80. Clients must be able to connect to activation servers as per the KB article. Are you able to open https://edf.eset.com/edf in a browser using the same proxy server settings as used by Endpoint and agent ? A short xml file should show up. Should the problem persist, carry on as follows: - in the advanced setup -> tools -> diagnostics enable 1. advanced licensing and 2. network protection logging - try to activate the product - disable logging - collect logs with ESET Log Collector and upload the generated archive here.

Please collect logs as per the instructions at https://support.eset.com/kb3404/ and supply the generated archive to customer care for perusal.

Do the machines connect directly to the Internet or through a proxy? If the latter, is the proxy configured properly in Endpoint and agent? Do you use a firewall? If so, are the necessary addresses allowed as per https://support.eset.com/kb332/?

Ok, there was a misunderstanding. As of v12.2, eamsi.dll is signed by Microsoft so that processes that utilize AMSI can load eamsi.dll without issues. What developers meant was that Microsoft would not sign the dll using the ELAM certificate.

The files were exclusively being open by the operating system so other applications could not access them. It's perfectly normal and ok.

I would say that developers and Microsoft know best so... I only quoted them and passed the information here to stop speculations. Also eamsi.dll is properly signed.