A Phishing Link Wearing Two Security Vendors' Badges: Inside a Benefits-Enrollment Credential Lure

A phishing link arrived last month wearing two security vendors' badges. The Complete Enrollment button in a benefits email did not point at an attacker domain. It pointed at Egress Defend, a legitimate email-security rewrite service. Buried inside that link, as a parameter, sat a second wrapper from Barracuda. And inside that, encoded, was the destination the attacker actually wanted you to reach.

To the reputation systems that decide whether a link is safe, this message looked like two trusted security companies vouching for it. That is the trick. The defenses built to inspect links became the cover that hid one.

The message reached a finance team at a hospitality organization. The reporting user, the Chief Financial Officer, did the right thing: he flagged a sender he did not recognize. Four mailboxes in the same department received it.

A bank email, branded for benefits, footed with the wrong company

The lure was a "Benefits Enrollment Deadline" notice. It used Regions Bank branding, the LifeGreen logo, the corporate address block in Birmingham, and the full Regions legal footer about service emails and phishing reporting. The copy read like a routine HR open-enrollment reminder.

Three details did not fit.

First, banks do not run your employer's benefits enrollment. The pretext stitched a financial brand onto an HR task to manufacture authority.

Second, the footer claimed the message was sent from the recipient organization's own domain, copyright and all. A Regions-branded body signed off as the victim's own company is a brand-to-footer mismatch no legitimate sender produces.

Third, the deadline was the same day the email arrived, at 11:59 PM. Same-day urgency is the oldest pressure lever in phishing, and it works because it shortens the window in which a recipient stops to think.

The personalization was light but effective: the greeting used the recipient's mailbox name and a "Status: Pending Enrollment" line, the kind of account-state detail that nudges plausibility.

Why authentication waved it through

Here is the uncomfortable part for anyone who treats SPF, DKIM, and DMARC as a verdict on trust.

The message was sent through Amazon SES, Amazon's bulk email-sending service, from the domain hatmi[.]sa. SPF passed, because the SES sending IP was authorized. DKIM passed for both hatmi[.]sa and amazonses.com. DMARC passed, aligned to hatmi[.]sa. Microsoft's composite authentication scored it 100, and the spam confidence level landed at -1, the value reserved for trusted mail.

WHOIS for hatmi[.]sa lists an unrelated Saudi registrant, a contracting company, on Namecheap nameservers. The domain has nothing to do with Regions Bank or with the recipient organization.

SPF (Sender Policy Framework), DKIM, and DMARC are alignment checks. They prove a message was authorized by the domain that sent it. They prove nothing about the brand shown in the body, the truthfulness of the footer, or whether the sending organization should be trusted at all. A clean DMARC pass on a throwaway or abused domain is exactly what a content-blind filter rewards. MITRE ATT&CK catalogs this as impersonation (T1656), and the delivery as spearphishing link (T1566.002).

The laundered redirect chain

The benign-looking links in the body, the Regions homepage, the App Store and Google Play badges, the privacy pledge, all resolved to real Regions-owned destinations and scanned clean. They were decoration, included so the message looked complete.

The one link that mattered was Complete Enrollment. It did not go anywhere obvious. Decoded, it ran like this:

The visible href pointed at links.us1.defend.egress.com/Warning, the rewrite domain for Egress Defend. URL rewriting is a security feature: a gateway replaces every link with a wrapped version routed through its own scanner, so it can re-check the destination at click time. Egress is a legitimate vendor, and its domain carries a clean reputation.

Inside that Egress URL sat an @OriginalLink parameter naming linkprotect[.]cudasvc[.]com, Barracuda's Link Protection rewrite domain. A second trusted vendor, nested one layer down.

And inside a Base64Url-encoded blob in that same URL was the parameter that gives the game away: Domain=aemf.org. That was the encoded target domain extracted from the redirect parameter, the endpoint the chain was built to deliver a victim to.

The redirector's own verdict on the Egress link was "clean," and that is the point, not a contradiction. The verdict applies to the rewrite domain, not to whatever sits at the end of the chain. The final landing page was never resolved in the case data, so the responsible read is this: the destination was deliberately hidden behind two security vendors' reputations, and the encoded target was an unrelated domain, not Regions. That is enough to call it credential-harvesting infrastructure by design.

Why does layering wrappers work? A reputation engine, or a Secure Email Gateway (SEG, the legacy perimeter-filtering appliance), reads the visible URL, sees defend.egress.com, recognizes a known security service, and passes it. It does not decode the nested @OriginalLink, follow the Barracuda hop, or de-Base64 the target. The trusted intermediary launders the link's reputation the way a shell company launders money: by the time anyone inspects the surface, the origin is two hops out of view.

What actually catches this

If your detection depends on the visible URL's reputation, redirect laundering beats you. The fixes are layered.

Decode and resolve. A control that detects threats inside credential-harvesting attacks has to unwrap nested redirects, follow each hop, and evaluate the real destination, not the first domain it sees.

Read the context the link sits in. A first-time sender, a financial brand applied to an HR task, a footer naming the wrong company, and a same-day deadline together describe a phishing message regardless of how the link is encoded. Behavioral and contextual analysis is what flagged this one, scoring it as phishing while authentication scored it as trusted. That is the layer Adaptive AI and Themis, the agentic AI SOC analyst, are built to provide.

The numbers say why this matters. The Verizon 2026 Data Breach Investigations Report attributes 62% of breaches to the human element and finds credentials involved across 39% of the kill chain, with phishing behind 16% of initial-access cases. The Microsoft Digital Defense Report 2024 documents adversaries routinely abusing legitimate cloud and security services to evade reputation filtering. The FBI IC3 2024 report logs phishing as the most-reported crime type by volume, and the IBM Cost of a Data Breach 2024 study puts phishing among the costliest initial vectors. CISA's phishing guidance is blunt: report what does not look right, which is exactly what saved this finance team.

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

The reporting user trusted his read over the email's polish. The brand was wrong for the task, the footer named his own company, the sender was a stranger, and the deadline was suspiciously tight. He flagged it, four mailboxes were quarantined, and a link laundered through two security vendors never got its click.

That instinct does not scale by itself. The lesson here is that the link's badge is not a verdict. When the wrapper is a trusted vendor, the only honest answer is to open the package and look inside.