The Redirect Was Real HubSpot. The Hiding Was Broken.

A controls engineer at a mid-size industrial automation company received a document-share notification in February 2026. The notification claimed that the recipient's own employer's domain had shared a contract with them. It allowed twenty-four hours before the link expired, and it offered exactly one thing to click: a button reading "View document here." Every authentication check the message met, it passed. SPF passed. DKIM passed twice, with two valid signatures. DMARC passed. Microsoft's composite authentication returned pass with reason 100, and the message arrived carrying a spam confidence level of 1, which is about as benign as a rating gets.

Then the interesting part. The button did not point at a lookalike domain, a freshly registered typosquat, or a compromised WordPress host. It pointed at HubSpot.

A Share Notification With No Lookalike Anywhere

The sender alias was a short garble of letters and digits that read like an internal management label, the kind of string a recipient skims past. The local part of the sending address embedded the target company's own name twice before a random token, which is the only place in the entire message where the impersonated brand actually appeared. The envelope domain behind it belonged to a dormant Australian small business with no relationship to the recipient, the recipient's employer, or anything in the lure.

That business is a bystander, and the WHOIS record supports reading it that way. No creation date on file, parked-style nameservers, and an individual listed as registrant: the profile of a real, quiet domain rather than purpose-built attacker infrastructure. What made it useful was that its DNS now published valid Amazon SES sending records. Amazon SES was the authenticated relay, and that single fact explains the entire clean authentication result. Authentication validates the domain that sent the mail, never whether the domain's owner authorized the send. A second unrelated small-business domain, with the same dormant profile, supplied the reply-to address.

The payload story did not hold together either. The lure named a contract file with the recipient's own username appended to it, while the message actually carried a differently named PDF of roughly 122 KB that scanned clean. The document the email promised and the document the email delivered were not the same object.

The First Hop Belonged to a Real Platform

This is where the case separates from the pattern. Before Microsoft's link-rewriting layer wrapped it, the button's underlying target resolved to a per-account click-tracking subdomain on hs-sales-engage[.]com, HubSpot's genuine sales-engagement redirect service. That was read directly out of the raw HTML rather than inferred from two brands appearing near each other, which matters, because brand A's assets sitting alongside brand B's sending domain is far more often an ordinary vendor relationship than an attack. Here the redirect host was live, correctly configured, correctly authenticated, and operated by the platform that owns it.

No lookalike host was ever registered. Nothing about the redirector needed to be spoofed, because the attacker was not pretending to be HubSpot. HubSpot's tracking layer was simply borrowed, the way credential harvesting campaigns borrow file-sharing services and CDN endpoints, and for the same reason: a reputable first hop inherits reputation that attacker-owned infrastructure has to build. The 2026 Verizon Data Breach Investigations Report puts phishing behind 16% of breaches as an initial access vector, with credentials involved in 39% of breaches across the full kill chain. Reputation borrowing is how a modern credential lure survives the first filter.

Why the Link Verdict Says Less Than It Appears To

The link scan returned clean, with no screenshot captured. Read carefully, that verdict is a statement about the first hop only. A tracking redirector serves no content worth judging; it issues a redirect and moves on. Because the chain was fronted by a reputable, authenticated host, the record never captured whatever sat behind it, and we will not claim to know. What we do have is a platform verdict rather than an observed destination: Themis scored the message at 90% confidence and labeled it credential theft, drawing on a content model, community resolutions of similar incidents, and sender reputation compared against known phishing behavior.

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

The Hiding Rule That Hid Nothing

Below the call to action, the message ran roughly fifty blank line breaks and then a block of text beginning with a bare CSS declaration, .hidden-block { display: none; }, sitting in the body as plain content. It was never placed inside a stylesheet block anywhere in the document. Immediately after it came a division of exactly that class.

No mail client applies a style rule that is not in a stylesheet. The concealment therefore did nothing at all, and the content the attacker intended to be invisible would have rendered as visible clutter in any client that displayed the message. Inside that block sat an unrelated commercial billing thread between two businesses, written in a language unrelated to the recipient's, along with direct contact details for a person with no connection to any party in this attack. None of it is reproduced here, and none of it belonged in a stranger's inbox.

Two things follow. First, whatever the padding was for, most likely defeating similarity and dedup filtering that keys on message body length and structure, it failed at its own job. Second, a kit defect is itself a detection surface. A message whose raw source contains an orphaned CSS rule, dozens of consecutive blank breaks, and borrowed correspondence in an unexpected language is structurally anomalous long before anyone resolves its links.

What the Authentication Stack Was Never Going To Catch

Nothing here defeated SPF, DKIM, or DMARC. The mechanisms worked exactly as RFC 9989 specifies. They validate a sending domain, which is why a hijacked domain plus a legitimate relay produces a full pass, and they evaluate nothing whatsoever about where an embedded redirect terminates. Both abuse layers in this campaign, the sending-domain hijack and the redirector-fronted link, sit outside what the protocols measure. CISA's phishing guidance and the NIST definition of phishing both frame the threat around deception of the recipient rather than technical failure of transport, and this message is a clean illustration of why.

What actually flagged it was behavior and structure: a first-time sender, a claim that the recipient's own domain had shared a file, a doubled brand name buried in a local part, and a lure filename mismatched against the real attachment. One mailbox was affected, and the message was mitigated roughly five seconds after receipt, with no user action required. Reported losses in the 2025 FBI IC3 report reached $20.877 billion across 1,008,597 complaints, and the gap between a five-second mitigation and a click is where that number is decided.

The practical takeaway for defenders is narrow and useful. Stop treating a reputable first hop as a clean chain. URL protection that resolves only the host it is handed will keep clearing links like this one, because the host it is handed is genuinely fine. The abuse is one hop further in, and the signal that it exists is usually not in the link at all.

Indicators of Compromise

MITRE ATT&CK Mapping