itman

If its a trusted app and one you know that was recently updated, it's OK to keep existing permissive rules. For example and most frequently, equi.exe, that was replaced as part of the ver. 12.2.29 upgrade.

Another thing about WD is that it can be bypassed as noted here: https://www.bleepingcomputer.com/news/security/gootkit-malware-bypasses-windows-defender-by-setting-path-exclusions/
My gut is telling me that even if Win 10 1903 WD self-protection was enabled, the registry mod implemented by this WMI event would have bypassed it. Perhaps the ASR mitigation to prevent WMI events from being created would have helped. But ASR mitigations would only be deployed by advanced users and in themselves, can cause operational issues in that they a absolutely block the activity.

I was using RS6; i.e. Win 10 1903, with ver. 12.2.23 installed without these new issues. As such, the problem is the new certificate Eset is using.

It appears to me that Eset is doing some type of "kluge" processing where it fools Win 10 into thinking no other AV/firewall is installed at boot time. That is what is causing the event log entries. My guess is Eset is not loading its ELAM driver. This will cause later Win 10 versions to startup Windows Defender and run it in parallel with the third party AV solution. Or the OS in the mean time seeing that no third party AV is installed, starts up the Win firewall front-end plus Windows Defender.
Eset then later registers itself with Windows Security Center and all is well in that regard. Once the Eset registration with Security Center completes, then the OS switches over to recognizing Eset as the firewall plus AV real-time provider and terminates the Windows Defender engine process.
The problem with the above is while Windows Defender is active, it is performing activities like trying to update its definitions and God only knows what else. There is also the issue of malware that runs at start-up "sneaking through" due to the fact two real-time AV solutions are running. What happens if WD detects the malware first but is not fully functional?
Eset really needs to do its initialization with Security Center properly as was done with ver. 12.2.23 and prior versions.

Continuing the above posted thought, Eset's Firewall and HIPS both have learning, policy, and interactive modes. It is far more likely that an end user could bork his system processing by improperly employing those features than by applying optional aggressive reputational, anti-exec whitelisting, etc. options. So I can only assume Eset just doesn't want to allocate the resources with resultant cost to provide the more aggressive mitigation options a number of its customers want.

One final comment in regards to Live Grid's performance in this incident.
Refer back in this thread to the posted Live Grid screen shot showing ransom.exe running. Note the red color. What does that mean? Per Eset online v12 help:
Hum ........ It certainly appears Eset's front-end heuristic scanning did its job.
So why can't Eset offer an option to be alerted to "risky" processes pre-execution? It most certainly appears to be the correct and logical action to take. For me, I can only conclude the following:
1. Eset has such little faith in Live Grid's reputational analysis that it doesn't trust it for user alert purposes. In this case, get rid of the feature and just perform any submission activities in the background.
2. Eset's avoidance of a false positive detection has reached the level that it is jeopardizing overall system security.

Kaspersky just released their 2018 Malware Incident Report today. Most notable is the following:
https://securelist.com/incident-response-analytics-report-2018/92732/
Also:
https://www.infosecurity-magazine.com/news/the-great-big-ransomware-revival/

Agreed. But if Eset hueristics detects a Live Grid red status risky unknown process, it should throw a suspicious alert and let the user make the decision. Again this should be an advanced Live Grid option with the disclaimer that activating it could lead to a FP detection. Also, it is highly unlikely Live Grid is going to classify a Win base OS process as risky.
Really, this isn't "rocket science."

This is the problem. I would gladly switch to Endpoint. However, I don't want to buy 5 licenses which it appears is Eset's purchase minimum for the product. Eset should have a single license purchase option with a higher cost which would be perfectly acceptable.
Another suggestion is Eset offer an "advanced" Internet Security version which in effect would be a "re-bagged" Endpoint version.

Now we are getting "at the meat" of the issue.
How about an ecmds initiated "aggressive" FP setting? This setting would do globally what you stated; loosen existing anti-FP detection. By keeping the setting out of the Eset GUI, it would prevent Eset "experimental" users from enabling it and subsequently complaining Eset is throwing alerts on some garbage they are trying to install.
At least, Eset should do something in this area to prevent long time users like myself from moving on to security solutions that have such capability.

