itman

Try adding the directories you want exclude using the \* option at the end of the path name to Deep Behavior Inspection exclusions section of the HIPS settings.

Maybe the way to proceed is to verify Eset's RDP brute force password protection. For anyone using RDP, here is an article listing a number of RDP brute force attack tools that are readily available for penetration testing: https://resources.infosecinstitute.com/popular-tools-for-brute-force-attacks/

Webex is not a browser: https://www.webex.com/ . Appears to be an interactive collaborative work software although it may include browser capabiility.

I was aware that a RDP setting existed in Eset IDS. However per Eset online help, it only covers: https://help.eset.com/eis/13/en-US/idh_config_epfw_advanced_settings.html As far as I am aware of, CVE's only pertain to known hardware/software vulnerabilities. A brute force RDP attack does not fall into this category to my best knowledge.

As far as I am aware of, Eset has no protection against it. On the other hand, Kaspersky's IDS has included it since 2014 on all product lines where IDS is included: https://www.kaspersky.com/blog/a-multiheaded-battering-ram-rdp-bruteforce-attacks-on-the-rise/14971/

I also forgot to post on the most important part of this ransomware attack: At this point, the attacker had admin privileges. Any thing after this point is academic in what the attacker could do.

The Sophos article is a bit murky on how PsExec is being used. From what is shown, it appears the attacker is running PsExec remotely after the reboot to safe mode to execute the ransomware. To accomplish this, both psexecsvc.exe download and creation of a service to run it would have had to been created prior to reboot. I have an Eset HIPS rule in place to prevent this but creation of it was a bit tricky.

This thread is somewhat related to the issue you are having: https://forum.eset.com/topic/19424-duplicate-ip-addresses-on-network-cause-by-vpn-and-rdp/ I doubt the camera has malware since 3/4 of your network PC's are not detecting anything.

Also of note is this malware uses bcdedit.exe to modify Win startup settings. I have had an existing HIPS rule in place for sometime to monitor its startup: https://news.sophos.com/en-us/2019/12/09/snatch-ransomware-reboots-pcs-into-safe-mode-to-bypass-protection/

Off the top of my head, the best way to prevent this is to create a HIPS rule to monitor the running of shutdown.exe. Note that malware since the XP days have used this to force a reboot to run their nasty at boot time. As such, it would not surprise me that Eset already as a built-in HIPS rule to monitor the start up of shutdown.exe.

In Win 10, Eset uses the Early Launch Anti-malware; i.e. ELAM, driver to load its kernel process drivers prior to any other non-device drivers. You can read about ELAM here: https://docs.microsoft.com/en-us/windows-hardware/drivers/install/early-launch-antimalware

Avast has a long reputation for tracking user activities, ad nag screens, you name it. This is especially true for the free versions of it but even the paid versions perform limited tracking activities. This is one major reason I stop using their products some years back.

Win 10 x(64) 1909, Eset IS ver. 13.0.24 This issue has persisted for some time. So it's not related to the current Eset ver. per se. Refer to the below screen shot. When I try to add the Trusted Zone to Local or Remote firewall rule, I receive a non-existent zone error message. This appears to be the only zone with add issues. Interestingly, the Netword Wizard has no problem creating a rule with the Trusted Zone specified.

From a Microsoft follow-up technical detail blog article on a ransomware infection targeting concerns in St. Petersburg, Russia. The original blog article which MS got a lot of free press was how WD ATP was the only one to detect it. Note that in that article there was no mention of the 5 9 WD ATP sites being infected by this ransomware. I checked out the date and time MS stated that they had detected the ransomware. The funny and interesting part is when I checked Eset's VirusRadar database and found Eset had a sig. for this ransomware a day earlier. -EDIT- I was in a rush last night when I posted this so didn't have time to search for the detailed MS blog article. Here it is: https://www.microsoft.com/security/blog/2017/12/11/detonating-a-bad-rabbit-windows-defender-antivirus-and-layered-machine-learning-defenses/ . Actually it was 9 WD ATP users who got nailed prior to WD ATP cloud scanning confirming this was actual ransomware. Also noted in the article was these folks were running WD ATP w/default 90% confidence level. Lowering it to the max. 80% level might have detected it. Of course, FPs at the 80% level reach stratospheric levels ......

I have long argued that what is need is a "professional" version of Eset consumer products. For example, the above mentioned EES 7.2 aggressive option could be one feature provided. Another I would like to see is more aggressive reputational scanning options such as the ability to alert/block unknown non-system processes and the like. Etc., etc.. To date, this has fallen "on deaf" Eset ears.