itman
-
Posts
12,172 -
Joined
-
Last visited
-
Days Won
319
Posts posted by itman
-
-
Are you using the browser extension or stand-alone version of AdGuard VPN?
The browser extension version doesn't work with Eset: https://forum.eset.com/topic/34409-eset-not-working-with-vpn-extensions/ .
-
6 hours ago, COStark26 said:
Still No Block for me. False setting & Quad 9 to Cloudflare (default) and that http.http3.enable set to falsestill shows.
In my case, the key element was switching back to my ISP DNS servers as my Win DNS servers. I had tried using both Cloudflare and Quad9 as my Win DNS servers previously with http.http3.enable set to false, and Eset failed to alert/block crackingpatch site. My suspicion it's the 6rd tunneling my ISP uses on their network.
-
On 3/20/2024 at 9:30 AM, COStark26 said:
Not a big deal .... but FF 124 with (about:config) -- network.http.http3.enabled -- changed to False I still get the -- https://crackingpatching.com/ -- site with DoH Enabled
Just retested.
Eset nows blocks the domain with network.http.http3.enable set to false. DoH set to maximum level using default Cloudflare servers. I am also now using my ISP DNS servers as Win DNS servers.
-
Well, I'll be damned.
I got Firefox to detect https://crackingpatching.com/2017/03/avast-pro-antivirus-internet-security-premier-17-2-3419-0-keys.html with DNS over HTTPS enabled. The problem turns out to be HTTP/3 ; i.e. QUIC, as discussed in the other recent thread on this issue.
Set network.http.http3.enable setting via about:config option to false and Eset now detects every time.
I will also add that disabling HTTP/3 in Firefox does not disable it as far as Firefox DNS over HTTPS server processing goes. Using Cloudflare check: https://www.cloudflare.com/ssl/encrypted-sni/ shows HTTP/3 is enabled.
-
Another issue with Firefox DNS over HTTPS or not if you're using a VPN. It will leak your ISP DNS servers: https://connect.mozilla.org/t5/discussions/firefox-has-dns-leak-security-issue/td-p/50582 .
-
Output of fsutil command just repeats its existing directory;
-
13 minutes ago, Marcos said:
The file may be in a subfolder of system32 since the whole path is not visible in the screenshot. I assumed it was directly in system32.
I found it. It's located here, C:\Windows\System32\DriverStore\FileRepository\nv_dispig.inf_amd64_866484083fc526af\Display.NvContainer
Also due to Nvidia's aggressive telemetry processing. it may be being re-created in System32 directory and then deleted after system startup.
In any case, good luck on trying to allow it via Eset firewall rule for process detection. There are other forum postings on this and none succeeded.
Since it can be blocked by a firewall rule for IP address, 152.199.20.80, a rule can be created to allow the IP address which is risky.
-
1 hour ago, Marcos said:
fsutil hardlink list C:\Windows\System32\NVDisplay.Container.exe
File not found on my PC.
I have a nVidia graphics card with nVidia drivers installed. The only like file on my PC running is NVContainer.exe located in C:\Windows\System32\DriverStore\FileRepository\nv_dispig.inf_amd64_866484083fc526af\Display.NvContainer directory.
As a rule, I never install GeForce Experience. This System32 directory based NVDisplay.Container.exe file might be related to that.
However, I know that NVContainer.exe "dials out' on my PC on every system startup to IP address, 152.199.20.80.
-
21 minutes ago, COStark26 said:
Not a big deal .... but FF 124 with (about:config) -- network.http.http3.enabled -- changed to False I still get the -- https://crackingpatching.com/
First, as best as I can tell, Firefox isn't using HTTP/3.
Next, the problem with Firefox is how it performs DNS resolution when DoH is enabled as noted in the other forum thread on this issue and repeated below;
https://support.sophos.com/support/s/article/KB-000043686?language=en_USQuoteThis may be due to Mozilla Firefox's enablement of DNS over HTTPS. This feature is designed to bypass enterprise DNS and security and should not be used in an Enterprise environment. Our Web Protection interception interferes with this lookup.
Note: Only Mozilla Firefox is affected by this. Other browsers that may use DNS over HTTPS such as Google Chrome, use the Operating System information for DNS, which we also do. Firefox is the only browser that uses its own DNS configuration.
DNS-over-HTTPS at an application level attempts to bypass many security features. As such, we do not recommend having this setting enabled when using Sophos Web Protection.
-
Eset doesn't state that the Online Scanner is officially supported on Win 11;
-
3 hours ago, Marcos said:
This is because the server uses HTTP/3. If you disable QUIC in Chrome per https://support.eset.com/en/kb6757,
According to Watchguard, you also need to also create a firewall rule to block UDP port 80 and 8080 network traffic: https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Endpoint-Security/manage-settings/disable-http-3-protocol-for-web-access-control.html?TocPath=Troubleshooting|_____19 .
1 hour ago, Marcos said:I assume it has nothing to do with DoH.
Except for Firefox which uses its own DNS processing with DoH enabled. Also, Firefox has QUIC enabled by default.
-
11 hours ago, Ahmeduchiha said:
I use Cloudflare DNS but, on the network level not in the browser.
Your posted screen shot shows you have DNS over HTTPS enabled.
Edge refers to DNS over HTTPS as "secure DNS." You also have "Use current service provider" enabled. You stated that you are using Cloudflare as your Windows DNS servers; i.e. current service provider. Therefore, you are using Cloudflare as your DNS over HTTPS provider.
Disable the "Use secure DNS" setting; close and reopen Edge; and retest. Eset should alert and block access to this malicious web site every time
-
I would open a support request with your in-country Eset vendor and ask them to verify if the Suspicious Application detection is correct.
-
57 minutes ago, Ahmeduchiha said:
I am using Microsoft Edge so, this DNS option that Firefox has isn't available
Refer to this article: https://winaero.com/enable-dns-over-https-in-microsoft-edge/ to determine if DNS over HTTPS is enabled in Edge and what DNS provider it is using.
-
This also is very informative and might be what is going on here: https://www.securityweek.com/cloudflare-users-exposed-to-attacks-launched-from-within-cloudflare-researchers/ .
-
46 minutes ago, Marcos said:
I don't know why but I'm unable to reproduce the issue with DoH enabled and set to Max protection with Cloudflare selected as the provider:
Same setting in Firefox. Of note is I am also using Cloudflare as my Win 10 DNS servers;
-
I did more research on this issue yesterday with a number of interesting results.
The first find is that Firefox is unique in how it handles DNS over HTTPS;
QuoteThis may be due to Mozilla Firefox's enablement of DNS over HTTPS. This feature is designed to bypass enterprise DNS and security and should not be used in an Enterprise environment. Our Web Protection interception interferes with this lookup.
Note: Only Mozilla Firefox is affected by this. Other browsers that may use DNS over HTTPS such as Google Chrome, use the Operating System information for DNS, which we also do. Firefox is the only browser that uses its own DNS configuration.
DNS-over-HTTPS at an application level attempts to bypass many security features. As such, we do not recommend having this setting enabled when using Sophos Web Protection.
https://support.sophos.com/support/s/article/KB-000043686?language=en_US
The next find is how this web site: https://crackingpatching.com/ is bypassing Eset blacklist detection. It yielded how the bypass occurs but not how it is being done w/DoH enabled.
Firefox has developer network tools that can be accesses via about:networking. One of these tools is DNS which will log all DNS name servers used by a web site. Access to https://crackingpatching.com/ yielded the same results as shown by Sucuri: https://forum.eset.com/topic/40209-eset-web-protection-doesnt-block-websites-on-firefox/?do=findComment&comment=181351 .
Of note is this name server IP address,172.67.219.95. This IP address is also listed as the IP address in the VirusTotal detection: https://www.virustotal.com/gui/url/5583ee6d3fa820c9c851f37746d9b5a896da37bc7ce93329d6dcc02e4b7d9daa/detection . This IP address is not shown as a DNS name server associated with this web site: https://forum.eset.com/topic/40209-eset-web-protection-doesnt-block-websites-on-firefox/?do=findComment&comment=181211 . Finally, a lookup of this IP address shows it is no way associated with https://crackingpatching.com/ ; per Robtex lookup;
https://www.robtex.com/ip-lookup/172.67.219.95
-EDIT-
I almost missed this. Notice the IP addresses highlighted;
Those are the DNS name servers associated with https://crackingpatching.com/ . It really appears that someone has figured out a way to manipulate Cloudflare DNS server connection when DNS over HTTPS is being used.
-
It's the same DNS over HTTPS Eset bypass discussed at length in this thread: https://forum.eset.com/topic/40209-eset-web-protection-doesnt-block-websites-on-firefox/ .
With DoH disabled, Eset blocks access to web site via blacklist detection.
With DoH enabled, web site access is granted w/o issue. The only difference in this case when using Firefox, no Eset Filtered Web site log block entries are created. Perhaps with Browser Security & Privacy enabled - I have it disabled - the search result malicious icon display factored into Eset block log entries not being created as has been previously documented.
-
Just a clarification here.
If you look at the video carefully, you will observe that Win HVCI - Memory Integrity is disabled. Also confirmed by this malwaretips.com comment:
QuoteI reposted a new video because in the old one, I forgot to mention that Memory integrity is disabled (incompatible Intel driver in Virtual Machine).
With Win HVCI - Memory Integrity enabled, this bypass won't work.
BTW - Win HVCI - Memory Integrity is by far the most important Win 10/11 security protection. It prevents kernel mode access from user mode as was done in this test. It should never be purposely disabled.
-
16 minutes ago, Tetranitrocubane said:
Unfortunately (or fortunately?) the file was deleted by ESET and I cannot upload it to VT
File should be in Eset Quarantine.
-
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;
QuoteTo circumvent the protection offered by DoH, an active adversary might try to downgrade DoH to DNS and carry out the known DNS attacks. In fact, this is feasible as the usage profile RFC [35] specifies that a stub resolver can choose Opportunistic Privacy profile, which allows DNS encryption to fall back to plaintext when the encrypted channel cannot be constructed.
ESET web protection not working properly
in ESET Internet Security & ESET Smart Security Premium
Posted
Ahh .............. You poor soul! That is also my ISP.
First, you can't change any DNS server info on AT&T gateways/routers. They have locked the settings from modification.
Do as I did. Remove any third party DNS server settings from your IPv4/IPv6 connections. Now you are using AT&T DNS servers assigned via DHCP. Reboot Windows. Retest with http.http3.enable set to false in Firefox.