Authenticated by Microsoft, Hosted on Railway

The message that reached the accounts-payable alias of a small home-services contractor had a subject built for exactly that inbox: Payment Advice Notification- Invoice [224] Payment. The From line wore the label Account Payable. The body announced, in clean templated HTML, Payment Advice Note: You have received a payment, above a single gold button reading REVIEW PAYMENT. One mailbox received it, and no human reported it, because automated detection caught it and resolved it as phishing on its own.

What makes the case worth pulling apart is that the authentication was not merely convincing. It was real. SPF passed. DKIM passed. DMARC passed, against a domain publishing REJECT for itself and its subdomains. There was no forgery in the headers, because Microsoft genuinely sent this email.

The authentication was not spoofed, it was earned

The sending address was surveys@email[.]formspro[.]microsoft[.]com. The envelope sender resolved to nam[.]pb-dynmktg[.]com, Microsoft's Dynamics marketing domain, and the connecting host was mail14[.]mailip[.]dyn365cv[.]com at 40[.]78[.]242[.]9. SPF passed for that envelope domain and address. DKIM validated with selector fpnamkey1 against email[.]formspro[.]microsoft[.]com. DMARC then evaluated the aligned result against a header From of microsoft[.]com and returned a pass, with the published policy at p=REJECT and sp=REJECT.

That is the strongest authentication posture a receiving system can hope to see, and it tells you exactly one thing. As RFC 7489 defines it, DMARC answers whether a message was authorized by the domain in the visible From field. It has no opinion on whether a URL inside the body leads somewhere hostile. The recipient ran Google Workspace, so this crossed vendor boundaries and still arrived with every gate green.

A survey platform pressed into invoice duty

The infrastructure is Dynamics 365 Customer Voice, the survey product formerly branded Forms Pro. The legacy name survives in the sending domain, a small tell for anyone reading headers closely and a meaningless string to everyone else. Platforms like it are unusually well suited to phishing delivery: templated HTML, per-recipient personalization tokens, a link-shortening service, and the vendor's own authenticated sending domain, all of it free to whoever gets a campaign out of a tenant. That is MITRE ATT&CK's T1583/006, acquiring or abusing web services as attack infrastructure.

Two details confirm the platform was doing real work. The footer carried the standard on-behalf-of disclaimer, naming an unrelated finance-sounding organization as the sending tenant. And beside the button sat a plain-text copy-and-paste alternative pointing at nam[.]dcv[.]ms, the platform's own short-link service, which scanned clean because it genuinely is part of Microsoft's delivery chain. Whether that tenant was created for abuse or simply compromised is unresolvable from the message. Either way, there was no spoofing to detect.

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

The one element that left the platform

The REVIEW PAYMENT button pointed nowhere inside Microsoft. Its destination was hxxps://lifesgreat-production-567[.]up[.]railway[.]app/, an app hosted on Railway, a developer platform-as-a-service. Reputation and community matching flagged the link as malicious, a link scan returned a mixed verdict rather than a clean one, a static fetch found no visible credential form, and reverse DNS on the hosting address returned no PTR record. A script-injected form cannot be ruled out from a static scrape, so the honest read is a hostile destination whose final harvest mechanism was never captured.

The hosting choice is the part worth internalizing. A PaaS subdomain costs nothing, needs no domain registration, provisions valid TLS on deploy, and inherits a parent domain carrying far too much legitimate developer traffic to blocklist. Heuristics built on WHOIS age, newly registered domains, or self-signed certificates have nothing to grip. The click is T1204/001, user execution of a malicious link, delivered as T1566/002 spearphishing link. The 2024 Verizon Data Breach Investigations Report puts the median time to click at 21 seconds, roughly how long this defense had.

The URL carried the target's own address

Appended to that link, after a hash character, was the recipient's own accounts-payable address. As a URL fragment it never travels to the web server in the HTTP request, so URL inspection and server-log analysis frequently discard it. Script on the loaded page reads it immediately.

That buys three things at once. The page can pre-fill an identity field so the victim sees their own address already waiting, which is powerfully reassuring. The campaign is confirmed to have been assembled per recipient rather than blasted. And a load tied to a specific fragment marks that mailbox as live for the next attempt. Payment lures are where that care pays off: the 2023 FBI IC3 report attributes roughly $2.9 billion in reported losses to business email compromise for the year.

The mismatch was structural, not visual

No third-party vendor was impersonated here. Nobody wore a shipping logo or a bank's letterhead. The mismatch sits a layer deeper: a message presenting itself as the recipient's own accounts-payable correspondence, authenticating in transport as Microsoft, delivered by a survey platform, on behalf of a finance-sounding organization nobody at the contractor had dealt with. That is T1036/005, masquerading as a legitimate name or location, executed at the platform layer instead of the pixel layer.

Detection came from that composite. IRONSCALES Adaptive AI scored the message at 90% confidence, weighting a first-time sender, a survey platform carrying an invoice notice, and a button that abandoned the sending platform for an anonymous developer host, then matching the link against previously reported community activity. No header check produces that verdict, because every header was honest.

Legitimate-service abuse inverts the usual defensive economics. CISA's phishing guidance is clear that authentication controls reduce spoofing, not phishing, and nothing here was spoofed. When the sender, the signature, the policy and the infrastructure are all genuine, the only surface left is where the links go and whether the relationship is plausible. Malicious URL and link protection that evaluates a button's real destination, independent of who signed the envelope, is the control that closes this gap.

Indicators of Compromise

MITRE ATT&CK Mapping

• T1566/002, Phishing: Spearphishing Link. The button was the entire payload.
• T1204/001, User Execution: Malicious Link. Compromise required the click leaving the platform.
• T1583/006, Acquire Infrastructure: Web Services. Survey platform for delivery, developer PaaS for hosting.
• T1036/005, Masquerading: Match Legitimate Name or Location. Genuine Microsoft infrastructure, invoice pretext.