Key takeaways
A phishing campaign chains six legitimate Google services (Google Meet, DoubleClick, Custom Search, Image Search, Tag Manager, Analytics) into a redirect so email gateways see only trusted Google domains and let the link through (source).
The victim's email address is base64-encoded in the URL's hash fragment, which the browser strips before sending any request, hiding the targeting from server-side scanners (source).
At the end of the chain, the victim gets a fake corporate login page that harvests credentials, or a fake verification prompt that installs ScreenConnect for remote access.
The fake login page builds itself from the victim's email alone and displays a live screenshot of their real company website behind the login. Stolen credentials reach the attacker's Telegram channel within seconds.
Every link-based defense (reputation, URL scanning, gateway inspection) is defeated by design. The one place left to catch it is the rendered page in the browser, at the moment before anything is entered.
Most phishing gets caught, or missed, at the link. Security gateways inspect the address, check its reputation, follow where it points, and decide whether to let it through. A campaign documented this month is built to win that inspection on purpose. It does not hide the link from your filters. It hands them exactly what they are trained to trust.
Researchers at KnowBe4's Threat Lab described an ongoing global campaign that chains together six legitimate Google services into a multi-hop redirect. By the time an email gateway inspects the link, every hop it sees is a real Google domain, so the URL passes. As the researchers put it, most phishing bets on the gateway missing a bad link. This one does not need the gateway to miss anything. It feeds the gateway exactly what it expects: trusted Google domains at every hop.
At the end of that chain sits the actual attack: a fake corporate login page, or a fake identity-verification prompt that installs a remote-access tool. This matters for every organization, because the defenses most companies rely on to stop phishing, link inspection and reputation filtering, are precisely the ones this campaign is designed to defeat.
How the attack defeats your filters
Start with what normally stops a phishing link. An email security gateway sees a URL, checks it against reputation databases, and often follows the redirects to see where it lands. If the destination or any hop looks bad, it blocks the message. This works because most phishing links eventually point at something with a poor or unknown reputation.
This campaign breaks that model in two ways.
First, the redirect chain is built entirely from trusted infrastructure. The researchers describe a three-hop chain routed through six Google services, including Google Meet, DoubleClick ad infrastructure, Google Custom Search, Google Image Search, Google Tag Manager, and Google Analytics. When a gateway follows the link, every hop it can see is a legitimate Google domain with an excellent reputation. There is nothing bad to flag, so the message passes. The trust your filters place in Google is turned into a delivery mechanism.
Second, the targeting is hidden from scanners. The victim's email address is encoded in base64 and tucked into the URL's hash fragment, the part after the #. Browsers strip that fragment before sending any request to a server, so it never appears in server-side logs and most URL scanners never see it. The link looks generic to automated inspection, while the attacker's page quietly reads the fragment to tailor the attack to a specific person. As the researchers note, an email address after the # in a link is itself a signal that the link was built for you specifically.
The result is a link that is clean at every point a machine can inspect it, right up until it renders in a real browser.
What waits at the end of the chain
Once the redirects resolve, the campaign delivers one of a few payloads, and the sophistication continues into the page itself.
In many cases, the victim lands on a fake corporate login page. What makes it convincing is that it is assembled on the fly. The page's JavaScript reads the victim's email address, then constructs a login screen branded for that person's employer, and even renders a live screenshot of the victim's real corporate website behind the login form. The interface is multilingual and localizes to the victim's region. To the employee, it looks exactly like their own company's sign-in. The moment they enter their credentials, those are sent to the attacker's Telegram channel within seconds, along with their IP address, geolocation, browser details, and their organization's verified mail records.
In other cases, the page presents a fake identity-verification prompt, and a script installs ScreenConnect, a legitimate remote-access tool, giving the attacker hands-on control of the machine. This is the same move we described in our post on fake-document phishing that installs remote-access software: a real IT tool, delivered under a believable pretext, that antivirus has little reason to block.
The lures that carry people into the chain vary widely, by design: document review, an expiring password, a package delivery, a payment notification, a government benefit, a voicemail. There is no single tell to train against.
Why the usual advice runs out here
Two of the most common recommendations after a phishing incident are "improve your email filtering" and "turn on MFA." Both are worth doing, and both have real limits against this specific campaign.
Better link filtering does not help when the link is engineered to pass filtering. The whole design goal is to present trusted domains to inspection and hide the targeting from scanners. And MFA has gaps here too. KnowBe4's threat intelligence lead notes that the campaign's remote-access and device-code paths never touch a login form, so there is no MFA challenge to protect. On the credential-harvesting path, a convincing fake login can still capture what an employee types.
This is the same lesson running through modern phishing, which we covered in why the old warning signs no longer work: the tells have been engineered out, and the defenses that operate before the page, on the link and the sender, are exactly what attackers now optimize against. You cannot ask an employee to spot a flawless, personalized fake of their own company's login, and you cannot count on a filter that has been handed only trusted domains to see.
Where this can actually be stopped
If the link is built to pass every inspection, and the page is a pixel-perfect, personalized fake, the defense has to move to the one place the attack can no longer hide: the rendered page itself, in the browser, at the moment before the employee acts.
That is where Haven works. Haven is a browser extension that checks whether a page truly is who it claims to be, rather than trusting how the user got there or how convincing the page looks. It does not rely on the link's reputation or the domain's history, which is exactly what this campaign defeats. When an employee lands on a fake corporate login page at the end of one of these redirect chains, Haven flags it as an impersonated login before they enter anything, no matter how clean the link was or how perfectly the page is assembled. And because one of the payloads is a fake verification prompt that pushes a remote-access install, Haven pauses risky downloads so the employee can stop before ScreenConnect lands.
To be precise about scope: Haven is a browser extension, not an email gateway. It does not inspect the redirect chain or stop the email, and it does not need to, because it works at the destination page, which is exactly where the campaign's link-based evasion stops mattering. Haven catches the two payloads that put a fake page in front of the user: the impersonated login and the fake verification-and-download prompt. A pure device-code interception flow that uses a legitimate provider page, with no impersonated page rendered, is a different mechanism and is best addressed with Conditional Access and by disabling device-code flow where it is not needed. Haven closes the gap those controls leave open: the flawless fake page an employee is about to trust.
For organizations and the MSPs that protect them, Haven for Business extends this browser-level check across every employee's browser, which is the level this campaign operates at. As we argued in why small businesses have a last-mile problem, tools and training protect everything up to the final moment of decision. This campaign is built specifically to survive everything up to that moment. The rendered page is where it finally has to show itself, and it is the last place left to catch it.
About Haven
Haven is a browser extension that helps people make safer trust decisions online, before a scam can cost anything. It works at the moment someone is about to click a link or enter a password, flagging fake and impersonated login pages, suspicious links, and look-alike sites, and pausing risky downloads. Rather than only checking a page against a list of known-bad sites, Haven analyzes the actual page in front of the user, so it can catch brand-new and convincing fakes that other tools miss.
Haven is free for individual use. For teams, Haven for Business extends this browser-level protection across every employee. Haven is operated by MirrorTab, Inc.
