Jump to content

itman

Most Valued Members
  • Posts

    12,157
  • Joined

  • Last visited

  • Days Won

    319

Posts posted by itman

  1. 17 hours ago, Ahmeduchiha said:

    Adguard Adblocker for windows you will notice that ESET unable to detect the website.

    Did you disable WFP use in Adguard Adblocker as shown here: https://adguard.com/kb/adguard-for-windows/solving-problems/wfp-driver/ ?

    My advice is don't use anything installed AdGuard related with Eset. Their installed products overall are not compatible with Eset. Alternatives are to use Adguard browser extension or use uBlock Origin browser extension and activate AdGuard TPLs within it.

  2. Since you are persistent in your desired use of this app, the only solution I know of is to disable Eset Browser Privacy & Security feature since it is what is alerting about this .dll.

    Browser Privacy & Security is not an essential security protection. Its primary purpose is to examine browser search results and warn via icon notification about a suspect web site. As far as I am aware of, there is no way to create exceptions to Browser Privacy & Security.

  3. 1 hour ago, Ahmeduchiha said:

    I don't know if use Wintun is the same as WFP or it's different filtering approach.

    Turn on WinTun option. Reboot PC. Retest at AMTSO Phishing test site.

    Ref: https://adguard-vpn.com/en/blog/adguard-vpn-v2-2-for-mac-and-windows.html .

    Note that AdGuard documentation does not specifically state that WFP use is disabled when WinTun driver is used. But, the implication is the tunnel driver is bypassing WFP use.

  4. Quote

    Mspydll.dll is able to manipulate other programs, monitor applications and record keyboard and mouse inputs. Therefore the technical security rating is 62% dangerous.

    https://www.file.net/process/mspydll.dll.html

    Since Eset's Browser Privacy & Security feature is alerting about this .dll, I assume its attempting to perform one or more of the above activities against your browser.

  5. It might be related to the QUIC issue affecting browsers as posted in recent forum threads.

    Disable this setting;

    Quote

    Filter HTTP/3

    If this option is enabled, AdGuard will filter requests sent over HTTP/3 in addition to other request types.

    https://adguard.com/kb/adguard-for-windows/solving-problems/low-level-settings/#filter-http3

    and see if this resolves the issue.

    Another known Adguard incompatibility with ESET is Adguard's default use of Windows Filtering Platform. It needs to be disabled as shown here: https://adguard.com/kb/adguard-for-windows/solving-problems/wfp-driver/ .

  6. 6 minutes ago, COStark26 said:

    .I'm looking at my AT&T Uverse Gateway

    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.

  7. 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.

  8. 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.

  9. 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.

  10. 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.

  11. 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.

  12. 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;

    Quote

    This 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
  13. 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.

  14. 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

×
×
  • Create New...