The Health Spending Account Alert That Rode a Benefits Administrator's Own Infrastructure

Every link scanner in the chain returned a clean verdict.

The domain hosting the redirect URLs has been registered since 1996. The email template included a pixel-perfect Anthem Blue Cross Blue Shield legal footer, complete with state-by-state entity disclosures running hundreds of words. And DMARC, the one protocol designed to stop exactly this kind of impersonation, returned a hard reject.

The email landed anyway.

This campaign impersonating Anthem health insurance didn't rely on a sketchy domain or a newly minted phishing kit. It rode the infrastructure of a legitimate benefits administration platform, routing every link through redirect URLs that automated scanners had no reason to distrust. The technique exploits a fundamental gap in how link-based detection works: if the intermediate domain is clean, the verdict is clean.

A Spending Account Notification From the Wrong Sending Infrastructure

The email arrived as a transactional alert: "Your recent debit card transaction was approved. The amount will be withdrawn from your account." It carried the Anthem brand, including the Anthem logo, instructions to navigate to "Spending Accounts" under "My Plans," and the standard customer service language about keeping receipts. The footer contained Anthem's full legal disclosure, listing every Blue Cross Blue Shield affiliate by state.

For an employee enrolled in an Anthem health spending account, this looks indistinguishable from a real notification.

But the sending infrastructure told a different story. The From header claimed anthem.com. The Return-Path pointed to returnto.alegeus.com, a domain belonging to Alegeus, a third-party benefits administration company. The DKIM signature referenced anthem.com with the selector shvdkim, but the body hash verification failed. That failure means either the email body was altered after signing, or the signature was forged entirely.

The authentication results were unambiguous:

• SPF: Softfail for returnto.alegeus.com (the sending IP was not fully authorized)
• DKIM: Fail (body hash did not verify for anthem.com)
• DMARC: Fail with p=reject for anthem.com

Anthem publishes a strict DMARC reject policy. The receiving infrastructure should have blocked this message outright. According to the FBI IC3 2024 report, healthcare-related phishing campaigns resulted in over $1.6 billion in reported losses, with benefits and insurance impersonation among the fastest-growing pretexts.

The Redirect Chain That Made Every Link Look Legitimate

Every clickable link in the email pointed to secure.wealthcare.com, a domain owned by WealthCare (an Alegeus-affiliated benefits platform registered in 1996). The URLs followed two patterns:

1. Tracking URLs: secure.wealthcare.com/intranet/php/track_url.php?... with encoded parameters
2. Email-link redirects: secure.wealthcare.com/{token}/email-link/{id}/{id}/take-me?v1={hash}

The display text for these links showed anthem.com, "about us," and "ALTERNATE LANGUAGES," creating a visual mismatch between what the recipient sees and where the links actually resolve. This is a textbook anchor-text spoofing technique (MITRE ATT&CK T1566.001: Spearphishing Link).

The critical problem: automated link scanners evaluated wealthcare.com and returned clean verdicts. Six separate link scans, all clean. The domain is legitimate. The SSL certificate is valid. The infrastructure is real. Scanners had no signal to flag.

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

This pattern of abusing legitimate redirect infrastructure is not new, but it is accelerating. The Verizon 2024 DBIR found that phishing campaigns using trusted intermediary domains had a 3x higher click-through rate than those using attacker-controlled domains. When the URL itself looks trustworthy, users lose one of their few remaining visual verification signals.

Relay Chain: Fourteen Hops Through Legitimate Infrastructure

The email traversed at least fourteen relay hops before reaching the recipient's inbox. The path tells a story of how deeply embedded this campaign was in real infrastructure:

1. Originated inside an Alegeus production host (BOSPRODAPPA.mbiproduction.com)
2. Passed through Alegeus mail servers (rs7141.alegeus.com) via LuxSci encrypted relay
3. Scanned by Barracuda Email Security Service (ESS)
4. Processed by Avanan cloud proxy (Check Point)
5. Delivered through Microsoft 365 Exchange Online Protection

At each hop, the message picked up additional headers and security annotations. Barracuda's spam score was just 0.31 (quarantine threshold: 3.0). The Microsoft Digital Defense Report 2024 notes that multi-hop relay chains through legitimate services are increasingly used to fragment authentication checks, making it harder for any single gateway to reconstruct the full trust picture.

The IRONSCALES community intelligence network identified this campaign through cross-organization pattern matching. Multiple organizations reported emails with the same sender fingerprint, and Themis flagged the behavioral anomaly: a sender claiming to be Anthem, routing through third-party benefits infrastructure, with failed authentication across all three protocols. That combination of signals, invisible to any single link scanner, triggered automated classification as a credential harvesting attempt.

Indicators of Compromise

Why DMARC Reject Didn't Stop This (and What Will)

Anthem's DMARC policy is p=reject with 100% enforcement (pct=100). That should have been the end of this email. But DMARC enforcement depends entirely on the receiving infrastructure honoring the policy. When emails pass through multiple security gateways, cloud proxies, and link-rewriting services, the original authentication context can degrade.

According to CISA's phishing guidance, organizations should treat authentication failures as high-confidence indicators of impersonation, even when link scans return clean. The gap between SPF/DKIM/DMARC verdict and link-scan verdict is where these campaigns survive.

Security teams dealing with healthcare benefits impersonation should focus on three specific actions:

1. Enforce DMARC at the receiving end. If your gateway overrides DMARC reject policies (action=oreject instead of reject), you are leaving the door open. Audit your DMARC enforcement posture.
2. Stop trusting link verdicts in isolation. A clean URL scan means the intermediate domain is legitimate. It says nothing about the final destination or the intent behind the redirect chain. Layer adaptive AI analysis that evaluates sender authentication, link behavior, and content context together.
3. Train benefits and HR teams on transactional email verification. Employees who manage health spending accounts should verify transaction alerts directly through their benefits portal, never through email links. Security awareness training that simulates benefits-related pretexts builds exactly this muscle.

The attackers behind this campaign didn't need to build anything new. They borrowed a legitimate platform's infrastructure, copied a real email template, and counted on the fact that most security stacks evaluate authentication and link reputation as separate, unrelated signals. For organizations that still treat those signals independently, this is the result: a phishing email that every scanner called clean.