Three Security Wrappers, One Redirect to a Google Docs Phishing Page

The email looked like a routine document notification. A colleague named "Jennifer Johnson" had shared a financial report. The subject line referenced the company by name. And the link in the body pointed to what appeared to be a Google Docs presentation, wrapped inside a recognizable link protection service.

Every visible signal said "safe." Every authentication check said otherwise.

In May 2026, IRONSCALES detected a credential-harvesting campaign targeting a mid-size equipment finance company. The attack weaponized three layers of legitimate link protection infrastructure to disguise a redirect to an attacker-controlled domain, then onward to a Google Docs presentation serving as the phishing payload. Despite failing SPF, DKIM, and DMARC at the recipient's gateway, the message landed in the inbox with Microsoft's lowest spam confidence score.

The Display Name Said One Thing, the Envelope Said Another

The email arrived from "Jennifer Johnson" with a subject line referencing a company-specific aging report. The format mimicked an internal document-sharing workflow: professional, contextually relevant, and addressed to the company's sales team.

The display name was a fabrication. The actual sender address was davidbr@bellnet[.]ca, a Canadian consumer ISP account with no connection to the target organization or any document-sharing platform. The recipient had never received email from this address before.

This is display name impersonation at its most effective: the attacker chose a common name, paired it with a plausible business context, and relied on the fact that most email clients display the name prominently while hiding the envelope address behind a click.

The Redirect Chain That Turned Protection Into Camouflage

The email contained a single call-to-action link. What the recipient would have seen in the email body was a URL pointing to link[.]edgepilot[.]com, an Oracle-owned link protection service, wrapping what appeared to be a Google Docs presentation URL.

The actual redirect chain told a different story:

1. EdgePilot (link[.]edgepilot[.]com): Oracle's link protection service wrapped the URL, providing the first layer of apparent legitimacy
2. Barracuda LinkProtect (linkprotect[.]cudasvc[.]com): A second link protection wrapper, adding another layer of trusted-domain camouflage
3. Throwaway domain (smstkart[.]com/bee): The actual attacker-controlled redirect, an Indian domain with no connection to document sharing or financial services
4. Google Docs (docs[.]google[.]com/presentation/d/e/...): The terminal destination, a published Google Slides presentation, likely hosting a credential-harvesting form or a secondary redirect

The architecture is deliberate. Each layer serves a purpose. EdgePilot and Barracuda LinkProtect are legitimate security tools whose domains pass URL reputation checks by definition. The throwaway domain handles the actual routing logic. And Google Docs provides a trusted hosting environment where the final payload benefits from Google's domain reputation.

AppRiver's SecureTide gateway, which processed the message before delivery, logged "Link Protection: 2 link(s) wrapped" and returned a clean verdict. The security tools designed to protect the recipient became the outermost layer of the attack's disguise.

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

Authentication Failed at Every Level, Delivery Succeeded Anyway

The email's authentication posture at the recipient's Microsoft 365 tenant was unambiguous:

• SPF: SoftFail (bellnet[.]ca does not designate the AppRiver relay IP as a permitted sender)
• DKIM: Fail (body hash did not verify, indicating the message was modified after signing)
• DMARC: Fail (p=none, action=none)
• compauth: None (reason=405)

All three standard authentication mechanisms returned negative results. Microsoft's composite authentication score was zero. And yet the email was delivered to the inbox with SCL=-1, the lowest possible spam confidence level, typically reserved for messages from trusted senders or allow-listed sources.

The likely explanation lies in the relay architecture. AppRiver's SecureTide gateway, positioned between the sender and Microsoft 365, performed its own SPF and DKIM validation and returned passing results at that layer. When the message was forwarded to the recipient's tenant, the relay broke the original authentication chain (a well-documented side effect of intermediary gateways), but the recipient's infrastructure appears to have trusted the relay's verdict rather than re-evaluating from scratch.

This is a systemic gap. Intermediary gateways that validate authentication before forwarding can create a false trust signal downstream, where the recipient's MTA sees the relay's clean bill of health rather than the raw authentication failures.

MITRE ATT&CK Mapping

• T1566.002 (Phishing: Spearphishing Link): Credential-harvesting URL embedded in a business-context document notification
• T1036.005 (Masquerading: Match Legitimate Name): Display name "Jennifer Johnson" impersonating a plausible business contact
• T1608.005 (Stage Capabilities: Link Target): Multi-hop redirect chain staged through legitimate security infrastructure

Indicators of Compromise

The Layer That Caught It

Themis, the IRONSCALES Adaptive AI, flagged this message at 84% confidence and auto-resolved it as phishing. The detection was not based on URL reputation (the visible links pointed to trusted domains) or authentication results (which the relay architecture had muddied). It was based on behavioral signals: a first-time sender using a consumer ISP address, a display name that did not match the envelope sender, and a communication pattern inconsistent with the target organization's vendor relationships.

Link protection wrappers are designed to make links safer. When attackers embed their redirect chains inside those wrappers, they transform protection into camouflage. The defense that works is the one that evaluates the full chain, the sender, and the context, not just the domain in the URL bar.