itman

Also verify that your current Eset version is 16.2.13. If not, force an Eset product update. There was an issue with the original 16.2 release in regards to handling inbound local subnet network traffic.

That should not be necessary and is potentially dangerous. If you reviewed my comments in the above linked posting I referred you to, Eset default rules are conditioned upon what firewall profile is used. As long as your Eset network connection/s is set to Private, it has the same effect as the rule you created and does so in a safe manner.

Yes. It removes the network connection.

Review my comment with suggested mitigation at the end of this thread: https://forum.eset.com/topic/37455-incoming-connections-on-private-trusted-network-profile-are-blocked/ . It appears to have worked for this poster.

Open this file: C:\Windows\System32\drivers\etc\hosts using notepad. Post a screen shot of what is contained within it.

I will make this comment. The web is full of postings of Google's associations to Voluum such as this one: https://doc.voluum.com/en/google_ads_traffic_source.html .It is reasonable to assume that Google via Chrome use is facilitating Voluum's ad activities tracking. As such, it is also reasonable that Chrome itself is thwarting ad blocker extension activity to block Voluum's ad tracking activities. What is odd is it appears you are the only one recently who has posted about Eset alerting about this add tracking activity. One reason might be is you state this is a new PC. If you purchased it from a retail manufacturer such as HP, these devices are known to have multiple factory installed crap software apps; some of those tracker based.

If you start to monitor IP addresses out of context to their source process, you could suffer a malware paranoid breakdown. Microsoft maintains IPv4/IPv6 backbone networks all over the world. This is the network traffic you are observing. As far as attempting to block all Windows telemetry network traffic, it is an effort in futility.

Searching the web, I couldn't find one reference to Eset being installed on this mod Win10/11 OS version. It does appear Kaspersky runs fine on it.

My take on this is the Eset scheduled/on-demand scan lockup will continue to manifest on an intermittent basis. The recommended Eset and MBAM exclusions for each other are to prevent real-time scanning conflicts. It can be assumed when Eset is running a full device scan, it is performing file access and control methods different from that performed in real-time scan mode.

Some driver updates and other legit app installs might cause the command window behavior you observed. Unless this command window behavior occurs repeatedly, I would not be overly concerned about it.

I am still of the opinion that one or more corrupted files exist in the C:\Windows\System32\ directory. Open an admin level command prompt window and enter the following; sfc /scannow When the scan completes which will take a while, you will be informed if corrupted /missing system files were discovered and if recovery of those were successful. If corrupted files were discovered and recovered, now repeat a scan of C:\Windows\System32\ directory. Hopefully, it will complete sucessfully.

You can also try this. Go to Chrome Store and install uBlock Origin extension. It's a free extension; This should silently block all ads using Voluum ad tracker. Make sure you close and then re-open Chrome after installing the extension. If for some reason an ad is not blocked on the source web page, uBlock deploys a TPL that will block any connection to the Voluum web site;

One other possible source for this Eset scan hang activity. Are using another AV or security product that has its real-time scanning component enabled? Doing so could be the source of this hang.

Do as @Marcos instructed. Uninstall at your existing Chrome extensions. If the Eset detection alerting stops, this confirms the activity is originating from an extension. Now one by one, reinstall your extensions. Wait a bit before installing a new extension to observe if Eset alerts again. Once Eset starts alerting again, that recently installed extension is the source of Eset alerting. Permanently uninstall that extension.

I just ran an on demand scan of; and the scan completed w/o issue. One possibility here is ctfmon.exe is corrupted and this is what is causing the scheduled scan to hang. Also, odd and notable is the posted scan log only shows 2748 objects were scanned. My log entry for the C:\Windows\System32\ directory alone shows 15701 objects scanned. This leads me to believe that the scan is not hanging on ctfmon.exe

This is an ad tracker related to voluum.com. Related forum posting here: https://forum.eset.com/topic/18146-how-to-check-eset-knowledgebase/ . Since it can do browser redirection, it can be used to redirect to a malicious web site. A more recent posting is here: https://forum.eset.com/topic/35040-clients-reporting-alerts-from-foxnewscom/#comment-163133 . In this case, the Eset detection source was from an ad displayed from a legit web site. If the Eset detection only occurs on certain web sites, either avoid those web sites or install a good ad blocking extension such as uBlock Origin.

I also found this Microsoft posting: https://answers.microsoft.com/en-us/windows/forum/all/cant-open-notepad-by-using-run-command/df43ca46-8450-47c7-ae33-446086a27502 indicating there is an issue when a Microsoft Store version of notepad is installed. The issue appears related to when notepad is run other than by direct invocation of it. This confirms what I posted above. Note that in Win 11, Microsoft replaced the classic notepad .exe in System32 directory with a MS Store version. It appears MS Store apps can't be run via PowerShell; Invoke-WmiMethod -Class Win32_Process -Name Create -ArgumentList method which makes sense since MS Store apps are run from an applicable service. Ref.: https://stackoverflow.com/questions/68907012/how-to-open-installed-microsoft-store-apps-from-powershell

The only automated way way retrieve Eset license key is to do so as described here: https://www.eset.com/us/support/lost-license/ using the e-mail address you used when you purchased Eset. As long as your current Eset license hasn't expired, you don't need the license key to update to the latest product version.

Eset Endpoint of Android mentions camera restrictions; https://help.eset.com/eesa/2/en-US/device_management.html?zoom_highlightsub=camera What is unclear is if this feature only exists in the managed versions of the product.

You posted in the Eset Mobile section of the forum. As such, I assumed you were referring to the Eset Mobile product. Are you referring to the desktop versions of Eset?

As shown below, my Eset HIPS rule to monitor child process startup from wmiprvse.exe does detect this PowerShell activity; -EDIT- I believe I know what may be the issue. You reference this in your posting; package Microsoft.WindowsNotepad_11.2306.15.0_x64__8wekyb3d8bbwe Now when I run; Invoke-WmiMethod -Class Win32_Process -Name Create -ArgumentList notepad.exe what is being run from being run from PowerShell via WMI is the default Win notepad.exe app; Did you update Win 10/11 to use notepad++ or download a notepad app from the Win Store app instead of the Win default notepad.exe? I believe this is why the detection of the wmiprvse.exe child process detection is failing for you. Also note that multiple unpatched vulnerabilities exist for notepad++: https://cybersecuritynews.com/multiple-notepad-flaw/ Use calc.exe in your test instead of notepad.exe

That error code is associated with a Win Update error. Refer to this article: https://learn.microsoft.com/en-us/answers/questions/1022056/error-0x80070005 ; It is possible that Microsoft Store is corrupted;

I missed this. Since its no longer being detected by Microsoft Defender, you should no longer be concerned about this. As far as Eset Online Scanner, just download it and run it if you want a second opinion scan.

You were already instructed to post in English! Just manually delete the two .sys Zemana driver files Microsoft Defender is detecting.

Verify that the URL you're arriving at is https://help.netflix.com/en/ . Your browser might be redirecting you to a phished web site.