Since the above Eset's requested enhancements to Live Grid falls into the category of "wishful thinking," let's talk about a free solution built into Win 10 that has such capability. That is Windows Defender's Advanced Surface Reduction; i.e. ASR mitigations:
Since we are on that topic, let's list all the ASR mitigations available:
https://docs.microsoft.com/en-us/windows/security/threat-protection/microsoft-defender-atp/attack-surface-reduction

Some additional comments on how Live Grid should be configured by Eset.
1. The risky status alert option would be an "Advanced option" setting for the existing Live Grid setting in Eset's GUI. It would be disabled by default. Hence and God forbid, Eset gets "dinged" on an AV lab test because of it.
2. It is assumed that Eset already has in place criteria for handling of known assumed safe apps such as OS apps in their respective directories, etc.. I will state that I have never seen any process set to "Red" status in viewing Live Grid's status screen. As such, I am assuming the "Red" status is reserved for unknown reputation apps performing questionable system modification activities.
3. The alert would display additional descriptive information such as signing status, publisher, creation date, directory location, etc.
As I see it, the most that could happen in blocking the process from running would be some app installation or some process .exe you purposely downloaded is blocked/borked. App installers can always be rerun.
The above would allow one to submit the process to VirusTotal for additional verification or Hybrid-Analysis for a detailed sandbox analysis. Win 10 1903 users could additionally run the process in the  Windows sandbox.
Unfortunately, these Live Grid operational modifications have been suggested by me and others in the past and have "fallen on deaf ears" as far as Eset is concerned. After all, Eset always knows best when it comes to security features.

One final comment in regards to Live Grid's performance in this incident.
Refer back in this thread to the posted Live Grid screen shot showing ransom.exe running. Note the red color. What does that mean? Per Eset online v12 help:
Hum ........ It certainly appears Eset's front-end heuristic scanning did its job.
So why can't Eset offer an option to be alerted to "risky" processes pre-execution? It most certainly appears to be the correct and logical action to take. For me, I can only conclude the following:
1. Eset has such little faith in Live Grid's reputational analysis that it doesn't trust it for user alert purposes. In this case, get rid of the feature and just perform any submission activities in the background.
2. Eset's avoidance of a false positive detection has reached the level that it is jeopardizing overall system security.

Most of the dedicated anti-ransomware solutions do the same. BTW - Checkpoint has an excellent anti-ransomware solution that costs around $15 USD w/yearly subscription.
I believe Kaspersky also works the same way. In addition if its System Watcher feature is enabled, it will use a snapshot to restore any files encrypted prior to its ransomware detection mechanism kicking in.
As far as Eset goes, your best solution is to create HIPS rules to monitor file modification activities against any of your User folders. This really shouldn't be too much of an inconvenience for the average user since those directories are not updated that frequently in normal daily use. For business environments, process exceptions would have to be created increasing the risk of ramsonware succeeding due to malware modification of those processes.

Some additional comments on how Live Grid should be configured by Eset.
1. The risky status alert option would be an "Advanced option" setting for the existing Live Grid setting in Eset's GUI. It would be disabled by default. Hence and God forbid, Eset gets "dinged" on an AV lab test because of it.
2. It is assumed that Eset already has in place criteria for handling of known assumed safe apps such as OS apps in their respective directories, etc.. I will state that I have never seen any process set to "Red" status in viewing Live Grid's status screen. As such, I am assuming the "Red" status is reserved for unknown reputation apps performing questionable system modification activities.
3. The alert would display additional descriptive information such as signing status, publisher, creation date, directory location, etc.
As I see it, the most that could happen in blocking the process from running would be some app installation or some process .exe you purposely downloaded is blocked/borked. App installers can always be rerun.
The above would allow one to submit the process to VirusTotal for additional verification or Hybrid-Analysis for a detailed sandbox analysis. Win 10 1903 users could additionally run the process in the  Windows sandbox.
Unfortunately, these Live Grid operational modifications have been suggested by me and others in the past and have "fallen on deaf ears" as far as Eset is concerned. After all, Eset always knows best when it comes to security features.

One final comment in regards to Live Grid's performance in this incident.
Refer back in this thread to the posted Live Grid screen shot showing ransom.exe running. Note the red color. What does that mean? Per Eset online v12 help:
Hum ........ It certainly appears Eset's front-end heuristic scanning did its job.
So why can't Eset offer an option to be alerted to "risky" processes pre-execution? It most certainly appears to be the correct and logical action to take. For me, I can only conclude the following:
1. Eset has such little faith in Live Grid's reputational analysis that it doesn't trust it for user alert purposes. In this case, get rid of the feature and just perform any submission activities in the background.
2. Eset's avoidance of a false positive detection has reached the level that it is jeopardizing overall system security.

Also on Win 10, native SmartScreen goes much farther in that it will block (default setting) or warn of any executable not downloaded from the Win Store. Problem is I don't fully trust it in regards to stealthy malware code execution such as reverse shell and the like. -EDIT- Also another major issue with native SmartScreen is Microsoft in its "infinite dis-wisdom" runs it as a medium integrity process. As such, it can be easily suspended by malware to run its code.

This is the problem. I would gladly switch to Endpoint. However, I don't want to buy 5 licenses which it appears is Eset's purchase minimum for the product. Eset should have a single license purchase option with a higher cost which would be perfectly acceptable.
Another suggestion is Eset offer an "advanced" Internet Security version which in effect would be a "re-bagged" Endpoint version.

One final comment in regards to Live Grid's performance in this incident.
Refer back in this thread to the posted Live Grid screen shot showing ransom.exe running. Note the red color. What does that mean? Per Eset online v12 help:
Hum ........ It certainly appears Eset's front-end heuristic scanning did its job.
So why can't Eset offer an option to be alerted to "risky" processes pre-execution? It most certainly appears to be the correct and logical action to take. For me, I can only conclude the following:
1. Eset has such little faith in Live Grid's reputational analysis that it doesn't trust it for user alert purposes. In this case, get rid of the feature and just perform any submission activities in the background.
2. Eset's avoidance of a false positive detection has reached the level that it is jeopardizing overall system security.

For those who want to "get into the nitty gritty" of this bugger, Dr. Web has a full behavior analysis here: https://www.virustotal.com/gui/file/32db24cc3456965ba75319617ef2094c9549874533b5fc6c13769a994dc57877/behavior/Dr.Web vxCube . I can see one reason this "flew under the Eset ransomware behavior detection radar." It's a "system hostage" ransomware. Appears to encrypt everything related to existing installed apps. I didn't see one reference to user personal directories being encrypted. Very strange ransomware. Also don't understand what it is trying to accomplish since system repair (Win 10 only) plus app re-installation would bring everything back to normal.
-EDIT- It is possible one of the system files it encrypted will block access to user personal directory files giving the impression that all your files have been encrypted.

Most of the dedicated anti-ransomware solutions do the same. BTW - Checkpoint has an excellent anti-ransomware solution that costs around $15 USD w/yearly subscription.
I believe Kaspersky also works the same way. In addition if its System Watcher feature is enabled, it will use a snapshot to restore any files encrypted prior to its ransomware detection mechanism kicking in.
As far as Eset goes, your best solution is to create HIPS rules to monitor file modification activities against any of your User folders. This really shouldn't be too much of an inconvenience for the average user since those directories are not updated that frequently in normal daily use. For business environments, process exceptions would have to be created increasing the risk of ramsonware succeeding due to malware modification of those processes.

One nasty ransomware. It's disguised to appear to be a .pdf file using the xxxxx.pdf.exe naming convention.
Appears to be one of these dreaded compile on the fly .Net .dll malware buggers and then inject that .dll into legit process. Hook a thread to the .dll and we're off and running encryption wise.
I would say the major complaint Eset-wise is why it didn't have a sig. for this when 37 other VT vendors did.
Notice how it targeted WD and Malwarbytes via legit Net process use?
Will say that this sample is a perfect example of why Eset needs "block-at-first-sight" capability; not just for Enterprise subscribers of EED.

This is also worth a read and very much indicates that what Avast/AVG is doing is something Google doesn't approve of:
https://techdows.com/2019/08/chrome-you-are-using-an-unsupported-environment-variable-sslkeylogfile.html

Interesting article. I checked the environment variables for FireFox; I don't use Chrome, and Eset does not use or need to use this baloney.
Both Avast and Kaspersky were having issues with use of their root CA certificates in Chrome a while back to decrypt SSL/TLS traffic. Appears this is Avast's solution to the problem and a very insecure one at that.

The Eset firewall doesn't recognize the APIPA: https://www.pcmag.com/encyclopedia/term/37858/apipa assigned address range; i.e. 169.254.xxx.xxx. Personally, I think its a bug.
In any case if the router or gateway is assigning APIPA addresses to devices, it is indicative of a problem with the DHCP server.