The DocuSign That Lived on an S3 Bucket (and Couldn't Decide Who Sent It)

The email passed every authentication check. SPF, DKIM, DMARC (with a p=REJECT policy, no less). It arrived from a real Google Workspace account belonging to a real K-12 school district in the southeastern United States. The DocuSign branding was pixel-perfect, the "Review Document" button looked exactly right, and the footer included a legitimate abuse-reporting link hosted on protect.docusign.net.

There was just one problem. The email couldn't decide who sent it.

The From header said Kristen Bowers. The body block said Luis Novella. And the footer credited the whole thing to Hasan Kurt. Three names, one envelope, zero legitimate explanation.

Three Names, One Template, Zero Excuses

Phishing kits are reusable. Attackers build templates with variable placeholders for sender names, document titles, and branding elements, then swap values for each campaign. When the template engine misfires (or when the operator gets careless), remnants from previous campaigns leak through.

That is exactly what happened here. The From header pulled one name from the compromised account. The body block rendered a second name from a previous campaign variable. And the DocuSign footer, which uses a "This message was sent to you by" attribution line, displayed a third name entirely.

For a recipient scanning the email quickly, the banner and CTA looked perfectly normal. The name mismatch only becomes visible if you read the full message, including the fine print. According to the Verizon 2024 Data Breach Investigations Report, the median time to click a phishing link is under 60 seconds. Most recipients never reach the footer.

A School District Domain as the Sending Platform

The attacker did not spoof the sender domain. They controlled it. The sending address, kristen.bowers@brantley[.]k12[.]ga[.]us, belongs to a Georgia K-12 school district running Google Workspace. The email was transmitted through mail-sor-f41[.]google[.]com (IP 209[.]85[.]220[.]41), a legitimate Google mail relay.

Because the message originated from an authorized Google Workspace account:

• SPF passed: Google's IP is an authorized sender for the district's domain.
• DKIM passed: The message was signed with the district's google DKIM selector.
• DMARC passed: The domain's DMARC policy is set to p=REJECT sp=REJECT, the strictest possible configuration. The email aligned perfectly.

This is the paradox of DMARC in account compromise scenarios. A p=REJECT policy is designed to prevent unauthorized senders from using your domain. But when the attacker IS an authorized sender (because they compromised a legitimate account), DMARC does exactly what it is supposed to do: it passes. The Microsoft Digital Defense Report 2024 documented a significant increase in attacks leveraging compromised educational institution accounts for exactly this reason. These domains carry inherent trust with email filters.

K-12 school districts are especially vulnerable to account takeover. Limited security staffing, shared devices, and inconsistent MFA enforcement create conditions where a single compromised credential provides access to a fully authenticated sending platform. According to the FBI IC3 2024 Internet Crime Report, educational institutions reported a sharp rise in business email compromise incidents involving compromised accounts being weaponized against external targets.

The S3 Bucket That Wasn't DocuSign

The "Review Document" button, the primary call-to-action in every legitimate DocuSign notification, linked to:

hxxps://proposal-submission-1[.]s3[.]eu-north-1[.]amazonaws[.]com/invite/request[.]html

Not docusign.com. Not docusign.net. An Amazon S3 bucket in the eu-north-1 region (Stockholm), serving a static HTML page designed to harvest credentials.

Attackers favor S3 for phishing infrastructure because the amazonaws.com domain carries implicit trust. Many URL reputation engines and Secure Email Gateways treat Amazon Web Services hostnames as categorically safe. The bucket name, proposal-submission-1, was chosen to look plausible in logs. The path, /invite/request.html, mimicked a document-sharing workflow.

The rest of the email was dressed in legitimate DocuSign assets hotlinked from docucdn-a[.]akamaihd[.]net, the real DocuSign CDN. Footer links pointed to actual DocuSign pages (Terms of Use, Privacy, Support), and a valid protect.docusign.net abuse-reporting URL was included. This mix of legitimate brand links surrounding a single malicious CTA is a textbook evasion technique. It makes automated link scanning produce a mostly-clean verdict. When seven out of eight links are legitimate, the eighth gets less scrutiny.

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

The Subject Line Told on Itself

The email subject read: "Complete with Docusign: Kristen Bowers shared a file with you.pdf"

That trailing .pdf is a social engineering artifact. Legitimate DocuSign notifications never append file extensions to subject lines. The trick works because recipients mentally process it as "there is a PDF waiting for me," which increases urgency and the likelihood of clicking. The referenced document title, "Request_For_Proposal_Partnership_2026-0331," reinforced the pretext with a business-plausible filename and a date stamp.

The email was also BCC'd to undisclosed-recipients, a mass-distribution indicator. Legitimate DocuSign signing requests are addressed to specific signers, not blind-copied to hidden distribution lists.

Where the Behavioral Signals Broke Through

Email authentication told one story: everything is fine. Behavioral analysis told a different one. Themis, the IRONSCALES Adaptive AI engine, flagged the message at 90% phishing confidence within seconds of delivery. The detection signals included a first-time sender from a high-risk external domain, a primary CTA linking to infrastructure inconsistent with the impersonated brand, and community intelligence from the IRONSCALES global network where similar DocuSign-themed S3 campaigns had already been reported and classified by other organizations.

Across four affected mailboxes, the message was quarantined before any recipient clicked the harvesting page. Authentication passed. Behavior did not.

Indicators of Compromise

MITRE ATT&CK Mapping

What This Case Reinforces

Authentication is a necessary baseline, not a detection strategy. When the attacker controls a legitimate account, SPF, DKIM, and DMARC become accomplices rather than defenses. Security teams should pressure-test a specific scenario: what happens when a fully authenticated email from a first-time sender carries a CTA pointing to cloud infrastructure that is not the impersonated brand?

The three-name mismatch in this email was a gift. Most template assembly errors are subtler. The detection that mattered here was behavioral: sender reputation, link destination analysis, and cross-organization threat intelligence that had already seen this exact S3 pattern in the wild.

The school district domain, meanwhile, likely remains compromised until someone investigates. Per CISA guidance, organizations that discover their domains being used in phishing campaigns should immediately audit account access, rotate credentials, and review OAuth application grants. For the recipients targeted here, the lesson is simpler: if the "Review Document" button does not point to docusign.com, it is not DocuSign.