itman

Do this. Temporarily, disable all the add-ons in Chrome. If you no longer receive any blocked Eset Network log entries related to runtnc.net, you have found the source. Then one by one enable each add-on monitoring for any blocked Network log entries until you find the exact source of the activity.

It's enabled by default. Look under Internet Protection section in the Eset GUI to verify that it is.

Suspect the POC wasn't publically disclosed. In any case, a CVE would not have been issued unless there was supporting data. As far as I am aware of, there haven't been any public disclosure on any exploiting. The main issue is both of these vulnerabilities only need low privledge status to exploit. https://nvd.nist.gov/vuln/detail/CVE-2019-5675 https://nvd.nist.gov/vuln/detail/CVE-2019-5677

For reference: I am posting this since I assume many Eset users are using older Nvidia chipset graphics cards. Nvidia pretty much treats older cards as legacy. As such, they are no longer offering driver updates for these cards; even for critical security vulnerabilities such as noted previously. For example, the last available driver for my card is R390 dated Mar., 2018. This vulnerability affects all drivers prior to R430. Since these are device driver vulnerabilities, I realize there is only so much Eset can do protection-wise against kernel mode vulnerabilities. If it can't protect against these, I guess its time to purchase a new graphics card.

If you click on the Eset Virusradar prevalence map, this malware is very much localized to Peru. This is one possible explanation for lack of detection by the other AV vendors listed at VirusTotal. The malware signature just hasn't been uploaded to the malware feed sources these other AV's use. Or since the malware is localized and incident occurances might be low, the other AV vendors consider its malware detection of low significance. Also this malware appears to be web site Javascript based. If the other AV solutions do not employ active browser based Javascript web filtering such as Eset does, it would be another explanation for lack of detection.

Kaspersky forum also has a posting on this: https://forum.kaspersky.com/index.php?/topic/398092-sarahruntc-blocked/&do=findComment&comment=2815790 . You really have to do a thorough "house cleaning" on your PC; especially in regards to any programs you have installed in the last few months from questionable sources and that you really don't need. Then proceed to doing likewise for temp directories and browser add-on and extensions. Whatever this bugger is, it appears to "fly under the detection radar" of most security software.

You did manually enter the the proxy server name and port? I believe that is what @Marcos did versus using the "Detect" option. Also the default setting in the Eset Proxy section is to "Use a direct connection" if proxy server is not available. As such, no necessary Eset server communication such as LiveGrid, sig. updates, etc. should have been blocked.

By any chance are you using FireFox? From the below screen shot, it appears it is also using a localhost proxy to filter traffic. Perhaps the uBlock Origin or Decentraleyes add ons do that. Don't know if that is a possible factor in this behavior. I've also disable WebRTC, RTCPeerConnection:

Here's another possibility, Your router has been hacked with DNSChanger malware. Go to this website: http://www.dcwg.org/detect/ and click on any of the links shown. I didn't see anything posted for Slovak. So you will have use an English based site or perhaps German, if you're fluent in that language. Actually, just use this site for a check: http://www.dns-ok.us/

Referring back to your log entries, they all appear to be redirects to Amazon servers in the U.S. associated with Massachusetts Institute of Technology. For example, selecting the first two entries yields this from Robtex site lookup: M.I.T. is one of the premier technical universities in the world. It also does a lot of computer research and does like activities for the U.S. government. If the Eset alerts for this only occur on certain web sites, I would stay away from those sites.

Note the following from the NOD32 knowledgebase article link I posted previously: However in Win 10, proxy settings can be set globally for all network adapters:

Try another browser for a while; IE11, Edge, or Firefox. If there no Eset log entries generated for Amanda runtnc, then this confirms the issue is most likely a malicious Chrome extension or the like. Uninstall Chrome and do as @Marcos just posted recently. -EDIT- Also reviewing your prior posting, I assume you reinstalled Chrome after you performed the Win 10 reset option. When a Win 10 reset is performed, all existing user accounts and their related files and registry entries are left intact. If you now get blocked Amanda runtnc activity when using other browsers than Chrome, we can assume the source is related to your local admin account directories or registry entries given that is how you log on to Win 10. Before proposing more radical solutions, I would give both Malwarebytes anti-malware and AdwCleaner a shot to see if they can remove this. Make sure to disable Malwarebytes realtime scanning so it doesn't conflict's with Eset's like protection. Then run a scan with both to see if they can find and remove this Amanda runtnc baloney. Also have you run an "in-depth" scan with Eset to see if it detects and removes this? This should have run automatically after Eset was reinstalled after you performed the Win 10 reset.

As note in step 1)., the original Eset detections should be shown in the Eset Filtered Web Sites log. If you performed the instructions given in step 2)., any resultant detections will be shown in entries contained in the Eset Network protection log.

I am wondering if you had previously set up a proxy setting in Windows, forgot about it, and it is overriding Eset's proxy settings?

I can confirm that it doesn't work. When I had a weekly scheduled scan configured and it was missed due to a PC sleep status, the scan did not start upon PC power up. Nor did it start at next PC boot time.

More details here: https://blog.malwarebytes.com/detections/riskware-dontstealoursoftware/

One Million Devices Open to Wormable Microsoft BlueKeep Flaw https://threatpost.com/one-million-devices-open-to-wormable-microsoft-bluekeep-flaw/145113/

Appears Eset is following Windows conventions here in that a weekly scan means once every 7 days. Also appears scheduled date is only applicable if PC is powered up always on the specified date/time to run the scheduled scan. The solution to me is for Eset to just create a Win Task Manager task for scheduled scans. Then users could edit that "to their heart's content."

Not really. It's a legit Win system process in Win XP: https://www.neuber.com/taskmanager/process/internat.exe.html If it is running from any location other than the System32 directory or on Win Vista+, then that process is suspect.

Appears to me all installed SSD/HDD drives spin up upon Eset GUI opening is by design. The Computer scan -> Advanced scan option for example allows for selection of drives/folders to scan. I also believe opening Windows Explorer will also cause all installed drives to spin up so that they can be displayed. -EDIT- You might consider unmounting/mounting drive option instead: https://www.wikihow.com/Unmount-a-Drive

According to the below, only IP addresses are allowed for a proxy server: https://help.eset.com/eav/12/en-US/idh_config_connection.html

Wind.exe is a PUA: https://www.bleepingcomputer.com/startups/wind.exe-6367.html My best guess is it was preloaded in the Hiren's boot cd .iso file in one of the included programs/utilities. -EDIT- I am assuming that your hard drive was disconnected when this scan was run?

Yes. But existing Eset default firewall rules do not monitor for any app execution. Again, all outbound program activity is allowed.

Not in this case. Adding the rule/s at the end of the existing rule set is fine.

I think this one needs a detailed investigation. Why? https://attackevals.mitre.org/evaluations/cybereason.1.apt3.1/procedures/credentialdumping