# Nested Triple-Chain Google Domain Phishing — Microsoft SafeLinks -> meet.google.com/linkredirect -> google.com/url -> adservice.google.com.ph Evades SEGs and Lands M365 Credential Theft Plus OAuth 2.0 Device-Code Phishing (KnowBe4 ThreatLabs Nested Delivery Matrix)

> KnowBe4 ThreatLabs is actively tracking a phishing campaign dubbed the Nested Delivery Matrix that stacks three Google-owned services (Google Meet linkredirect, Google Search Redirect, and Google Ad Service on the .com.ph TLD) inside a single URL — typically wrapped first by a Microsoft SafeLinks rewrite — to defeat Secure Email Gateway (SEG) reputation and URL-detonation engines. Lures impersonate FedEx, DocuSign/AutoSign, Microsoft 365 password-expiry alerts, payment remittances, and QR codes; landing pages either pre-populate the victim email on a pixel-perfect M365 sign-in to harvest credentials or display a fake OneDrive preview that tricks the user into typing an attacker-supplied Microsoft device authentication code into login.microsoftonline.com/common/oauth2/deviceauth, giving the operator an MFA-bypassing session token without ever stealing the password.

- **Published:** 2026-05-27T00:00:00Z
- **Last reviewed:** 2026-05-27T00:00:00Z
- **Canonical:** https://intel.threadlinqs.com/threat/TL-2026-0601
- **ID:** TL-2026-0601
- **Severity:** HIGH
- **Category:** PHISHING
- **Status:** ACTIVE
- **Detections:** 9 · **IOCs:** 27 (full data via the Threadlinqs MCP server — Purple tier)

## Description

## Overview

KnowBe4 ThreatLabs published a PHISH ALERT in late May 2026 documenting a high-volume phishing campaign that abuses a triple-nested chain of legitimate Google-owned domains to smuggle malicious links past Secure Email Gateways (SEGs), URL detonation sandboxes, and reputation-based filters. Because each intermediate hop terminates on a Google-controlled host — and the first hop is frequently wrapped by Microsoft Defender for Office 365 SafeLinks — the URL the SEG sees and detonates is, to its inspection engines, a trusted Google service. The malicious endpoint never appears in the inspected URL chain because the redirect resolution only fires on actual click in the victim's browser.

## Triple-Chain Architecture (Outer to Inner)

1. **Microsoft SafeLinks wrapper (optional outer layer)** — `safelinks.protection.outlook.com/?url=<encoded>` — added automatically by Defender for Office 365 when the message hits a protected tenant; ironically lends the email an extra Microsoft-blessed reputation signal as it traverses downstream secure gateways.
2. **Google Meet linkredirect (hop 1)** — `https://meet.google.com/linkredirect?dest=<url-encoded-target>` — an open redirect inside the Google Meet web client originally intended for in-meeting chat link safety prompts. Because Google Meet is on the SEG allow-list of essentially every enterprise, neither the host nor the path triggers a flag.
3. **Google Search Redirect (hop 2)** — `https://www.google.com/url?q=<url-encoded-target>&sa=...` — the classic search-result wrapper Google uses for click tracking. Attackers chain it as the destination of hop 1 to add a second trusted-domain hop and to consume any SEG hop-depth heuristic budget.
4. **Google Ad Service (hop 3)** — `https://adservice.google.com.ph/aclk?...` — the Philippine TLD variant of the Google Ad redirector. Researchers note attackers preferentially pick non-US country-code TLD variants (`.com.ph`, `.com.br`, `.co.id`) because those subdomains receive less scrutiny from US-region SEG telemetry yet inherit Google's wildcard SSL and SafeBrowsing trust.
5. **Cloudflare Worker delivery shim (optional hop 4)** — `*.workers.dev` URLs such as `Link-form-unj9.p-sm7rw6ru.workers.dev` and `data-cloud-ofe8.p-8yejy42o.workers.dev` host JavaScript fingerprinters that gate access to the final phishkit based on User-Agent, geo, and TLS JA4 — bots and sandboxes are silently 302'd to a benign Google page; real victims receive the phishkit HTML.
6. **Attacker-controlled landing page** — one of ten observed lookalike domains (e.g. `vazquezfleytas.com`, `unitedtechnofzmlogies.vu`, `staiwooje.app`) hosting one of two payload templates.

