The premise of reputation-based email security is straightforward: block links to malicious domains, allow links to trusted ones. That premise has now been systematically inverted. A phishing campaign actively tracked by KnowBe4 ThreatLabs routes victims through three consecutive Google-owned domains before delivering them to an attacker-controlled page — meaning every hop a secure email gateway inspects carries a clean Google reputation score, and the malicious destination never appears in the link chain that automated scanning evaluates.
The technique, which researchers have named the Nested Delivery Matrix, doesn’t require a zero-day vulnerability or a compromised Google service. It exploits the trust architecture that enterprise email security was built around, using Google Meet, Google Search Redirect, and Google Ad Service in sequence to construct a URL that is, from every automated inspection perspective, entirely legitimate. The gap between what a machine sees and what a human experiences after clicking is the entire attack surface — and it is wide enough to bypass the security controls that most enterprise organizations have invested heavily in deploying.
How the Nested Delivery Matrix Works Against Automated Inspection
The link chain KnowBe4 ThreatLabs documented follows a specific routing sequence. Microsoft’s SafeLinks processes the URL first, encountering a legitimate meet.google.com/linkredirect address. That redirects to google.com/url, a standard Google redirect service. Which then passes through adservice.google.com.ph before finally resolving to the attacker-controlled phishing page. At every inspection point in that chain, the domain under evaluation belongs to Google. Reputation scoring returns clean results across the board. The secure email gateway marks the message as safe and delivers it.
The attacker-controlled destination — the actual phishing page — never appears in the URL that security tooling evaluates. It exists only at the end of a redirect chain that terminates after automated scanning has already rendered its verdict. This is not a flaw in any specific vendor’s implementation. It is a structural limitation of link inspection methodologies that evaluate reputation at scan time rather than at click time, and it affects the category broadly.
The lures used to drive clicks are engineered with the same precision as the delivery mechanism. FedEx delivery updates, DocuSign and AutoSign document requests, Microsoft 365 password expiry notifications, payment remittances, and QR code-embedded emails are all deployed — each constructed to generate the sense of immediate required action that overrides the cautious behavior that security awareness training attempts to instill. The emotional engineering is as deliberate as the technical architecture.
Device Code Phishing Is the Payload That Should Concern CISOs Most
The campaign delivers two distinct credential theft outcomes depending on the specific lure a victim receives. The first is conventional: a pixel-perfect Microsoft 365 sign-in page with the victim’s email address pre-populated, designed to capture username and password with a legitimacy signal — the familiar email address already present — that lowers the suspicion that an unfamiliar login page would otherwise generate.
The second is considerably more dangerous from an enterprise security architecture standpoint. Victims routed to a fake OneDrive shared document are presented with a Microsoft device authentication code. If that code is entered into a legitimate Microsoft authentication page — a step that looks entirely normal to a user who believes they’re completing a standard document access workflow — the attacker silently acquires a valid corporate session token.
No password is captured.
No credentials are stolen in the traditional sense.
And, multi-factor authentication is bypassed entirely, because the device code flow is a legitimate Microsoft authentication mechanism that MFA is not designed to intercept.
Device code phishing has been documented as an attack vector for several years, but its combination here with Google’s redirect infrastructure and high-quality social engineering lures represents a maturation of the technique into a production-grade enterprise attack chain. Organizations that have positioned MFA deployment as their primary phishing defense need to reckon with the fact that device code phishing specifically targets the authentication flow that MFA governs — and succeeds without defeating it.
Why Secure Email Gateways Cannot Solve This Alone
The honest assessment of the current enterprise email security landscape is that reputation-based filtering and URL scanning — the foundational capabilities of secure email gateways — are not architecturally equipped to detect this attack pattern reliably. The Nested Delivery Matrix is specifically designed around the inspection methodology that these tools use. As long as link evaluation occurs at scan time against domain reputation, and as long as Google’s domains carry legitimate reputation scores, the attack chain will continue to pass inspection.
This is not a criticism of any specific vendor. It reflects a fundamental tension in email security architecture: real-time URL scanning must complete within the delivery latency window, which constrains the depth of redirect chain resolution that is operationally viable. Attackers who understand that constraint design redirect chains that exhaust the resolution depth before reaching the malicious destination. The Nested Delivery Matrix, at three Google hops, is precisely calibrated to that constraint.
The implication for security leaders is that email gateway investment, while necessary, cannot be the sole control layer for this class of attack. The detection gap needs to be addressed through complementary controls that operate at the identity and session layer rather than the message delivery layer.
The Identity Architecture Controls That Actually Constrain This Attack
Conditional access policies within Microsoft environments represent the most effective compensating control for the device code phishing payload, specifically. Policies that restrict device code flow authentication to managed, compliant devices — or that disable device code authentication entirely for user populations that have no legitimate operational requirement for it — eliminate the authentication pathway the attack exploits without requiring detection of the phishing attempt itself.
For the credential harvesting payload, impossible travel detection and session anomaly monitoring provide the post-authentication detection layer that pre-delivery controls miss. A session established from an IP address inconsistent with the user’s known access patterns, or authentication events occurring outside normal working hours for a given user’s historical baseline, are detectable signals that identity threat detection platforms are positioned to surface even when the phishing delivery bypassed email security controls entirely.
Browser isolation — routing web traffic through a remote browser that renders the destination page in an isolated environment before presenting it to the user — addresses the click-time gap that scan-time inspection cannot close. The technique is operationally demanding at enterprise scale but provides genuine protection against redirect chain attacks that terminate in malicious pages only after passing through legitimate infrastructure.
The Broader Trust Exploitation Pattern Enterprises Need to Confront
The Google redirect chain technique is one instance of a pattern that has been accelerating across the phishing landscape: the systematic weaponization of trusted platform infrastructure to bypass controls built around domain reputation. The same logic that makes this campaign effective against Google’s services has been applied against Microsoft, Cloudflare, and other major platforms whose domains carry the categorical trust that automated security tooling extends to recognized infrastructure.
For CISOs making email security investment decisions, the relevant question is no longer whether the gateway blocks links to malicious domains. Sophisticated campaigns have largely solved that problem by routing through domains the gateway will never block. The relevant question is what controls operate at the authentication and session layer, after delivery succeeds, because against the Nested Delivery Matrix, delivery succeeding is the baseline assumption that the defensive architecture needs to be built around.
Research and Intelligence Sources: Kb4Threatlabs
To participate in our interviews, please write to our CyberTech Media Room at info@intentamplify.com
