The DocuSign Button That Pointed at Adobe, and Redirected to an S3 Credential Page

The email announced a completed document. "Your completed document is ready to review," it read, above a single blue button in the visual language of a DocuSign envelope. The subject line referenced an executed agreement and signature packet, the kind of routine legal artifact nobody scrutinizes. Beneath the button, a long and entirely unrelated business thread had been appended, complete with real corporate signatures, to make the message look like the latest reply in an ongoing conversation.

The button did not point to DocuSign. It pointed to a third party's Adobe Campaign marketing-automation subdomain on campaign[.]adobe[.]com, whose /r/ tracking link redirected the click onward to a page hosted on s3[.]us-east-1[.]amazonaws[.]com. The destination was a credential-harvesting page, reached by way of borrowed Adobe and Amazon reputation.

The Sender Was Real, Which Was the Problem

This message was not spoofed. It originated from a genuinely compromised Microsoft 365 mailbox at a European design firm. Because the attacker was operating a real account, the message carried a valid DKIM signature for that tenant's onmicrosoft.com domain and earned a composite authentication pass (compauth=pass) as it transited Microsoft's own protection.outlook.com gateway.

The only authentication wrinkle was an SPF fail at the original connecting IP, a German hosting address (195.201.92.211, a your-server.de host). That looks alarming in isolation, but legitimate gateway forwarding breaks SPF alignment the same way, and the receiving system saw SPF pass at the Microsoft gateway hop. The signal washed out.

This is the defining trait of email account compromise: authentication confirms that a mailbox really sent a message. It says nothing about whether the mailbox owner authorized the content. Every cryptographic check the message was designed to pass, it passed honestly.

Why the Link Cleared the Gateway

The deception lived in the gap between the brand the email claimed and the domain its button actually resolved to. A recipient, and a link scanner, both see a URL on campaign[.]adobe[.]com. That is genuine Adobe marketing infrastructure with clean reputation and no malicious history. Marketing and email-tracking platforms routinely wrap outbound links in tracking endpoints like /r/?id=..., so a click on a reputable host can resolve to somewhere else entirely.

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

Routed this way, the reputable domain absorbs the scan. The malicious S3 landing page only enters the picture after the redirect fires, by which point the trusted host has already vouched for the click. The final hop, Amazon S3, supplies a second layer of borrowed trust: object storage on a hyperscaler is not something most gateways are willing to block wholesale.

No lookalike domain. No newly registered infrastructure. No malicious URL string for reputation engines to match. The visible part of the attack is built entirely out of services every enterprise already trusts.

The Personalization Tell

The redirect URL was not generic. Decoded, one of its parameters resolved to the recipient's exact email address, Base64-encoded into the link. That detail reframes the message. This was not a spray campaign that happened to land in one inbox. The link was assembled for one named person, for click tracking and likely to pre-fill the credential form on arrival. It is the fingerprint of spear-phishing: curated, one-to-one, and patient.

How It Was Caught

There was no malicious URL verdict to lean on, because the visible link was a clean Adobe domain. There was no failed authentication to quarantine on, because the compromised sender authenticated correctly. IRONSCALES Themis flagged the message on the relationship between its parts: a DocuSign-branded signature request from a first-time external sender whose sole call-to-action pointed at a marketing-automation subdomain rather than a DocuSign endpoint, carrying an encoded recipient parameter, with an appended thread that did not match the claimed transaction.

The credential harvesting intent was legible in the structure of the message, not in any single technical indicator. The message was quarantined before delivery completed.

Stopping Redirect-Laundered Credential Lures

Inspect brand-to-domain alignment. A DocuSign, Microsoft, or Adobe Sign request whose only button points somewhere other than that brand's own signing domain is anomalous no matter how reputable the link domain is. The mismatch is the signal.

Follow redirects to the final landing page. Stopping the analysis at the first reputable hop is the entire vulnerability. Resolve /r/, /redirect, and tracking parameters all the way to the destination before trusting the link.

Treat marketing-automation and tracking domains as pass-through surfaces. A click endpoint on a marketing platform can resolve to another host. Reputation on the visible domain is not reputation on the destination.

Decode personalization parameters. A recipient address encoded in a URL marks a targeted message and warrants closer review.

The MITRE ATT&CK framework classifies this as Spearphishing Link (T1566.002), paired with Compromise Infrastructure (T1584). The Verizon DBIR 2025 continues to rank phishing and the use of stolen credentials among the top paths into an organization, and CISA guidance emphasizes verifying unexpected document-signing requests through a known channel rather than the link in the message.

A trusted brand, a trusted tracking link, a trusted cloud host, and a real mailbox. Four reputable strings, assembled into one credential trap.

---