itman

Submit parsifal.dll to VirusTotal and see if anyone else has issues with the file.

Refer to this thread: https://forum.eset.com/topic/29087-club-pogo-and-selective-games-blocked-by-eset/ . Appears to be related to games with Pogo being the main culprit.

The point to note here is if a downgrade from DoH to DNS is occurring, it is being done on the browser server. As such, it is physically impossible for Eset to inspect that DNS traffic.

Scholarly article on why you don't want to use DoH; https://www.usenix.org/system/files/foci20-paper-huang.pdf

As far if DoH should be used at all, this article is worth a read: https://flashstart.com/dns-over-https/ . I again reiterate, both Win and browser based DoH are now removed from my PC.

Another interesting observation. Excluding the browser DoH factor, the TLD is not detected by Eset blacklist used by Sucuri: https://sitecheck.sucuri.net/results/crackingpatching.com . Could it be that since the site is using a trusted cert., scanning of it is being ignored?

Eset supports older Intel processors. The initial list is shown in this Eset KB article: https://support.eset.com/en/kb8336-intel-threat-detection-technology-tdt-supported-processors . This list dates to 2022 and additional later dated processors have been added.

Malware still on web site. Refer to this Sururi report: https://sitecheck.sucuri.net/results/spzoz-warka.pl .

Have you tried Win10Pcap: https://www.win10pcap.org/ ?

I can access the web site w/o any Eset alert.

The point of Andy Full's test is Eset should be VBS protecting its critical drivers; The problem is many older PCs don't meet the minimum requirements for VBS protection: https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-vbs However, the main protection mechanism of VBS is HVCI - Memory Integrity which my ancient PC supports;

https://malwaretips.com/threads/esets-challenge.129485/post-1078600 I have had Eset HIPS configured to ask mode for cmd.exe child process startup for some time.

Confirmed. DoH does not prevent a DNS rebind attack; https://research.nccgroup.com/2020/03/30/impact-of-dns-over-https-doh-on-dns-rebinding-attacks/

It gets better ....... This domain is using Cloudflare DNS servers;

I am also wondering if we are looking at exploitation of a new IPv6 DoH DNS rebind vulnerability similar to the IPv4 one noted here; Now my ISP uses 6rd tunneling on its network. This is the reverse of the above in that all IPv6 traffic is tunneled through an IPv4 connection via use of a tunnel broker ISP. Let's again review what happens when a connection is made to https://crackingpatching.com/2017/03/avast-pro-antivirus-internet-security-premier-17-2-3419-0-keys.html with DoH enabled in Firefox; Eset Filtered Web Site log shows it blocked access; Time;URL;Status;Detection;Application;User;IP address;Hash 3/9/2024 11:43:27 AM;https://crackingpatching.com;Blocked;Internal blacklist;C:\Program Files\Mozilla Firefox\firefox.exe;xxxxx;104.21.43.46;F736FE1F2C3ACB8E53F9E22EFE632D18B65DECCB Time;URL;Status;Detection;Application;User;IP address;Hash 3/9/2024 11:43:28 AM;https://accounts.google.com/o/oauth2/postmessageRelay?parent=https://crackingpatching.com&jsh=m;/_/scs/abc-static/_/js/k=gapi.lb.en.8uXxGUoumbY.O/d=1/rs=AHpOoo96qx3mL4tzGUOa-0q0udyPRqEAoA/m=__features__;Blocked;Internal blacklist;C:\Program Files\Mozilla Firefox\firefox.exe;xxxxx;2607:f8b0:4023:140d::54;F736FE1F2C3ACB8E53F9E22EFE632D18B65DECCB Notice first two connections are made with the first connection in IPv4 to the TLD. Eset doesn't alert or block the connection in this instance. However with DoH disabled in Firefox, only one connection is being made/logged. It is to the TLD. Most important it is via IPv6. Eset alerts and blocks this connection; Time;URL;Status;Detection;Application;User;IP address;Hash 3/11/2024 11:25:41 AM;https://crackingpatching.com;Blocked;Internal blacklist;C:\Program Files\Mozilla Firefox\firefox.exe;xxxxxxxx;2606:4700:3034::6815:2b2e;F736FE1F2C3ACB8E53F9E22EFE632D18B65DECCB Also significant is that the URL shown on the Eset block alert is the sub-domain; https://crackingpatching.com/2017/03/avast-pro-antivirus-internet-security-premier-17-2-3419-0-keys.html I have seen enough that I am keeping DoH permanently disabled.

https://www.salvagedata.com/cryptowall-ransomware-data-recovery/

My guess is Chrome and Edge are reloading the web page from their cache versus from its source as Firefox does.

If your concern is that file names are fully displayed, enable the two File Explorer options shown in the below screen shot;

Based on this forum posting: https://forum.eset.com/topic/25526-expired-license-how-to-disable-popup/ and others like it, there is no way to stop the license expiration popup alert other than by uninstalling Eset.

No problem in Firefox on this regard w/DoH disabled. When I select reload icon, the site is blocked again.

I would say DoH should be disabled on all browsers till Eset fixes the problem.

Another observation. With DoH disabled in Firefox, attempted access to https://crackingpatching.com/2017/03/avast-pro-antivirus-internet-security-premier-17-2-3419-0-keys.html results in blocking at the TLD as should be; Time;URL;Status;Detection;Application;User;IP address;Hash 3/10/2024 10:09:53 AM;https://crackingpatching.com;Blocked;Internal blacklist;C:\Program Files\Mozilla Firefox\firefox.exe;xxxxxxxx;2606:4700:3034::6815:2b2e;F736FE1F2C3ACB8E53F9E22EFE632D18B65DECCB

Your posted screen shots shows the Eset firewall blocking incoming DNS traffic from your router. At first glance, I would say your router is not properly configured, malfunctioning, or has been hacked.

Did more testing with the TLD https://crackingpatching.com/ The problem is with DoH enabled in Firefox. With DoH disabled, Eset will alert and block access every time. When any of the DoH settings are enabled, Eset might block it once after setting change but not thereafter. Doesn't matter what DoH option is selected or DoH provider selected. I am keeping DoH disabled until this is resolved. Glad you found this problem.

Found the problem, I believe. Eset Filtered Web Site log shows it blocked access; Time;URL;Status;Detection;Application;User;IP address;Hash 3/9/2024 11:43:27 AM;https://crackingpatching.com;Blocked;Internal blacklist;C:\Program Files\Mozilla Firefox\firefox.exe;xxxxx;104.21.43.46;F736FE1F2C3ACB8E53F9E22EFE632D18B65DECCB Time;URL;Status;Detection;Application;User;IP address;Hash 3/9/2024 11:43:28 AM;https://accounts.google.com/o/oauth2/postmessageRelay?parent=https://crackingpatching.com&jsh=m;/_/scs/abc-static/_/js/k=gapi.lb.en.8uXxGUoumbY.O/d=1/rs=AHpOoo96qx3mL4tzGUOa-0q0udyPRqEAoA/m=__features__;Blocked;Internal blacklist;C:\Program Files\Mozilla Firefox\firefox.exe;xxxxx;2607:f8b0:4023:140d::54;F736FE1F2C3ACB8E53F9E22EFE632D18B65DECCB But web site access is not blocked. Notice the redirect to Google. Looks like someone has figured out how to bypass Eset Web Filtering on Firefox.