itman

If its using UDP, the Eset network connections feature will not show the connection. It only shows TCP connections similar to many network activity monitors such as TCPView.

Did you reboot immediately after making the Autoruns changes? Also you posted that you are using Win 10 Enterprise. You sure you don't have any Group Policy rule set in regards to context menu changes? It sure appears to me that Windows is re-adding those menu items regardless of any deletion of same on your part. It also seems reasonable to me that Win 10 will not allow for Pin to Start menu to be disabled for example, since Win Store apps will auto add any new app to it.

Try using Autoruns to disable the Context Menu items. Screen shot given below. The advantage of Autoruns is it first, will modify the associated registry keys by simply unchecking the shown associated item. Next, the registry keys are only modified and not permanently deleted. Simply recheck marking the item reactivates the associated registry key. Note: when opening Autoruns for the first time, click on the Option tab and remove the checkmarks for "Hide Microsoft and Windows entries." This will ensure all Windows settings are shown. Also you will have to run Autoruns as admin to perform most registry modification activities.

I run as a limited admin and never created a standard user account, so that is not the culprit.

EIS ver. 12.0.31 I noticed something similar after my recent upgrade to Win 10 1809. When I was running 1803, I had the PC set to never enter standby mode. This was because my old hardware was not compatible with it if Core Isolation/Memory Integrity was enabled. I reenabled standby mode on 1809 since it won't let me enable Memory Integrity. My scheduled scan is set to run on Thursday at noon. Yesterday the scan did not run and the PC was in standby mode at that time. I also have the run as soon as possible if scan is missed option enabled. So I have now set it to run if does not do so after 4 hours from the scheduled time. So we'll wait and see what happens when the PC happens to be in sleep mode at scheduled scan time.

I was able to create a .iso using Media Creation Tool 1809 with Eset IS enabled w/o issue. I then used the disk based .iso to perform an in-place upgrade from 1803 to 1809 w/o issue. I additionally burned a bootable DVD from the .iso file using Windows DVD writer which successfully booted w/o issue. If your desire is to create a bootable 1809 ver. from the downloaded .iso to a USB drive, I would recommend Rufus 3.0 which can be downloaded here: https://rufus.ie/en_IE.html . Note: use default format options. Do not format the USB drive as NTFS.

No clue what the Windows alert is showing since it is not in English language. This is an English language forum.

Then why is the alert shown in red color? I have never seen that before as I recollect. Also my other questions; no action given and nothing quarantined? Because it's HTML code, Eset JavaScript scanner just blocks the code execution and that's it? -EDIT- Below is a screen shot of the actual Eset alert. Appears my above assumption of in-memory execution blocking is correct. Also, I guess the red color is now used to show an actual threat and orange/brown used for simulated malware detection? Details on alert color coding scheme in log files would be helpful in the Eset online help.

Are you stating that this stopped the inbound port 445 blocked connections you originally posted?

If this was the case, you should have been receiving HIPS alerts about modification of registry keys. Did you check your Eset HIPS log for entries related to your registry modification activities? If none of the prior apply, Eset is not preventing any of the registry key modifications you are performing.

@Marcos, suspect that the recent patch Microsoft issued for a JavaScript vulnerability which resulted in jscript.dll being modified might have busted Eset's javascript scanner in IE11.

Win 10 Home x(64) 1809, Internet Security 12.0.31 Never saw this one before. IE11 detected threat is shown in red color in the Eset associated log. Although no action appears to have occurred per log entry, I assume nothing malicious happened since the Eset alert stated threat was deleted. Note that nothing for this exists in Quarantine.

If a worm is able to install itself, the first thing it will try to do is connect outbound TCP port 445. Eset by default doesn't block outbound TCP port 445 since if your on a internal network and share files or printers, it is valid communication. I am not on a network and as such, don't share files or printers.

Try AdwCleaner. You can download it here: https://www.malwarebytes.com/adwcleaner/

You already posted a thread on this topic here: https://forum.eset.com/topic/17959-hank/

SSDP Eset firewall blocks are the norm. I just disabled the service in Windows since I was tired of my associated Win Event log filling up with blocked entries.

As far as the inbound port 445 traffic, your router should be blocking any unsolicited inbound traffic on that port. That means something on your PC is most likely sending outbound TCP traffic on port 445. This is a no-no in my security book but the Eset firewall by default rule will allow it. The culprit my best guess is the above noted process.

First up is the Microsoft Publication Service Device Host that is connecting to a Russian IP address per Robtex lookup: Per Microsoft: https://msdn.microsoft.com/en-us/library/bb756908.aspx/ Why that process is running let alone installed on an end user PC is beyond me.

Out of curiosity, post what the expanded link shows.

You might want to review this article on how Emotet is spread: https://www.us-cert.gov/ncas/alerts/TA18-201A Use an e-mail client and configure it to disable active content and not automatically open e-mail attachments. Also Eset will scan all the incoming e-mail prior to arrival on your hard disk. Or, go to the extreme and configure the e-mail client to only receive e-mail in text format such as I do.

According to this article: https://www.techspot.com/guides/1670-windows-right-click-menu/ , you're not deleting the entries from the correct registry keys:

It's a browser hijacker. Malwarebytes has an article on it here: https://blog.malwarebytes.com/puppum/2017/02/spigot-browser-hijackers/ . Look in Control Panel -> Programs and Features for anything installed that matches any of the names listed in the Cleaning section of the article.

Do a Google search using this: "access to xmlhttprequest at from origin has been blocked by cors policy". Appears it's a security issue with the web site you mentioned. Why Eset protocol filtering would trigger it, I really don't have a clue. You can always exclude that web site from protocol filtering at your own risk.

One other thing to check. Verify that Windows Defender - realtime - is disabled. Who know what it will do to third party AV submission if it is active. Likewise, verify no other third party AV or like software is installed and running in realtime mode.

LiveGrid feedback is enabled on my Win 10 Home x(64) 17763 build and has been so since upgrade to EIS 12.0.31. Since you reference a Win 10 Pro ver., the only thing I can think of is he set on some Group Policy setting that is possibly interfering with Eset outbound uploading of LiveGrid data.