DocuSign Lure Chains Through EdgePilot and SendGrid to a Fabricated Microsoft OAuth Authorize Endpoint

The login page the victim would have seen was real. The Microsoft domain, the SSL certificate, the familiar authorization prompt: all genuine. What was fabricated was everything around it: the application requesting permissions, the parameters injected into the URL, and the redirect destination waiting to receive the access token.

A senior lending officer at a regional bank received an email displaying DocuSign branding, complete with DocuSign's real San Francisco corporate address, a "View Completed Document" call to action, and a subject line formatted with the random-token suffix style that DocuSign uses on genuine signing notifications. The sender address was info@welook[.]com[.]au, a domain with no affiliation with DocuSign. The message was delivered via SendGrid. Inside the body, an unpopulated template placeholder ({Frmsite}) was visible alongside grammar errors and an unrelated mailing-list thread appended below the signing prompt. These are artifacts of a commodity phishing kit assembled from multiple templates, sent at scale without final quality checks.

The email reached five mailboxes at the same financial institution. The detection system automatically resolved it as phishing at 90% confidence and mitigated all five copies before any recipient clicked.

The Three-Layer Redirect Chain and What It Concealed

The "View Completed Document" CTA did not link to docusign.com. It linked to link.edgepilot.com, the URL-wrapping prefix inserted by the recipient organization's own email security gateway.

EdgePilot is a legitimate click-protection service. When a security gateway installs EdgePilot link-rewriting, every URL in inbound email is wrapped in an EdgePilot proxy that checks destination reputation at click time. The attacker's link structure exploited this in two ways. First, the EdgePilot wrapper inspected a SendGrid click-tracking URL (u53717309.ct.sendgrid[.]net), not the final destination: the reputation check was performed one layer too early. Second, the presence of the EdgePilot prefix gave the link the visual appearance of having passed security review. A recipient who recognizes their organization's link-protection prefix may interpret it as a safety endorsement.

The full chain ran: link.edgepilot[.]com redirect → u53717309.ct.sendgrid[.]net click tracker → Microsoft OAuth v2.0 authorize endpoint.

The Microsoft OAuth endpoint was real: login.microsoftonline[.]com/common/oauth2/v2.0/authorize. What was injected into the URL parameters was not.

The Fabricated OAuth Application

The OAuth authorize URL carried a client_id of 0176e8f8-0828-4657-8eea-2adc34f5e7fd. This is a specific Azure Active Directory application registration. The parameters accompanying it included fabricated device telemetry: deviceModel=SM-G998B, os_version=Android13, platform_type=tv, and partnerID=BRAVIA-META-AI. None of these are standard Microsoft OAuth parameters. They are attacker-injected values designed to make the URL look like it originated from a specific device or partner ecosystem, adding surface complexity that might confuse automated parameter inspection.

The redirect_url was set to hxxps://www.grammarly[.]com/callback?extra_step=validate. In a legitimate OAuth flow, the authorization code or token is sent to the registered redirect URI. An attacker using a malicious Azure application can register any redirect URI they control, then direct the callback to an intermediate handler before passing through to a legitimate-looking domain. The extra_step=validate parameter appended to the Grammarly callback URL is another fabricated injection with no function in the real Grammarly application.

This is the adversary-in-the-middle pattern applied to OAuth: the legitimate authorization page is used as a trust anchor, while the attacker's application registration intercepts the delegated token. MITRE ATT&CK T1550.001 (use alternate authentication material: application access token) covers the token-theft objective. The attacker does not need the victim's password. A granted token for User.Read and openid profile scopes provides persistent access to profile data and serves as the foothold for further access escalation.

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

Template Artifacts as Detection Signal

The body analysis found the phrase "Document can only be view by" (verb tense error), the unpopulated {Frmsite} token, and a block of unrelated content from a Harford County civic committee newsletter appended below the DocuSign template. These are quality-control failures from a bulk phishing operation: the same kit sent multiple template variants, and one or more recipients received a partially configured instance where variable substitution failed and a content block from a separate campaign leaked in.

Two links in the message resolved to a YouTube video and a Facebook page for a local civic organization, neither related to DocuSign or banking. These clean-verdict links served as noise: scanner systems that evaluate a link list as a whole may weight a majority of clean verdicts toward a benign classification even when one link in the set carries risk.

Consent phishing via OAuth is particularly effective against organizations where employees use Microsoft 365 and are accustomed to authorizing third-party applications. The authorization prompt is genuine, the domain is microsoft.com, and the user has no reason to inspect the client application's registration details. IRONSCALES detected the cluster of signals: first-time sender, domain mismatch, fabricated OAuth parameters, and the Themis community signal correlating this template against prior phishing activity.

MITRE ATT&CK T1566.001 covers the spearphishing link delivery. T1656 covers the DocuSign identity impersonation throughout the message.

Indicators of Compromise