The Only Fake Thing in This ShareFile Alert Was the Button

The notification said that someone had sent files through ShareFile, and almost every part of it was true. The sender address belonged to a real program director at a regional environmental nonprofit. The domain that address sat on had been registered in the mid-2000s and had spent nearly two decades doing exactly what a nonprofit domain does. The signature block underneath carried the director's real job title, a mobile number, a mailing address and working links to the organization's actual social media accounts. The brand furniture around the message was genuine ShareFile presentation, down to a real corporate mailing address in Raleigh, North Carolina, and terms of service, privacy policy and support links that all resolved to the vendor's own web properties.

One element had been changed. It was the Open button.

The message reached three mailboxes at a mid-sized U.S. city government, and the platform recorded it as a first-time sender for all three. No prior correspondence existed between the nonprofit's director and any of those recipients. A file-share alert from a stranger is not remarkable in a municipal inbox, where outside parties send documents constantly, and that ambient noise is exactly what this shape of attack is built for.

Two Authentication Verdicts, Both Correct

The header trail carried two contradictory sets of results, and reading them in the wrong order is how a case like this gets misfiled.

At the recipient organization's own inbound gateway, the first hop that evaluated authenticity, everything passed. SPF passed for the nonprofit's envelope sender, designating a Google address consistent with the domain's Workspace tenant. DKIM passed on that tenant's default signing domain. DMARC passed under a published policy of none, the permissive setting described in RFC 7489, and the ARC chain validated. The mail genuinely came out of that nonprofit's mail infrastructure.

Then the gateway did its job. It rewrote the body to wrap outbound links in its own click-time inspection service, and it forwarded the modified message onward from its own relay address. By the time Microsoft 365 evaluated the result, SPF returned a softfail (the sending address was now the gateway's relay rather than Google's), DKIM failed outright because the body hash no longer matched a signature applied before the rewrite, DMARC failed with no action, and composite authentication came back with no verdict at all.

Read cold, that second block looks like a spoof. It is not. It is a body-rewrite-after-signing artifact produced entirely inside the recipient's own security stack. The discriminating question in any case carrying this signature is whether the message authenticated at the last hop before the recipient's own gateway touched it, and here it did, cleanly. Which means the attacker never had to defeat sender authentication at all, because the attacker was sending from inside a mailbox that was already authorized to pass it.

The Button Went Somewhere Else Entirely

Unwrapping the primary call to action past the gateway's rewriter gave the real destination host: a subdomain whose label read secureportal-sharefile, sitting on an apex domain with no relationship to ShareFile, to any file-transfer product, or to the nonprofit whose employee appeared to have sent the message.

That apex was registered over two decades ago to a private individual in the upper Midwest. It is a bystander. Someone with control of its DNS or hosting appended a brand-shaped subdomain to it and pointed the lure there. Every other link in the email, the support link, the legal links, the social profiles, resolved where it claimed to. Exactly one link did not, and it was the one the message existed to get clicked.

This is the part worth internalizing. Domain age and reputation are evaluated against the apex, and this apex carried twenty-plus years of clean history. The brand name lived only in the subdomain label, where no registrar record, no creation date and no accumulated reputation applies. A control that scores the apex and moves on will hand a brand-new credential harvesting page two decades of borrowed trust.

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

A Signature Real Enough to Check

The reviewing analyst cross-referenced the mobile number in the signature block against the nonprofit's publicly listed main line and found that the two did not match. That detail came from the analyst's own external lookup rather than from anything in the headers, and it was not independently reproduced here, so it belongs in the suggestive column rather than the conclusive one. A personal mobile number would not match a published main line either.

What it does illustrate is how thin the remaining verification surface gets once the sender is genuine. There was no lookalike domain to compare, no display-name mismatch, no fresh registration, no attachment, and no broken link other than the single one that mattered. The evidence supports a compromised sender account used to mail a lure to its own contact list, which is how three municipal mailboxes with no history with this sender ended up on the same distribution. That remains an inference rather than a confirmed fact, but it is the reading most consistent with a fully authenticating message from a well aged domain carrying a signature copied from real correspondence.

The subject line offered one small tell, reading that a named person "sent you an file via ShareFile." A malformed article in an otherwise polished automated notification is the sort of residue a hand-edited template leaves behind. It is not proof of anything on its own, and it is not a signal a filter can be built on.

The economics here are well documented. The 2024 Verizon Data Breach Investigations Report places the human element in 68 percent of breaches, names stolen credentials as the single most common initial action at 38 percent, and finds phishing present in 15 percent. It also measures the median time to click a phishing link at 21 seconds. A message that authenticates, looks correct and arrives from a name the organization can verify is not asking much of those 21 seconds.

What Held the Line

Nothing in the envelope was going to stop this. Detection had to come from relationship and behavior: an unknown sender, a brand-shaped destination that did not belong to the brand, and one anomalous link on a page of genuine ones. The platform automatically resolved the incident as phishing, and all three copies were mitigated or reverted. The per-mailbox action fields recorded no explicit quarantine step, which indicates remediation was applied systemically across the affected mailboxes rather than one at a time. No stored analyst narrative was attached to the incident.

The durable lesson is that a compromised trusted sender collapses most of the checks a mail pipeline runs, so the destination behind the button has to be evaluated against the brand it claims, never against the age of the domain hosting it. That takes Adaptive AI that models who actually talks to whom, plus account takeover protection that catches the upstream compromise before a contact list becomes a target list.

Indicators of Compromise

MITRE ATT&CK Mapping

Further reading on the pattern: CISA phishing guidance, the NIST definition of phishing, and the 2023 FBI IC3 Internet Crime Report, which recorded roughly $2.9 billion in reported business email compromise losses.