The DocuSign Portal That Was Two Days Old and Spelled Wrong: Typosquat Credential Harvesting via SendGrid Redirect

The email claimed a new file had been assigned for review. The subject line read "has assign a new file," a grammar error that a real DocuSign notification would never carry. The sender displayed as "westernbanks | Fax" from 876532@tiendajireh[.]com[.]mx, a Mexican retail domain with no connection to document signing services.

SPF failed at the AppRiver relay hop. DKIM failed. Yet the message landed in the recipient's inbox, carrying a single CTA button labeled "Review & Return Copy" that pointed to a domain registered two days earlier.

A Redirect Chain Through Three Trust Layers

The link behind the CTA did not go directly to the attacker's infrastructure. It routed through link.edgepilot[.]com, a URL defense service, then to u106697411.ct.sendgrid[.]net, a SendGrid tracking redirect, before finally resolving to cloud.docusign-electronical-signature-portal[.]com.

That final domain is a textbook case of typosquatting. The misspelling ("electronical" instead of "electronic") is subtle enough to pass a quick visual scan but obvious under inspection. The domain was registered on April 29, 2026, hosted on IP 91.92.41[.]5 in Bulgaria with no PTR record. No legitimate DocuSign infrastructure runs from a Bulgarian IP block with zero reverse DNS.

Each hop in the redirect chain served a purpose. EdgePilot added a layer of URL defense legitimacy. SendGrid added a trusted intermediary domain. By the time a scanner reached the final destination, it had already passed through two reputable services.

Anti-Bot Gating Blocked Automated Analysis

The landing page at the typosquat domain did not immediately present a credential form. Instead, it deployed "HumanCheck" anti-bot gating, a JavaScript challenge designed to distinguish human browsers from automated URL rewriting scanners and sandbox detonation tools.

When a security scanner followed the redirect chain, it encountered the HumanCheck page and returned a clean verdict. The actual credential harvesting form sat behind the gate, visible only to human visitors who passed the challenge. This two-layer evasion (redirect chain plus anti-bot gating) ensured that automated analysis never saw the payload.

The email body itself was Base64-encoded, adding a third evasion layer. Content inspection filters scanning for suspicious keywords or brand references in the raw message body would find only encoded text. The footer claimed the message came from "Document Services Team, Inc." described as an Amazon subsidiary, a claim with no verifiable basis.

The Signal Three Trust Layers Could Not Hide

Themis flagged the convergence of signals that no single check could catch: dual authentication failure (SPF and DKIM), a sender domain with no relationship to document signing, a redirect chain terminating at a two-day-old domain, and a Base64-encoded body obscuring the visual content from pre-delivery inspection.

Authentication told the story plainly. Both SPF and DKIM failed. The message should never have delivered. But relay infrastructure and ARC headers from earlier hops created enough ambiguity for the gateway to pass it through.

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

Indicators of Compromise

MITRE ATT&CK Mapping