Google Meet URL Chains: How Attackers Use Google’s Own Infrastructure to Steal Microsoft 365 Credentials + Video

By /

Listen to this Post

Featured Image

Introduction:

A single Google Meet link with a padlock icon—everything looks legitimate. Yet that innocuous-looking URL can traverse multiple Google-owned domains before landing on a credential-harvesting page hosted on Amazon S3. This is not a theoretical attack; it is an active, multi-layered open redirect campaign (CWE-601) that has been documented and analyzed by security researchers throughout 2026. By chaining together Google Meet’s `linkredirect` endpoint, Google’s URL redirector, and Google Ad Services—all trusted domains that email gateways never block—attackers can bypass every automated security control and deliver victims to a pixel-perfect Microsoft 365 fake login page. The victim’s email address is pre-filled via a fragment identifier, making the phishing page even more convincing while leaving no trace in server logs.

Learning Objectives:

  • Understand how attackers chain multiple Google open redirects to evade email security gateways
  • Learn to identify obfuscation techniques including multi-layer URL encoding and hexadecimal hostname representation
  • Master detection strategies for spotting `meet.google.com/linkredirect` abuse across network and email logs
  • Implement defensive measures against open redirect phishing campaigns targeting Microsoft 365 credentials
  1. The Four-Hop Attack Chain: How Google Infrastructure Becomes a Weapon

The attack begins with a phishing email that appears to be a legitimate document signature request. The email contains a hyperlink that uses Google Meet’s open redirect endpoint:

hxxps://meet[.]google[.]com/linkredirect?dest=hxxps://www[.]google[.]com/url?q=amp/google[.]com%2Furl%3Fq%3Dhttps%253A%252F%252Fshorter[.]me%252FNjxgq%26sa%3DD%26sntz%3D1

Hop 1 – Google Meet Redirect: The initial link uses meet.google.com/linkredirect, an endpoint designed to redirect users to external resources associated with meetings. To an email gateway, this is a legitimate Google domain with an impeccable reputation score.

Hop 2 – Google URL Redirect: The `dest` parameter points to www.google.com/url, the redirector Google uses to track outbound clicks from search results. The `q` parameter contains the next encoded destination.

Hop 3 – Google AMP / Ad Service: The chain passes through `adservice.google.com.ph` or Google’s AMP infrastructure, adding another layer of indirection. Every domain in the chain belongs to Google.

Hop 4 – Attacker-Controlled Destination: The final hop lands on an Amazon S3 bucket or a compromised WordPress site, often protected by a CAPTCHA to lend credibility and filter out automated scanners.

Step-by-Step Guide to Analyzing This Chain:

  1. Extract the full URL from the email (both HTML and plaintext versions).
  2. Decode URL encoding layers progressively. The example above uses `%25252F` (which decodes to %252F, then to %2F, then to /), indicating multiple encoding passes.
  3. Follow each redirect using `curl -v` or a browser’s developer tools (Network tab) with “Preserve log” enabled.
  4. Document each hop’s domain and note that every intermediate domain is Google-owned.
  5. Identify the final destination—look for Amazon S3 bucket names (.s3.amazonaws.com) or compromised WordPress sites with CAPTCHA pages.

2. Obfuscation Techniques: Hiding in Plain Sight

Attackers employ multiple obfuscation methods to make detection even harder:

Multi-Layer URL Encoding: The destination URL is encoded multiple times. For example, `%25252F` represents three layers of encoding—each pass decodes to reveal the next layer. This prevents simple string-matching detection rules from identifying the malicious destination.

Hexadecimal Hostname Representation: The attacker’s server hostname may be represented in hexadecimal format within the URL, bypassing domain-based filters that only check for plaintext strings.

Email Pre-Filling via Fragment Identifier: The victim’s email address is appended after a “ (fragment identifier). This pre-fills the email field on the fake Microsoft 365 login page. Critically, fragment identifiers are not sent to the server in HTTP requests, so the victim’s email never appears in server logs—making forensic investigation more difficult.

Detection Commands:

To identify these obfuscated URLs in your environment:

 Linux - Search mail logs for Google Meet redirects with suspicious destinations
grep -E "meet.google.com/linkredirect.dest=.google.com/url" /var/log/mail.log

Extract and decode multi-layer encoded URLs from a suspicious link
echo "https%3A%2F%2Fwww.google.com%2Furl%3Fq%3Dhttps%253A%252F%252Fshorter.me%252FNjxgq" | python3 -c "import sys, urllib.parse; print(urllib.parse.unquote(sys.stdin.read()))"

 PowerShell - Decode URL encoding layers
  1. Why Email Gateways Fail: The Trusted Domain Problem

Secure Email Gateways (SEGs) inspect each hop in a URL chain and assign reputation scores based on the domain. When every domain is `google.com` or meet.google.com, the reputation score remains clean. The gateway never sees the final destination because it doesn’t follow the redirect chain dynamically—it only evaluates the initial link.

This is not a new technique. Security researchers have documented an 84-85% increase in phishing attacks leveraging Google’s open redirects since 2021. The campaign documented by Hornetsecurity in March 2026 and tracked by KnowBe4 ThreatLabs in May 2026 represents an evolution: a nested, triple-chain delivery method that weaponizes Google Meet, Google Search Redirect, and Google Ad Service in sequence.

Detection Strategy for Security Teams:

  1. Monitor `meet.google.com/linkredirect` in email and web proxy logs. Flag any instance where the `dest` parameter does not ultimately resolve to a Google-owned domain.
  2. Inspect outbound traffic for patterns: Google redirect followed by a request to `.s3.amazonaws.com` or a non-Google domain within seconds.
  3. Look for multi-encoded URLs in email attachments and hyperlinks. A URL containing `%25252F` or multiple `%25` sequences is highly suspicious.
  4. Deploy browser isolation or URL sandboxing that follows redirect chains dynamically rather than relying on static reputation.

