A DocuSign Lure Whose S3 Path Spelled SharePoint

The button said REVIEW DOCUMENT, and almost everything around it was real. Genuine DocuSign header artwork. A footer support link that resolved to docusign[.]com. A report-abuse link that resolved to protect[.]docusign[.]net. Subject line: Complete with DocuSign: Important. The message landed in a mailbox at a workforce-management and gig-labor marketplace platform having passed SPF, DKIM, and DMARC cleanly, with ARC intact behind it.

One link in the message was hostile. It pointed at an Amazon S3 object, and the person who staged that object had named the key so that anyone glancing at a status bar or a hover preview would read a SharePoint address instead of a storage bucket.

The Object Key Was the Disguise

Defanged, the destination was hxxps://s3[.]us-east-1[.]amazonaws[.]com/amzn-redirecturl-dc783fyf221-campaign[.]sharepoint[.]com/nbila[.]html.

Read it the way a browser reads it and the answer is unambiguous: the host is Amazon S3, and everything after the first single slash is an object key, which is to say a filename the attacker chose. Read it the way a person reads a URL under time pressure, left to right until something familiar appears, and the eye catches the campaign fragment, then the SharePoint fragment, and stops. The trusted brand string is inside the path, where an attacker controls it for free, rather than in the hostname, where it would cost a registration and leave a WHOIS record.

The two decoy tokens in front of the brand string do real work. amzn-redirecturl reads as an Amazon-sanctioned redirect service, which primes the reader to expect a hop to somewhere else and to accept the SharePoint fragment as the real destination. The random-looking identifier that follows it reads as a tracking token, the kind of opaque string legitimate marketing and document platforms bolt onto every link, so its presence lowers suspicion rather than raising it.

What the object actually served was 371 bytes of HTML behind an AmazonS3 server header. That size is the tell. Nothing hosting a real document review flow fits in 371 bytes. It is a shim: a page whose only job is to bounce a visitor onward to a credential-collection form or to assemble one from a remote script, keeping the file that antivirus and static scanners see almost empty. A second domain, kufritio[.]biz[.]id, sitting behind Cloudflare addresses, surfaced during visual detection of the landing flow, which is consistent with that bounce.

Authentication Was Real, Which Was the Problem

The sending domain was a nonprofit religious organization's, registered in the late 1990s, with a full set of passing authentication results including a valid DKIM signature under its own selector. Nothing was spoofed. The message was genuinely sent from that domain, which points at an abused or compromised mailbox rather than a forged header. That organization is a bystander here, not an attacker.

This is the part of email authentication that gets consistently oversold. DMARC and the specification behind it, RFC 7489, answer exactly one question: did the domain owner authorize this sending path. They do not, and were never built to, say anything about whether the human at the keyboard is the mailbox's rightful owner. A twenty-five-year-old domain with clean alignment carries reputation that a same-day registration never will, and that reputation is precisely the asset an attacker buys when they take over a mailbox instead of building infrastructure. The 2024 Verizon Data Breach Investigations Report puts stolen credentials at the top of initial breach actions, present in 38% of breaches, with phishing in 15%. Authenticated delivery from borrowed mailboxes is how that loop closes on itself.

Mixed Legitimacy as Camouflage

The genuine DocuSign links were not laziness. They were the control mechanism.

Link-reputation scoring tends to aggregate. Feed a scanner one message containing a real brand support URL, a real report-abuse URL, real footer assets, and one unknown storage object, and the aggregate leans clean. Human review behaves the same way, only worse: a cautious reader who decides to spot-check the links will usually check one or two, and four of the five in this message were authentically DocuSign. The report-abuse link is the sharpest piece of it, because clicking it and landing on a real DocuSign abuse page is powerful confirmation that the message came from DocuSign. It did not.

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

The greeting gave the game away, quietly. A real signing request names the signer, because the platform knows who it sent the envelope to. This one opened with a generic greeting to a team, which is what a template looks like when it is being sprayed rather than addressed.

The Variant That Reached Real Mailboxes

The first sighting was a single message. Roughly six weeks later the same template returned against the same organization with the brand name miscapitalized and an accounts-receivable reference bolted onto the subject: Complete with Docusign: AR HS 5942558. That second wave reached four mailboxes, and all four were quarantined and mitigated.

The reference number is worth a moment. It does not correspond to any invoice the recipient organization issued. It exists to make a signing request feel like a follow-up to a conversation the reader cannot immediately place, which is the same pretexting logic that drives business email compromise, the top social-engineering pattern in the DBIR and roughly $2.9 billion in reported losses in the 2023 FBI IC3 Internet Crime Report.

Detection did not come from the sender, the authentication headers, or the brand assets, because all three were clean or genuine. It came from the shape: a first-time sender relationship, a document-signing pretext with no matching envelope, a primary call to action resolving to cloud storage rather than the brand it claimed, and a landing object too small to be a real page. Themis, our Adaptive AI scored that combination as credential theft against a high-value recipient and flagged it, which is why the wider wave was contained rather than clicked. Six weeks between the first sighting and the campaign is a long time for a static blocklist to stay useful, and a short time for a behavioral baseline to hold.

MITRE ATT&CK Mapping

Indicators of Compromise

Where to Put the Controls

Three practical takeaways. First, treat a trusted brand string anywhere except the hostname as a red flag rather than reassurance, and teach that as a rule rather than a hunch, because the median time from opening a phishing email to clicking is 21 seconds and nobody parses a URL in 21 seconds. Second, stop reading authentication results as trust results; a clean pass on an aged domain is exactly the profile of a borrowed mailbox, a point CISA's phishing guidance makes about credential-theft campaigns generally and NIST's definition of phishing has always implied. Third, score the relationship and the destination together, not the links individually, because a message can be four-fifths authentic and still be an attack.

The economics here are worth sitting with. This campaign cost an attacker one abused mailbox and one carefully named file in a public storage bucket. The IBM Cost of a Data Breach Report 2024 puts the global average breach at $4.88 million. A 371-byte file is a very cheap way to start one.