TL;DR Attackers sent a convincing DocuSign notification with a "Review & Sign" button that chained through Google Maps redirects to an Amazon S3-hosted credential harvesting page. The redirect chain defeated URL scanners, and real law-firm footers added legitimacy. IRONSCALES Adaptive AI flagged the behavioral mismatch between sender infrastructure and brand identity before the first click.
Severity: High
Credential Harvesting
Brand Impersonation
MITRE: T1566.002
MITRE: T1598.003
The "Review & Sign" button looked exactly like every DocuSign notification you've ever received. Same blue branding, same layout, same urgency. But the button didn't point to DocuSign. It pointed to Google Maps > then to Amazon S3 > then to a credential harvesting page that looked close enough to a Microsoft login to fool anyone moving fast.
A Redirect Chain Built to Dodge Scanners
The email arrived at a mid-size financial services firm on a Monday morning, formatted as a forwarded legal document awaiting signature. The body included realistic law-firm footers, a bank reference, and multiple legitimate links — all designed to make the one malicious link blend in.
That malicious link: a maps[.]google[.]be redirect that resolved to a public S3 bucket hosting an HTML page at bucket-secure-cdn-cdn-media-static[.]s3[.]us-east-1[.]amazonaws[.]com/about[.]html. The page mimicked a Microsoft 365 login.
The redirect chain is the whole game here. URL scanners check the first domain, Google, and stop. The S3 destination isn't evaluated until someone clicks, and by then, the scanner has already marked it safe.
Attack Flow
DocuSign Lure Email
→
Google Maps Redirect
→
Amazon S3 HTML Page
→
Credential Harvest
See Your Risk: Calculate how many threats like this your gateway is missing
Why the Gateway Gave It a Pass
Email authentication didn't help. SPF passed, the sending server was legitimately authorized by the envelope domain, a small Japanese web services company with no connection to DocuSign. No DKIM signature. DMARC returned a best-guess pass.
So the email arrived with clean authentication, a trusted redirect domain (Google), and a hosting provider (AWS) that no blocklist is going to flag broadly. The attacker's infrastructure looked legitimate at every checkpoint.
| Check | Result | Why It Didn't Help |
|---|---|---|
| SPF | Pass ✓ | Sending server was authorized - by the wrong domain |
| DKIM | None | No signature to validate |
| DMARC | Best-guess Pass | No DMARC record - receiver inferred "pass" |
| URL Scan | Safe ✓ | Only scanned first hop (Google domain) |
IRONSCALES Adaptive AI caught what the static checks missed: the behavioral mismatch between the sender's domain infrastructure (a Japanese web hosting provider) and the claimed identity (DocuSign). Combined with community-reported patterns matching the same S3 bucket across three other organizations, the platform quarantined the message within 90 seconds of delivery, before any recipient clicked.
Your Takeaway
If your email security relies on URL reputation at the first hop, redirect-chain attacks will sail through. Ask your security team: does our scanning follow redirects to the final destination? If the answer is "sometimes" or "I'm not sure" - that's the gap attackers are counting on.
Get a Demo: See how IRONSCALES detects redirect-chain phishing in real time
The post The DocuSign Email That Wasn’t – A Three-Redirect Credential Harvest appeared first on Security Boulevard.
Themis
Source: Security Boulevard
Source Link: https://securityboulevard.com/2026/03/the-docusign-email-that-wasnt-a-three-redirect-credential-harvest/