When the phishing link starts on google.com: the six-hop chain behind the 2026 Microsoft 365 attacks
A link can begin on a domain you trust completely and still finish on a fake Microsoft sign-in page. That is not a hypothetical. It is how a campaign running through mid-2026 has been getting into company mailboxes, and the whole trick lives in the gap between the first hop and the last one.
The Brief: judge the page you land on, not the domain you clicked.
Attackers are chaining legitimate services so that a phishing link opens on google.com and quietly ends on a copy of the Microsoft 365 sign-in page. Arctic Wolf Labs reported in July 2026 (writeup) that hundreds of organisations were hit this way, and Microsoft tracks overlapping activity as Storm-2755 and Storm-2657. Because the visible domain is real, hovering the link tells you almost nothing. The only thing that settles it is what loads at the end of the chain, and whether that page lives on a Microsoft domain or on somebody else's proxy.
Add to Chrome, free
Get the free Android app
or scan a URL now →
Six hops, one lie
The interesting part of this campaign is not the fake login page. Convincing copies of the Microsoft sign-in screen have existed for years. What is new is the road that gets you there. Arctic Wolf traced a six-stage redirection chain in which every early step is a service no security team would think to block.
It begins with a Google Meet redirect link. That passes through Google's own outbound-link infrastructure, then into a Google Ads Campaign Manager click tracker, the kind of dynamic /ddm/clk URL that advertisers use to measure clicks and that carries a destination inside it. From there the victim is handed to an HTML page sitting in an Amazon S3 bucket, and that page finally pushes the browser to the attacker's infrastructure, which proxies the real Microsoft OAuth authorisation endpoint.
Count what a filter sees along that route: Google, Google, Google, Amazon. Four hops of unimpeachable reputation before anything attacker-controlled appears. By the time the browser reaches the part that matters, the email has already been delivered, the link has already been clicked, and the reputation checks that were supposed to help have all returned green.
Why the first hop does all the work
Every piece of advice about phishing links tells you to hover before you click and look at the domain. This chain is built specifically to survive that advice. Hover, and you see google.com. Paste it into a chat with a colleague and it still says google.com. Forward it to IT and the domain reputation lookup comes back clean, because the domain genuinely is clean. Google is not compromised here. Its redirect and advertising infrastructure is being used exactly as designed, just with a destination the designers did not have in mind.
This is the same borrowed-trust mechanic we have written about in the FBI advisory on cloaked redirects, only turned up a level. There the redirector was obscure. Here it is one of the most recognisable domains on the internet, and that makes the reflex to trust it almost automatic.
It is worth being precise about what is and is not happening. Nobody has broken into Google. An open redirect and an ad click tracker are features: one takes a destination as a parameter, the other exists to forward clicks. Neither was ever meant to be a security control, and treating a familiar hostname as a safety signal is what the attacker is charging you for.
The page decides whether you are worth showing
If a researcher lands on the final page, the campaign would rather show them nothing. So before the fake sign-in screen appears, JavaScript on the page fingerprints the visitor: operating system, screen dimensions, browser language, time zone offset. That profile goes to a PHP endpoint, and a public IP-geolocation service is queried to work out where the visitor is. Only a visitor who looks like a plausible target gets the phishing page.
The same profile is then reused against the victim. When the stolen session is replayed, the sign-in comes from a residential proxy chosen to match the victim's country, so the login looks like an ordinary person on an ordinary home connection rather than a datacentre. Arctic Wolf observed those sign-ins repeating at roughly eight-hour intervals from rotating residential addresses, which is patient enough to look like a person checking mail across a working day.
The tell, when there is one, is that the disguise is imperfect. Impossible combinations show up in sign-in logs, mobile Safari reported on Windows being the clearest example. No real user generates that.
What they actually came for
Once a session cookie is captured, the attacker is inside without ever knowing the password, which is why multi-factor authentication does not stop this class of attack. We covered that mechanism in detail in how adversary-in-the-middle attacks steal a 2FA session, and in the FBI Kali365 warning about OAuth device-code phishing. The 2026 twist is what happens next, and it is unusually quiet.
Rather than mass-mailing everyone in the address book, the intruder queries Microsoft Graph to find people by role, looking for payroll, HR, finance and administrative staff. Their mailboxes are then read for invoices, payment instructions and banking details. A narrow inbox rule is often created, moving specific messages to Deleted Items so a warning or a query about a changed bank account never reaches the person who would have spotted it.
In most cases Arctic Wolf saw no MFA method being added, no password changed, and no onward phishing from the compromised account. All of those actions raise alerts. Doing none of them keeps the door open, and the payoff arrives later as a redirected salary run or an invoice paid to the wrong account, the same destination as a classic wire-transfer fraud but reached through a stolen session rather than a spoofed sender. The organisations named span healthcare, education, manufacturing, government and professional services across the United States, Canada and Europe.
Trace the link to its last hop, not its first
The practical defence for this chain is a shift in habit rather than a new product: stop grading a link by the domain you can see, and start grading it by the page that finally loads. Everything in the chain before that last hop is borrowed credibility.
That is the part SafeBrowz is built around. Our three layers work on the address you end up at and the page it serves. The local layer looks at the shape of that final address, the reputation layer checks it against a 550+ brand database along with Google Safe Browsing, PhishTank, URLhaus and our blocklists, and the AI layer reads the rendered page in over 100 languages. A proxied copy of the Microsoft sign-in screen is, to that last layer, a page presenting itself as Microsoft while living somewhere that is not Microsoft, which is exactly the brand-impersonation pattern it is trained to call out. For links that are shortener-shaped, we also follow the hops ourselves, up to five of them, including JavaScript and meta-refresh forwards, so you get the verdict for where the link ends rather than where it starts. You can try that on any link with the free URL checker, and this guide to checking where a shortened link goes walks through it.
Being straight about the limits matters more than a clean claim. A wrapper like this one, where the destination is buried in a query parameter on a large legitimate host, is not something we chase hop by hop, so the wrapper on its own can look unremarkable. What protects you is the verdict on the page that opens. And once an account has already been taken over, an inbox rule quietly deleting mail is inside Microsoft 365, not in the browser, so that part belongs to your administrators and your sign-in logs, not to an extension.
Five things that give the chain away
- A sign-in prompt you did not start. You clicked a meeting or document link and ended up being asked to authenticate. Real sessions rarely work that way, and the request should be treated as the anomaly it is.
- A very long URL with another URL inside it. Click trackers and redirects carry their destination as a parameter. If you can see http appearing a second time inside the address, the visible domain is not the destination.
- The address bar changes host while you wait. A short pause and several hostnames flicking past before a login screen settles is the chain doing its work.
- The login page is not on a Microsoft domain. Microsoft 365 sign-in happens on login.microsoftonline.com. Anything else asking for those credentials is not Microsoft, however faithful the pixels are.
- Sign-in logs with impossible devices. For admins, the mobile-browser-on-desktop-OS combination and repeated logins from rotating residential addresses are the fingerprint of a replayed session.
If you want the wider pattern rather than this one campaign, how to spot a Microsoft phishing email and the device-code phishing explainer cover the two other routes attackers take into the same accounts.
If you think you clicked
Speed matters more than certainty here, because the asset stolen is a session, not a password. Sign out of all sessions for the account, which invalidates the stolen cookie, then reset the password and re-register multi-factor authentication. Check the mailbox for inbox rules you did not create, particularly anything routing to Deleted Items or forwarding externally. Review sign-in logs for the impossible-device pattern above, and tell finance directly, by a channel other than email, that any bank-detail change received recently needs to be re-verified by voice.
A link that starts on a domain you trust? Check where it ends.
Paste the full link and we judge the page it actually lands on, not the hostname you hovered. Our 3-layer engine (Local + APIs + AI) returns a verdict in about 3 seconds. Free, no signup.
Common questions
The link really was a google.com address. How can it be phishing?
Because the address you see is only the first stop. Google's redirect and advertising infrastructure accepts a destination as part of the URL, which is what makes click tracking work at all. An attacker supplies their own destination, so the link genuinely starts at Google and genuinely ends somewhere else. Nothing at Google has been compromised. The lesson is that a familiar hostname at the start of a link is not evidence about the page at the end of it.
I have multi-factor authentication switched on. Am I not protected?
Not against this. An adversary-in-the-middle page sits between you and the real Microsoft login, passes your password and your one-time code straight through, and captures the session cookie that Microsoft hands back. The attacker then replays that cookie, so they never need your password or your code again. Phishing-resistant methods that bind to the site, such as passkeys or FIDO2 security keys, are the ones that break this, because they refuse to authenticate to a domain that is not the real one.
How would I know the account was already taken over?
The behaviour in this campaign is deliberately quiet, so look for absence rather than noise. Check for inbox rules nobody created, especially ones moving specific messages to Deleted Items. Look at sign-in logs for repeated access from rotating residential addresses, or device and browser combinations that cannot exist, such as a mobile browser reported on a desktop operating system. Attackers here usually avoid changing passwords or MFA methods precisely because those changes generate alerts.
Why are payroll and finance staff the ones being hunted?
Because the money is one email away. Once inside a mailbox, the intruder uses Microsoft Graph to find people by role, then reads invoices, payment instructions and banking details. The end goal is usually a redirected salary payment or an invoice paid into an attacker's account, which is why a compromise can look like nothing at all for weeks and then surface as a missing payment.
Can SafeBrowz stop a chain like this?
It judges the page you land on, which is where this attack becomes visible. The final hop is a copy of the Microsoft sign-in screen hosted somewhere that is not Microsoft, and that is the brand-impersonation pattern our three layers are built to flag, using a 550+ brand database plus reputation feeds and an AI read of the page in over 100 languages. For shortener-shaped links we follow the hops ourselves, up to five, including JavaScript and meta-refresh forwards. What we do not do is chase a destination buried in a query parameter on a large legitimate host, so the wrapper itself may look ordinary, and anything that happens inside the mailbox after a takeover is a job for your Microsoft 365 administrators rather than a browser extension.