itman

Correct.

You should not use the Eset Connected Home feature if the Eset Network Protection profile is set to Public. You will receive an alert from the Eset GUI about this with the advice to switch to the Home/Office network profile. The reason for this alert is what you are experiencing; the population of all devices currently connected to the Hotel's router.

When connected to a public network such as the hotel wi-fi network you are using, it is imperative that Eset's Public network profile be used. Perform the "ipconfig" solution shown in this article: https://support.eset.com/en/kb3430-identical-ip-addresses-detected-in-network , and see if that resolves the duplicate IP address issue.

As far as Eset's detection of OneKey Optimizer, it appears the PUA detection is justified as noted here: https://tipsmake.com/instructions-for-removing-lse-on-lenovo-computers . In fact, this article classifies the source of this software, as a rootkit.

Eset periodically releases stand-alone utilities that scan for widely exploited vulnerabilities. Below I believe is the latest one developed: https://www.welivesecurity.com/2019/12/17/bluekeep-time-disconnect-rdp-internet/

You can use SysInternals Sigcheck utility for this: https://www.howtogeek.com/238765/how-to-check-for-dangerous-root-certificates-on-your-windows-pc/ I had previously read Matt Graeber's articles on this subject. I didn't know someone had posted a script on Github to automate the event logging. Neat! I requested Eset employ this sometime ago. Of course, that "fell on deaf ears." Also you would think Eset would have a utility by now to remove MBR malware or repair it since they don't protect against it getting infected.

It's back to detecting it at VT. My guess is they don't 100% trust Kaspersky's signatures. Yes - it was a generic detection, HEUR:Trojan.Script.SAgent.gen. Checkpoint later did an initial cloud sandbox analysis and removed it when nothing was detected. After that, they did a full lab sandbox analysis w/human review and decided it was malicious after all.

Also of note is @Tzatzhas posted the decrypted script code of this malware at the stackoverflow web site linked at the beginning of this thread. The problem is the code is so heavy obfuscated, it is impossible to determine exactly what it is doing. My best guess is my initial one; it's node.js based malware. What node.js is described here: https://www.tutorialspoint.com/nodejs/nodejs_introduction.htm A recent prevalent malware using node.js based malware is here: https://fossbytes.com/windows-pcs-affected-node-js-based-malware/ Of note was PowerShell was used in this current Javascript attack and I assume it was doing the same activities shown above.

So how can Eset and other AVs stop "living off the land" attacks like this? One way is to flag any MS signed LOL process at file creation time where file name doesn't match internal PE header name*; a clear indication of renaming activities. * List of abused MS living off the land processes is here: https://lolbas-project.github.io/#

Interesting how things work at VT. After the Microsoft detection, now 13/58 detecting at VT. In any case, this was a long time for a 0-day to be floating around in-the-wild after initial VT submission. Also of note is the stackoverflow posting is over a week old. It can be assumed the bugger has been in-the-wild for some time. It also shows that carefully crafted scripts can still bypass most AV detection.

It also appears this malware technique is far from new. Here's an article dating to 2016: https://www.securityweek.com/javascript-uses-aggressive-persistence-functions . Sound familiar?

Here's another interesting development. Eset, Kaspersky, and now Ikarus detect this keylogger at VT, but Checkpoint no longer does. Makes me wonder "if there is more to this than meets the eye."

I also strongly recommend you run an Eset scan. It by default will scan WMI and registry areas for malware entries. No guaranty it will find this bugger, but it's a start. The next step would be to run WMILister that can be downloaded here: https://www.xednaps.com/2018/05/06/wmilister/ . This utility was developed by Eset's @JamesR

OK. I looked at the Eset EFS documentation and its network protection contains all Endpoint features minus the Eset firewall. Relying on the Win firewall is a real bummer. I assume EFS must interface with the Win firewall in some way? The blocked inbound traffic from Win firewall is what shows in Eset Network Troubleshooting detail? And selecting "Unblock" there will create a Win firewall inbound rule for connection? I only see one block rule for UDP and IP. Should there not be three rules for each; one for each profile; domain, public, and private?

Refer to what I posted above: https://forum.eset.com/topic/29183-ids-use-over-70-of-cpu-too-many-attacks-detected/?do=findComment&comment=136864 . Again, by default Eset will only refer to Windows inbound firewall rules if the network activity being handled by existing Eset firewall rules has not been processed by one of these Eset rules. In this situation, the Eset firewall will pass control to the Windows firewall processing to determine if an existing allow inbound rule exists for the network activity. If such a rule exists, the Eset firewall will allow the inbound network traffic; otherwise the Eset firewall will block the inbound traffic. Bottom line - Only Windows inbound firewall rules are referenced but at no time does the Windows firewall itself block or allow any network activity. In the situation where the Windows firewall contains inbound block rules, the question is if the Eset firewall will process those rules or ignore them? My best guess is it ignores those rules since it is only looking for an allow rule for the network activity. The end result however is that the inbound network traffic is blocked; but always by the Eset firewall. Finally and important, note the following. Win firewall rules are stored in clear text in the Win registry. This makes them not only easy to read but also to be modified by malware. As such, the Eset option to use Win inbound allow firewall rules does pose a potential risk.