itman

Oh, my. This is one reason why I am always hesitant about showing my HIPS rules when asked. You should review HIPS rule creation using Eset built-in online help on the subject. 1. For the first screen shot. change the Rule name prefix from "CameRule:" to "User rule:" All user created rules should use this prefix. No need to log any events since you already know you're blocking Edge start up. Click the "Next" button. 2. As far as the second screen - Source applications, you ignored my previously posted instructions. Click on the down arrow next to where "Specific applications" is displayed and select "All applications." Click the "Next" button. 3. Your next screen displayed at this point should be Application operations. Deselect "All application operations." Select "Start new application." Click the "Next" button. 4. The next screen displayed should be "Applications." Click on the down arrow next to where "All applications" is displayed and select "Specific applications." Click on the "Add" tab. Now enter the full path name for Edge there. Warning - verify that the EDGE .exe is actually stored at that location. Remember what I posted previously is for ver. 1809. Click on the "Finish" button. 5. Click on any subsequent "OK" button shown to save your newly created HIPS rule. 6. Reopen the HIPS section and verify that your rule was created as specified. Note this is my last instruction posting to you on how to create HIPS rules.

The Eset HIPS rule I monitor Edge execution with is shown below. Source applications setting for this rule is "All applications." Note: This rule works for me using Win 10 x(64) 1809. I haven't validated that this is so on 1903 since I haven't installed it yet.

I guess you do still do not understand my previous reply on this occurrence. An "in-the-wild" occurance of 10 statistically equates to a near zero probability of capture, analysis, and mitigation using existing capture methods. The Eset forum response as to "10 times" was in regards to the "in-the-wild" instance of the malware; not how many times an Eset product detected it. The OP's complaint at the time was that three days had elapsed since his posting about his detection and still no specific signature for it had been issued by Eset. I can't recollect if the OP actually official submitted the malware via Eset in-product method to do so. I just recently did so for a malware sample Eset wasn't detecting that also originated geographically from this region with a low "in-the-wild" count. Eset promptly responded with detection capability in a few hours; the exact elapsed time I don't know since I wasn't specifically monitoring for that.

Eset and other AV vendors get data from malware feeds and honeypots world-wide. The problem is that there are certain geographic areas such as China for example, where access to such data is restricted, filtered, or otherwise difficult to obtain in a timely fashion. Of course, malware dispersion and frequency is a major factor in detection by the aforementioned. If only a few samples exist in the wild, their targets are restricted to a specific area or business concern, etc., the likelihood of quick detection by existing monitoring methods are quite low.

Microsoft a while back got a lot of free press on how Windows Defender ATP was able to detect a a zero day malware. What Microsoft didn't publicly disclose at the time but did so later via a blog detailed analysis of the incident is the following. At least 6 WD ATP installations were infected by the malware prior to Azure AI cloud server analysis returned a positive identification of malware status. BTW - those infected installations were all located in a specific region within Russia. Bottom line - there is no such thing as 100% 0-day protection. If there was, that concern would in short order be the only security solution used and all other AV vendors would cease to exist.

This again shows your obvious disconnect with the "real malware world." Not the simulated one put forth in AV lab testing. Someone recently sent me a malware 0-day sample that only recently had been detected by 6 AV vendors at Virus Total. Half of those vendors specialize in malware detection circulated in the country where the malware had been discovered. The remaining detection vendors specialize in malware detection in the specific region. BTW - this malware specifically targeted Windows Defender and bypassed it. So if other AV solutions did not detect it, is that a missed detection since it was not a threat to them?

Again, this is for 2018. I posted a link above for the current 2019 test.

https://www.wilderssecurity.com/threads/how-do-i-stop-edge-from-automatically-starting.406358/

Here we go again. Windows Defender had a whopping 74 false positives in this test. Refer to the below screen shot that clearly shows that WD "block-at-first-sight" was set to aggressive setting level; basically blocking execution of any process without established reputation. Whereas this might be acceptable to advanced security level professionals, it certainly isn't so for the average user; especially for corp. users. -EDIT- Also 55 of the WD 74 false positives were user dependent block/allow action. It is a no-no to have the user decide if a process is malicious or not: Ref.: https://www.av-comparatives.org/tests/real-world-protection-test-february-may-2019/ Finally and most important, note the following. A-V C does not factor false positive scoring into its protection scores for its realtime tests as is done for its more comprehensive malware protection test series. Using the above false positive scoring criteria of 50% of user decisions are wrong, WD would have scored 27/752 or 96.4% placing it at the bottom of the protection scoring heap.