## Dual-Payload Model

### Template A — Pixel-Perfect M365 Credential Theft
The landing page is a near-frame-perfect clone of `login.microsoftonline.com/common/oauth2/v2.0/authorize` rendered with the same Fluent UI fonts and tenant branding lookup logic. Critically, the victim's email is pre-populated into the username field via a `?login_hint=` style parameter passed through the entire redirect chain (URL fragments survive Google's `?q=` wrappers when the operator builds the chain correctly). The victim therefore arrives at what appears to be their own tenant's sign-in page mid-authentication and only needs to enter their password. Submitted credentials are POSTed to the Cloudflare Worker which forwards them to a Telegram bot and an attacker-controlled mailbox; some samples also relay the password live to the real Microsoft endpoint and capture the resulting session cookie (adversary-in-the-middle style, similar to Evilginx/EvilProxy phishkits).

### Template B — OAuth 2.0 Device-Code Phishing (MFA Bypass)
This is the higher-impact payload. The landing page mimics a OneDrive document preview that is 'protected' and asks the user to verify their identity. It displays a Microsoft device authentication code (e.g. 'AB7-CDE9F') and instructs the victim to:
1. Visit `https://login.microsoftonline.com/common/oauth2/deviceauth` (a real Microsoft URL),
2. Enter the displayed code,
3. Approve the prompt.

Under the hood the attacker has just issued an OAuth 2.0 device-code flow request (RFC 8628) against Microsoft Entra ID using a first-party Microsoft client ID (commonly `d3590ed6-52b3-4102-aeff-aad2292ab01c` for Microsoft Office or `1950a258-227b-4e31-a9cf-717495945fc2` for Azure Active Directory PowerShell) and is polling the token endpoint. When the victim completes the prompt — which Microsoft renders as a legitimate first-party experience and which many Conditional Access policies treat as 'compliant device flow' — the attacker's polling call returns access_token + refresh_token bound to the user's full identity, with whatever MFA satisfaction the victim just performed. No password ever leaves the victim. Multi-factor prompts the victim already passed (FIDO2, Authenticator push, even number-matching) are silently consumed by the attacker session because the device-code flow does not distinguish which device the request originated from.

## SEG Evasion Principle

Legacy and modern SEGs (Mimecast, Proofpoint TAP, Microsoft Defender, Cisco IronPort, Barracuda) score URLs on:
- Domain reputation (Google = whitelist),
- TLS certificate issuer (Google CA = trusted),
- Page content fingerprint after detonation (the *first* hop renders a 200 OK Google redirector page with no overtly malicious DOM).

Most SEGs limit redirect-chain following to 3–5 hops and abort with a 'safe' verdict on timeout. The triple-Google chain plus optional SafeLinks consumes the entire hop budget without ever revealing the attacker domain. Detonation-time geo (typically US datacenter IPs) and User-Agent (Bot UAs) cause the Cloudflare Worker to serve a benign page, so even SEGs that do fully follow the chain see harmless content.

## Adversary Tradecraft and Attribution

