Elise

It's a legitimate file, created by TLC (the owner of Alcatel). The McAfee detection is a false-positive.

Hello, Thank you for reporting this issue. Without an actual file there is nothing we can do to check this. My recommendation would be though to contact McAfee and ask them to check if this is a false-positive since it is their application detecting it.

No idea, probably a slow update connection. You could try to check if the browser is up to date via Help > About Chrome in the menu.

Does this happen after a restart (not standby) before you start the browser at all?

According to their manual you can uninstall it from Apps & Features: http://h10032.www1.hp.com/ctg/Manual/c06379792

This has not changed. The article also states clearly at the start:

RDP attacks are not really new, please see also this article from 2017: https://blog.emsisoft.com/en/28622/rdp-brute-force-attack/ As for software, I would always try out a program to see if it suits your needs, in case of brute force protection its usually the user/administrator, and not the software that makes the difference.

The short answer to that is: no. It can be broken by malware (as in: won't run) or blocked (a replacement is attempted but after a reboot the original bad file is back), but that is about it. That being said, malware doesn't need to manipulate it, if it can just circumvent it. If a system is infected and a replaced system file has sufficient permissions to fool Windows into thinking it is legitimate (this typically is rootkit-level), you can run SFC all you want and Windows will report everything is fine, while in fact you can have one or more infected system files. So running SFC is not a malware scan nor should it be used as such.

I will test this a bit next week, in the mean time you may want to check what the alert was for, because I highly doubt it was for 7zip and rather for the malware file(s).

It depends completely on how this script is executed; in a "normal" malware scenario it will be dropped or downloaded, which will lead it to be blocked.

Unfortunately I can't access that topic. I have checked the files and I suspect the issue is with the powershell script (mal.ps1). A script like that one is usually the result of being dropped by other malware or ending up on the system using exploit code, which will be blocked. To simulate that correctly in a test you would need to find out what malware dropped this script and run that instead.

Can you share the password as well?

Thank you for your feedback. Could you please send us the samples that weren't blocked so we can check out why they were able to encrypt files?

Generally speaking if you see (A) or (B) behind a detection name it is a signature detection. If it is not there and the detection is not from the Surf Protection (URLs), then it usually is a heuristics detection.