itman

Since you referred to a PC Security Channel test, here is an Eset Internet Security test against ransomware: https://www.youtube.com/watch?v=ps7XNo-DOmI&list=PLRs8fqjYD5ILw73zeNeEXpwoP9Swk13qD&index=18 that was performed a while back.
Comparing to two test results shows WD does have behavior detection capability against 0-day ransomware whereas, EIS does not. Since the Eset test is a bit dated, a retest of EIS would be required before a definitive conclusion can be had on current Eset 0-day ransomware protection capability.

Glad you brought this up.
Eset in ver. 16 by default enabled the Secure all browsers option which is the source for all these green border complaints.
However to allow supported browsers to be usable, Eset by default also allows all browser extensions to be functional. It goes without saying that the primary source of browser malware are extensions/add-ons. Also by doing this, Eset actually weakened prior B&PP capability which didn't allow any extensions/add-ons to load.
I for one want nothing to do with the Secure all browsers feature. If Eset decides in a future release to make the feature mandatory, it's "bye-bye" to Eset usage for me.

FTL,
Thanks for the additional info.  Its starting to sound like your server may be hosting Remote Desktop Services with Remote Desktop Gateway.  Which will have ntoskrnl.exe listening on port 443 for RDP requests to forward to other servers.  While this might be intended, the trigger event info you shared shows an IP from Russia attempting the connection (I used this site to look up the location of the IP address: https://www.maxmind.com/en/geoip-demo).
I highly recommend reviewing the roles installed on the server to verify if "Remote Desktop Services" (previously called Terminal Services) is one of the installed roles.
These detections could very well be a sign of an RDP Brute Force attack from undesired IP addresses.  If this server is an RDP Gateway, and 443 needs to be open to the internet, I would recommend restricting which blocks of IPs you allow to connect.  Geo-IP Blocking could help reduce connections from attackers, but any compromised device in your country, could continue an attack.  And ensure you are using 2fa on any RDP logins (especially Admin logins).
With that said, there is still a chance its not Remote Desktop Services with an RDP Gateway.  That is just what I would expect at this point.
If you have a list of IP Addresses which are allowed to connect, that you want to exclude from triggering this detection, you can use the following exclusion as a template to modify and meet your needs.  Then you will only get detections on untrusted IP addresses:
<definition> <process> <!-- Describe process to apply exclusion too --> <operator type="and"> <!-- SignatureType of 90 = Trusted --> <condition component="Module" property="SignatureType" condition="greaterOrEqual" value="90"/> <condition component="FileItem" property="FullPath" condition="is" value="%SYSTEM%\ntoskrnl.exe" /> <condition component="ProcessInfo" property="ProcessOwner" condition="is" value="nt authority\system"/> </operator> </process> <operations> <operation type="TcpIpProtocolIdentified"> <!-- List of IP Addresses to exclude from triggering detection. Accepts CIDR notation. --> <operator type="or"> <condition component="Network" property="IpAddressV4" condition="is" value="172.16.0.0/12" /> <condition component="Network" property="IpAddressV4" condition="is" value="192.168.5.123" /> </operator> </operation> </operations> </definition>  
Side note: RDP can be brute forced, and its not uncommon for someone to have setup a secondary admin account, with a weaker password and no 2FA, to use incase their primary account is not working (disabled due to bad passwords, or 2FA isnt functioning as expected).  It is not uncommon that a ransomware attack starts with a form of brute force on exposed services (RDP, SMB, vCenter/ESXi web console, etc...).  Also, if some form of Remote Code Execution is discovered, or only known to attackers, it could allow them to walk right in without authentication (In 2017 WannaCry used an RCE on SMB to spread without needing any credentials).

Glad you brought this up.
Eset in ver. 16 by default enabled the Secure all browsers option which is the source for all these green border complaints.
However to allow supported browsers to be usable, Eset by default also allows all browser extensions to be functional. It goes without saying that the primary source of browser malware are extensions/add-ons. Also by doing this, Eset actually weakened prior B&PP capability which didn't allow any extensions/add-ons to load.
I for one want nothing to do with the Secure all browsers feature. If Eset decides in a future release to make the feature mandatory, it's "bye-bye" to Eset usage for me.

In Windows Security Center -> Threat & Protection setting, verify that you have not enabled Periodic scanning per below screen shot. If Period scanning is enabled, the Windows Defender engine will load at system startup and remaining running regardless of if a scan is being performed.

Since everything has been said and explained about this topic's subject and we're just moving in circles which annoys other users, we'll draw it to a close.

One way Eset can detect BIOS/UEFI/MBR malware is that it conducts on going research activities in this area.
A recent example is how it discovered multiple vulnerabilities in select Lenovo new laptop/notebook models: https://www.neowin.net/news/eset-found-lenovo-windows-11-and-10-laptops-have-secure-boot-vulnerability-bios-update-out/ . This discovery enabled Lenovo to patch and issue firmware updates prior to these vulnerabilities being exploited en mass.

From another recent forum posting:
However in my ESSP installation, that setting doesn't exist. It might only appear in an outdated OS situation.

@itman
They were not drivers.  They were text files containing PowerShell scripting and saved as .sys files.  Just a simple technique to try and hide on a system.  I always advise against relying on a file name and/or file path to decide what a file contains or is.
In this case, the malware is reading the contents of the .sys files, and converting them to UTF8 to get PowerShell code to execute.  Here is a snip it of the command being executed to read from the file, prior to executing the contents.

If you do and your browser is Firefox, your Win Security-Mitigations event log - kernel mode will be full of the following blocked entries;

If you do and your browser is Firefox, your Win Security-Mitigations event log - kernel mode will be full of the following blocked entries;

The Eset log entry;
3. 11. 2022 2:38:35    AMSI scanner    file    script    PowerShell/TrojanDownloader.Agent.EDX trojan    blocked    NT SERVICE\MSSQLSERVER
does show the source of this script execution. It is MSSQLSERVER; i.e. C:\Program Files\Microsoft SQL Server\MSSQL\Binn\sqlservr.exe. One possibility here is its service entry has been modified to run this PowerShell script. If this is the case, it should show where the script is located.

I would say the most important point to address is the attacker appears to be gaining remote access after 8 - 10 logon attempts which is an unbelievably low number as far as brute force attacks go. Is the password being used a strong one and not one that can be easily guessed.
It should be noted that Eset's RDP brute force protection default is 10 logon attempts with a blacklist retention period of 10 mins. on my installation. However, Eset on-line help states that the default blacklist retention period is 30 mins.?
-EDIT- Reviewing the above event log screen shot, I see at least 14 logon attempts starting at 6:37 PM. If this was a RDP based attack, Eset RDP brute force logon protection should have kicked in after the 10th logon attempt.
However if the attacker could find an open inbound port on any network protection firewall component, he could perform a brute force logon attack using that port. Eset brute force protection would be N/A in this case.
This article is worth a review: https://bobcares.com/blog/account-lockout-threshold-sql-server/

BTW - are you using the default RDP port of 3389?
There was a recent issue on Eset consumer product versions when the port was changed to another value, Eset RDP brute force detection didn't work.

Acer is the PC manufacturer.
Again, look for a setting in the BIOS options titled, Boot mode selection. If the setting doesn't exist, then your motherboard is using a BIOS versus UEFI.

I suspect the PowerShell script is most likely contained within another script; e.g. command script, and is most likely obfuscated making it difficult to identify.
You could create a temporary HIPS rule to block C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe startup assuming you are not using custom PowerShell scripts for anything. The Eset HIPS log will then contain an entry showing the startup process of PowerShell. Then, search for that script on your PC.

Most likely it is. The setting in the BIOS is usually in a section titlled, "Boot mode selection."

Windows system information will show the manufacturer and model number of your motherboard. Go to the manufacturer's web site for further details on motherboard specifics.
There is a BIOS Mode section in system info. display. This setting will contain the word "UEFI" if the motherboard has been set to boot to UEFI mode.

 

The above said, UEFI based motherboards do have some chip based firmware components to them. Here's an example of malware that abuses those:
https://securelist.com/moonbounce-the-dark-side-of-uefi-firmware/105468/
Since Eset can detect Lojax, it is assumed the same goes for Moonbounce. Removal of it is an entirely different issue.

This article explains the difference between BIOS and UEFI based PC's: https://www.freecodecamp.org/news/uefi-vs-bios/ .
The main difference is BIOS settings are stored in chip based firmware whereas UEFI settings are stored in a file.

I suspect the DesLock service is still installed and running at system startup time.
Open Win Control Panel -> System & Security-> Administrative Tools -> Services. Look for the service associated with DesLock. If found, stop it. Then disable the service. Then test to determine if this resolves the issue.

This indicates that CompuTrace was never installed on your laptop or someone patched the BIOS.
One possibility is if you acquired this laptop from someone else, they "patched" the BIOS to eliminate Computrace from appearing there under the mistaken assumption this actually would remove it.

As I see it, B&PP is not a sandbox.
B&PP is just a browser lock down mode that prevents the browser from external malware injection. Since the default for secured browser is to allow all extensions, that is how the browser will be compromised with possible system infection.

I really don't understand the complaints about the "green frame." It's so inconspicuous using Firefox that I really have to look hard to see that its there. The only obvious thing is the "X" and Eset Icon display on right side border of the browser window which is no big deal.
Perhaps "dark mode" which I don't use makes the border more obvious.

If a new virus uses the same techniques as a previous virus, then there is a good chance that it will be detected. If the people who made the virus discover a new exploit, then it wouldn't be detected. But at the same time, they are not going to waste that on attacking a random person's computer. They'll save that for attacking a high-level person's computer e.g., a politician or CEO. As once the anti-virus companies pick up on this then the exploit becomes worthless. 
For regular people this isn't something you will have to worry about.