In need of addressing Google AMP Evasive Phishing Tactic
Hello All,
The following articles have come out re: Evasive Phishing that domain front-ends Google to protect potentially malicious or unintended traffic from being picked up by filtering or threat.
This means if NGSWG can't categorize the URL is hiding in AMP then it will treat the site as categorized as safe (or likely safe) based on that it is hosted at google, not the real site of xxx.xxx (or whatever malicious site and path is included there).
Examples:
https://www.google.com/amp/s/xxxxx.xxxx/somesite.html or https://www.google.co.uk/amp/s/xxxx.xxx/badimage.img
From a position of making sure this product is competitive in the market, there are some other vendor tools that can granularly expose this hidden URL and site and evaluate it piecemeal from the original request, but I have not found a way to address this w/ NGSWG.
It is not appropriate to assume all material hosted via AMP is bad, but there is the potential legitimate traffic is fronted via AMP but on the same hand is also bad traffic. We simply don't know, and taking too strict of a security posture will impact business inappropriately, so one cannot create traffic to block anything with "google(.*)/amp/s/" (regex likely not accurate but given to make a point).
Looking for feedback from Netskope support, or other customers, in how they have addressed this concern with Netskope policy. I would prefer to have a way to solve this with Netskope NGSWG, and not have to solve it with a competitor product.
Alternatively, if someone tells me there is awareness for Google AMP as a product (app) and we have some options in there, I'd also be interested in that.
Ultimately I would like:
Evaluate the hidden URL and identify it's risk separate from the Google AMP URL as a whole
Make policy decision based on the AMP fronted (protected) site (ALLOW, DENY, Isolate? :))
Thank you,
AKH_BGT
Page 1 / 1
Hello AKH_BGT,
Protection against this technique would fall under the same recommendations that we use for all types of phishing attacks. By levering it, a Netskope customer would be using signature based protection, protection against known phishing and risky URLs and ML-based phishing detection. Netskope would analyze not only the requested URL but all subsequent redirects.
To protect against Phishing attacks, you should at least configure:
1- a threat protection policy exists in Real-Time Policy (more here)
2- a category based policy is blocking traffic to the "Phishing" category exists in Real-Time Policy
3- another category based policy could also be used against "Uncategorized", "NOD - Newly Observed Domains" and "NRD - Newly Registered Domains" exists in Real-Time Policy. The action can be set to Block or either Isolate and leverage our Netskope Browser Isolation Technology.
Hope this helps!
@frosa I'd argue a few things we would want to consider here.
Why would I want the redirect to occur? It's bad enough the query was allowed out, the site has already been pinged for a "Server certificate" check, I don't want the redirect follow to even occur in this circumstance.
What if the site was a C&C? The validation of hitting that AMP hosted would qualify that someone was able to "phone home" or "phone out".
How will I see the check against the full URL vs the sub-check on the hosted URL in logs? I don't believe I can see the granular sub-check for that domain-fronted AHEAD of it actually making the redirect call, but I'd like to not step forward if I can see there is a cliff I'm going to step off of ahead of me (by granularly checking that URL AMP is protecting/hosting).
A worse-case-scenario would be isolating ANYTHING at /amp/s from any google, but I'd rather block the known bad and not even redirect to HIT the known bad. Why give the bad site the idea I was even allowed to redirect to them? Same reason I don't put my password out on the web assuming it won't be used against me in some way 🙂
As stated, I can use other competitive tools to pre-check the fronted URL and block the redirect, so prohibiting the redirect is the main go, vs letting the redirect get re-evaluated and blocked.
Thanks,
BGT_AKH
Thanks for your reply.
As I mentioned, we have three functions of our threat protection stack that could help prevent against this type of attack. Our categorization database, which is one of them, not only takes domains into consideration but full URLs so whenever an AMP domain is classified as Phishing it will be blocked right away and no request would ever get served to that domain.
My comment on redirects is valid for the technologies mentioned above. If an AMP domain is followed by a series of redirects and one of them is a domain/URL that is categorized as phishing or something else risky then, again, nothing will get served from that domain and the requests will be blocked.
Hope this helps clarify your question.
@frosa I'm going to break down the original request, and get to your reply shortly.
To protect against Phishing attacks, you should at least configure:
1- a threat protection policy exists in Real-Time Policy (more here)
We can assume this policy exists, yes.
2- a category based policy is blocking traffic to the "Phishing" category exists in Real-Time Policy
As google.com/amp/s or google.co.uk/amp/s would not be categorized as Phishing at their current domains, this would only affect the redirect.
The point here is to STOP before the redirect is handled. Why would I want a redirect followed if I could block it before that step was executed?
Let me give an example, let's say it was google.com/amp/s/BADSITES.]xyz I'd want to see that attempt to redirect and peel out BADSITES.]xyz and not allow the redirect to occur. That's clearly an example where it's visually obvious it's bad, but no all will be bad sites, but the ones that are bad also may not be so obvious visually.
I'd like to see the request and stop before we even get the "302" to redirect.
(obviously my next redirect is to braxtongrant.com, but what if I could see this before I even DO the call out for that original Request URL? What if it wasn't an innocent site? How about C&C control waiting to respond with next steps if reached?)
3- another category based policy could also be used against "Uncategorized", "NOD - Newly Observed Domains" and "NRD - Newly Registered Domains" exists in Real-Time Policy. The action can be set to Block or either Isolate and leverage our Netskope Browser Isolation Technology.
The above google domains would likely keep their Google associated assignments for categorized, even if the website they were front-loading/domain-hosting for wasn't the same category.
I've attached what a query on that example I have above is as an image to this post: https://www.google.co.uk/amp/s/braxtongrant.com
Now your most recent post:
Our categorization database, which is one of them, not only takes domains into consideration but full URLs so whenever an AMP domain is classified as Phishing it will be blocked right away and no request would ever get served to that domain.
As notated in the image, nothing at this SPECIFIC domain will ever be triggered as bad, it will, to your point, simply redirect, and sure, will show up as a referrer to the site it's redirecting to. I disagree what would trigger AMP domain to be classified as Phishing, it's still a Google Site, and will remain tagged as it's current category.
If an AMP domain is followed by a series of redirects and one of them is a domain/URL that is categorized as phishing or something else risky then, again, nothing will get served from that domain and the requests will be blocked.
I will agree follow up redirects will be blocked, but the goal here isn't to allow the redirect AT ALL!
I disagree that you believe over time that "google(.*)/amp/s" variants would be tagged as suspicious, AMP does likely more safe than unsafe redirects, and until it's more widely abused, likely won't be blocked and Netskope isn't likely to look less-fondly on Google's use of this path to determine it's safety level or category.
I had a response posted here but it appears that my response was removed from this thread.
If someone at Netskope would like to talk to me directly, they can feel free to reach out, as I'm a Partner and hoping that a more appropriate solution other than what has been offered can be identified by this team.
Clearly something I posted previously struck a nerve, but I felt it necessary to highlight the severity of this issue.
That said, my contact information for my Partner account is still accurate, and from what has been presented, the request to solve this in a more prudent and proactive way has yet to be directly addressed.
If you haven't already registered, now is a good time to do so. After you register, you can post to the community, receive email notifications, and lots more. It's quick and it's free! Create an account
