A Microsoft Clarity Field Delivered a PayPal Callback Scam

A single mailbox at a state health and human services agency received an invitation to collaborate on a Microsoft Clarity project. The invitation was genuine. Microsoft composed it, Microsoft signed it, and Microsoft delivered it from its own notification address under a DMARC reject policy. The fraud was the project's name. Someone had created a Clarity project, typed a fabricated PayPal refund notice and a callback phone number into the title field instead of a project name, and used the product's built-in invite feature to add a government mailbox as a collaborator. Microsoft's notification service then rendered that title verbatim, twice.

The subject line announced an invitation from an account presenting itself as a PayPal invoicing team. The body carried one sentence in the product's standard phrasing: an account has invited you to join a project, followed by the project's name in quotation marks. That name claimed a transaction of $445.67 USD had been successfully processed, and instructed the reader to call a number if they had not authorized it. No credential page. No attachment. No QR code. One phone number, sitting inside a legitimate product notification.

A Product Metadata Field Became the Message Body

Microsoft Clarity is a free behavioral-analytics product, the kind of tool a marketing or web team uses for session replay and heatmaps. Its collaborator invite is not a messaging feature. It is housekeeping, a way to add a teammate to a workspace. But that housekeeping primitive accepts an arbitrary destination address and emits first-party vendor mail containing a string the account holder controls.

Two properties of this particular field compound the problem. First, the abused field is a display name, so it propagates: it reached the subject line and it reached the visible body. Second, the product uses the project name as the anchor text of the join link. Anchor text is normally read as a trust signal, the label a defender compares against the destination. Here the label was attacker-authored and the destination was authentically Microsoft. The usual mismatch check runs backwards.

Nothing in This Chain Was Compromised

This is where the case separates from the more familiar pattern of scam copy pasted into a calendar invitation or a shared-document comment. Those attacks normally ride a hijacked tenant, and the account takeover is the part worth hunting. Here there was no hijacked mailbox, no borrowed relay, and no compromise of any kind. The attacker appears to have needed nothing more than a free account with the platform.

Authentication was not merely passable, it was pristine. SPF passed at every hop, on sending addresses inside Microsoft's own space. DKIM passed with a signing domain of microsoft[.]com. DMARC passed with alignment intact under a published policy of reject for the domain and its subdomains at full enforcement, the strictest posture the specification in RFC 9989 describes. Four sealed ARC hops chained with a passing chain validation, and composite authentication returned a pass with the highest confidence reason code Microsoft issues. Every one of those results was correct. None of them had anything to say about the message.

The recipient side behaved normally too. The message transited the agency's own government-cloud Microsoft 365 tenant, its links were rewritten by that tenant's own protection layer, and the internal routing address in the header differed from the reported mailbox in the ordinary way. There was no anomaly to escalate, because nothing anomalous happened.

Every Automated Check Answered a Question That Did Not Matter

Link analysis returned clean on all of it. The join link resolved to a real project-join path on clarity[.]microsoft[.]com. The rest of the message pointed at Microsoft documentation, Microsoft learning content, a Microsoft privacy statement, and a Microsoft short link about sender identification. No paypal[.]com address appeared anywhere in the headers, the body, or the links. PayPal was impersonated entirely in text, which means tooling watching for lookalike domains had nothing to match on.

That leaves a purely semantic detection surface, and it is a strong one once the message is read as a whole rather than as a set of fields. A behavioral-analytics product is inviting a state government security mailbox, with no prior relationship to that product, to join a project whose name is a billing dispute quoting a dollar figure and a support line. Every component is legitimate. The composition is absurd.

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

CISA's phishing guidance frames the defensive problem around the human decision rather than around delivery infrastructure, and the NIST definition of phishing turns on deception of the recipient, not forgery of the sender. Neither requires an attacker to own a domain. This message owned nothing.

Why the Phone Number Is the Entire Attack

Callback scams persist because a voice channel is unobservable to the email stack. The 2026 Verizon Data Breach Investigations Report puts the human element in 62% of breaches, up from 60% the year before, and separately publishes an email gateway attack mix drawn from telemetry contributed by a security vendor rather than measured by Verizon itself. In that mix, which reflects a median monthly share of the attacks those gateways blocked rather than everything that arrives, roughly 5% are attempts at getting the victim to call back to the attacker. It is a thin slice of blocked volume attached to an outsized share of loss: the 2025 FBI IC3 report counts cyber-enabled fraud at 45% of complaints but 85% of reported losses, $17.697 billion of a $20.877 billion total.

In technique terms this is phishing via link delivered through abuse of a legitimate web service, with impersonation supplying the pretext. The attacker's only asset was a project record inside somebody else's product.

What Actually Stopped It

A person did. The recipient, a security officer on the agency's information security team, recognized that an analytics invite quoting a refund amount made no sense and used the report button. The platform tagged the message as vendor impersonation, a scam, and a suspicious message, an analyst confirmed the verdict by hand, and the message was quarantined roughly 53 minutes after it arrived. One mailbox was affected, and the number was never dialed.

That outcome is the model that scales, because signature and reputation layers had no purchase here at all. What generalizes is behavioral evaluation of the whole message in context, which is the job our Adaptive AI platform does when it weighs sender relationship, product familiarity, and content intent together instead of grading each field separately, and it is the job a well-trained reporter does when the composition looks wrong. Vendor impersonation that never touches a vendor's credentials sits squarely in the territory business email compromise defenses have to cover, and for tenants whose inbound mail already authenticates perfectly, Microsoft 365 augmentation is where the remaining judgment has to live.

Three practical moves follow. Inventory which SaaS products in your estate can send mail to arbitrary addresses on a user's behalf, and which of those render a user-controlled name or description field into the resulting message. Alert on first-party vendor notification mail whose subject or anchor text carries billing, refund, or dispute vocabulary, or a phone number. And keep reporting frictionless, because on a message with flawless authentication and clean links, the reporter is the control.

Indicators of Compromise

MITRE ATT&CK Mapping