itman

Hum ........ Not sure "You're out of the woods" on this browser and also Waterfox. To begin, other things need to be in place for Eset's SSL/TLS browser protcol scanning to work properly. The browser must either use the Windows root CA store where Eset's root certificate is installed by default at installation time, or Eset's root certificate must be added to the browser's root CA store. The later is done by Eset automatically for browser's it officially supports; Chrome, Firefox. IE11, Edge, and possibly Opera use the Win root CA store. The fact that you were able to pass the AMTSO phishing test by force enabling Eset SSL/TLS scanning for both, does not imply that it is functioning properly on both Brave and WaterFox.

Very strange behavior. I use the Network Trouble Shooting feature all the time. In fact, as recently as last weekend. This last instance was because of some old deeply embedded malware that appears to related to a drive I have Win 7 installed on. I haven't accessed this drive directly in years but running a WD periodic scan must have triggered it somehow. It was a pretty ugly event with my assumption that my Win 10 1809 build on the same device was totally trashed. Turns out luckily it wasn't. Appears the malware injected explorer.exe but couldn't run properly from there on Win 10. Anyway, prior to this I had created Eset firewall rules to monitor all outbound explorer.exe traffic. As I knew from years ago past experience with this malware, it attempted to connect to an IP address in Taiwan via port 21 that serves up the Conifiker worm of all things. Anyway when the Eset firewall alert appeared, I blocked it and had it create a firewall rule to block port 21 outbound traffic from explorer.exe. Thereafter, I monitored for any like outbound traffic using Eset's Network Wizard until the previous block connections shown timed out. From everything I have observed, Eset Network Troubleshooter is working w/o issue.

As far as what systemrequirementslab.com does: And one example of negative effects from using the site: Ref.: https://www.reddit.com/r/lowspecgamer/comments/8jbwex/can_you_run_it_a_site_that_will_check_you_systems/

As far as I am aware of Eset IS,SS, and NOD32 Web Access protection filters all port 80 and 443 communication. It is therefore not restricted by browser used. Proof of this can be had by opening the Web and Email section in Advanced setup option of the Eset GUI. Then open the List of SSL/TLS filtered applications section. You will observed a number of apps listed that are not browser related. What specific problems are you having with Anti-phishing protection?

Assuming you have configured IE11 for max. protections including and most important EPM, AppContainer will protect you against most browser based non-user initiated downloaded malware. There is also the "security through obscurity" factor. Since IE11 usage these days is in the single digit category, malware authors have turned their attention to Chrome and FireFox. Also although IE11 in its heyday topped the vulnerability charts, most of those have been resolved. Forget IE11 SmartScreen as a protection mechanism except for possibly unknown executables. I used IE11 for years and during that time had no more than two or three alerts from it. UAC at maximum level is your biggest native protection since it will prevent most but not all hidden privileged escalation attempts. Your biggest risks on these PCs are user initiated downloads and in-browser based Javascript malware such as coin miners. MSE PUA protection is for all practical purposes non-existent. Only recently in Windows Defender has it become reasonably effective and only if manually enabled. I certainly woundn't use these PCs for any e-commerce activities since AppContainer won't prevent IE11 banking Trojan web site injection. Finally, MSE lacking any web filtering capability will only increase the odds of being adversely impacted by web site/server in-browser based malware. -EDIT- Go to this web site using one of your Win7/IE11/MSE PCs and see what the results are in regards to coin miner protection: https://cryptojackingtest.com/ . Note: if SmartScreen blocks access to the site, that's a false detection.

👍

Site looks clean to me. I checked with URLVoid and did a new scan at Quttera.

Blanket statements like this are meaningless without a frame of reference. For example, none of those devices are used on a daily basis for Internet activities via browser. Do those devices employ supplemental security protection? If used for browser activities are those restricted to accessing know safe web sites? Etc., etc. Overall, consider yourself very lucky. There is no way that using Win 7 and MSE equates to the protection provided by Win 10 and Windows Defender.

As far as Eset's 0-day detection capability goes, it is often overlooked that they have one of the best malware research organizations in the world. Case in point. Microsoft published an article here: https://www.microsoft.com/security/blog/2018/07/02/taking-apart-a-double-zero-day-sample-discovered-in-joint-hunt-with-eset/ where they were alerted to a double 0-day malware instance courtesy of Eset's malware research group.

I never attempted to block Cortana using Eset HIPS. I use O&O ShutUp 10 to "harness" its activities.

Since you seem fixated on this point, we are referring to an incident that happened almost 2 years ago. I have previously posted the same did not occur with a malware submission I recently submitted. So move on to something else.

More details needed. Are you using the Win Store app? Or, did you download from Google store and it installed as an extension in Chrome for example.

I just checked the VirusRadar database and the signature for this variant was created on 7/28/2017. It really appears what happened in this instance was the malware was not properly submitted for analysis. This is what caused the unusually long delay in signature creation. One other thing that should be mentioned here. It is imperative that LiveGrid settings allow for submission of suspicious files for analysis. This is one of the primary methods Eset captures "in-the-wild" malware originating from Eset software installations.

Background For some time, there have been forum postings regarding Eset's scoring in this test series. This has resulted in long and oftentimes mindless discussions on this issue. I am sure Eset has better use for its forum disk space. Solution Microsoft a while back adopted the use of published AV lab "transparency" reports to respond to its scoring in select AV lab tests. Their reports reflect typical Microsoft verbose detailing as only a concern with the resources it has to allocate to such an undertaking. Here's an example of a transparency report: https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RE27O5A?ocid=cx-docs-avreports . I think it would be sufficient that Eset's report simply state the samples missed along with a brief explanation as to the cause for non-detection and corrective action implemented. Of course, there should be verbiage provided if Eset disputed the AV lab non-detection finding.

@Marcos, care to clarify the above comment you made?

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.