itman

STOP Ransomware Decryptor Released for 148 Variants https://www.bleepingcomputer.com/news/security/stop-ransomware-decryptor-released-for-148-variants/

You're clean. In this instance Eset detected a redirect to a malware web site via JavaScript HTML code associated with the web site you were viewing at the time.

Just noticed that my HIPS specified logged entries are now appearing in both the Eset Event and HIPS logs. Is this by design?

Post a few link references to what you used. We still have no idea what you are referring to in regards to this border issue and how it could be in any way related to the Eset software you have installed.

One other important part about ecmds.exe. It only runs at system startup time via a registry run key. Its sole purpose is to start the desktop toolbar icon Eset GUI and Windows Security Center processes. If it runs at any other time, it is most likely malware related. It would be an ideal malware target since it can run hidden.

I assume you have verified that ekrn.exe is indeed running and Eset is fully functional? Also did you verify that WD; i.e. MsMpEng.exe, is not running? Appears this is a "glitch" with EFS registration processing on Server 2019. Suggest you open an Eset support ticket.

In my case, the ecmds.exe activity started on 10/8 and stopped on 10/10 after I discovered the malware and removed it. The activity was completely random in nature occurring once a day at random intervals with multiple attempts each interval. The activity did not occur at boot time and was not related to any Windows Security Center initialization activities. For reference on Win 10, a code integrity violation occurs when an executable is compiled with Win 10 code integrity guard protection. This ensures that only code signed with a Microsoft code signing certificate can be injected. In my case, I believe the malware was most likely attempting to inject its malicious .dll into ecmds.exe. This would allow the malware to bypass any Eset detection since ecmds.exe is a trusted process to it. -EDIT- The preceding only applies to Windows system executables compiled with CGI protection. A code integrity violation for an app such as ecmds.exe would occur when the hash value of the .exe does not match that stored in the Eset code signing certificate associated with ecmds.exe. One possibility is in my case, the initial malware set a backdoor on my Win 10 installation. Whatever the malware was, it had to be quite old. Suspect all the backdoor did was periodically ping the attacker's C&C server to let it know the backdoor was alive and well. Also believe backdoor statuses are sold on the Dark web and automation is employed to periodically check their statuses. The one on my device suddenly "came alive" and was sold to the highest bidder. This does raise the question of if ecmds.exe is monitored by Eset's self-protection mechanism? It appears it is not. Of note is CGI bypasses have been demonstrated in the past.

Here's the story. It's also the reason why I haven't complained about Eset non-detection. Call this a classic example of "shooting yourself in the foot" by someone who should have known better. Recently I received my first every Win 10 blue screen during normal operation. Researching that it turned out one of the three HDD's in my tower case died. Luckily it wasn't the Win 10 boot drive but it was my largest, newest, and fastest SATA drive. Being extremely peeved over this, I rummaged around in my stack of old HDD's and found an old Western Digital SATA 3 GB drive that would be a suitable replacement. Couldn't remember when I last used the drive but its be years. Still livid, swapped out failed drive for the WD drive. Upon boot into Win 10, took a look on what was on the drive. Norton Ghost backup files. This means either it was used last on XP or the early days of Win 7. Promptly did a quick reformat of the drive, All was well after that or so I thought ........... My best guess at this point is there was some very nasty malware on the drive that activated upon install of that drive. Besides entrenching itself in the page file, it somehow found my router and reconfigured it to pass through mode to a gateway using DNS servers in Poland no less. This also explains why my IPv6 connections became borked at the same time. Now for the "shooting in the foot part." I should have used my SATA to USB converter to perform a full reformat of the drive via USB connection prior to installing it in the tower. This way at least Eset would have had a chance to scan the drive fully. Whether if Eset would have found MBR or rootkit malware is debatable, but it should be removed via a full reformat. Or better yet, using a solid disk wiper utility running from bootable DVD media.

Malwaretips.com has a removal guide on it dated 8/19: https://malwaretips.com/blogs/remove-newsmode-me/ . So its is far from being a recent event. It's adware. The problem is adware can serve up malicious ones. The best way to prevent crud like this is using a good ad blocker in your browser. What I am curious about is VT shows an Eset detection as "suspicious." Is this a new detection? If not, Eset should have thrown an alert upon attempted access to this domain. Was the alert ignored?

Appears to be a "quirk" of FireFox. Like warning does not appear in IE11. Believe FF will immediately try to connect to the URL specified when its opened. As posted above, the URL shown is not route-able.

This appears to be normal: https://support.eset.com/kb6063/?locale=en_EN&segment=home

The problem here is that WD's engine, MsMpEng.exe, shouldn't even be loading. It obviously has been loaded and additionally is detecting Eset as malware: None of the above sounds anywhere near normal Windows Security Center normal initialization processing as far as third party AV use goes. Microsoft just announced it is auto enabling WD's self-protection on all Win 10 versions. This also might apply to Win Server 2019. It also might be a factor of what is going on in regards to this very weird EFS and WD behavior. -EDIT- Another possibility is Eset's ELAM driver. If Windows detects this third party AV driver isn't loaded at boot time, it will enable both WD's and the third party AV real-time scanner running them concurrently.

That is the correct URL for U.S. based B&PP. Try the steps listed here: https://help.eset.com/eis/12/en-US/how_resolve_bp_browser_error.html

Again, B&PP only supports Chrome, FireFox, and IE11. If your current Win default browser is set to anything other than those noted, B&PP when accessed via desktop icon shortcut will fail. When you access a B&PP protected web site via FireFox, it will open that web site in B&PP mode within FireFox. In other words, Eset is using the current open browser as long as it's a supported browser. The purpose of the desktop B&PP icon is to allow the option to open the default browser in B&PP mode w/o predefined protected web site consideration.

Being in the pagefile, its almost impossible to access. Over the years have become fairly good at spotting pagefile malware. In this case it was fairly obvious since it increased my pagefile storage allocation 50% and kept it there. I just set the registry option to clear the pagefile at system shutdown time and the bugger was gone as evidenced by pagefile returning to normal allocation size.