Listen to this Post
Cybercriminals have found yet another way to abuse one of the most trusted domains on the internet — Google.com. A fresh phishing campaign reveals how attackers are manipulating Google’s /travel/clk redirect endpoint to trick users and distribute malicious content under the cloak of credibility. Despite being designed for legitimate purposes, such as tracking hotel bookings via Google Travel, the redirect mechanism is now being weaponized due to its weak validation and lack of expiration controls.
Google Redirects Hijacked: A Deep Dive into the Latest Phishing Campaign
A recent phishing attempt uncovered by ISC Security researchers shows how open redirect vulnerabilities continue to pose significant threats — especially when they involve well-known and widely trusted domains like Google.com. In this case, the phishing email mimicked a typical security warning claiming that the user’s account had been locked for safety, urging the recipient to follow a link to “unlock” it.
The suspicious URL embedded in the message was hosted on Google’s /travel/clk endpoint. This particular Google URL is meant to serve as a redirect tool within the Google Travel ecosystem, redirecting users to external hotel booking sites. Its format typically looks like this:
`https://www.google.com/travel/clk?pc=[token]&pcurl=[destination_URL]`
Upon clicking, the user is temporarily sent to the /travel/clk page before being silently forwarded to the final destination specified by the pcurl parameter. The problem? The token (pc) doesn’t actually validate the destination. It merely controls whether the redirect works or not — and the same token can remain functional for months or even years.
Evidence of the
Further analysis indicates the tokens follow a structure typical of encrypted data, likely built using AES-GCM via Google’s open-source Tink library. Although this cryptographic approach prevents attackers from easily forging tokens, they can still harvest valid ones by simply visiting Google’s hotel search tool and copying the redirect URLs.
The real kicker is Google’s stance on the issue. According to their Bug Hunter documentation, Google considers open redirects to carry “very little practical risk.” They argue that modern phishing defense mechanisms — like automated phishing detection and user alerts — compensate for any user confusion caused by redirecting from Google domains.
However, the persistent abuse of /travel/clk undermines that argument. This isn’t Google’s first brush with redirect vulnerabilities either — past issues have been reported involving Google Ads, Search, and even YouTube. All of this suggests a broader systemic issue in how Google manages redirect mechanisms across its platforms.
Unless Google reconsiders the structure and validation process of these redirectors, attackers will continue to exploit this loophole, turning a trusted brand into an unwitting accomplice in phishing schemes.
What Undercode Say:
From a technical standpoint, Google’s open redirect vulnerabilities have created a troubling paradox: a platform that’s supposed to lead the world in cybersecurity innovation is now a recurrent vector for phishing. The /travel/clk endpoint is particularly dangerous because it’s obscure enough to evade basic detection yet influential enough to mislead even cautious users.
Let’s break this down analytically.
Redirectors serve legitimate tracking and user navigation functions. But when they lack restrictions or token expiration, they create backdoors. In Google’s case, /travel/clk accepts a cryptographically generated token (pc) and a destination (pcurl) but never validates if the destination is safe or even relevant to the original context. This means an attacker could reuse a token from a hotel booking link to redirect users to a phishing site — effectively laundering their malicious URL through Google.
Because these tokens don’t expire (at least not in any practical timeframe), attackers can archive and reuse them indefinitely. And since they originate from a trusted domain, they can easily bypass spam filters and user skepticism.
The situation is worsened by Google’s laissez-faire security posture on this issue. By brushing aside open redirects as “low risk,” the company is ignoring the real-world exploitation evidence mounting across platforms. While automated phishing defenses are important, they shouldn’t be the only line of defense when better redirect validation could mitigate the issue from the root.
There’s also an underlying tension between usability and security. Google favors seamless user redirection for analytics and partner integrations. But as demonstrated here, the balance has tilted too far toward usability, leaving the door open for abuse.
It’s worth noting that this issue
A responsible redesign would involve:
Making tokens expire after short periods.
Binding tokens to specific destinations.
Creating an allow-list of approved redirection domains.
Automatically invalidating tokens exposed in public datasets.
Until then, attackers will continue to use this pathway to cloak their phishing campaigns with Google’s legitimacy. It’s a ticking time bomb — one that’s been quietly ticking since at least 2023.
Security teams should proactively sandbox or block emails containing these redirect patterns. And users should remain vigilant, especially when even legitimate-looking Google URLs could lead them into traps.
Fact Checker Results ✅
✔️ Verified phishing attempts reused tokens from February and April.
✔️ Public sandbox entries confirm tokens from 2023 are still active.
✔️ Google’s stance downplays risks, but real-world abuse shows otherwise. 🔍
Prediction 🔮
Unless Google revises its redirect policy, phishing campaigns using /travel/clk will escalate in both frequency and sophistication. Attackers are likely to automate token harvesting from public hotel searches, creating new campaigns at scale. Expect increased use of Google domains in phishing kits, making detection harder and trust erosion more widespread. Without structural changes, even Google’s robust detection systems won’t be enough to shield users from this growing threat.
References:
Reported By: isc.sans.edu
Extra Source Hub:
https://www.reddit.com
Wikipedia
Undercode AI
Image Source:
Unsplash
Undercode AI DI v2
