itman

When you create the firewall rule, do so for an existing signed app. The Publisher info should be auto copied into the rule. Now delete the data shown in the Application path field and save the rule. Finally, edit the rule again and verify nothing is shown in the Application path field. Also verify this rule proceeds in the Eset firewall rule set any other existing rules you created for Beijing Sogou Technology Development apps; better yet temporarily disable those rules. Now test. Note and important - if there are .exe's for apps you're using from Beijing Sogou Technology Development that are not signed, this Publisher based rule will not stop them from connecting to the Internet. You will have to create individual path based rules for those apps. -EDIT- If after creating the Publisher firewall rule as noted above the apps can still establish Internet connectivity, the following may be the cause; 1. Not all the apps are being signed using the same cert. of the app you used to create the Publisher based firewall rule. That is the Publisher name used on those apps is different from the one specified in the firewall rule you created. In this case, a unique firewall rule would have to created for each different Publisher name. 2. Internet connectivity for these Beijing Sogou Technology Development apps is being established by means other than by the app .exe itself; i.e. hidden proxy connection, etc.. In this case, you would have to use something like Wireshark to determine what is actually performing Internet connectivity.

I just duplicated your rule and it didn't prevent Firefox from establishing Internet connectivity; -EDIT- It work!s I forgot to enable child processes in the rule. I'll be damned ,,,,,,,,,,,

Err ........ none of your screen shots are shown.

One thing you could try is deleting your existing Eset Ethernet network connection. Upon exit from that Eset GUI section, Eset will create a new network connection. It is possible the existing network connection settings got hosed in the upgrade process. Upon creation of the new network connection, verify that its profile shows as Private for the Eset generated connection.

Similar posting here: https://www.reddit.com/r/Malware/comments/14nwzgh/rambler_ru_malware_hacking_accounts/?rdt=42159 . I would think it is common sense to stay away from Russian web sites these days. https://www.ipqualityscore.com/domain-reputation/rambler.ru

By doing this, there is no way to validate your claim or to perform forensic analysis as to what the malware is.

A further test shows that this is correct and Eset firewall Publisher setting only applies to signed .exe's. Therefore it's referring to cert. Company name. In other words, the firewall rule field is for code signed publishers only.

All Eset defined scans and what triggers them are shown in the below screen shot. Eset default established scans only run for a short period of time since they are only scanning select system areas that are known to hide malware;

I have discovered part of the issue. Publisher name is not always the same as the company name shown in the cert. of a signed .exe. Publisher name is shown by mouse hovering over the .exe which will show a Company name. That is the Publisher name that must be used. Also, not all .exe's are signed. For example, I use an old Seagate hard drive utility. Its .exe is signed and its cert. shows a company name of Seagate Technology LLC. However when I mouse hover over the .exe, the company name shown is Seagate Technology. Therefore, the name to be entered in the Publisher name of an Eset firewall rule is Seagate Technology. To further show the issue with Publisher names, there's an unsigned uninstaller in the same associated directory. Its publisher company name shows as Seagate Technology LLC. Therefore the question is how specific is Eset's matching of Publisher name in a firewall rule to the .exe's actual publisher name? All software I have used in the past that has Trusted Publisher detection capability always provided a list of Publisher's to select from with the capability to add new ones as needed.

What do you mean by "mini-Apps?" If they are not .exe's, there is no way to create a firewall rule for them per @Marcosstatement.

My final statement in this thread is since it appears your router is blocking UDP flood attacks adequately, I won't be concerned about the activity.

You might want to clarify this statement further; I interpreted this to mean no app with path specification is required when using publisher criteria.

Verify the "Apply to child processes" setting is enabled in the firewall rule. It is possible the main app is spawning a child process to perform network communication.

If this is an ASUS notebook/laptop, it most likely was installed at the factory. If Computrace was pre-installed by the PC vendor at the factory, in most cases it is not malware. Eset detects it as a PUA. You can exclude the detection per instruction here: https://support.eset.com/en/kb6567-you-receive-an-eset-uefi-detection. The only main issue I see in the log is Microsoft Security Center is not running. Running MBAM w/real-time scanning concurrent with Eset in the past might be the reason for this. You can manually start it by accessing its associated service and then manually starting the service. Verify thereafter that the service is running after system startup: Also, Windows Auto Updating service is not running for some reason.

Yes, it it normal. It means that Windows had a lock on the file and it can't be accessed by Eset. As far as UDP flooding router log entry, the source IP is 45.155.19.88. This appears to be a legit ISP/telecom, UAB Linama. If I were to take the log entry at face value, it is this ISP/telecom that is performing the UDP flood attack against your VPN provider using your router as a middle-man source. -EDIT- It appears this UAB Linama has subsidiaries in Italy. If this happens to be your ISP, it appears it is trying to bust your VPN connection via UDP flooding. If this is the case, you will have to ask them why they are performing this activity.

Here's a web site that lists routers with vulnerabilities: https://modemly.com/m1/pulse . If your router is shown to contain vulnerabilities, the latest firmware update to remove the vulnerability must be applied or the router replaced.

Try this: https://www.emsisoft.com/en/home/emergency-kit/ .

My advice is to uninstall MBAM or at the very least, disable its real-time protection. Then install Eset Internet Security or Smart Security Premium. Finally, monitor what network connections are being blocked by the Eset firewall, IDS, etc..

Looks like the router blocked the attack successfully. However the firewall log entry doesn't make sense to me since the destination IP address is 151.50.153.26? Your router might be hacked and has been enrolled as part of a botnet.

UDP flooding is a DDoS targeted attack usually performed against servers. Check your gateway/router's firewall log for evidence of such an attack.

If the Public firewall profile which is the default is being used, it is normal behavior to see inbound network traffic being blocked for the above processes and ports. If you only see this blocked inbound traffic upon return from Windows stand-by mode, it is expected behavior. For some unknown reason, the Eset firewall doesn't initialize fast enough upon return from Win stand-by mode resulting in the observed blocked activity.

The IP address is flagged by other AV solutions as hosting malware: https://www.virustotal.com/gui/ip-address/172.64.80.1 .

As far as what wmiprvse.exe child processes to monitor for; https://redcanary.com/threat-detection-report/techniques/windows-management-instrumentation/ Also, the article gives multiple examples of why WMIC execution should be blocked.

It's just not AI generated e-mails one has to be concerned about: https://www.darkreading.com/attacks-breaches/attackers-dangle-ai-based-facebook-ad-lures-to-take-over-business-accounts .

Your best way for tech support in the UK is via their Customer Support web page here: https://www.eset.com/uk/support/existing-customers/ . If you don't wish to use e-mail support, scroll to the bottom of the web page for their phone number.