How a real Intuit link ended on a fake login page

By Armaan Chakrabarti · June 22, 2026
One of our agents flagged an email last week that almost anyone would have clicked. It looked like a routine remittance notice about overdue invoices, the sort of message a finance team sees a dozen times a day, and the single link inside it pointed at intuit.com. If you hovered over the link, it checked out. If you ran the domain through a reputation service, it came back clean. The reader clicked, and a few quiet redirects later they were looking at a page designed to harvest their login.
What makes this one worth writing about is that nothing in it was actually faked. The domain really did belong to Intuit, the certificate was valid, and the first thing the link touched was Intuit’s own infrastructure. The attack worked precisely because it borrowed trust that already existed rather than trying to forge it.
The email

The message that started it. The grammar is slightly off, but the link looked legitimate.
The lure was deliberately ordinary. It claimed to be remittance advice for a payment, it was signed by a finance department at a real-sounding company, and it asked the reader to download an attachment. The writing was a little clumsy, which is often the first sign that something is wrong, but busy people tend to forgive clumsy writing when the request itself feels routine. The only thing that really mattered was the link, and the link looked safe.
What one click actually did
Clicking the download link did not send the reader straight to a malicious site. It moved them through a short chain of hops, each one quietly handing off to the next:
The click began at links.notification.intuit.com, the genuine address Intuit uses to track the links inside the email it sends, so the journey really did start on Intuit’s servers.
From there it bounced to guzeldagenerji.com.tr, the website of a real Turkish company that had been quietly compromised and turned into a waypoint.
It passed through that same hijacked site a second time, which does nothing for the visitor but helps the attacker blur the trail.
It finished on a workers.dev address, where a convincing login form on Cloudflare’s free platform was waiting to collect the password.
The entire sequence took about as long as a page needs to load, and the reader saw none of it.
Why the real Intuit link is the dangerous part
Most companies do not put plain links in the email they send, and Intuit is no exception. Every link gets wrapped in a tracking redirector so the sender can measure who clicked, which is exactly what links.notification.intuit.com is for. You click an address on intuit.com, Intuit records the click, and then it forwards you on to wherever the link was pointed.
A redirector is essentially a door with a trusted name on it, and that trust is the entire point. When an attacker manages to send their own destination through that door, every automatic check sees Intuit first. The authentication records pass, because the mail genuinely travelled through legitimate infrastructure. Domain reputation passes, because intuit.com has spent decades earning a spotless record. The hover test passes, because the address under the cursor really does belong to Intuit. Everything that is supposed to catch a bad link inspects the front door, approves it, and never walks down the hallway behind it.
This is how a great deal of modern phishing works now. Attackers have largely stopped registering clumsy lookalike domains and hoping nobody notices. Instead they route their links through services that people already trust, so the reputation they need is borrowed rather than built.
Here is what that wrapped link actually looked like:

It is long and unreadable by design. Almost nobody is going to decode a string like that before opening an invoice, and the only part most people register is the beginning, which clearly says intuit.com.
The compromised site in the middle
The second stop, guzeldagenerji.com.tr, belongs to a legitimate business that had no idea it was involved. Its site was broken into and used as a relay. Routing through a hacked but reputable site accomplishes several things at once. It adds another domain with a clean history to the chain, it keeps the real destination hidden from any tool that only inspects the first link, and it gives the attacker a control point. When a blocklist eventually catches the final page, they can simply repoint the same compromised site at a fresh one and carry on, without ever touching the email already sitting in inboxes.
The page at the end
The final address lived on Cloudflare’s workers.dev, the free hosting it offers for small applications, and it is an appealing place to put a phishing page. It stands up in minutes, it comes with a valid HTTPS certificate automatically, and it sits on a domain shared by millions of legitimate projects, so no one can block it wholesale without breaking real services. The specific page was brand new, which meant it carried no reputation and sat on no blocklist. Its address was dressed up with words like pages-sessions and imp0rtant-docs, the second spelled with a zero, so that anyone who did look closely would see something that resembled a document portal.
Why hovering is no longer enough
For years the standard advice was to hover over a link before clicking it, and for years that advice worked, because attackers had to host their own obviously suspicious pages and the domain under your cursor told you most of what you needed to know. It falls apart here, because the domain under the cursor was real.
Verifying the rest of this link by hand would mean decoding a tracking URL, following three redirects, and reading the intent of whatever page loaded at the end, and nobody is going to do that in the middle of an ordinary workday. Attackers are counting on it. They are not aiming at the most careful person in the company, they are aiming at the busiest one.
A better question to ask
The useful question is no longer whether someone hovered. It is whether anything actually followed the link, opened the final page, and understood what it was built to do. A defense that stops at the words “intuit.com looks safe” is not really inspecting the threat. It is making an educated guess about a domain and trusting that the rest of the chain is friendly, and this time the rest of the chain was not.
We caught this one because our agents do not stop at the domain. They follow the link the way a person would, move through each redirect, load the page that finally appears, and judge it on what it does rather than on where it claims to come from. The verdict took a few seconds: credential theft, quarantined, with the full redirect chain attached as the explanation. Nobody on the team had to take a tracking URL apart by hand.
Trusting a domain was never quite the same thing as security. It is a reasonable assumption that holds up most of the time, and this was one of the times it did not.