## 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.