itman

Since this topic has turned into bashing and ranting by arguing that a competitive AV detected a few more samples out of a bigger set (keep in mind there are dozens of thousands of unique new threat emerging on a daily basis) while ignoring other fact, we'll draw this topic to a close.

I will also note there appears to be renewed interest of late by attackers of injecting explorer.exe and then running a cmd.exe script from it as done in this attack.
I have revised my HIPS rules to now always alert at cmd.exe startup whereas in the past, I excluded explorer.exe startup of cmd.exe. It's a slight inconvenience to answer the alert but it's better to be safe than sorry.

It's an AMS detection. As such, no way to exclude it as far as I am aware of other than disabling Potentially Dangerous Application Detection category as you previously did:

 
 

The problem with hoax malware like this is it will often employ a screen locker at system startup time to display the hoax malware/tech support message. The result is a totally inaccessible system. This appears to be the case with this sample.
Whereas the Ctrl-+Alt-+Del, ALT+F4, etc. keyboard combo works with most of these to bypass the lock screen and allow access to the desktop, only security aware individuals are aware of this trick.
Finally, the average user will most likely respond to the telephone number posted in the hoax message to get access to his system. Once done, he can be duped into paying money to fix the issue. Or worse, actually downloading malware or remote control software allowing full access to his system.
Eset needs to detect hoax malware.

Eset needs to improve its detection of Cobalt Strike components. Having a backdoor residing on your device is totally unacceptable:

Learning mode settings are only accessible if firewall Filtering mode is set to Learning mode:

Learning mode settings are only accessible if firewall Filtering mode is set to Learning mode:

A detection for this variant was added on Oct 31, 2022:
@Trojan.Linux/Filecoder.RansomEXX.B

Here's a link to the PC Security Channel video: https://www.youtube.com/watch?v=e6o2afben0s .
Leo does note that many of these fake installers are huge; the one he analyzed was 300 MB+. As such, it won't be scanned by many of the web based malware detection sites since they have restrictions on file upload size.
The insertion of binary zeros in various portions of the executable is a clever trick. Assumed here is the malware creator went to some lengths to test what AVs he could bypass their scanning using this technique.
The most important thing to note in the video is Leo's statement that this type of malware does have a short "un-detection shelf life" by AV's with most detecting it fairly quickly.

Actually, this topic is out of scope for the forum since it doesn't directly relate to Eset products.
There is plenty of into on the web on man-in-the-middle attacks. Below are two such references:
https://cheapsslsecurity.com/blog/types-of-man-in-the-middle-attacks/
https://beaglesecurity.com/blog/article/man-in-the-middle-attack.html

DPC Watchdog Violation BSOD is usually caused by misbehaving drivers; most notably nVidia graphics card ones: https://learn.microsoft.com/en-us/answers/questions/349623/bsod-dpc-watchdog-violation-windows-10?page=2#answers .
This also could be the reason HV Memory Integrity is not enabling. However, there are a number of other reasons it won't enable. In my case, I had intentionally altered my motherboard memory timings to run my installed 1600 Mhz memory from its default 1333 Mhz setting. Once memory timing was reset to 1333 Mhz default, I could enable HV Memory Integrity.
Additional DPC Watchguard Violation causes are listed here: https://www.howtogeek.com/742322/how-to-fix-a-dpc-watchdog-violation-in-windows-10/ and here: https://windowsreport.com/dpc-watchdog-violation-windows-8/ .
To date, I have never seen Eset per se being the cause of this issue,

No problem here using Edge ver. 110 and ESSP with Protect all browsers option disabled on Win 10 22H2.
Are you running Win 11?

Actually in the OP's case, the reverse is true:
Inconsistent behavior like this points to Secure all browser protection per se is not the base source of these issues.
There currently is a major issue with old Intel graphics drivers borking DirectX processing in Windows 10/11: https://www.bleepingcomputer.com/news/microsoft/microsoft-says-intel-driver-bug-crashes-apps-on-windows-pcs/ , tracking back to 11/2022 Win update.

Wondering if you have tried uninstalling in safe mode and then reinstalling the latest from scratch.
I remember this bug being posted a bit a while back but I've not seen it brought up lately so just wondering if parts of old code etc. has remained when updating 

A few comments here.
There a multiple postings in the forum about this attack method. The malware creators are exploiting a Windows bypass method to get around directly dropping a file into the System32 directory. Namely, create a directory there and drop your file into that directory.
Next is the "folly" in using signatures to detect a malicious script. As shown multiple times at malwaretips.com, a minor script modification will defeat an existing Eset signature detection of the original script. The poster was lucky here in that the payload deployed by the script was one Eset had a signature detection for. If the payload was a 0-day one, he would have been nailed.
Eset HIPS needs to be "beefed up" to detect suspicious script file creations. A file being created under hidden file critera; e.g. xxxxxx.tmp.ps1, with a script suffix is suspicious and should be quarantined until it is further examined by a malware expert.
Alternatively, implement what Microsoft Defender does via optional ASR rule. Block execution of any obfuscated script via HIPS option.

Just disable the Secure all browsers option. You don't want to disable B&PP keylogger protection.
Secure all browsers to date conflicts with a lot of software. Add to this that it by default allows all browser extensions, etc., etc.. It should have never been implemented in the first place.

A hell of a lot more functionality.
For starters, it has full wildcard support. It's custom rules support detection and parsing of command line paths, etc. etc.. Also, a newer feature is whitelisting via Trusted Publisher specification.
 

If you were infected by ransomware, all your files in folders such as My Documents would have a suffix attached to them. Also you should have a ransomware note showing on the desktop at system startup time.
As far as a rollback option, Eset does not employ a system snapshot option such as Kaspersky employs. Therefore, system rollback to  prior period in not possible.

Win 10/11 HVMI and HVCI should never be disabled unless there are serious operational problems with using Windows on the device. Win10/11 advanced protection mechanisms rely on HVMI and HVCI being operational.

Getting back to the green border or whatever other color is shown issue when secure all browsers option is selected, I suggest Eset do what Kapersky does in their B&PP feature titled Safe Pay. Just show an Eset desktop popup notification that the browser is running in B&PP mode which will fade away as do all popup notifications do.
It appears Kaspersky developers had the foresight to anticipate users don't like modification to the browser's display format.

https://support.eset.com/en/kb332-ports-and-addresses-required-to-use-your-eset-product-with-a-third-party-firewall

Firewall rules are not automatically created in Automatic mode but only in Learning mode.
In Automatic mode, the Network Trouble-shooting Wizard will record all blocked firewall traffic and the user then must manually select what blocked activity to allow.

Refer to this Eset knowledge base article on how to create Web Cam access rules: https://support.eset.com/en/kb7071-create-and-edit-webcam-rules-in-eset-windows-home-products .
Based on your screen shot, it appears you did this necessary step;
So there might be a bug in Eset Internet Security. I suggest you create an Eset support request about the issue.
You can add the app manually to Web Cam protection but you will have to add the full path specification of the app. Also, as I noted previously if Microsoft updates the app name or path specification, you will have to repeat this process again.

https://support.eset.com/en/kb332-ports-and-addresses-required-to-use-your-eset-product-with-a-third-party-firewall

I posted about this previously and will post it again.
Cisco after the Petya incident developed a MBR Filter driver, publicly available, that will block write access to track 1, sector 0 where the MBR resides: https://www.talosintelligence.com/mbrfilter .
Further described as:
https://github.com/Cisco-Talos/MBRFilter
Why Eset never incorporated this driver into its software is really beyond me.