The SharePoint Share That Borrowed Cloudflare's Reputation

The same message was addressed to three mailboxes at a boutique financial advisory and wealth-management firm, and by the time it arrived the firm's own mail-security stack had already bolted a SPAM and PHISH warning plus an EXTERNAL tag onto the front of the subject line. Underneath that machinery the subject read "Continuing the conversation: Can we discuss next steps?", the sort of phrasing that implies a thread already in progress and a colleague waiting on a reply. The body was something else: a Microsoft SharePoint document-share notification, reproduced with enough fidelity that nobody scrolling on a phone would have a visual reason to hesitate.

The template quality is not what makes this case worth pulling apart. It is where the credential page lived, and how little of the attack had to be hidden as a result. The link pointed at a free subdomain on Cloudflare's Workers platform, a serverless host that thousands of legitimate development teams use every day. The sending domain sat on Cloudflare nameservers too. One trusted provider, leaned on twice, and almost nothing left for a reputation check to object to.

The sender that authenticated perfectly

The message came from no-reply@pct89[.]com, presented under a generic finance-department role rather than a person's name. SPF passed. DKIM passed, signed with d=pct89[.]com. DMARC passed. Microsoft's composite authentication returned compauth=pass reason=100, the strongest result in the set.

None of that is a bypass, and calling it one misses the point. The attacker was not spoofing a brand at the protocol layer. The attacker owned pct89[.]com outright, published a valid SPF record for it, signed with a real key, and set a DMARC policy that its own mail satisfied. Every gate answered the question it was built to answer, and answered it correctly. RFC 7489 defines DMARC as an alignment and reporting mechanism for the domain in the From header. It does not, and was never designed to, opine on whether that domain deserves your trust.

The domain also defeated the heuristic that usually rescues defenders here. It was privately registered roughly three years before this message went out, long enough to age past any newly-registered-domain rule, with WHOIS details behind a privacy service. Submission came from mail[.]pct89[.]com at 94[.]72[.]113[.]185 over an authenticated ESMTPSA session, then travelled through standard Microsoft inbound protection into the target tenant. A purpose-built, patient, entirely legitimate-looking sending operation.

A share link with nothing to crawl

The body announced that a named individual had shared a document via SharePoint and invited the reader to use the link below to view it. The destination shown was b74e[.]page-112[.]workers[.]dev.

Here is the detail worth slowing down for. That string was not a clickable link. It was rendered as styled plain text, formatted to read like a hyperlink, with no href behind it for anything to follow. The choice looks deliberate, and it targets a specific weakness in automated inspection. Most link-analysis pipelines enumerate the real anchor targets in a message, then fetch, detonate, or reputation-check each one. Strip the anchor and that workflow has no input: no URL to submit to a sandbox, no destination to score, no redirect chain to unwind. A person, meanwhile, reads it exactly as intended and copies it into a browser without a second thought.

The message then borrowed credibility from the brand it was imitating. Its footer carried genuine, benign links to support[.]microsoft[.]com and aka[.]ms, both of which scan clean because they are clean. To a filter tallying good and bad destinations, the only real links in the message were Microsoft's own. There were no attachments at all, so the payload surface was a single line of text.

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

Reputation on loan from developer infrastructure

Typing that address led to a page mimicking a SharePoint document viewer, staged on Cloudflare Workers. This maps to MITRE ATT&CK T1583/006, acquiring infrastructure as a web service, and it is one of the highest-leverage moves available to a credential thief.

Consider what the attacker gets for free. The parent domain is old and shared with an enormous population of real applications, so domain-age scoring returns nothing interesting. TLS is valid and automatic, so no certificate warning appears. Hosting stands up in minutes at no cost, making takedown an inconvenience rather than a setback. And while the parent domain can be blocked wholesale, doing so breaks preview deployments and internal developer tooling, which is why many organizations decline to. That leaves defenders on per-subdomain blocking against an adversary who can mint a new subdomain whenever the old one burns.

The lure, the click, and the harvest map to T1566/002, Spearphishing Link and T1204/001, User Execution: Malicious Link. Credentials remain the prize because credentials still work: the 2024 Verizon Data Breach Investigations Report found stolen credentials involved in 38% of breaches, the most common initial action, and measured a median of 28 seconds between a click and data submission. There is no meaningful window in which a human notices and calls someone, which is CISA's phishing guidance argument for placing the control before the click rather than after it.

Three lures against the same mailboxes in two days

Microsoft's inbound anti-phish filter did catch this one, scoring it SFTY:9.25 CAT:PHISH with SCL=5 and quarantining it before anyone at the firm could act on it. Worth stating plainly: Themis assigned this specific message a confidence of only 50%. A well-executed visual template that authenticates cleanly and carries no clickable payload gives a content-focused model very little to push against, and pretending otherwise would be the wrong lesson to draw.

The campaign is where the finding actually is. Inside the prior forty-eight hours the same sender and domain had already reached the same small set of recipients twice, once with "Urgent, review confidential material now, don't wait" and once with "Need a quick recap? Catch up on what you missed!". Both were quarantined and one was permanently deleted. Three distinct pretexts, one after another, aimed at a handful of mailboxes at a firm that moves client money. That is not opportunistic spray. It is a sustained effort against chosen targets, and reading it as such depends on correlating across messages, mailboxes, and tenants rather than issuing an isolated verdict per email. A member of staff also reported the message through community reporting, confirming the pattern from the human side.

When the only tell is a domain that does not belong

Nothing in this attack was broken. Authentication was legitimate, the sending domain was aged and quiet, the hosting provider was reputable, the Microsoft links were real, and there was no attachment and no anchor tag to analyze. Every individual signal was clean.

The mismatch was the whole case: a message wearing Microsoft SharePoint branding whose one meaningful destination lived on a developer platform Microsoft has nothing to do with. That contradiction is invisible to a control that checks reputation, authentication, and payload separately and stops once each returns green. It is visible to analysis that asks what a message claims to be and compares that against every domain it actually uses, which is why credential-harvesting protection belongs behind the native filter rather than assumed redundant with it, and why Microsoft 365 augmentation is about catching the campaign a per-message verdict cannot see.

Indicators of Compromise

MITRE ATT&CK Mapping