Google Redirect Abuse Powers Phishing and Spam Delivery

5 Auguat 2026

By Archa Archa and the Mimecast Threat Research Team

Threat Overview

Google redirect abuse is a widespread technique in which threat actors exploit legitimate Google URL redirection services to mask malicious links, bypass email security defenses, and increase the perceived legitimacy of phishing and spam campaigns. Attackers leverage Google's trusted domain reputation so that links appear to point to google.com (or other Google properties) while redirecting users to credential-stealing pages, malware, or unwanted content.

Because these redirects are served from authentic Google infrastructure, they frequently pass domain reputation checks, URL rewrite policies, and user scrutiny. Defenders who rely on allow listing *.google.com or who treat Google URLs as inherently safe remain exposed to this class of abuse.

 Mimecast Threat Research continues to observe Google redirect techniques across credential harvesting and high-volume spam. The sections below  document the primary redirect families, their URL structure and evasion behavior.

 Redirect Families

1. Google Web Light

Google Web Light was a transcoding service that served lighter, faster versions of web pages to users on slow mobile connections (for example 2G), mainly in countries such as India, Brazil, and Indonesia. It used the domain googleweblight.com and path-level resources sp and i to fetch and redirect to a target URL passed in the u parameter.

Google retired Web Light on 19 December 2022 and removed public documentation, but the domain and redirect behavior remain reachable and are still abused in malicious campaigns.

Example URL

 https://googleweblight.com/sp?otherkeys=othervals&u=https://7d63dd4a.ryhryhyj6j56h6t4635.pages.dev?ut=name@domain.com

Part	Value
Hostname	Always googleweblight.com
Redirect resource	Path-level resource required for redirect: must be sp or i
Optional query parameters	Custom query parameters can appear before u and do not affect redirect success
Redirect destination key	The u key. Its value is the destination URL. All query parameters after u belong to the destination page
Redirect protocol	Not enforced. Legitimate use usually includes a protocol; abuse often omits it
Redirect destination	Value of u. Must contain a protocol and a valid destination URL

2. Core URL Redirect: `google.*/url`

The primary mechanism is the open redirect at paths such as /url on various Google hosts.

Look for google./url? with a q= parameter containing a URL. Any host that serves this path can redirect to an arbitrary destination.

Example URL

https://www.google.com/url?q=https://malicious-site.com&sa=D&sntz=1

Usual parameters

Parameter	Role
q=	Destination URL (primary redirect target)
sa=D	Direct navigation; with sntz=1 can reduce interstitial warnings
sa=t	Search-click style; often combined with AMP abuse
sntz=1	Time zone parameter; commonly paired with sa=D in abuse
usg=	Signature token tied to query string; changing other parameters without updating usg can break the redirect
rct=j	Referrer context; seen in AMP-linked abuse
url=amp/...	Nested AMP destination path within the redirect chain

3. Google AMP (Accelerated Mobile Pages) Abuse

Google AMP is an open-source HTML framework used to build websites optimized for browser and mobile use. Because AMP can display web page contents inline, threat actors now abuse it to present phishing pages live after the user clicks a link.

Standalone AMP Abuse

Field	Value
Example URL	https://google.com/amp/malicious-site.com
Redirect resource	Path /amp/<domain-or-path> (abuse variant omits s; legitimate form is /amp/s/...)
Redirect destination	The path after /amp/ is the target (for example malicious-site.com)

Legitimate AMP:

https://google.com/amp/s/domain.com/path

Abused form (dropping the s):

https://google.com/amp/domain.com

This variant is relatively rare in benign traffic but appears in multiple malicious campaigns. It is often combined with other phishing indicators rather than used as a sole block signal.

Attackers embed Google AMP URLs in emails (for example ...&url=amp/malicious-site.com). When the q parameter is changed, the final destination can be altered while the URL still passes through Google, so the visible link remains a Google URL.

Example pattern

https://www.google.co.uk/url?q=...&rct=...&sa=t&url=amp/mimecast.com

Changing the last path in url=amp/... can redirect to an arbitrary site; removing /amp often triggers Google's interstitial warning page.

This service is very forgiving in URL formatting and will normalize a wide range of incorrect formatting, allowing threat actors to work around existing visibility by modifying URLs in unexpected ways.

4. Google Travel: `/travel/clk`

