itman

There were BlueTooth issues on Win 10 2004 that were "supposedly" fixed in the latest non-security cumulative update: https://www.bleepingcomputer.com/news/microsoft/microsoft-fixes-windows-10-2004-bluetooth-and-intel-gpu-issues/ I for one have not been offered this update via Win Updates. So don't know if it is being pushed to all installations.

"Time to take the bull by the horns" on this one. First the Microsoft reference in regards to AV code signing of their amsi.dll version: https://docs.microsoft.com/en-us/windows/win32/api/amsi/nn-amsi-iantimalwareprovider Next, "translation" of the above. Microsoft expects AV vendors to use an Authenticode + WHQL code signing certificate to sign their amsi.dll version. However, it provides a workaround to this for testing purposes only. When employed, Microsoft will throw a code integrity event because as far as they are concerned, the AV amsi.dll is not properly signed. Windows will also allow the AV vendor to inject their amsi.dll into a Win code integrity protected process. Eset uses their driver code signing certificate to sign eamsi.dll. This cert. is not a Authenticode + WHQL code signing certificate. Why Eset needs to use an Authenticode + WHQL code signing certificate to sign eamsi.dll Once done, then this registry validation can be enabled: 0x2 The check for Authenticode + WHQL signing is enabled. Why is this critical? Because without the validation, it is possible for an attacker to modifiy the registry to point to his malicious .dll instead of eamsi.dll. This will allow the attacker to insert his malicious .dll into any Windows code integrity protected process. It is also imperative if Authenticode + WHQL signing is enabled in the registry, this key, HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AMSI\FeatureBits, be protected by the AV vendor to prevent modification. I was going to write a POC about this a while back, but really got fed up with the excuses Eset was and continues to make on this issue.

I am going to wrap up my comments in this thread with the following. I regards to Eset new connection alert for your router. This is occurring because something changed its built-in MAC address. I doubt this is due to any anti-tracking mechanism built into the router. If this was the case, the MAC address changing would have been done once when the router fully initialized itself after setup or power up. This leaves the conclusion that any attacker has access to your router. I would start by performing a hard reset on the router and change its Admin interface password to strong one. If this issue still persists, try to upgrade the router's firmware to the latest version that exists from the manufacturer. If the router is provided by your ISP, contact them about this issue and see if they have a new firmware version for the router.

Yes. To be safe, first create a System Restore point. Then via Autoruns, delete those two scheduled task entries as shown from an article I posted a link to previously: http://sufistech.com/startupchecklibrary-dll-and-winscomrssrv-dll-error-on-windows-startup-fixed/

Err ........... It's a Windows Code Integrity error. Obviously the hash is valid, so it has to be a code signing certificate issue.

I edited my prior posting with what "Use Windows settings" does.

If this was the case, CHM would show dozens if not hundreds of IP addresses. So far, it appears Microsoft and Google IP address are being detected by CHM for what appear to be non-browser based outbound connections. Again, try changing Eset's "Protection type of new networks" setting shown in an above posting to "Use Windows settings." Believe this might stop the new connection alerts. Of note: https://help.eset.com/eis/13/en-US/idh_config_epfw_basic_group.html?idh_config_epfw_known_networks_group.html

Have you tried this? https://help.eset.com/eis/13/en-US/idh_page_settings_antivirus.html?idh_config_gamer.html

I assume your device is using a Wi-Fi connection? If so, perform the following. Check if "random MAC address in Windows 10 for Wi-Fi adapter" is enabled per shown in this article: https://winaero.com/blog/enable-random-mac-address-in-windows-10-for-wi-fi-adapter/ . If so, this might be an explanation for Eset's new connection alerts. If this setting is enabled and you desire to use this MAC randomizing feature, I would change Eset's "Protection type of new networks" setting shown in an above posting to "Use Windows settings." Suspect this will stop the Eset new connection alerts.

I believe this is a Microsoft "techno-babble" issue. These Win 10 non-security updates are classified in the Microsoft Update Catalog as Recommended updates versus Optional updates. However, Microsoft in its KB articles will note that they show under the Win 10 Update Settings section of Optional Updates. A true Optional update is Silverlight, etc..

