Every Hop Was Borrowed and Every Verdict Came Back Clean

A message arrived in the mailbox of a senior executive at a large commercial property developer. It carried one bolded hyperlink, and the visible text of that hyperlink was a filename ending in .pdf, assembled from the sending firm's own name and the send date. Above it sat two lines of body copy: a one line greeting, then a request to see the attached.

Nothing was attached. The record lists exactly one real file on that message, a 30,747 byte inline PNG from the sender's signature block, verdict clean, with a smaller inline graphic beside it. The promised document did not exist in any form.

The destination behind the label was not a document host. It was a merchant callback endpoint on the production API of an Australian buy now pay later provider.

A Label Where a File Should Have Been

Anchor text is free text, and a string ending in a file extension recruits a habit rather than an emotion. A recipient scanning a short internal message does not evaluate a filename. They read it as an object already present and click to open it.

The framing was equally cheap. The message was addressed to the compromised mailbox itself, so the header From and the header To were the same address, and it carried In-Reply-To and References headers pointing at an earlier message, presenting itself to the recipient's client as a conversation already in progress. Below the link ran the mailbox owner's complete corporate signature, down to the confidentiality notice. None of it was fabricated. The attacker inherited it by sending from inside the real mailbox.

The Redirector Belonged to a Payment Company

The body preserved the pre-rewrite destination in the anchor's originalsrc attribute, which is where the chain becomes visible. The first hop was global-api[.]prod[.]au[.]edge[.]zip[.]co, path /merchant/callback, with a query string carrying redirect=, region=au, result=approved, a customer identifier and a checkout identifier. The endpoint honoured that redirect value and forwarded the browser to a deep path on an unrelated website.

Two qualifications belong here. The record does not establish whether that endpoint forwards arbitrary destinations by design or whether the attacker created a genuine checkout session to obtain a callback URL pointing where they chose. The tokens look real and result=approved suggests a completed flow. Neither reading is a defect in the provider's platform. The provider is a bystander: its infrastructure was used, not owned.

What matters to a defender is the reputation arithmetic. The first hop out of the body resolved to a well known commercial payment domain with valid certificates and years of clean history. The recipient's own tenant then rewrote the anchor into a link protection wrapper and delivered it, preserving the destination. A rewritten link that was not blocked reads to almost everyone as a link that was cleared.

Clean Described the Scanner, Not the Page

Both the callback URL and the bare terminal URL were scanned, and both render an identical screen: a padlock badge reading "Automation Protection Active", a distorted five character code, a text field, a Verify button. Absent a solved code, that is all the page serves.

The verdicts follow directly. The callback URL came back Clean, the terminal URL came back Mixed Result, and neither came back malicious. Both describe how far an automated visitor travelled, not what waited at the end. The scanning infrastructure named its stored artifact after the terminal domain, confirming the redirect was followed.

What sits behind the gate is not in the record, and filling that in would be the easiest mistake to make here. No credential form was captured, no brand clone, no download. The finding is not the payload. It is that three controls, sender authentication, link protection and URL reputation, all reported success while none examined what the link served. The gate is not there to hide content from a human. It is there to convert a scanner's failure into a clean result.

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

Signed on the Way Out, Unsigned When It Was Written

The arrival authentication block is as strong as a block gets. SPF passed. DKIM passed with the signature verified. DMARC passed with action none. Composite authentication returned a pass with reason code 100, and two ARC seals were present, the second validating.

One header undoes the reassurance. Authentication-Results-Original, the sending tenant's own view before egress, reads dkim=none (message not signed) and dmarc=none. The message was unsigned when composed and cryptographically signed by the time it arrived. That is not forgery. It is a genuine Microsoft 365 tenant signing its own outbound mail, under that tenant's own onmicrosoft.com domain. Unsigned at composition, authenticated on delivery, is the profile a compromised in tenant mailbox produces, and it is why account takeover defeats identity controls instead of tripping them.

The DMARC policy in force was none, so the pass reflects alignment, not an enforced instruction.

The Signal That Caught It

Microsoft's own filtering scored the message mildly and delivered it: SCL 1, BCL 0, verdict non spam. Adaptive AI scored it at 84 percent confidence, applied a VIP recipient label, and named the offending link by its display text, the fake filename. The incident automatically resolved as phishing, and three mailboxes were quarantined within four to five minutes. A fourth message with an unrelated subject joined the same incident about three hours later.

The signals were relational, because nothing technical failed. A message addressed to itself. A reply into a thread the recipient could not place. A filename as anchor text with a payment API behind it. Microsoft 365 augmentation exists for this shape of message, which the native stack scores as ordinary because every field it reads is genuine.

Four Changes Worth Making

The 2024 Verizon Data Breach Investigations Report puts the human element in 68% of breaches, phishing in 15%, and stolen credentials in 38% as the top initial action. A chain built entirely from borrowed reputation is how those numbers stay steady.

Four practices follow. Treat a Clean verdict as unresolved whenever the scanner stopped at an interaction gate, and record terminal state alongside verdict. Score anchor text against its destination, since a displayed filename resolving to an API endpoint is a cheap, high signal mismatch. Resolve redirect parameters rather than grading the first hostname in a chain. And read a self addressed message from a known correspondent as a compromise indicator, not a formatting quirk, which is where CISA's phishing guidance and the NIST definition of phishing both point. The attacker registered no domain and stood up no server. Every hop was somebody else's.

Indicators of Compromise

MITRE ATT&CK Mapping