A Real Intuit Notification Link, Then a 7-Day-Old Domain

The email arrived at a regional financial services company and its mortgage-lending affiliate with exactly one thing in it to click. No attachment, no second link, no signature block, no explanation of why it had been sent. The template was the generic "someone has sent you a message" document-share notice, and its single button read "read the message."

Under that button, the destination was links[.]notification[.]intuit[.]com, a real notification and click-tracking host operated by Intuit. Not a lookalike, not a typosquat: the genuine article, correctly authenticated, carrying the reputation of a large financial-software vendor.

That first hop was the whole disguise. The credential page was further down the chain, at account-maildocuments-xsaas[.]icu, on a domain that had existed for seven days when this message was sent.

The Legitimate Redirector Was the Camouflage

Two link records exist in the incident. The first is the Intuit notification URL, and it scanned clean, correctly: it is legitimate infrastructure doing what it normally does. The second is a landing page at hxxps://account-maildocuments-xsaas[.]icu/?3114ed38, which returned a partial, mixed verdict rather than a clean pass. Both records point at the same captured snapshot of that landing page: when our link analysis walked the click, the Intuit host forwarded it straight through to the .icu endpoint.

That is the mechanic worth internalizing. A redirect chain does not have to begin on infrastructure nobody trusts, and this one began on infrastructure everybody trusts, without Intuit being compromised. Notification and click-tracking subdomains exist to accept a click, look up a token, and forward the visitor onward. When the forwarding target is attacker-chosen, that host becomes a trust-laundering service with no breach of the vendor required. The record does not show which mechanism made this particular forward possible (an open-redirect parameter, a replayed campaign token, or a sub-account inside the notification platform), but all three produce the same observable: a reputable first hop, an attacker-controlled last one.

Note also what was not in the email. Nothing in it was Intuit-branded: no accounting pretext, no invoice, no renewal, no logo. The body was a generic personal document share. The brand appeared in exactly one place, inside a URL no recipient reads, so it carried all of the reputation and did none of the persuading. It was borrowed to satisfy the scanner, not to convince the human.

The Endpoint Was Barely a Week Old

WHOIS on account-maildocuments-xsaas[.]icu shows it registered through NameSilo seven days before this email went out, with its record updated two days before the send and its nameservers pointed at Cloudflare. That is the profile of a purpose-built endpoint rather than a compromised site: register, wait briefly, repoint DNS, fire.

A domain that young defeats reputation-based tooling in a specific way: it has no history to hold against it. It has never been reported, categorized, or listed in a feed, and on many reputation scales brand new and clean resolve to the same score. Meanwhile the hop in front of it had years of legitimate traffic behind it, so the reputable half of the chain is the half a scanner meets first.

The hostname fits that read, stitched together from generic trust vocabulary (account, mail, documents) on a cheap top-level domain with no brand string in it. One further inconsistency backs it up: the subject line named one attached document and the body named a different one. A document-share notice that cannot keep its own filename straight is not a notice a real vendor sent.

What the Authentication Results Actually Said

This part is easy to get backwards, so state it plainly. The message authenticated. DKIM passed with a verified signature aligned to gmail[.]com. DMARC passed. Composite authentication passed with reason=100. ARC passed. The mail came from a personal free-mail account, and free-mail accounts authenticate correctly by design.

The record does carry an SPF softfail, and the softfail is not the story. It was recorded at the Microsoft ingestion hop against a third-party relay address (108[.]60[.]195[.]213, reverse DNS in mxthunder[.]net) that is not listed in the sending domain's SPF record, because the message had already left Google's infrastructure and traversed that relay. An upstream stamp added by the relay itself records SPF passing for the true originating Google address. The softfail is an artifact of the delivery path, not evidence of spoofing and not an evasion the attacker chose. Reading it as the signal that gave this attack away would be reading it exactly backwards. Under the current DMARC specification, RFC 9989, an aligned pass on either SPF or DKIM is a pass, and DKIM alignment carried this message.

See Your Risk: Calculate how many threats your SEG is missing

Why the Layer That Caught It Was Behavioral

Every static property of this message pointed the wrong way. Authentication passed. The visible sender domain is one of the most common on the internet. The first hop in the click path was a genuine, correctly-operated host at a well-known vendor, and there was no spoofed brand in the body to match against.

What was left was behavior and context. IRONSCALES Themis scored the message at 84% confidence and labelled it for credential theft against a recipient in a high-value role. The signals were structural rather than reputational: a first-contact free-mail sender addressing a finance-sector mailbox, a single-action document-share template with no supporting context, a click path whose destination brand had nothing to do with the message, and a terminal host with no registration history. It reached four mailboxes, all quarantined and reverted roughly seventeen minutes after delivery, with the incident auto-resolving as phishing.

That gap matters at scale. The 2026 Verizon Data Breach Investigations Report puts phishing behind 16% of breaches as an initial access vector, and credentials in 39% of breaches across the full kill chain. The 2025 FBI IC3 Annual Report recorded 1,008,597 complaints against $20.877 billion in reported losses, a 26% increase year over year. A credential-harvest page one forward away from a trusted host is a cheap way into those numbers.

Indicators of Compromise

What Actually Catches This

Resolve every hop, then judge the terminal host. A scanner that stops at the first URL it sees will keep scoring a notification redirector as safe, because it is safe. The verdict belongs to where the click ends, which is the difference between URL and payload analysis and a domain-reputation lookup.

Treat notification and tracking subdomains as delivery channels, not verdicts. Legitimate click-tracking, e-signature, ESP and notification hosts appear in real mail constantly, and their reputation belongs to the platform rather than to whatever the forward points at. CISA makes the same point in its phishing guidance: the countermeasure sits at the destination, not the wrapper. NIST's definition of phishing frames it the same way.

Weight registration age on the endpoint, not the entry point. Age is one of the few properties an attacker cannot fake on a purpose-built landing domain. A seven-day-old host at the end of a forward from a decade-old one should raise the verdict on the whole chain, not average out against it.

Correlate the mismatch. A destination brand with no relationship to the message content is a cheap, strong signal that survives exactly the cases where authentication and reputation all read clean.

MITRE ATT&CK Mapping