A Pre-Wrapped Barracuda Link Behind a Fake Google Docs URL

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." Only the sender's behavior said otherwise.

In May 2026, IRONSCALES detected a credential-harvesting campaign targeting a mid-size equipment finance company. Its link displayed a Google Docs presentation address but pointed to a Barracuda LinkProtect URL the attacker had supplied already wrapped, which hid a redirect through an attacker-controlled domain. The message authenticated cleanly at the recipient's gateway and still 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. By the time it reached the inbox, the link pointed to link[.]edgepilot[.]com, because the recipient organization's own AppRiver gateway (now part of OpenText) rewrites inbound links through EdgePilot. Its display text showed what appeared to be a Google Docs presentation URL.

The actual redirect chain told a different story:

1. EdgePilot (link[.]edgepilot[.]com): Added on delivery by the recipient organization's own AppRiver gateway (now part of OpenText). This is recipient-side link rewriting, not a layer the attacker chose
2. Barracuda LinkProtect (linkprotect[.]cudasvc[.]com): Already present in the message as sent. The attacker supplied a URL that Barracuda had already wrapped, so the first hop of their link was a security vendor's domain
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 address shown in the link text, also present as a separate link: a published Google Slides presentation serving as the visible decoy. A later scan of the redirect returned a 404, so the final landing page was not captured

The attacker's choices are deliberate. The Barracuda LinkProtect domain passes URL reputation checks by definition, the throwaway domain handles the actual routing logic, and the Google Docs address in the link text gives the recipient a familiar destination to expect. EdgePilot is different: it is the recipient's own gateway doing its normal job, and its rewrite did not change where the link led.

AppRiver's SecureTide gateway, which processed the message before delivery, logged "Link Protection: 2 link(s) wrapped" and returned a clean verdict. Rewriting a link is not the same as judging it: the gateway wrapped the attacker's pre-wrapped Barracuda URL as it was and passed the message on.

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

Authentication Passed at the Gateway, Then Failed at Microsoft 365

By the time the message reached the recipient's Microsoft 365 tenant, its authentication results read:

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

Those results describe the last hop, not the sender. One hop earlier, AppRiver's SecureTide gateway recorded SPF, DKIM, and DMARC all passing for bellnet[.]ca, so the message really was sent through that Bell consumer account. The failures at Microsoft 365 came afterward, from the gateway's own relay IP and its link rewriting. 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.

That SCL is consistent with a tenant configured to trust its own gateway. 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.

That arrangement is normal when a third-party gateway filters mail first, and it makes the gateway's verdict the one that counts. Here that verdict was clean: the message authenticated, its links were wrapped, and the gateway's checks did not flag a first-time sender on a consumer ISP account behind a fabricated display name.

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): Redirect staged behind a pre-wrapped Barracuda LinkProtect URL and a throwaway domain

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 passed at the gateway). 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 supply a link that a security vendor has already wrapped, and the recipient's own gateway wraps it again, every domain the recipient can see belongs to a security vendor. 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.