4. Microsoft 365 Credential Harvesting: The Final Payload

When the victim lands on the final phishing page, the attack branches into two primary outcomes:

Classic Credential Harvesting: A pixel-perfect Microsoft 365 login page captures usernames and passwords. The victim’s email address is already pre-populated (via the fragment identifier), lending the page an air of legitimacy that lowers suspicion.

Device Code Phishing: Some victims are shown a fake OneDrive document preview containing a pre-generated Microsoft device code. If the victim enters this code, attackers gain full access to the victim’s corporate account without ever needing the password.

Immediate Response Actions:

If you or a user has entered credentials into such a page:

1. Change the password immediately—do not wait.

  1. Enable multi-factor authentication (MFA) if not already active.
  2. Revoke all active sessions from the Microsoft 365 admin portal.
  3. Check for mailbox forwarding rules that may have been created by the attacker.
  4. Review sign-in logs in Azure AD for unusual locations or user agents.

Azure AD PowerShell Commands for Incident Response:

 Connect to Azure AD
Connect-MgGraph -Scopes "AuditLog.Read.All", "User.Read.All"

Review recent sign-in logs for a specific user
Get-MgAuditLogSignIn -Filter "userPrincipalName eq '[email protected]'" | 
Select-Object CreatedDateTime, AppDisplayName, ClientAppUsed, 
@{N="IP";E={$<em>.IPAddress}}, @{N="Location";E={$</em>.Location.City}}

Revoke all refresh tokens for a compromised user
Revoke-MgUserAllRefreshToken -UserId "[email protected]"

5. Defensive Measures: Protecting Against Open Redirect Phishing

For Security Teams:

  1. Implement URL rewriting in your email gateway that follows redirect chains and inspects the final destination before delivering the email.
  2. Deploy browser isolation for all external links—this renders the phishing page in a sandboxed environment where credentials cannot be stolen.
  3. Create detection rules for `meet.google.com/linkredirect` with destinations outside Google’s domain list.
  4. Enable Microsoft’s Advanced Protection Program (APP) for high-risk accounts—Google reports no successful phishing against APP-enrolled users.

For End Users (Awareness Training):

  • A link starting with `google.com` does not guarantee you will stay on Google—it can redirect anywhere.
  • The padlock icon (🔒) only indicates an encrypted connection (HTTPS)—it does not verify the website’s legitimacy. A fake page can have a padlock too.
  • Before clicking, hover over the link to see the actual destination. On mobile, long-press the link to preview the URL.
  • If you are prompted to sign in after clicking a link you did not explicitly request, stop and verify the request through a separate channel.

Linux Command to Check URL Redirect Chain:

 Follow redirects and show final destination
curl -Ls -o /dev/null -w "%{url_effective}\n" "https://meet.google.com/linkredirect?dest=https://www.google.com/url?q=https://malicious.com"

What Undercode Say:

  • Trust is the vulnerability. Attackers do not need to exploit a zero-day; they abuse existing, legitimate features of trusted platforms. The open redirect (CWE-601) is not a bug—it is a design choice that becomes a weapon when chained creatively.
  • Detection requires dynamic analysis. Static reputation scoring is obsolete for this threat. Security tools must follow redirect chains in real-time; otherwise, they will continue to green-light emails that lead directly to credential theft.
  • The human element remains the final frontier. No matter how sophisticated the attack chain, the breach occurs only when a user clicks and enters credentials. Continuous security awareness training—specifically teaching users to inspect URLs before clicking—is the most cost-effective defense.

This campaign is not an isolated incident. It represents a broader trend: attackers are weaponizing the trust that organizations place in major tech platforms. Google Meet, Google Drive, Google Docs—any service with open redirect functionality can be abused in the same manner. The attack documented by Hornetsecurity in March 2026 and tracked by KnowBe4 in May 2026 is still active, with new variants emerging regularly. The infrastructure is cheap (an S3 bucket costs pennies), the execution is simple (URL encoding is trivial), and the success rate remains high because the attack exploits fundamental human psychology: if it looks like Google and smells like Google, it must be safe.

Prediction:

  • -1 Email security vendors will be forced to implement dynamic redirect following as a standard feature within the next 12–18 months. Static URL reputation will no longer be considered sufficient protection against multi-hop phishing chains.
  • -1 We will see an increase in “service chaining” attacks that abuse not just Google but also Microsoft, Amazon, and Cloudflare redirectors—any platform with open redirect functionality will be fair game.
  • +1 Browser vendors will introduce more prominent URL preview features and warnings when a redirect chain leaves a trusted domain, similar to the “dangerous site” warnings currently used for malware.
  • -1 The barrier to entry for these attacks is so low that we will likely see a surge in phishing-as-a-service offerings that package Google Meet redirect chains into easy-to-deploy kits, democratizing credential theft.
  • +1 Organizations that invest in user education and browser isolation today will be significantly better positioned than those that rely solely on gateway filters—this attack exposes the limits of perimeter security and will accelerate the shift toward zero-trust browsing models.

▶️ Related Video (78% Match):

🎯Let’s Practice For Free:

🎓 Live Courses & Certifications:

Join Undercode Academy for Verified Certifications

🚀 Request a Custom Project:

Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands

IT/Security Reporter URL:

Reported By: Aitor Herrero – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeTesting & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky

Related Posts: