itman

You need to keep that rule enabled. Also, that rule means any network traffic from local IP address to 127.x.x.x or; from 127.x.x.x to local IP address. As your screen shot shows, the default Eset "Allow all traffic within the computer" will allow access to the Hosts file which in turn would block all 127.0.0.1 domains listed there preventing the firewall alert you are receiving.

Only if if contains malware or potentially unwanted content.

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.

Appears WD's block-at-first-sight and resultant cloud scan failed to detect the malware. Not surprising since the default scan time is 10 secs. Doubt you will get a specific time range from Eset. My best guess is it is dependent upon LiveGrid server load and other factors. I also suspect that WD Azure cloud server full submission scan and determination varies likewise. One thing that is known for sure is Microsoft's Azure cloud AI server network is substantially larger than Eset's LiveGrid server network.

This is an excerpt from a corresponding Microsoft blog posting. I would think that by now most would take stuff like this as pure unmitigated marketing propaganda. Case in point. In an also recently Microsoft blog posting: https://www.microsoft.com/security/blog/2019/08/27/improve-security-simplify-operations-windows-defender-antivirus-morphisec/ spotlighting how one company is addressing its concerns over 0-day and fileless malware, it was shown how they are using WD plus Morphisec, a Microsoft partner, solution to do so. Of note: Obviously Bill, the IT Director, is not going to waste corporate dollars on purchasing a duplicate protection solution if WD provided like protections. So what does Morphisec do: http://web.mit.edu/br26972/www/pubs/mt_survey.pdf

Another possibility of why WD is starting at boot time and would also be an explanation as to why WD's Periodic Scanning feature is being "mysteriously" disabled is the following. Eset internally is using that option to enable WD at boot time. This will cause the WD engine process to load at boot time. Once Eset "straightens itself out" registration-wise with the Security Center, it then internally disables WD's Periodic Scanning feature. If so, this definitely falls into the "mega-kluge" category.😬

I am not referring to the new Win 10 stand-alone sandbox feature, but Windows Defender's self-sandbox feature. Refer to this article on how to enable it: https://www.howtogeek.com/fyi/windows-defender-now-offers-ultra-secure-sandbox-mode-heres-how-to-turn-it-on/

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.

I assume that was the case although it wasn't specifically noted as such. Believe the purpose of the test was that a of corps. still use Win 7. I personally still have a lot of doubts in regards to WD fileless malware protection on Win 10. WD doesn't have advanced memory scanning protection as best as I can determine. It is relying primarily on it's block-at-first-sight and resultant short duration cloud sandbox analysis to determine malicious post-execution behavior. Also Win 10 relies heavily on protected process - light (PPL) to protect its critical processes. Problem is that its rather trivial to bypass PPL. If you do use WD, make sure you enable its self-sandboxing feature since I really don't trust its self-protection mechanisms that were introduced in Win 10 1903. This will at least protect you from malware spreading outside the sandbox if the WD engine, MsMpEng.exe, is compromised. Finally and a clear indication that base WD protection is deficient against ransomware is the fact that an optional PowerShell or Group Policy implemented advanced surface reduction (ASR) rule exists; Use advanced protection against ransomware to provide additional protection.

Further proof something is not right in regards to the 12.2.29 upgrade pertaining to Windows Security Center and Windows Defender. Not only is the WD engine starting at boot time, but it appears WD is attempting to also update its signature database. Refer to the below screen shot. Also in this instance, MpCmdRun.exe runs for an extended period of time till it apparently times out and finally terminates. Again, this process should not be running unless Windows believes WD is the active real-time solution.

As far as how other AV's handle external network Win RDP, it appears Kaspersky Endpoint doesn't allow it period to its GUI interface as best as I can determine. Refs..: https://support.kaspersky.com/us/9400 https://support.kaspersky.com/us/10947

I am more concerned that the WD engine is starting up at boot time; abet for a short period only. Note this activity occurs after user logon. Prior to Win 10 1903, WD has no self-protection. Also as I noted in another forum posting, 1903 WD self-protection is not always enabled initially as it should be. This makes it an ideal target for code injection, APC thread hijacking, etc. by an attacker. Note to anyone running WD periodic scanning on Win 10 1903. Verify that its self-protection option is enabled. Additionally make sure that MsMpEng.exe is self-sandboxed.

Appears Eset prefixed the installer with "legacy" so folk won't confuse it with the existing current version installer. Also check the downloaded file Properties and ensure it states 12.2.23 prior to running it.

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.

On that regard, review its performance against exploits and fileless malware on this AV lab test: https://www.mrg-effitas.com/wp-content/uploads/2019/08/MRG_Effitas_2019Q2_360.pdf where it missed 80% of the malware samples while at the same time scoring highest in false positives.