This open redirect is related to the Google Travel service, available on all Google hostnames. It directs traffic to external sites through the Google Travel product. This is a partially contained open redirect — a system-generated token is required, but it doesn't restrict where the redirect can point. That token can be generated through Google Travel on request and doesn't prevent the destination from being changed.

Field	Value
URL path	/travel/clk on google.<tld>
pc=	Token that controls whether a redirect occurs; does not constrain the destination
pcurl=	Destination URL
Token lifetime	Tokens lack visible expiration and can be reused for weeks or months

Example URL

https://www.google.com/travel/clk?pc=AA80Osz1Y9jFF8K4dj7wcdCsT2otn5mxfNX82xi-cd4&pcurl=https://malicious-site.com

5. Non-Standard Google Hosts (ccTLDs and Service Subdomains)

Same structure as the Core URL Redirect; only the hostname changes.

Attackers use the same /url?q= (or equivalent) pattern on hosts other than www.google.com, for example google.es, google.de, google.fr, maps.google.*, contacts.google.*, and drive.google.*. These are legitimate Google properties but are less often included in redirect-specific rules.

Country-code domains (ccTLDs)

Attackers use less-monitored Google ccTLDs so that domain-based allow lists and reputation checks still see "Google" while reducing coverage of custom rules.

Examples:

https://google.es/url?q=http://bad-domain.com
https://google.de/url?...
https://google.fr/url?...

Service subdomains

Redirect abuse is also seen on subdomains not commonly associated with link redirects, increasing the number of patterns defenders must handle:

Service	Example
Maps	https://maps.google.de/url?q=http://bad-domain.com
Contacts	https://contacts.google.fr/url?q=...
Drive	https://drive.google.*/url?q=...

These are also seen as part of redirect chains originating from other sites:

originating URL → Google redirect (with &sa=D&sntz=1&usg=) → url?q= value

6. Google Meet/Hangouts and App Engine

(1) Meet

Path meet.google.com/linkredirect with query parameter dest= containing the destination URL Previously, Google Hangouts also followed a similar path to redirect.
https://meet.google.com/linkredirect?dest=https://malicious-site.com

(2) App Engine

Path appengine.google.com/_ah/logout with continue= pointing to another URL (often Hangouts or the final site). In email, chains combining both are a strong abuse signal.

Chained redirect example

https://www.google.com/url?sa=D&q=https://appengine.google.com/_ah/logout?continue=https://hangouts.google.com/linkredirect?dest=https://www.vizor.cloud/...

Such chains (App Engine logout → Hangouts → final destination) have no common legitimate use in email and are suitable for high-confidence blocking.

7. Google DoubleClick / Ad Services

Google's marketing link analytics products expose open redirects on googleadservices.com and doubleclick.net. Unlike Google Search's /url redirects, these are not publicly documented as hardened against abuse and have seen increased misuse. Attackers typically lift valid ads links and change only the adurl destination, often chaining further redirects and preserving query fragments (for example recipient email) to customize phishing pages.

(1)doubleclick.net

Example URL

https://adclick.g.doubleclick.net/pcs/click?xai=...&sig=...&urlfix=1&adurl=https://wikipedia.org

Part	Value
Hostname	Static: adclick.g.doubleclick.net or googleads.g.doubleclick.net
Redirect resource	Path always /pcs/click
Analytic parameters	Analytics/account data. Can be modified, omitted, or replaced arbitrarily
Redirect destination key	adurl — must be followed by a valid redirect URL
Redirect destination	Value of adurl
Notes	Query formatting is very flexible; fragments in the redirect URL are preserved

(2) googleadservices.com

Example URL

https://www.googleadservices.com/pagead/aclk?sa=L&ai=...&sig=...&adurl=https://wikipedia.org

Part	Value
Hostname	Static: www.googleadservices.com (no other known variants)
Redirect resource	Path always /pagead/aclk
Required analytic parameters	Parameter names and values required and validated by Google for a successful redirect
Partially required parameters	If missing or incorrect, Google shows a safety/warning interstitial on click
Optional parameters	Appear to have no effect on redirect success; can be changed or removed
Redirect destination key	adurl — must be followed by a valid redirect URL
Redirect destination	Value of adurl
Notes	Less forgiving than doubleclick.net; abuse typically lifts valid ads links and only changes adurl. Fragments are preserved

8. Google Translate

translate.goog is abused by encoding the phishing domain into the hostname.

Example URL

https://phishing-com.translate.goog/?_x_tr_sl=auto&_x_tr_tl=en

