DocuSign Kit So Reused It Left a Hearing-Aid Signature

Some phishing operations fail not because the trickery is bad, but because the operator is lazy. A message that reached a major food and dairy producer looked, at a glance, like a routine DocuSign e-signature request. It carried the familiar branding, the familiar "review the documents" language, and the familiar sense that someone was waiting on a signature. What it also carried was a signature block belonging to an unrelated hearing-aid retailer, left in place from a previous target the same kit had been pointed at. The attacker had swapped the subject and body to fit a new victim but never bothered to clean out the footer.

That single oversight is a window into how commodity phishing actually works. Kits get resold, recycled, and repointed at fresh victim lists faster than their operators can proofread them. The technique matters more than the polish, and the technique here was a credential-harvest funnel dressed up as a document to sign.

The lure and the click path

The email pushed one action: click through to review and sign a document. But the link the recipient saw did not go straight to any signing service. It went to a Google redirect, a hxxps://google[.]co[.]in/url wrapper that quietly forwarded the browser onward. Redirect wrappers on trusted domains are attractive to attackers because the visible link starts with a name a person, and many link scanners, already trust. The recipient sees Google. The gateway sees Google. Nobody sees where the ride actually ends.

Where it ended was a static HTML page hosted in an Amazon S3 bucket in the us-east-1 region, under a bucket name the attacker chose rather than any brand-registered domain. The page was styled as a DocuSign e-signature request with a prominent "REVIEW THE DOCUMENTS" call to action. Enter your credentials to proceed, and they went straight to the operator.

The personalized detail sat in the landing-page URL itself. The recipient's own email address was base64-encoded into a URL parameter, so the page could confirm exactly who had arrived and present a tailored experience. That is a small touch with two payoffs for the attacker: it lends the page an air of legitimacy (it already "knows" you), and it lets the operator track which targets took the bait. Abusing legitimate cloud storage to host the credential page is a recognized pattern, mapped in MITRE ATT&CK as T1585, Establish Accounts, with the click itself falling under T1204.001, User Execution: Malicious Link.

Authentication that almost laundered the mail

The interesting part of this case is that the technical signals were genuinely mixed, and the wrong reading of them would have let the message through. At origin, the mail failed. The true sending IP was an ISP-hosted address with no PTR record and no email-gateway reputation, and it failed SPF against the mail-from domain, which resolved to zakzoneindia[.]com. There was no DKIM signature at all. On its own, that is a message that should never have been trusted.

But a later hop told a friendlier story. As the message transited Microsoft's own relay infrastructure, that hop produced an SPF pass for a different IP and a best-guess DMARC result. Read only the last line of the authentication results, and the email looks acceptable. That downstream pass is an artifact of Microsoft accepting and forwarding the mail, not evidence that the original sender was ever authorized. A gateway that keys its verdict on the final relay's result, rather than reconstructing the origin, can be talked into delivering exactly this kind of message.

This is the practical reason authentication alone is not a phishing verdict. SPF, DKIM, and DMARC describe whether a server was allowed to send for a domain. They do not describe whether the content is a lie. The 2024 Verizon Data Breach Investigations Report found stolen credentials involved in 38 percent of breaches, the single most common initial action, and phishing present in 15 percent. When credentials are the prize, the delivery mechanics only have to work once.

Why this one did not land

The message never reached a working inbox. IRONSCALES Adaptive AI flagged it at 90 percent confidence and labeled it credential theft. The call did not hinge on the mixed authentication picture, which a naive check could have misread. It came from a content-pattern match on the flagged malicious link combined with a strong community-reputation signal, the collective intelligence of thousands of other mailboxes that had already seen and reported the same fingerprints.

That is the difference between reading headers and reading intent. The recycled hearing-aid signature, the redirect that unwrapped to an untrusted S3 bucket, the base64 target confirmation, and the reputation of the infrastructure all pointed the same direction, regardless of what the last relay hop claimed. The behavior is catalogued as T1566.002, Spearphishing Link, and it is exactly the shape of attack that slips past a legacy secure email gateway leaning on authentication and static reputation.

Indicators of Compromise

What to take from it

Treat brand-styled document requests as unproven until the destination is proven, not the pretext. A DocuSign, Adobe, or e-signature notification is trivial to imitate, and the real signal is where the link resolves after every redirect, not what logo sits at the top. Guidance from CISA on stopping the phishing attack cycle reinforces the same point: the tell is in the flow, not the framing.

For defenders, three habits close most of this gap. Resolve redirects fully before trusting a link, including wrappers on otherwise reputable domains. Do not read a downstream relay pass as origin authorization. And back human review with detection that weighs content and community reputation together, because a lazy kit will always leave a thread hanging, and the job is to be watching for it. Credential-harvest pages are cheap to spin up on cloud storage, so protecting the account itself with account takeover protection matters as much as blocking the mail. The kit reuse here was sloppy. The intent was not, and only one target had to miss the hearing-aid signature for it to work.