Per Robtex lookup: Obviously this is an Edge browser/update connection. It really is a mystery why this type of normal outbound Internet traffic is being picked up as a new network device connection. One possibility is your prior postings show port 445 and SMB protocol is being used when these new network device connections appear. Use of that port/protocol should be restricted to local network connections only. What is becoming evident is normal Win outbound communication that should be using HTTP/S ports 80/443 is instead using SMB over TCP port 445. Eset interprets this as a new network connection resulting in a like alert. Are you using a proxy server or anything that is filtering Internet traffic using port 445?

Is 10.0.0.220 your router's IP address? That's what it looks like to me. Next, in regards to the MAC address of your router. I assume it is not 10-11-22-AB-CD-EF. It really appears that some type of MAC spoofing: https://en.wikipedia.org/wiki/MAC_spoofing is being performed against your router. This is what is triggered the Eset alert since as far as Eset is concerned, this is a new device to it. As the Wikipedia article notes: As such, it really is starting to look like you have a malicious driver installed. Additional possibilities are: The strong possibility is Win 10 is doing the above MAC address randomization and Eset is misidentifying this activity as a new network connection. BTW - this has nothing to do with Eset Home Connection Monitor per se. It's Eset Network Protection that is detecting a new network connection.

And just what are the details? Preferably shown in a screen shot.

If this is the alert: Click on "View device" to see device details about the new connection.

Also refer to this Eset CHM Knowledgebase FAQ: https://support.eset.com/en/kb6268-eset-connected-home-monitor-faq . Browse to this section, What do the icons on the devices in Connected Home Monitor mean?. What icon is showing for this device?

The first question is if Eset is showing a firewall alert when one of these connections is established? Try setting Eset new network detection to "Ask user" as shown below. Hopefully this might shed some light on the device being used.

First at the end of the video, it appears real-time protection is still disabled. Next, there was no attempt to update to latest ver. 13 release. My best guess is that would have failed. The crack version did do a product update, but it only received the lastest ver. 12 release it appears.

Is an Eset scan; e.g. startup, after update, or on demand, running when these file locks occur?

IP address 172.253.63.199 is Google: Pondering this a bit more, "my money is on" this is Bluetooth device connection. Eset HCM is detecting it whenever the device establishes a connection on your Wi-Fi router. When the device disconnects from your router, the connection disappears. The source device could be within your premises. Or if your Wi-Fi connection on the router is not properly secured, it can be any device within range of your Wi-Fi router such as your neighbors or a Wardriveby: https://en.wikipedia.org/wiki/Wardriving

You can download the portable version of this: https://www.nirsoft.net/utils/wireless_network_watcher.html i.e. ZIP file download, and see if the COMSYS device shows.

It also appears that the CIMSYS reference might be related to a driver for BlueTooth devices: https://escrutgers.com/cimsys-bluetooth-15/ In Windows, open Control Panel -> Hardware and Sound -> Devices and Printers and see if anything related to CIMSYS is shown. Likewise using Device Manager, look for unknown devices and what driver those devices are using.

Assumed here is the CIMSYS reference is to some type of network hardware device that existed at some time. As noted here: https://macaddress.webwat.ch/vendor/CIMSYS_Inc , there was a driver for whatever this is. Note that the driver download link is no longer valid. This does not however imply that somehow the driver is currently being used maliciously. You might want to check your Windows driver directory for any recent driver; i.e. .sys, file creations and anything related to CIMSYS.

Additional reference here: https://community.fing.com/discussion/2486/blocking-a-previously-blocked-device

As far as this goes: Refer to this thread: https://forum.netgate.com/topic/152536/arp-00-11-22-ab-cd-ee-is-using-my-ip-address/2

My best guess is this is related to Facebook tracking: https://www.henrirantanen.fi/2019/01/05/stop-facebook-tracking/ . Troublesome is the port 445 SMB2 protocol reference which could imply some type of worm use to harvest data from the entire network. The first step here is to see of port 445 is open on the router. Go here: https://www.grc.com/shieldsup and run the Common ports test. Report back on the status of port 445.