itman

It appears to me that the Eset firewall can't process the "(" and ")" symbols in the file name; i.e. LenovoVantage-(VantageCoreAddin).exe. I have never seen a file name using those symbols although they are allowable characters.

For those who haven't noticed it, I observed this morning that the ver. 16.2.11 of consumer products firewall rules were auto updated. The "Allow all connections with computer" rule plus the DHCP rules were changed to allow inbound/outbound network traffic from the previous only allow inbound network traffic. I assume the same rule changes were also made on EES.

Multiple network connections show on my ver. 16.2.11 installation per the the below screen shot; Also, care needs to be taken when removing network connections. For example, my second network connection is only used at system startup time with Eset auto switching to the first network connection shortly thereafter. Finally, ver. 16.2.11 changed how network connections are displayed and modified. The only way to view existing network connections is via the above Network connections option. They are no longer viewable via Network access protection section in Advanced Setup mode. Further, settings for any network connection setup automatically by Eset are no longer modifiable other than for Connection profile type; why Eset did so is beyond me. It is possible to set up a new network connection manually but you have to create a new Network connection profile to do so.

The alert shown is originating from Eset's Web Access protection. It is an IP address blacklist detection as confirmed by VirusTotal detection; If you only receive the Eset alert when you manually access some web site, do not continue to access this web site. Otherwise, my best guess at this point is you have a malicious extension installed in Chrome and it is trying to connect to this IP address. The extension must be removed to stop this Eset alert. Your PC is protected since Eset blocked access to the malicious remote connection. -EDIT- If this Eset alert appears w/o any browser open, have you recently installed a free or cracked game download? A number of these contain malware in the installer which will download additional malware from a compromised Google cloud store server. Open Eset "Filtered websites" log and search for entries related to this 104.155.138.21 blocked IP address. Open one of those entries and it will show what application was the source of the IP address traffic.

Post a screen shot of the Eset firewall alert you are receiving.

I can't access this URL in Firefox. It states it can't find this domain.

I would submit C:\Program Files\WinRar\WinRar.exe to VirusTotal for a scan and see if any of its scanners detect anything. It spawned the malicious .exe in the %Temp% directory.

Refer to this posting: https://forum.eset.com/topic/37260-issues-with-1012046-update/?do=findComment&comment=170107 for creating an outbound rule to allow all outbound network traffic for "Allow all traffic within the computer." Hopefully, that will resolve the VM network localhost connectivity issue. As far as all the other network traffic being blocked, I suggest you remove all existing network connections that ver. 16.2 created. Upon exiting from that Eset GUI section, Eset network processing will create new network connection/s. Now test to determine full network connectivity has been resolved.

Yes.

What Win OS version do you have installed?

Did you try this; as noted in the Eset KB2289 article?

Also of note is this article: https://helpcenter.veeam.com/docs/agentforwindows/userguide/ports.html?ver=60 that shows all protocols and ports use by Veeam Agent Components. No where is mentioned localhost communication. One possible reason for lack of this is the Win firewall does not monitor localhost communication. I would verify with Veeam that the localhost traffic observed is normal and legit.

Sucuri has an article on how clean a web site of magneto malware: https://sucuri.net/guides/how-to-clean-hacked-magento/

The real question is why other previous in/out firewall rules were likewise changed? As far as I am concerned, the previous in/out "Allow all traffic within the computer" rule was more secure. It restricted this network traffic to local subnet addresses only for the default Automatic profile which by default, allows all outbound traffic. Note that there are documented malware that deploy a hidden localhost proxy that allows communication to their C&C attack server.

Sucuri found magneto card stealing malware in multiple locations on the web site: https://sitecheck.sucuri.net/results/https/zespa.fr .

It's not only game installer downloads to be leery of these days, but any download from other than direct URL access to the author's web site; https://thehackernews.com/2023/07/fruity-trojan-uses-deceptive-software.html This puppy is using Python and deploying process doppelgänging, https://attack.mitre.org/techniques/T1055/013/ , to avoid AV detection.

There also been forum postings in regards to ESET Endpoint 10.1.2046 that is not referring in Win firewall inbound rules as it should under Eset default firewall setting. This also might be occurring in ESSP/EIS ver. 16.2.21.

Eset ver. 16.2.21 made changes to certain default firewall rules. One of those changes was the "Allow all traffic within the computer" rule. Previous to ver. 16.2.21, the rule was for both inbound and outbound network traffic. Now it applies to only inbound network traffic. My suspicion is the firewall is not allowing outbound localhost traffic because Eset's firewall internal default processing as far as localhost addresses is not being covered by its default processing to allow all outbound traffic. Another posting here about firewall localhost issue: https://forum.eset.com/topic/37252-only-localhost-ip-blocked/

This is starting to appear the recommended fix since you are not the first to post about issues with the ver. 16.2.11 firewall processing. However, in the other incidents, uninstalling and reinstalling ver, 16.2.11 fixed their issues.

Since this is a Win service, have you tried creating an Eset firewall Allow In rule for C:\Windows\System32\svchost.exe and then selecting the applicable Veeam Agent service? I assume you want this service to always have Internet connectivity.

As far as the ASAR mitigations given in this article: https://taggart-tech.com/quasar-electron/ ; The problem with Electron is it has the capability to associate any file extension to it: https://blog.theodo.com/2015/12/link-files-to-application-in-windows/ . Also, refer back to RabbitCheecks.exe analysis at VT: https://www.virustotal.com/gui/file/d4524f9c529ffd945c789b8379116b8bb6227de2ffa045729f47a4131f3d5cfb/behavior and you will not find any reference to a .asar being created on the disk. What you will observe is a number of modified .7z filles. -EDIT- I rechecked the Hybrid-Analysis report of RabbitCheecks.exe and it does show a .asar file being created; Again, a hacked version of the 7-zip plug-in was deployed in these installers and the only AV solution to id it as such was CloudStrike.

I did some more testing today and here's the findings. When the DHCPv6 lease extension occurs, only a single network outbound DHCPv6 request occurs. My assumption is Eset firewall is triggering off of an inbound DHCPv6 request to realize a DHCPv6 change has occurred. But the real question here is why DHCPv6 activity in any form can terminate ekrn.exe monitoring of UDPv6 traffic?

As far as ASAR files go, here's an interesting read; https://taggart-tech.com/quasar-electron/

I set Eset firewall filtering mode to Interactive and received the action popup as expected on ESSP ver. 16.2.11; Are you running Eset Internet Security?

Eset Uninstaller tool must be run in Win Safe mode. Did you do so?