The Fake ShareFile Alert on a Real ShareFile Link

An inbox at an insurance and underwriting company received what looked like the most routine message in modern business: an automated ShareFile notification announcing that a folder had been shared. The From address was mail@sf-notifications[.]com, and that detail is what made the message dangerous rather than obviously fake. sf-notifications[.]com is a real domain, genuinely registered to the vendor behind ShareFile. This was not a look-alike, a typosquat, or a freshly registered clone. It was the actual brand-notification domain a recipient would expect to see on a legitimate share alert. The display name attached to it was that of a purported business contact, adding a familiar human face to the automation.

A real brand domain that still failed its own authentication

Owning a domain and being authorized to send from it are two different things, and this message proved the gap. At final delivery, the email failed SPF, because the connecting client was not authorized for the sending domain. It failed DKIM, because the body hash did not verify. And it failed DMARC outright, which resolved the message to a quarantine action. A genuine ShareFile notification travels through the vendor's authorized mail path and lands with clean, aligned authentication. This one did not. An earlier relay hop showed a pass for a bounce-style envelope address, the kind of VERP return-path artifact that can look reassuring in isolation, but the authentication that governs the visible From header collapsed by the time the message reached the mailbox.

That is the whole tension of this case. If you built your defenses around domain reputation alone, sf-notifications[.]com would sail through as a trusted SaaS vendor. If you actually checked whether the message was authorized to carry that domain, it fell apart immediately. Authentication is a verification of the sending path, and this attacker never had the sending path, only the brand name.

The link was real, which is exactly the problem

The call to action pointed to insuranceriskmanagement[.]sharefile[.]com, a live folder hosted on a genuine ShareFile subdomain. There was no malicious attachment. The payload was the notification itself and the credential-harvest surface waiting behind that folder link. Because the destination lived on real ShareFile infrastructure, automated scanners cleared it on reputation. The platform is trusted, the subdomain resolves, the certificate is valid, and the folder is login-walled, so a scanner sees a legitimate SaaS login prompt and nothing more. What it cannot see is what an attacker placed on the other side of that login wall.

This is the abuse of a legitimate web service as hosting, a technique catalogued as T1102 in the MITRE ATT&CK framework, paired with the delivery of a malicious link, T1566.002. The attacker outsourced the trust signal to a real vendor. ShareFile provides the reputation, the TLS, and the plausible login page. The attacker provides only the lure. It is a clean division of labor that turns a defender's allow-list into a liability.

Reply here, not there

The final piece of the design was a quiet redirection. The Reply-To header did not point back to any ShareFile or vendor address. It pointed to an unrelated insurance-industry domain, an address engineered to look like it belonged to a colleague or vendor in the same sector as the target. A recipient who hit reply, perhaps to ask a question about the shared folder, would have been talking to the attacker's channel rather than the apparent automated sender. Reply-To diversion is how these operators keep a conversation alive off-channel once the notification does its job. The visible identity and the reply destination were never the same.

Detection: the failure and the pattern

The 2024 Verizon Data Breach Investigations Report puts phishing in 15 percent of breaches and stolen credentials in 38 percent, the single most common initial action, with the human element a component of 68 percent of all breaches. The same report clocks the median time to click a phishing link at 21 seconds and to submit data at 28 seconds. Against a lure that borrows a trusted brand and a trusted link, those windows are brutally short. CISA's phishing guidance makes the same point differently: stopping the attack cycle early beats hoping a user hesitates.

Our Adaptive AI analyst, Themis, did not lean on any single technical verdict, because most of them were unhelpful. The link scanned clean. The brand was real. What Themis surfaced was the combination of an authentication failure on a message pretending to be a routine, automated vendor notification, and the recurrence of the same templated lure against the same organization. The pattern did not arrive once. A near-identical message struck a second employee at the company weeks and then months later, a cadence that a reputation-only allow-list treats as unrelated noise but that a system with memory reads as a campaign.

That recurrence is the reason this belongs in a conversation about account takeover protection rather than one-off spam filtering. A folder-share lure that harvests a credential is not the end of the story. It is the opening move toward an authenticated session inside the very SaaS tools that make modern brand-notification phishing so effective. Teams that assume a trusted-vendor domain plus a trusted-vendor link equals a safe message are exactly the ones an attack like this is built for, which is why measuring what your gateway waves through with a SEG gap assessment is worth the hour it takes.

Indicators of Compromise

MITRE ATT&CK Techniques

The takeaway

A real brand domain, a real vendor link, and a familiar-sounding contact are not proof of anything. Authentication verifies the path a message actually traveled, and this message could not survive that check even while wearing the right name. When the brand and the link are both borrowed from a trusted vendor, the failure signals and the pattern over time are what remain, and they are enough if you are watching for them.