The DocuSign Template That Shipped With Its Variables Still Showing

The DocuSign notification looked professional enough to pass a quick glance, but the attackers shipped their template before populating it. The placeholder {Frmsite} sat in the body text. "Document can only be view by" betrayed a grammar error the template author never fixed. Below the signing CTA, an unrelated mailing-list thread was stitched into the message, a bulk-send artifact that no legitimate DocuSign notification would contain. These were the visible mistakes. The invisible part, the multi-hop redirect chain ending at a Microsoft OAuth endpoint, was considerably more sophisticated than the wrapper it arrived in.

A Sending Path That Doesn't Match the Brand

The message was sent from info@welook[.]com[.]au, an Australian domain unrelated to DocuSign, through SendGrid transactional infrastructure at 149[.]72[.]126[.]143. An AppRiver SecureTide gateway at 8[.]31[.]233[.]206 scanned and relayed the message downstream, breaking SPF alignment in the process (softfail recorded at the AppRiver hop). DKIM results were inconsistent across relay hops.

The body used DocuSign branding complete with the real DocuSign corporate address ("221 Main Street, Suite 1550 San Francisco, CA 94105"). But the sending domain, return path, and tracking infrastructure all pointed to SendGrid and a third-party Australian domain. Legitimate DocuSign notifications originate from docusign.com with matching DKIM signatures.

Three Redirects to an OAuth Endpoint

The "View Completed Document" CTA did not link to docusign.com. The click path was:

1. link.edgepilot[.]com (click-protection/rewriting gateway)
2. u53717309.ct.sendgrid[.]net (SendGrid click tracking)
3. login[.]microsoftonline[.]com/common/oauth2/v2.0/authorize with redirect_url=https://www.grammarly.com/callback

The final URL was a legitimate Microsoft OAuth authorize endpoint. URL reputation checks returned clean because login.microsoftonline.com is a real Microsoft domain. The attack lived in the parameters: the OAuth flow would prompt the recipient to authenticate and potentially grant permissions to an application controlled by the attacker. The grammarly.com/callback redirect target added another layer of plausibility, piggybacking on a well-known brand's domain.

An encoded registered-trademark symbol appeared in the query parameters, a sign of malformed or obfuscated strings typical of phishing kits that manipulate URL parameters to evade pattern matching.

Two Quality Tiers in One Attack

The template errors ({Frmsite}, grammar mistakes, appended mailing-list content) suggest a low-sophistication operator. The redirect chain (EdgePilot, SendGrid tracking, Microsoft OAuth with a plausible callback) suggests a capable credential harvesting infrastructure. This mismatch, sloppy presentation over competent technical plumbing, is increasingly common as phishing-as-a-service platforms provide pre-built redirect chains to operators who lack the skill to write clean lure content.

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

Indicators of Compromise

MITRE ATT&CK Mapping