(Decodes to destination host phishing.com.)

Hostnames take the form *..translate.goog where the subdomain is the target domain with dots replaced by hyphens (for example example.com → example-com.translate.goog). Parameters such as _x_tr_sl=auto and _x_tr_tl=en may be present. Security filters are less likely to flag these because they appear as legitimate Google domains.

Construction pattern

1. Replace dots in the target domain with hyphens (for example example.com → example-com)
2. Use as subdomain of translate.goog: https://example-com.translate.goog
3. Optional parameters such as _x_tr_sl=auto, _x_tr_tl=en make the URL look like a normal Translate link

9. Google OAuth Redirect

Google OAuth 2.0 is an industry-standard authorization framework designed to enable secure, delegated access to user accounts without requiring password sharing. The system allows third-party applications to request limited, scoped permissions to access user data (email, profile, calendar, and so on) through a user-controlled consent process.

Google OAuth 2.0 authorization flows use a redirect to send the user back to the application after consent. The redirect_uri parameter tells Google where to send the user (and the authorization code or token). If an attacker can control or influence this value, they can steal authorization codes or tokens or send users to a phishing page after a legitimate-looking Google login.

Example URL (authorization request)

https://accounts.google.com/o/oauth2/v2/auth?client_id=123456789.apps.googleusercontent.com&redirect_uri=https://attacker.com/callback&response_type=code&scope=openid%20email%20profile&state=random_state

Evasion Techniques

Because the usg token is tied to the query string, attackers cannot freely change query parameters to pass user-specific data without invalidating the redirect. Attackers therefore use URL fragments for tracking, pre-filling forms, or passing tokens to the final page without breaking the Google redirect.

URL fragments (the part after #):

• Are not sent to the server
• Are not included in usg validation
• Are preserved by the browser through the redirect

Example

https://google.es/url?q=http://malicious-site.com&usg=...#user123

Additional evasion patterns:

Technique	Description
sa=D with sntz=1	Can avoid the warning interstitial when leaving Google, especially when paired with a valid usg
sa=t with url=amp/...	Search-click pattern seen in abuse; changing the final path in url=amp/... can send users anywhere while still routing through Google
AMP formatting normalization	Threat actors modify URL structure in unexpected ways to evade static pattern matching
ccTLD and subdomain rotation	Shifts abuse to less-monitored Google hostnames while preserving redirect semantics
Fragment preservation on ad redirects	adurl fragments carry recipient identifiers or form pre-fill data to the final phishing page
Multi-hop chains	App Engine logout → Hangouts → final destination obscures the ultimate target from single-hop analysis

Mimecast Protection

Mimecast has identified attributes associated with Google redirect abuse across email link analysis, URL rewrite inspection, and post-click redirect chain evaluation. Detection coverage spans:

• Core /url?q= redirects on standard and ccTLD Google hosts
• AMP path abuse (/amp/ without /s/)
• Retired but still reachable Web Light redirects on googleweblight.com
• Travel redirect tokens on /travel/clk
• Hangouts and App Engine chained redirects
• DoubleClick and Google Ad Services adurl manipulation
• Translate hostname encoding on *.translate.goog
• OAuth authorization requests with suspicious or unregistered redirect_uri values

The Threat Research team continues to monitor for new formatting variants, host rotations, and combinations with credential harvesting and malware delivery infrastructure.

Recommendations

User Awareness Training

• Educate employees that a link displaying google.com does not guarantee safety; attackers routinely abuse Google redirects to reach malicious pages
• Instruct users to inspect the final browser address bar after any redirect, especially before entering credentials
• Warn that Google interstitial warning pages can be suppressed by certain parameter combinations; absence of a warning does not indicate legitimacy
• Emphasize that unsolicited emails should not be trusted based on the visible link domain alone

Conclusion

Google redirect abuse remains one of the most durable techniques in the threat actor playbook. By routing victims through authentic Google infrastructure, attackers inherit domain trust, bypass naive allow lists, and increase click-through rates on phishing and spam campaigns. The breadth of redirect families — from retired Web Light endpoints to OAuth parameter manipulation — means defenders cannot rely on a single detection rule or domain allow list.

Organizations should treat all Google URLs in unsolicited email as untrusted until the full redirect chain and final destination are validated. Security teams should prioritize detection at both the email link stage and the post-click redirect stage, with particular attention to chained redirects, fragment-based evasion, and abuse of less-monitored ccTLD and service subdomains.