itman

The Eset HIPS rule I monitor Edge execution with is shown below. Source applications setting for this rule is "All applications."
Note: This rule works for me using Win 10 x(64) 1809. I haven't validated that this is so on 1903 since I haven't installed it yet.

 

https://www.wilderssecurity.com/threads/how-do-i-stop-edge-from-automatically-starting.406358/

I did some testing a while back in regards to Edge and Eset B&PP. Now, it is possible things have changed since then.
I set Edge to my default browser. Manually running Eset B&PP from the desktop opened Edge as a protected browser w/o issue. Whether Eset B&PP was fully functional in regards to keystroke protection and the like, I did not test for.

Here we go again. Windows Defender had a whopping 74 false positives in this test. Refer to the below screen shot that clearly shows that WD "block-at-first-sight" was set to aggressive setting level; basically blocking execution of any process without established reputation. Whereas this might be acceptable to advanced security level professionals, it certainly isn't so for the average user; especially for corp. users.
 
-EDIT- Also 55 of the WD 74 false positives were user dependent block/allow action. It is a no-no to have the user decide if a process is malicious or not:

Ref.: https://www.av-comparatives.org/tests/real-world-protection-test-february-may-2019/
Finally and most important, note the following. A-V C does not factor false positive scoring into its protection scores for its realtime tests as is done for its more comprehensive malware protection test series. Using the above false positive scoring criteria of 50% of user decisions are wrong, WD would have scored 27/752 or 96.4% placing it at the bottom of the protection scoring heap.

Refer to wilderssecurity.com that has multiple postings on this issue.
In summary, Win 10 will try it's darnedest to keep Edge always running. Since I don't use Edge as my browser, I just block its start up with an Eset HIPS rule. This has resolved the issue for me.

A-V C is "very creative" when it comes to finding samples for its Realtime test series. It's not uncommon for it to slip in a few samples that are geographically restricted to one country and/or region within with an "in-the-wild" dispersion of < 10. The odds of encountering one these samples in close to zero.

I assume the reference is to this year's most recent A-V C Realtime test where Eset scored 98.4%; approximately the same as it has previously scored recently in this test series.
If one has concerns about Eset, refer to this more comprehensive test series where over 10,000 malware samples are used: https://www.av-comparatives.org/tests/malware-protection-test-march-2019/ . Eset scored 99.86% for malware protection.
Again, this is only one AV Lab's test; and test series for that lab. Refer to all the AV lab tests that Eset participates in and you will observe that Eset is a top scorer overall.

https://forums.geforce.com/default/topic/1056140/geforce-drivers/defeating-nvidias-telemetry/post/5830317/#5830317
Personally, I just disable the Nvidia Telemetry service and leave it at that. I haven't seen any outbound Nvidia traffic after that. I also can't vouche the the above rundll32 method since I never used it.
As far as blocking GeForce Experience outbound activity, the best way to stop it is never install it or uninstall it. Also according to this article, nothing Nvidia Telemetry or Geforce Experience does is supposedly nefarious: https://www.howtogeek.com/280101/relax-nvidias-telemetry-didnt-just-start-spying-on-you/

Since it appears you want to still use GeForce and not uninstall it, you can download the latest non-vulnerable update here: https://www.geforce.com/geforce-experience/download . That should eliminate the update alert you have been receiving.
As far as your other nVidia drivers, you have a problem. For any drivers less that release 390.65, you're vulnerable to the Spectre and Meldown vulnerablities noted here: https://nvidia.custhelp.com/app/answers/detail/a_id/4611/~/security-bulletin%3A-nvidia-driver-security-updates-for-cpu-speculative-side . I would serious considering updating your graphics card.

To begin with, there is a serious security vulnerability in regards to Nvidia GeForce versions prior to 3.18. You can read about that here: https://www.bleepingcomputer.com/news/security/nvidia-patches-high-severity-geforce-experience-vulnerability
The article also refers to Nvidia driver vulnerabilities that have been recently discovered. So you have to verify if your Nvidia drivers have been have recently updated.
As far as your screen shot goes, your Nvidia software is indicating that a GeForce software update is available. In light of the above posted, you probably want to perform the update. BTW - you don't need the GeForce software for your Nvidia drivers to function properly. It's primary purpose is to inform you that NVidia driver updates are available. It can be uninstalled via Control Panel -> Programs option.

Guess I am not following you on this one. Each time you export your settings, a new .xml file is created. Just import the latest .xml file you created.

Some "free press" courtesy of bleepingcomputer.com:
Windows 10 Apps Hit by Malicious Ads that Blockers Won't Stop
https://www.bleepingcomputer.com/news/security/windows-10-apps-hit-by-malicious-ads-that-blockers-wont-stop/

See this thread: https://forum.eset.com/topic/19081-jsspigotb/ . Also refer to the Eset knowledgebase article link I posted in the thread.

Some "free press" courtesy of bleepingcomputer.com:
Windows 10 Apps Hit by Malicious Ads that Blockers Won't Stop
https://www.bleepingcomputer.com/news/security/windows-10-apps-hit-by-malicious-ads-that-blockers-wont-stop/

You might want to refer to this latest A-V Comparatives Endpoint test and resign yourself to living with the issue of high false positives as far as TrendMicro is concerned: https://www.av-comparatives.org/tests/business-security-test-march-april-2019-factsheet/

