Same Button, Two Destinations: A Link-Swap Phish

A message that looked like a routine file-share notification landed in four mailboxes at a large engineering and infrastructure consulting firm. It announced a document waiting for signature, an agreement, and it invited each recipient to open it. Nothing in the header told the mail filter to hesitate. SPF passed. DKIM passed. DMARC passed under a strict reject policy. Even ARC, the seal chain that preserves authentication results across intermediate hops, carried two valid seals. Microsoft's own composite authentication verdict, compauth, returned pass with reason 100, the cleanest score the system can issue.

By every signal a gateway is built to trust, this was a legitimate email. It was not.

The notification that checked every box

The message was sent from a domain whose DKIM signature validated cleanly, and the From address aligned with that signing domain, so DMARC's alignment requirement was satisfied even under a reject policy. The sending header was self-addressed, with the From and To set to the same fabricated business persona, and the real targets were fanned out as blind recipients. That structure is quiet by design. A recipient scanning the visible headers sees a plausible internal-looking sender and no obvious list of other victims.

Authentication answers a narrow question: was this message sent from a domain permitted to use this From address, and was it altered in transit? Here the answer was a clean yes on both counts. What authentication never inspects is the one thing that mattered in this case, which is where the links inside the body actually go. The 2024 Verizon Data Breach Investigations Report puts phishing in roughly 15 percent of all breaches and notes a median time to click a phishing link of about 21 seconds, with data submitted around 28 seconds. A message that clears every authentication gate and reaches the inbox intact is already most of the way to that click.

Two buttons, one label, two destinations

The body presented itself as a file-share prompt with call-to-action buttons. Both buttons carried the identical visible label, a reference to an agreement document. To the eye they were interchangeable, two copies of the same trustworthy control. Underneath, they were not.

One button resolved to a legitimate, widely used e-signature platform. That was the decoy. Its presence did real work: a security-aware recipient who hovered a button and recognized a known e-signature host would reasonably conclude the message was safe and click the other one without a second look. The second button, wearing the same label, resolved to a confirmed-malicious domain hosting a credential-harvesting path. The malicious destination was screenshot-verified as hostile. The attacker had borrowed the credibility of a real service and stapled it to a hostile one by making them look identical.

This is a link-swap, or dual-CTA, technique. It maps to MITRE ATT&CK T1566.002, Spearphishing Link, and the intended follow-on is T1204.001, User Execution: Malicious Link. The technique does not try to defeat authentication. It routes around it entirely, because the deception lives in a layer authentication cannot see.

A pixel that watched the room

Embedded in the body was a tracking pixel hosted on Microsoft infrastructure, on a svc[.]ms path. Because it loaded from a recognized Microsoft domain, it rendered without objection in most mail clients. Every time one of the four recipients opened the message, the pixel quietly reported the open back to the operator. That gave the sender a live map of who was engaged and who was not, the kind of signal an operator uses to prioritize follow-up or escalate pressure on the recipients most likely to click. Reconnaissance and delivery in the same message, with no attachment and nothing for a payload scanner to detonate.

Why authentication was the wrong lens

There was no auth failure to catch here, so an auth-first filter had nothing to act on. The single detectable anomaly was the destination mismatch between two buttons that claimed to be the same. Surfacing that requires resolving each URL, following any redirects, and comparing where identically labeled controls actually lead. That is link-resolution and visual analysis, not header inspection.

This is exactly the gap a legacy gateway leaves open, and it is worth measuring how much of your current stack still leans on reputation and authentication alone. Our SEG email security gap calculator is a quick way to frame that exposure. IRONSCALES treats every link as untrusted until it is resolved. Themis, our Adaptive AI, rendered the message, resolved both buttons, and flagged that two identically labeled call-to-action controls pointed to two different domains, one of them malicious, which is the precise contradiction a human eye and a reputation check both miss. Authentication had nothing to say. The destinations said everything.

Indicators of compromise

MITRE ATT&CK mapping

See you next Friday

Full authentication is table stakes now, not a verdict of safety. When SPF, DKIM, DMARC, and ARC all pass, the interesting question is not whether the sender is who they claim to be. It is where the message is trying to send you. If you want to see how link resolution and Adaptive AI catch what header checks cannot, request a demo.