Wrapped Three Deep: One Button, Three Redirect Layers

A single message reached one mailbox at a global engineering and infrastructure consulting firm. The subject line was two words, Account Deactivation. The display name was No_reply. Across the top of the body sat a large red banner reading OFFlCE-365, the Microsoft brand rendered with a lowercase L standing in for the capital I, a substitution that survives a glance in almost any sans-serif email client. The copy told the reader that a service deactivation request on their own mailbox had been approved, and it addressed them by the local part of their email address rather than by name. It signed off in the name of their own employer's service team.

Underneath all of that sat one green button.

That button is the entire case. Its destination was not a URL, it was a stack of them: two nested Amazon click-tracking hops, then a Barracuda Link Protect rewrite, then a landing page on an unrelated South African host with the string www[.]oracle[.]com sitting inside the URL path. A third, entirely separate destination was reachable without clicking anything at all, because the link's hover title pointed somewhere different again. Three independent layers, an Amazon tracker, a security vendor's rewriter, and a spoofed hover title, converge on that one button, and every one of them belonged to something a defender would ordinarily read as trustworthy.

The Same Button, Wrapped Three Times

Peel it in order.

The outermost wrapper was awstrack[.]me, the click-tracking domain used by Amazon Simple Email Service, and it appeared twice, one instance nested inside the other. That domain is handed to anyone who sends through the platform. It carries the platform's reputation and discloses nothing about where the click ultimately lands. Doubling it costs the attacker nothing and adds one more decode step for anyone unwrapping the chain by hand.

The next hop was linkprotect[.]cudasvc[.]com, a Barracuda Link Protect rewrite. That is an email-security control sitting in the middle of a credential-harvest chain. How it got there is not established by this record, and the honest position is to draw no conclusion about that. What matters operationally is the effect: a downstream filter scoring the visible hostname is scoring an email-security vendor's domain. Reputation-weighted URL analysis does not merely miss this pattern, it is pulled in the wrong direction by it, which is why advanced malware and URL attack protection has to resolve a chain rather than grade the string it was handed.

Only after both of those wrappers does the real destination appear: hxxp://xpress[.]co[.]za/wayy/www[.]oracle[.]com.

A Brand Name Living in a URL Path

Read that address left to right and the trick is obvious. Read it the way a hurried recipient reads it, scanning for a name they recognize, and the trick works.

The host is xpress[.]co[.]za, a South African domain registered in 2007, well over a decade before this message, sitting in a shared-hosting environment operated by a South African internet service provider. The www[.]oracle[.]com portion is a path segment on that host. It is not a hostname, it is not a redirect, and no part of a request to that URL ever reaches the vendor it names. Only the text before the first single slash determines who answers. Everything after it is chosen freely by whoever controls the page.

Two things follow from the age of that domain. First, seventeen years of clean history is exactly what a domain-age heuristic is built to reward. Second, nothing here suggests intent on the part of the ISP or the domain's owner. A hijacked customer page or a web shell dropped on shared hosting is a far likelier reading than complicity, and it is why credential harvesting so often terminates on infrastructure with an impeccable record.

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

What the Hover Text Said Instead

The link carried a hover title, the tooltip text a mail client surfaces when a cursor rests on a link, and it did not match the destination the button actually used. It pointed at a google[.]com/url redirect that forwarded on to alqaimaqs[.]com/wp-admin/js/kmu/, a path shape consistent with a compromised content management install, carrying a base64-encoded parameter. That parameter was not decoded during analysis and is not reproduced here.

That detail matters twice over. Users are taught to hover before clicking, so the tooltip is a trust surface in its own right, and here it showed a search-engine domain while the click went elsewhere. And two divergent destinations in one link means more than one path to a credential page, so blocking either alone leaves the other standing.

Authentication Answered a Different Question

Walk the headers and there is no seam. SPF passed for a sending address of 54[.]240[.]8[.]221, an amazonses[.]com host. DKIM passed twice, once against the sending domain's own selector and once against amazonses[.]com. Composite authentication came back as a pass (compauth=pass reason=109). Delivery went straight from the platform into the recipient's real corporate mailbox with no relay or gateway hop in between.

DMARC resolved as a best-guess pass, meaning the sending domain publishes no explicit policy and the receiving side inferred alignment from the other results. Under RFC 7489 a domain with nothing published gives a receiver nothing to enforce. The sending domain itself, syncdell[.]life, has no affiliation with Microsoft or with any brand named in the message, and no registration record was retrievable at analysis time.

None of that is a bypass. The attacker rented reputable infrastructure and used it correctly, and authentication answered the only question it is designed to answer: which domain really handed this message to the platform.

Mapping to MITRE ATT&CK

• T1566.002 Phishing: Spearphishing Link covers the delivery, a single call-to-action link presented as an account action rather than a file.
• T1204.001 User Execution: Malicious Link covers the intended next step, since nothing happens until the recipient presses the button.
• T1656 Impersonation covers the pretext, a productivity-suite brand plus the recipient's own employer invoked together to make an account warning read as internal.

Indicators of Compromise

Why the Depth Is the Signal

Take any one layer of this message on its own and it is unremarkable. Bulk email platforms send billions of legitimate messages with tracking wrappers. Link rewriters appear in ordinary mail every day. Long-registered hosting domains are the normal case, not the exception. A path segment is just a path segment.

The composition is what has no honest explanation. There is no legitimate workflow in which a productivity-suite account notice arrives from an unaffiliated domain, wraps its one action link twice in a marketing platform's click tracker, passes through a security vendor's rewriter, lands on a decade-old foreign shared-hosting page dressed with an unrelated vendor's hostname, and carries a different destination in its tooltip. Each layer buys reputation from a third party. Stacked, they describe intent.

That is the terrain Themis, our Adaptive AI analyst, is built to read, because the anomaly lives in the relationship between signals rather than in any single one of them. This incident was automatically resolved as phishing. The 2024 Verizon Data Breach Investigations Report puts the median time to click a phishing link at 21 seconds and stolen credentials in 38 percent of breaches, which is the window a chain like this is engineered to fit inside.

The Takeaway

Unwrap before you judge. A URL is not one string, it is a sequence, and a verdict on the outermost layer is a verdict on a third party's reputation rather than on the message in front of you.

Three habits follow. Resolve nested redirects fully, and treat repeat wrapping of a single link as a signal in itself rather than noise. Parse hostnames strictly, so a familiar name in a path never reads as ownership of the site. And compare a link's hover text against its actual destination, since divergence there is deliberate by definition. CISA's phishing guidance and NIST's definition of phishing are useful anchors for both the user-facing and the technical halves of that work.