Some further info on Telnet. Port 23 is not the only port used. Port 107 is used by Remote Telnet.
Also there is a way to shut down all Telnet activity using the Eset firewall. You would have to create a firewall rule to block all inbound and outbound activity specifying the protocol as "Custom" and the protocol number as 240 - 255. In other words, 15 firewall rules would be needed since the Eset firewall only also one protocol number to be specified per firewall rule.
Ref.: http://www.networksorcery.com/enp/protocol/telnet.htm

To be 100% accurate in regards to telnet is the following. The telnet client is not installed on Win 10 by default: https://www.rootusers.com/how-to-enable-the-telnet-client-in-windows-10/ . As noted in the article if the telnet client is installed, any port can be used by it; not just port 23.
When router's reference telnet, they are just referring to its default use of port 23. Disabling the telnet option on the router is just blocking all inbound/outbound WAN side port 23 TCP/UDP traffic to/from the router.
When the router is set to bridge mode, you are  instructing the router to pass all inbound and outbound traffic through the WAN side of the router. All firewall, IDS, and protocol filtering methods on the router are disabled. Additionally, both NAT and stateful transmission detection are also disabled on the router. As such, you are now relying 100% on Eset's firewall for port 23 protection. Whereas Eset's firewall will block an unsolicited inbound port 23 traffic by default, such is not the case for any outbound port 23 traffic. By default, Eset allows all outbound traffic.

Referring to the first two postings in this thread, browser ad and JavaScript blocking extensions and the like would not have prevented this activity.
It appears something was installed manually. It could have be standalone software. If it was then the following were applicable:
1. The software was installed prior to Eset being installed.
2. Eset's PUA protection was/is not enabled.
3. Eset's PUA detection was ignored and the poster allowed the software installation.
Another possibility is the poster either explicitly or inadvertently installed a browser extension that contains the javacript code being detected.

I would start by running Eset's AV Remover tool: https://support.eset.com/kb3527/ to verify that no other AV products are installed and to remove them. If this tool can't remove them, then you will have to do so manually. Reboot your PC.
Now try to install Eset Smart Security again. If it again hangs during the installation or doesn't install successfully, then do the following.
Download and run Eset Installation Fixer: https://support.eset.com/kb3544/?locale=en_US&viewlocale=en_US . Reboot. Now try to install Eset Smart Security again.

Also McAfee has an article on how to reset the affected registry key back to IMAGE_STATE_COMPLETE. Note that by doing so is at your own risk since the IMAGE_STATE_UNDEPLOYABLE status indicates an unsuccessful OS deployment:
https://service.mcafee.com/webcenter/portal/oracle/webcenter/page/scopedMD/s55728c97_466d_4ddb_952d_05484ea932c6/Page29.jspx?wc.contextURL=%2Fspaces%2Fcp&locale=en-US&articleId=TS102833&_afrLoop=1087443705220366&leftWidth=0%&showFooter=false&showHeader=false&rightWidth=0%&centerWidth=100%#!%40%40%3FshowFooter%3Dfalse%26locale%3Den-US%26_afrLoop%3D1087443705220366%26articleId%3DTS102833%26leftWidth%3D0%25%26showHeader%3Dfalse%26wc.contextURL%3D%2Fspaces%2Fcp%26rightWidth%3D0%25%26centerWidth%3D100%25%26_adf.ctrl-state%3Dugptswwfq_9 
I suspect the OOBE issue that affects McAfee successful installation might also be affecting Eset successful installation/operation.

Files were encrypted by Filecoder.LockedFile. According to the logs, there were about 170,000 failed attempts to log in via RDP as "administrator" and alike in approx. one day when the encryption occurred. Also an older version of EFSW 6.5 without Ransomware shield was installed.
The OP was informed and improvements in protection were suggested.

Let's analyze this in detail.
First screen shot is ThreatSense settings for Web Access protection. The important setting to note is "Advanced heuristics/DNA signatures":

 
The next two screen shots are for Realtime protection. The important thing to note is the omission of the "Advanced heuristics/DNA signatures" protection on base ThreatSense settings:

And for file creation and execution,  advanced heuristics are performed for both. Of note is the absence of any reference to "DNA signatures":

 
From the above, we can conclude that "DNA signature" usage is only used by default by Web Access protection. And that is indeed an issue. The solution to me appears to enable "Advanced heuristics/DNA signatures" scanning option for Realtime time protection. I assume that is disabled by default for system performance reasons.
Also this issue doesn't just apply to FireFox Send delivered files. What about anything not Internet downloaded such as files on USB media?

This just started today. All I see is myself?

Both ZoneAlarm and CyberSight state that their compatible with all AV solutions.
Since ZoneAlarm offers a 30 day free trial and CyberSight is freeware, best approach is to run Eset IS with either one during the 30 day period and monitor for any conflicts. If conflicts arise, most can probably be resolved by adding either product's main executable as an exception in Eset's Realtime and possibly the new Deep Behavior Inspection protection.
Note that the most important point in evaluating any security software is how effective is its self-protection mechanism. If ransomware can disable ZoneAlarm or CyberSight, they are worthless for all practical purposes. Worse is if malware can inject code into same. Since you may have created an exception in Eset for the product, malware running from same can run unabated. 

What I will say about this incident is based on @TomFace connection to an Israeli server, your ISP is suspect at this point. Appears it might be performing insecure routing through the Internet backbone. However, more proof will be needed in this regard.