Hackers Abuse Trusted Google Domains to Hide Phishing Links From Email Gateways
8 min. read 
Published on
Attackers are using trusted Google redirect services to hide phishing links from email security tools and send victims to Microsoft 365 credential theft pages or device-code phishing flows.
The campaign, tracked by KnowBe4 ThreatLabs coverage, uses a nested redirect chain that passes through Google Meet, Google Search Redirect, and Google Ad Service before landing on attacker-controlled infrastructure. Because the early hops use reputable Google domains, some secure email gateways may treat the link as safe before the final phishing destination becomes visible.
Access content across the globe at the highest speed rate.
70% of our readers choose Private Internet Access
70% of our readers choose ExpressVPN
Browse the web from multiple devices with industry-standard security protocols.
Faster dedicated servers for specific actions (currently at summer discounts)
The lures include fake FedEx delivery notices, DocuSign and AutoSign document requests, Microsoft 365 password expiry alerts, payment remittance emails, and QR-code messages. The goal is to make the recipient click quickly before checking where the link eventually goes.
How the Google Redirect Chain Works
The attack does not require compromising Google itself. Instead, attackers abuse legitimate redirect behavior across trusted services. A victim may first see a link that routes through meet.google.com, then through google.com/url, and then through an adservice.google.com domain before reaching the real phishing site.
That creates a gap between what a scanner sees and what a user experiences. If an email gateway checks only the visible or early-stage domains, it may see Google-owned infrastructure and allow the message through.
KnowBe4 ThreatLabs described the technique as a triple-chain abuse of Google services. The issue is not reputation alone, but the way attackers combine several trusted redirects to delay exposure of the malicious destination.
Campaign Details at a Glance
| Element | What attackers use | Why it matters |
|---|---|---|
| Trusted redirect chain | Google Meet, Google Search Redirect, and Google Ad Service | Gateways may see only reputable domains during scanning |
| Business lures | FedEx, DocuSign, AutoSign, Microsoft 365, and payment notices | Recipients feel pressure to act quickly |
| Credential phishing | Fake Microsoft 365 login pages | Attackers collect usernames and passwords |
| Device-code phishing | Fake OneDrive document pages with Microsoft device codes | Victims may authorize attacker-controlled access |
| QR-code phishing | Links hidden inside image-based codes | Some email tools may inspect QR content less deeply |
Two Payload Paths Target Microsoft 365 Users
After the redirect chain, victims generally face one of two outcomes. The first is a fake Microsoft 365 sign-in page that asks for credentials. These pages often pre-fill the victim’s email address, making the login screen look more convincing.
The second path uses device-code phishing. Instead of asking for a password directly, the phishing page may show what appears to be a OneDrive shared document and display a Microsoft device code. If the user enters that code on Microsoft’s real login page, they can approve access for the attacker’s session.
Microsoft’s analysis of device-code phishing explains that attackers can abuse legitimate device code authentication to gain tokens for Microsoft 365 services. This method can bypass normal password theft defenses because the user completes the sign-in on a real Microsoft page.
Why Device-Code Phishing Is Hard to Spot
Device code authentication exists for devices that are hard to type on, such as TVs, meeting room hardware, or shared devices. In a phishing attack, the attacker starts the login flow and gives the victim the code.
The victim may believe they are opening a document or joining a legitimate workflow. In reality, they are authorizing a session that belongs to the attacker. Once the attacker receives valid tokens, they may access Outlook, Teams, SharePoint, OneDrive, and other cloud resources depending on permissions.
Microsoft’s authentication flows guidance describes device code flow as a high-risk authentication method when attackers abuse it for phishing or unmanaged access. That is why organizations should restrict it unless they have a clear business need.
Why Email Gateways May Miss These Links
Many secure email gateways rely partly on domain reputation, URL scanning, and redirect resolution. Those controls remain useful, but nested trusted-domain chains can make analysis harder.
When a message contains several clean-looking redirect hops, a scanner may stop before reaching the final phishing host. Attackers benefit from that timing difference because the link looks safer at delivery time than it does after a human clicks through the full chain.
The KnowBe4-linked report says this campaign uses Google-owned domains to keep reputation scores clean across the visible redirect path. That makes user training and post-delivery scanning more important than simple domain trust rules.
How Organizations Can Reduce the Risk
- Inspect full redirect chains instead of trusting the first known domain.
- Use URL detonation that follows links to the final destination.
- Flag emails that combine trusted redirects with urgent business lures.
- Train users to report device code prompts they did not request.
- Block or restrict device code flow unless specific users or devices need it.
- Watch for sign-ins that use device code authentication from unusual locations.
- Review OAuth tokens, session activity, and mailbox rules after a suspected compromise.
Microsoft provides a dedicated guide to block authentication flows with Conditional Access. That control can restrict device code flow and authentication transfer across an organization.
Security teams should also investigate suspicious successful sign-ins, not only failed logins. Device-code phishing often succeeds through a legitimate Microsoft flow, so the key signal may be the authentication method, device context, IP address, or unexpected access pattern.
What Users Should Watch For
Users should be careful with any email that asks them to open a document, confirm delivery, approve a payment, scan a QR code, or fix a Microsoft 365 password problem. Urgency is one of the main tools in this campaign.
They should also be suspicious if a shared document page asks them to copy or enter a device code. A real document workflow should not normally require users to authorize an unknown device or enter a code they did not request.
Microsoft’s device-code phishing research notes that Safe Links and Entra ID protection can raise high-confidence alerts for this type of activity. Those alerts should trigger fast token review and account investigation.
Trusted Domains Are Not Always Safe Destinations
This campaign shows why security tools and users should not treat a familiar domain as proof of safety. Attackers often abuse redirectors, file-sharing platforms, ad services, collaboration tools, and cloud services because those domains already have strong reputations.
KnowBe4 ThreatLabs says the nested redirect chain gives attackers a way to blindside scanners that trust every visible hop. The final destination still matters more than the reputation of the first domain in the chain.
Organizations can reduce the impact by combining deeper URL inspection, user reporting, conditional access, and device-code restrictions. The campaign’s lesson is simple: verify the destination, not just the brand name in the link.
Conditional Access Is Now a Key Defense
For Microsoft 365 environments, device-code phishing should be treated as an identity risk, not just an email issue. A phishing message may start the attack, but the compromise happens when a user authorizes access through a legitimate authentication flow.
Microsoft’s Conditional Access guide shows how administrators can block device code flow by default and create controlled exceptions where needed. That gives organizations a practical way to reduce exposure without relying only on users to spot every lure.
Microsoft’s authentication flow documentation also recommends controlling device code flow together with other Conditional Access policies. In most environments, broad access to device code flow is not worth the phishing risk.
FAQ
Attackers route victims through a chain of legitimate Google redirect services, including Google Meet, Google Search Redirect, and Google Ad Service. This can make early link checks look safe while hiding the final phishing destination until a user clicks.
No. The campaign abuses legitimate redirect behavior on trusted Google-owned domains. The reports do not indicate that Google itself was compromised.
Device-code phishing tricks a user into entering a code on a legitimate Microsoft login page. The user thinks they are opening a document or completing a normal sign-in, but they are actually authorizing access for an attacker-controlled session.
Some gateways may inspect the visible or early-stage redirect domains and see only trusted Google infrastructure. If they do not follow the full redirect chain to the final destination, the malicious page may remain hidden until the user clicks.
Organizations should inspect full redirect chains, detonate suspicious URLs, train users to report unexpected device code prompts, restrict device code flow with Conditional Access, and monitor Microsoft 365 sign-ins for unusual authentication methods or locations.
Read our disclosure page to find out how can you help VPNCentral sustain the editorial team Read more
Improve this guide
User forum
0 messages