Every Link Was Real: DocuSign Reply-To Diversion With a Same-Day Domain

The email passed every check. SPF, DKIM, DMARC, composite authentication. Every link in the body resolved to na4.docusign[.]net. The sender address was dse_NA4@docusign[.]net. The template was pixel-perfect DocuSign, complete with security code, "Powered by DocuSign" footer, and a blue "REVIEW DOCUMENT" button that linked to a real DocuSign signing page.

DocuSign sent this email. That is not a simplification. The infrastructure, the signing keys, the envelope routing, all of it was DocuSign's production environment doing exactly what it was designed to do.

The attacker's fingerprint was in a field most recipients never see.

The Reply-To That Points Somewhere Else

The From address was dse_NA4@docusign[.]net, a standard DocuSign envelope sender. The Reply-To was receipts@leadsavingsonline[.]com.

That domain, leadsavingsonline[.]com, was registered on April 21, 2026. The same day this campaign was active. Privacy WHOIS. No DMARC record published. No MX records beyond what a registrar provisions by default. The domain existed for one purpose: to collect replies.

This is MITRE ATT&CK T1585.002 (Establish Accounts: Email Accounts). The attacker registered a domain and configured a receiving mailbox on it, then pointed DocuSign's Reply-To field at that address. The domain did not need to send a single email. It did not need to pass any authentication checks of its own. It just needed to receive.

The payment acknowledgment framing was designed to elicit a response. A recipient who believed the document was legitimate and replied with questions about the payment, confirmation of receipt, or a forwarded thread to their accounting department would send that reply directly to the attacker's infrastructure. No credential harvest page required. No link to click. The payload was the conversation itself.

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

The Brand Tell Nobody Caught on First Pass

The email carried a logo image displaying "Lead Bank" (singular). The body text referenced "Leads Bank" (plural). That is a small inconsistency, the kind of thing that reads as a typo if you notice it at all. In context, it reveals something about how the lure was constructed.

The attacker likely sourced the logo from one location and wrote (or templated) the body text separately. The mismatch means the envelope was not copied from a genuine Lead Bank communication. It was assembled. Real brands do not misspell their own name in their own templates.

This is a detection surface that automated systems can leverage. Brand consistency analysis, comparing entity names across visual assets, display names, body text, and signature blocks, is a signal layer that pure authentication and URL reputation checks cannot replicate. When the same entity name appears in three different forms across one email, the probability that the message is fabricated goes up sharply.

What the Scanner Stack Saw

Here is what a traditional email security gateway would have evaluated:

Authentication: SPF pass (docusign.net). DKIM pass (d=docusign.net). DMARC pass. Composite authentication score 100. No override, no policy exception. Clean.

URL reputation: Every link in the email body pointed to na4.docusign[.]net/Signing/EmailStart.aspx. DocuSign's production signing infrastructure. Scanned clean by every reputation feed. No redirect chains. No obfuscation. No second-hop destination.

Sender reputation: DocuSign's IP space. Massive sending volume. Established domain. High sender score.

Content analysis: Standard DocuSign template language. Security code in footer. Professional formatting.

Verdict: SCL 1. BCL 4. Delivered to inbox.

Every signal a signature-based or reputation-based system evaluates came back green. The email was, by every traditional measure, legitimate. Because DocuSign legitimately sent it.

The Detection Surface That Matters

The signals that identified this email as malicious were behavioral, not technical.

Reply-To domain age. The domain in the Reply-To header was registered the same day. This is a strong negative signal independent of authentication results. Legitimate business communications do not route replies to domains that did not exist 24 hours ago.

Reply-To domain mismatch. The sending infrastructure was DocuSign. The Reply-To was a completely unrelated domain with no connection to DocuSign, the impersonated brand, or the recipient's organization. This split between "who sent it" and "who receives the reply" is a core indicator of credential harvesting and reply-based fraud campaigns.

Brand entity inconsistency. The logo said one thing. The body text said another. This mismatch is programmatically detectable and statistically uncommon in legitimate platform-generated emails.

Sender relationship context. The recipient, at a forensics consulting firm, had no prior communication history with this DocuSign sender or the impersonated brand. First-contact DocuSign envelopes from unknown entities, especially those requesting payment acknowledgment, carry elevated risk.

A user at the recipient organization reported the email. IRONSCALES correlated that report with the behavioral signals already flagged by Themis, the platform's adaptive AI, and quarantined the message.

The Platform Abuse Model

This case represents what platform abuse looks like at maturity. The attacker did not compromise DocuSign. They used it as designed. They created an account, built an envelope, set a Reply-To, and clicked send. DocuSign handled the rest: the authentication, the template rendering, the link generation, the delivery.

The attack maps to T1566.002 (Spearphishing Link) for the initial delivery vector and T1036 (Masquerading) for the brand impersonation layer. The link in the email was real. The brand was fake. The payload was a reply.

There is nothing to detonate. Nothing to sandbox. Nothing to blocklist. The attacker infrastructure is a single receiving mailbox on a throwaway domain. By the time a threat intelligence feed picks up leadsavingsonline[.]com, the attacker has already registered the next one.

Detection for this class of attack has to move upstream of the payload. Reply-To domain age, brand consistency validation, sender relationship mapping, and behavioral anomaly detection are the layers that catch what authentication and URL scanning cannot.

---

Indicators of Compromise