Anti-phishing Protection Issue

[itman 1,921]

To begin, AMTSO Desktop Anti-phishing test works as expected.

When accessing an actual phishing web site per below posted event log entry, Eset logs that it blocked access. However, no Eset alert is generated and access to web site is allowed.

Time;URL;Status;Detection;Application;User;IP address;Hash
9/3/2021 2:39:12 PM;https://www.fixwindowserrors.biz;Blocked;Anti-Phishing blacklist;C:\Program Files\Mozilla Firefox\firefox.exe;XXX-PC\XXX;2606:4700:3036::ac43:8793;6E6C61A9F8A1D1C96B17E310A48AEAA49545C0EF

[Marcos 5,733]

Strange, works fine for me with Firefox. What about Edge or Chrome? Isn't the page blocked in those either?

[itman 1,921]

13 minutes ago, Marcos said:

What about Edge

Works properly in Edge.

Do you have Firefox set at default settings? Such as HTTPS over DNS using Cloudflare for example?

Edited September 3, 2021 by itman

[Marcos 5,733]

I was able to reproduce it eventually. I guess I didn't copy the whole url with https before; via http it's blocked in Firefox alright. Enabling DNS over HTTPS didn't make any different.

Thanks for the heads-up, will keep you posted about what the developers find out.

[shocked 60]

i can confirm that with Edge it's blocked whether it's https or not. FF will block it with http only.
meddling with dns-over-https in FF doesn't have any effect.

[itman 1,921]

Appears the connection is slipping through Eset HTTPS web filtering after being detected. The question is if its an isolated web site instance or all HTTPS affected? Appears that is not the case. Tested a couple of known phish HTTPS web sites from Phish Tank web site, and no issues with Eset blocking and alerting on those.

This web site appears to be using something new in the way of bypassing.

[itman 1,921]

I would also strongly recommend that Eset generate its small desktop popup window whenever an anti-phishing detection entry is written to the Filtered website log. This would give one a visual clue the accessed web site is a phishing one when Eset blocking access to the web site fails.

[NewbyUser 74]

Blocked  properly here on https,

 

[Marcos 5,733]

Don't know what happened but today I've been unable to reproduce this either. Tried various products and module versions to no avail; the block web page was always displayed.

[itman 1,921]

4 hours ago, Marcos said:

Don't know what happened but today I've been unable to reproduce this either. Tried various products and module versions to no avail; the block web page was always displayed.

Unfortunately, that is not the case for me using Firefox. Entering this URL, https://www.fixwindowserrors.biz/ , allows unblocked access with no Eset alert. Note that per my posted log entry, access to this web site is being made via IPv6.

When I use URL to IP address converters, they all resolve to IPv4 addresses. Robtex returns 198.187.31.37. URLVoid returns 172.67.135.147. Likewise, the IPv6 address being used changes. It's currently being shown in the Eset log entry as 2606:4700:3036::6815:1a3f which converts to IPv4 address, 104.21.26.63; i.e. Cloudflare interestingly.

Edited September 5, 2021 by itman

[NewbyUser 74]

I don't think it's related to IPv version, seems it's something Firefox is doing. Disabling SSL scanning allows the site to be shown but still showing a warning that it was supposedly blocked in Firefox. In my other browsers it's still blocked with SSL scanning on or off.

 

Edited September 5, 2021 by NewbyUser

[Marcos 5,733]

Isn't it blocked even if you press Ctrl+F5 in Firefox?

[NewbyUser 74]

Yes, even with clearing FF cache and history, still blocked with SSL scanning turned off.

[NewbyUser 74]

It's also blocking the IPv6 address here. And SSL Scanning still turned off.

 

Edited September 5, 2021 by NewbyUser

[shocked 60]

creating a new clean FF profile seems to make it work.. some weird setting seems to interfere with it but i can't understand what and why. even FF safe mode with addons disabled didn't help.

[NewbyUser 74]

5 minutes ago, shocked said:

creating a new clean FF profile seems to make it work.. some weird setting seems to interfere with it but i can't understand what and why. even FF safe mode with addons disabled didn't help.

That's likely the case with me then. I don't typically use FF and installed it just to try and help with this thread. 

[itman 1,921]

3 hours ago, shocked said:

creating a new clean FF profile seems to make it work..

I did a Firefox Reset and now Eset also properly alerts. Very strange indeed.

Of note, "Goback" button works sometimes and other times it does not.

Edited September 5, 2021 by itman

[itman 1,921]

A few additional comments here.

Eset had no issue detecting a phishing site using Firefox and alerting other than this web site in question based on my testing. As such, it can't be pointed to Firefox profile corruption as the source of non-alerting. If this was the case, Eset phishing alerting would not work on any blacklisted web site.

It appears this web site somehow interacted with Firefox profile settings initially to partially defeat Eset phishing alert processing. As such, I stick with my recommendation that Eset phishing detection be modified to show desktop popup alert upon creation of Filtered website event log entry.

Edited September 5, 2021 by itman

[Minimalist 16]

I still encounter this problem on Firefox but not on Edge and Chromium. I don't plan to refresh or recreate my profile so if logs or something similar is needed, I can provide them.

[shocked 60]

1 hour ago, itman said:

somehow interacted with Firefox profile settings

it's really weird how it can interact with the FF settings and "defeat" the protection. i haven't changed anything security related to the FF config settings, only some that relate to tab previews etc. so it's puzzling.

[itman 1,921]

Some additional info.

Robtex lookup on the domain name in question yields:

However, every Eset logged block event for this domain shows a Cloudflare server IPv6 address; i.e. DNS relay server. This parallels a recent posting I made in regards to Eset detection issues for the AMTSO cloudcar test. And I believe this has to do with 464XLAT tunneling my ISP is performing. It is basically now only using IPv6 and converting IPv4 addresses into IPV6 addresses en-route to my router. 

 

[NewbyUser 74]

56 minutes ago, itman said:

Some additional info.

Robtex lookup on the domain name in question yields:

However, every Eset logged block event for this domain shows a Cloudflare server IPv6 address; i.e. DNS relay server. This parallels a recent posting I made in regards to Eset detection issues for the AMTSO cloudcar test. And I believe this has to do with 464XLAT tunneling my ISP is performing. It is basically now only using IPv6 and converting IPv4 addresses into IPV6 addresses en-route to my router. 

 

But if it's your ISP, wouldn't the behavior be consistent regardless of whatever you did? And I could never reproduce the cloudcar issue either, so that may possibly be related to FF profile corruption also.

[Marcos 5,733]

7 hours ago, Minimalist said:

I still encounter this problem on Firefox but not on Edge and Chromium. I don't plan to refresh or recreate my profile so if logs or something similar is needed, I can provide them.

Does pressing Ctrl+F5 to refresh the web page in Firefox make a difference?

[itman 1,921]

13 hours ago, NewbyUser said:

And I could never reproduce the cloudcar issue either, so that may possibly be related to FF profile corruption also.

No.

Same behavior after resetting Firefox. Also although it appears Eset fixed the issue, what it is doing is detecting the cloudcar download when it hits the disk.

[itman 1,921]

7 hours ago, Marcos said:

Does pressing Ctrl+F5 to refresh the web page in Firefox make a difference?

It didn't for me. Only a full Firefox reset which creates a new profile resulted in Eset phishing alert being generated.