itman

I saw your question yesterday. Was getting around to responding and you deleted all the detail within the posting. As such, I assumed you resolved the question/issue on your own. Note that from Friday evening through Sunday evening, a lot of forum members are not active on the forum. The same applies to the moderators. They jump in and out during the weekend and might have missed your posting. Remember this is the weekend and they deserve time off also. So I advise you to re-post and wait for a response.

Did you edit the screen shot you posted? The path shown doesn't make any sense. AppData is associated with a logged on user. For example, C:\Users\xxxxxxxx\AppData. Post a screen shot of log entries, etc. these other "anti-malwares" found. And also which anti-malwares you used for scanning.

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.

Pure unmitigated "rubbish." As a primer, have the customer start here: https://docs.microsoft.com/en-us/windows-server/identity/software-restriction-policies/software-restriction-policies-technical-overview . Then enroll in the like Microsoft courses in the same subject matter. If they are unwilling to do so, then they need to contract out to a competent and certified source to perform those activities.

I noticed that also. I am also surprised this issue still exists since Microsoft is now supposedly outsourcing their sigs. to a competent third party source. As far as as WD goes, it is still not ready for "prime time" protection as evidenced by its exploit and fileless malware detection rate 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.

Confirmed and previously noted by forum posting to Eset. Since it appears that notification was deemed not relevant, I am assuming at this point this event log recorded activity is by design on Eset's part. Only Eset moderators can view attachments. I have previously and just recently reviewed my Win 10 Security settings and all show expected statuses. That is both WIn firewall and Defender are disabled and Eset is the firewall and anti-virus provider. Haven't tried this yet. So I reserve comment on it. I personally have observed something unusual at boot time recently. That is the Windows Defender engine, MsMpEng.exe, starting up and briefly running at boot time and performing an update to this directory, C:\ProgramData\Microsoft\Windows Defender\Support. There is also network activity associated with this.

Appears there are two ongoing issues; a brute force RDP attack and a complaint about Eset's response to the incident. In regards to the later, one is better served resolving that matter off-line and removed from this forum. Since it has been determined that a brute force RDP attack occurred, that fact alone is enough to determine the network was compromised. As such, any type of malicious activity could have occurred non-withstanding a least two known ransomware attacks. As @Marcos previously mentioned unless proper network security measures are employed by this installation to prevent not only brute force RDP attacks but all unauthorized network penetration, this installation will continue to be repeatedly attacked and its network compromised.

One example among many on how an attacker can use RDP maliciously: https://null-byte.wonderhowto.com/how-to/use-remote-port-forwarding-slip-past-firewall-restrictions-unnoticed-0179716/ BTW - plink.exe is a legitimate executable and will not be detected by Eset as malicious. Attacker drops his reverse shell - Netcat is a legit Windows process plus plink.exe and bingo - you're nailed.

As far as I am aware of, none do. It is not their function to ensure a network is properly secured from unauthorized external access using a legitimate Windows feature to do so. What they all do however is post multiple blog, security configuration articles, etc. on first, avoidance of RDP use, and second, on how to properly secure it if one still chooses to use it. The most basic of these security mitigations is to employ Windows Security Policy to control number of attempted logon attempts with subsequent account lockout as I have shown and repeatedly referenced in this posting: https://forum.eset.com/topic/20215-ransomeware-adage/?do=findComment&comment=98416

Suspect it will be enabled by default; just like AMSI option is. Also appears it's probability parameters won't be configurable like Windows Defender's ATP can be. Again, no optional control given to the user who wishes more aggressive protection.

Eset has a overview video on its Augur machine learning technology here: https://www.youtube.com/watch?v=UBqbKAOWsc8