The DocuSign Template That Forgot to Replace 'Putyourlinkhere'

Phishing kits are reusable. That is their advantage and their weakness. When an operator deploys a kit without replacing every placeholder, the artifacts they leave behind become forensic evidence, revealing the template's structure, the operator's sloppiness, and sometimes the kit's lineage across campaigns. In this case, the artifact was a single HTML attribute: title="Putyourlinkhere".

A DocuSign-themed credential-harvesting email arrived at a managed IT services provider, spoofing an internal employee's address as the From header. The message failed SPF (PermError), had no DKIM signature, and failed DMARC. Microsoft's composite authentication still passed it. Themis flagged it at 90% confidence as credential theft.

The Template Left Its Fingerprints

The phishing email mimicked a DocuSign e-signature notification, claiming "All parties have completed" a document titled "Executed NDA FY26 Agreement.pdf." The primary call-to-action button read "REVIEW & SIGN DOCUMENT" and was styled in DocuSign's blue (#275EF5) with white text. At a glance, it could pass for a real DocuSign notification.

But the HTML told a different story. The anchor tag wrapping the CTA button carried title="Putyourlinkhere", a placeholder the kit operator never replaced. This attribute is invisible in most email clients because title attributes render only on hover in desktop browsers, not in mobile email apps where most recipients read messages. The operator likely never saw it.

The template also contained duplicate content blocks, broken image references (empty src attributes on the DocuSign logo), and repeated instances of the recipient's email address in places where DocuSign would normally display the signer's name. These are hallmarks of a mass-produced phishing kit that uses email address injection as a personalization shortcut.

A fabricated security code (A6756F11989F4294AD8256DB8CB89D713) added false urgency, instructing recipients to "Click 'Access Documents' and enter the security code." Legitimate DocuSign workflows do not distribute access codes via email body text in this format.

The Google.it Redirect Chain

The CTA button linked to a Google.it redirect URL with the q= parameter pointing to marmotaweb[.]com[.]br/.io/87656/. This is a Google redirect that resolves the q= parameter to the attacker's landing page. Using Google's redirect service means the initial URL points to a Google-owned domain, which some link-scanning engines evaluate as clean without following the redirect to the final destination.

The landing page at marmotaweb[.]com[.]br/.io/87656/ is a compromised Brazilian domain. WHOIS shows a Brazilian registrant unrelated to DocuSign, and the domain hosts what appears to be a legitimate business website at its root. The attacker placed the credential-harvesting page in a subdirectory, piggybacking on the domain's existing reputation.

The URL also included a base64-encoded fragment (#87634598Family=am9lLmdyYWJvd3NraUBzZWVkc3BhcmsuY29t) that decodes to the recipient's email address. This pre-populates the credential form with the target's identity, reducing friction and increasing the likelihood of a successful harvest.

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

Authentication: Three Failures, One Pass

The From header used a real employee's address at a managed IT services provider. But the message originated from 198.23.177.24, a ColoCrossing hosting IP with no relationship to the spoofed domain.

SPF returned a PermError because the spoofed domain's SPF record contained an invalid mechanism that the evaluating gateway could not process. DKIM was absent entirely (dkim=none). DMARC failed because neither SPF nor DKIM aligned with the From header domain.

Despite these three failures, Microsoft's composite authentication (compauth) returned pass with reason=703. Reason 703 indicates the message "appears to be from a legitimate sender" based on heuristic signals, overriding the explicit authentication failures. The message was delivered at SCL 1.

IRONSCALES Adaptive AI evaluated the message at 90% confidence as credential theft. Community intelligence provided additional confirmation, with both community reputation signals and historical phishing resolutions supporting the classification. The message was automatically resolved as phishing and the affected mailbox was quarantined.

MITRE ATT&CK Alignment

IOC Summary Table

What This Case Demands From Your Stack

When authentication fails three ways and the message still reaches the inbox, the detection surface must extend beyond authentication.

Inspect HTML attributes, not just visible content. Title attributes, alt text, and class names in phishing emails frequently contain kit artifacts that are invisible to the recipient but detectable by automated inspection. These artifacts are high-confidence phishing indicators with near-zero false positive rates.

Follow Google redirects to their destination. Any link that uses google.com/url, google.it/url, or similar redirect services should be evaluated at the final destination, not at the wrapper domain. If your link-scanning engine stops at Google, it is blind to the actual threat.

Treat compauth reason=703 with caution. A composite authentication pass based on heuristics, not cryptographic verification, should not override three explicit authentication failures. Audit your transport rules to confirm that compauth results are weighted appropriately against SPF, DKIM, and DMARC signals.