Six Vendors Rewrote This Link. None Broke the Chain.

A shared team inbox at a regional CPA and accounting firm received a notification telling it that unread Microsoft Teams messages were waiting. The subject came out of a merge field, reading as a quick update on the firm's own tasks with the firm name spliced in and a date stamp bolted on the end. Authentication was clean in every direction: SPF pass, DKIM pass on two separate signatures, DMARC pass, composite authentication at the maximum, all of it from a Spanish business domain registered nearly two decades earlier.

The entire message existed to deliver one link. Decoding that link took six passes.

Six Layers, Recovered One Decode at a Time

The visible link text read "View Teams Messages", once per MIME alternative. Behind it was a URL that had to be peeled rather than read, because every layer hid the next one differently.

The outermost wrapper, the one rendered in the email, was a Libraesva urlsand sandbox link on urlsand[.]esvalabs[.]com, whose u parameter held a complete second URL rather than a destination. That URL was an Egress Defend interstitial on links[.]uk[.]defend[.]egress[.]com/Warning, carrying a base64 target, a campaign reference id, a threat value, and a Domain parameter. Decoding its target took base64 with the URL-safe alphabet followed by a zlib decompress, and out came a full Cisco Secure Web rewrite on secure-web[.]cisco[.]com, which the Egress URL also named openly in an @OriginalLink parameter.

Inside the Cisco rewrite sat a Sophos Central Email safelink on us-west-2[.]protection[.]sophos[.]com. Base64-decoding its u parameter produced an EdgePilot link on link[.]edgepilot[.]com, and base64-decoding EdgePilot's u parameter produced a Barracuda Link Protect URL on linkprotect[.]cudasvc[.]com. Barracuda's a parameter, double URL-decoded, finally gave up something that was not a security product: an administrative path on a hijacked website, serving the credential-harvesting page the message was built to reach.

Six protective services, nested six deep, and every one of them looked at the link, declined to stop it, and handed it onward intact.

Two of the Rewrites Were Generated for Somebody Else

The reflexive reading is deliberate attacker camouflage. The parameters say something more interesting.

The Egress rewrite's Domain parameter named emap[.]com, and the Sophos safelink's d parameter named edgepilot[.]com. Those fields identify the tenant a rewrite was generated for, and neither is the accounting firm. At least two of these layers were minted while the URL sat in some other organization's protected mailbox.

So these wrappers were not built, they accumulated, picked up as the link crossed one protected mail environment after another and got faithfully re-wrapped at each boundary. An attacker who obtains a link in that state does not need to construct cover. The cover is already welded on, donated by six vendors that never intended to help.

A Rewrite That Forwards a Link Lends It Your Reputation

Link rewriting is a genuinely good control. It moves inspection from delivery time to click time, the only moment that reliably reflects what a URL serves, and it works because users trust the wrapper.

Which is the whole problem. A service that rewrites a URL, inspects it, declines to block, and forwards the visitor has attached its own name to whatever sits at the end. It has laundered that destination's reputation, honestly and by design. Do it six times and the readable surface of the link is nothing but security-vendor hostnames, while the thing worth evaluating is buried under compression, base64, and two rounds of URL encoding that no hover preview will expand.

The consequences all point one way. A recipient who does the responsible thing and inspects the link sees a security product and stops. A scanner that unwraps one layer lands on another vendor's high-reputation domain and scores it clean, because at that layer it genuinely is clean. The 2024 Verizon Data Breach Investigations Report puts the median time to click a phishing link at 21 seconds, and nobody runs a six-stage decode in 21 seconds. Malicious URL and payload inspection has to keep unwrapping until it reaches something that is not a rewriting service.

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

The Landing Page Was Somebody Else's Website

The final destination was a WordPress admin path on hmchealth[.]net, a domain created a few years before the send and now registered to an unrelated company on another continent. That mismatch, plus a phishing page parked under the site's own admin directory, is the profile of a hijacked WordPress site rather than attacker-built infrastructure.

Which fits the rest of the case. Nothing here was newly registered and nothing needed to be. The sending domain was borrowed, the wrappers were borrowed, the landing host was borrowed, and blocklists are built to catch what is new. That reuse of trusted, previously benign platforms runs through the Microsoft Digital Defense Report 2024.

Aged, Authenticated, and Not the Attacker's Domain

The From address was info@interioresproyecta[.]com, with a run-together sender alias presenting the message as an automated no-reply notification. The domain was created nearly two decades earlier through a Spanish hosting provider, registrant redacted for privacy. Throwaway domains are days or weeks old. This one predates most of the tooling used to score it.

Delivery ran through a commercial transactional email relay in an EU region, envelope sender in the service's own domain, sending host at 54[.]240[.]4[.]14. Two DKIM signatures validated, one for the business domain and one for the relay. DMARC passed with an action of none, so the published policy asked for no enforcement even had it failed.

Authentication verified the mail was sent in a way the business domain permitted. It never verified that the business intended to send it, and an aged legitimate domain relaying through a mainstream service is the signature of compromised infrastructure rather than acquired infrastructure. As both NIST and CISA phishing guidance frame it, header results open a content review instead of replacing one.

A Role Address, and How the Case Closed

The one affected mailbox was a generic shared alias rather than a person, which is a deliberate choice: nobody personally recognizes that a message does not belong to them, and busy queues get triaged for speed. The rest of the body linked out to the genuine Microsoft Teams listings on Google Play and the Apple App Store, so counting distinct destination domains would have made this message look healthier than a real one.

The case closed on structure and behavior rather than reputation, because every reputation lookup here returns a good answer. Themis, the IRONSCALES Adaptive AI analyst, scored it at 88 percent, weighing a first-time sender against a notification pretext whose only action was a deeply buried redirect, and the incident resolved automatically as phishing. What the message cannot survive is being read as a whole, which is where credential harvesting protection has to operate.

What To Take From This Case

Add one question to URL triage: how many rewriting services appear in this link, and do any of them belong to us. A legitimate inbound URL picks up at most one rewrite, and it is yours. Several that are not yours means the link was assembled in other people's mail systems and shipped to you pre-wrapped.

Then treat rewrite domains as neutral rather than reputable. A vendor hostname tells you a control looked at the link. Six of them tell you six controls looked at the link. Not one tells you a control liked what it saw.

Indicators of Compromise

MITRE ATT&CK Mapping

See You Next Time

The wrapper is never the verdict. Unwrap until you reach something that is not a security product, then start judging. Back tomorrow with the next teardown.