Refer to wilderssecurity.com that has multiple postings on this issue. In summary, Win 10 will try it's darnedest to keep Edge always running. Since I don't use Edge as my browser, I just block its start up with an Eset HIPS rule. This has resolved the issue for me.

Might be a problem with Win 10 1903. SysInspector works fine on Win 10 1809.

The Autoruns screen shot I posted just showed the current registry settings. These have to be added manually via Regedit or possible by Group Policy: This type of activity should be restricted via Group Policy setting.

A-V C is "very creative" when it comes to finding samples for its Realtime test series. It's not uncommon for it to slip in a few samples that are geographically restricted to one country and/or region within with an "in-the-wild" dispersion of < 10. The odds of encountering one these samples in close to zero.

I assume the reference is to this year's most recent A-V C Realtime test where Eset scored 98.4%; approximately the same as it has previously scored recently in this test series. If one has concerns about Eset, refer to this more comprehensive test series where over 10,000 malware samples are used: https://www.av-comparatives.org/tests/malware-protection-test-march-2019/ . Eset scored 99.86% for malware protection. Again, this is only one AV Lab's test; and test series for that lab. Refer to all the AV lab tests that Eset participates in and you will observe that Eset is a top scorer overall.

I did some testing a while back in regards to Edge and Eset B&PP. Now, it is possible things have changed since then. I set Edge to my default browser. Manually running Eset B&PP from the desktop opened Edge as a protected browser w/o issue. Whether Eset B&PP was fully functional in regards to keystroke protection and the like, I did not test for.

I use Thunderbird. I just checked my e-mail and had no problem connecting to AOL servers using IMAPS using EIS 12.1.34. I also run Win 10 x(64) 1809. Did you just recently upgrade to Win 10 x(64) 1903 on the device with T-Bird e-mail issues? Are the PCs w/o issues also running Win 10 x(64) 1903?

I use the registry debugger option for .exe's that can run from any directory. I set them to open as svchost.exe which immediately terminates: Eset HIP rule to block any write activity to C:\PROGRAM FILES\TIXAT\*.* would prevent anything being created in the folder. Eset HIPS rule to block any application startup in %homepath%\AppData\Roaming\*.* would prevent any program startup in that or any sub-directories. Also note this in regards to using variables in Eset HIPS rules: https://forum.eset.com/topic/15740-environment-variables-for-hips-rules/?do=findComment&comment=77806

It might have something to do with the status of the specific user account. For example, the "All Users" account is considered an operating system directory and is not shown by default in Windows Explorer. I suspect that "\\" use as far as the Eset HIPS goes might only work for directories that are not hidden by default. It also might not work based on user account status. For example if the user logs in as standard user, versus a local admin.

Since this is a new license, you might try this: https://www.eset.com/us/activate/ Appears this will create a new Eset account specific to this license. Also appears that a cd-key can be enter here since the web site refers to "retail code" that I assume is the cd-key.

Correct. Hopefully, this new decrypter will allow for previously encrypted files that were saved to now be decrypted. Unfortunately, concerns still don't backup their files in spite of the ransomware threat.

https://www.europol.europa.eu/newsroom/news/just-released-fourth-decryption-tool-neutralises-latest-version-of-gandcrab-ransomware

To back up a bit, one should never see an Eset alert about external IP address sourced port scanning if they are using a router that includes a firewall. If such an Eset alert presents, it is an indication that there is a problem with the router or its current setup configuration.

You're on your own with this device. Appears to be something directly shipped from China. Might be used primarily by U.K telecoms and the like.

Here's the user manual for the ZTE device: https://www.consumercellular.com/Assets/documents/Manuals/ZTE Mobile Hotspot User Guide.pdf . As I suspected, the default password is "Admin." Also make sure WPS has been set up properly which also requires a password.

This indicates that the ZTE Hotspot is properly configured to block any unsolicited incoming open port activity. One possibility is the ZTE device has been hacked and is allowing incoming port activity to your PC from a remote attacker. Note that GRC test would not detect this type of activity. Check if a password has been established for ZTE device. On many such devices, a default password of "admin" or the like is used. Create or change the existing password to a strong one. Then you will have to reset the ZTE Hotspot to reestablish its default values.