Attribution is currently undefined. The lookalike domain naming convention (legitimate-looking compound English words with single-character substitutions or extra characters, e.g. `unitedtechnofzmlogies.vu`, `cloudbemismanufacturingcompanygroup.rydezyhrsysteminc.vu`, `servicetriumphgroupsimplyappraisals.spectrhwqumbrands.vu`) and the heavy reliance on the `.vu` (Vanuatu) and `.app` TLDs is consistent with bulk infrastructure procurement from registrars with weak abuse response. The dual-template phishkit, Cloudflare Worker fronting, and Telegram exfil suggest a Phishing-as-a-Service (PhaaS) origin — the TTPs overlap with kits previously branded Tycoon 2FA, Mamba 2FA, and Caffeine, though no kit signature has been confirmed in this campaign. Targeting appears opportunistic across English-speaking M365 tenants in North America and Western Europe, with notable concentrations in financial services, healthcare, manufacturing, professional services (DocuSign lure resonates), and government supply-chain contractors (FedEx lure resonates).

## Defensive Implications

Because the abused redirectors are Google-owned and the Cloudflare Worker hosts are short-lived, blocking the redirector hostnames is operationally impossible (it would break Google Meet and Search) and blocking individual lookalike domains is a losing reactive race. The durable controls are: (1) detect the device-code flow itself in Entra ID sign-in logs (`authenticationProtocol = 'deviceCode'` from a public-client first-party app to an unusual location), (2) detect OAuth consent grants on first-party app IDs from unusual geos, (3) block adservice.google.* country-code TLDs at the proxy if not needed for business, and (4) user awareness training on the device-code flow specifically — most users have never seen one outside of TV-app sign-in and are unaware that typing a code on a real Microsoft page can grant a session to a third party.

## MITRE ATT&CK

- T1589 Gather Victim Identity Information
- T1583 Acquire Infrastructure
- T1584 Compromise Infrastructure
- T1608 Stage Capabilities
- T1566 Phishing
- T1078 Valid Accounts
- T1204 User Execution
- T1036 Masquerading
- T1684.001 Impersonation
- T1564 Hide Artifacts
- T1497 Virtualization/Sandbox Evasion
- T1056 Input Capture
- T1528 Steal Application Access Token
- T1539 Steal Web Session Cookie
- T1621 Multi-Factor Authentication Request Generation
- T1102 Web Service
- T1071 Application Layer Protocol
- T1114 Email Collection
- T1567 Exfiltration Over Web Service
- T1048 Exfiltration Over Alternative Protocol
- T1531 Account Access Removal

## Sources

- [Hackers Abuse Trusted Google Domains to Hide Phishing Links From Email Gateways (Cyber Security News)](https://cybersecuritynews.com/hackers-abuse-trusted-google-domains/)
- [KnowBe4 ThreatLabs PHISH ALERT — Abuse of Google Infrastructure for Phishing (X/Twitter @Kb4Threatlabs)](https://twitter.com/Kb4Threatlabs)
- [Microsoft Learn — Block authentication flows with Conditional Access policy (device code flow)](https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-block-authentication-flows)
- [RFC 8628 — OAuth 2.0 Device Authorization Grant](https://datatracker.ietf.org/doc/html/rfc8628)
- [Microsoft Threat Intelligence — Token theft attacks via adversary-in-the-middle phishing kits (Tycoon 2FA, Mamba 2FA, Caffeine)](https://www.microsoft.com/en-us/security/blog/)
- [MITRE ATT&CK — T1566.002 Spearphishing Link](https://attack.mitre.org/techniques/T1566/002/)
- [MITRE ATT&CK — T1528 Steal Application Access Token](https://attack.mitre.org/techniques/T1528/)
- [MITRE ATT&CK — T1102 Web Service (C2 via legitimate web services)](https://attack.mitre.org/techniques/T1102/)
- [MITRE ATT&CK — T1656 Impersonation](https://attack.mitre.org/techniques/T1656/)
- [Volexity — Russian SVR/APT29 use of OAuth 2.0 device code phishing (technique precedent)](https://www.volexity.com/blog/)

## Full data

Detection queries (Splunk SPL / Microsoft KQL / Sigma) and IOC values require the Threadlinqs MCP server (Purple tier): https://intel.threadlinqs.com/mcp

Canonical: https://intel.threadlinqs.com/threat/TL-2026-0601