A Fake DocuSign That Never Touches DocuSign

The notice that landed at a mid-size US accounting firm looked like the most routine thing in the world: a DocuSign e-signature request, a document waiting, a button asking someone to review and sign. For a professional-services practice that lives inside contracts, engagement letters, and client filings, a DocuSign prompt is background noise. That is exactly what made it dangerous. Four mailboxes across the firm received it, and when a firm principal forwarded it to be checked, the disguise came apart in a way that no single authentication result would have revealed.

The first thing worth saying is what was not in the message. There was no DocuSign infrastructure anywhere in it. Not a single link to docusign.net or docusign.com, no genuine envelope ID resolving to DocuSign's own servers, none of the transactional plumbing a real e-signature request carries. The brand was claimed loudly in the display name and the body, and backed by nothing. That gap between what the message said it was and what it was actually built from is the whole story.

The sender that authentication almost cleared

The From header was malformed in a way a legitimate transactional platform never produces. The display name read Digital_Docsx_Authentcation, with "Authentication" misspelled, and the address itself mashed a do-not-reply placeholder together with what looked like an encoded meeting-invite fragment, all hung off itiffyconsultants[.]com. No real DocuSign sender looks like that.

The authentication trail is where this case earns its name. The first SMTP hop came from 82[.]152[.]110[.]162, an address geolocated to the United Kingdom whose reverse DNS resolved to the literal string InfoDomainNonexistent, meaning no valid PTR record at all. That hop failed SPF against itiffyconsultants[.]com, because the address was never authorized to send for it. On its own, that is a clean rejection signal.

Then the message was relayed through Microsoft's protection[.]outlook[.]com service, and the picture changed. SPF now showed a pass, but for the relay's own IPv6 address (2a01:111:f403:c408::1), not for the originating sender. There was no DKIM signature at all, the message was never signed. DMARC returned bestguesspass, a weak inference against a domain publishing p=none and sp=none with an action of none, which is a courtesy guess, not an authoritative verdict. Composite authentication settled on compauth=pass reason=109, a result that reflects the trusted relay hop rather than any genuine validation of the sender, and the spam confidence level came to rest at SCL=5.

Read quickly, the surviving signals look acceptable. A static, auth-first gateway can accept that laundered picture and let the original failure vanish into the relay chain. The 2024 Verizon Data Breach Investigations Report found phishing present in 15% of breaches, and cases like this show why authentication checks alone keep letting it through: the attacker does not need to forge a pass, only to get a legitimate intermediary to re-score a failure. DMARC's own specification, RFC 7489, was never designed to opine on a domain that simply declines to enforce anything, which is precisely the posture the spoofed domain hid behind.

A redirect laundered through Kiribati

The payload was not an attachment. It was a single call to action, a REVIEW & SIGN DOCUMENT button, and its destination is where the tradecraft shows. The button did not point at the final malicious host directly. Its href resolved through google[.]ki, Google's URL-redirect service on the Kiribati country-code top-level domain, in a google[.]ki/url?q= form. Because the visible link begins with a Google-owned domain, it inherits a halo of trust that survives a hurried glance and some reputation checks.

Follow the redirect and it hands off to owlarms[.]com, a Turkey-hosted domain with a PTR mismatch, no DMARC record of its own, and a recently updated WHOIS registration, sitting behind a long random URL path. This maps cleanly to MITRE ATT&CK's T1566/002 spearphishing link technique for delivery, T1204/001 malicious link user execution for the click itself, and T1036/005 masquerading as a legitimate name for the DocuSign brand costume. An open redirect on a trusted domain is one of the cheapest ways to defeat link-reputation filtering, and pairing it with a country-code service most filters rarely see is what makes it effective.

The page already knew who clicked

The landing page itself was almost aggressively unremarkable: a tiny, roughly 525-byte opaque HTML payload rendering a generic session-check or captcha gate, with no real branding, confirmed by screenshot. That minimalism is deliberate. A featherweight interstitial passes cursory sandbox inspection and buys time before the real credential form loads.

The detail that elevates this from ordinary phishing is the redirect query string. It carried a base64-encoded parameter that decoded straight to the recipient's own email address. That single trick does three jobs at once. It personalizes the harvest experience, it pre-confirms the target's identity before a single character is typed, and it functions as click and mailbox-validation tracking, telling the attacker that this specific, live mailbox engaged. A firm whose staff clicked through would be marked as a validated, responsive target for the next campaign.

Why the brand claim was the tell

Because the surviving authentication looked passable, detection had to come from behavior, and it did. IRONSCALES Adaptive AI weighed the signals a suspicious analyst would: a message shouting DocuSign while carrying no DocuSign infrastructure whatsoever, a malformed and misspelled sender identity, a brand-versus-domain mismatch, and a call to action that laundered its destination through a foreign redirect. Themis surfaced it on that pattern rather than on any failed gate, and the mailboxes across the firm were remediated after a firm principal reported the message.

The uncomfortable lesson is that authenticated and safe are not the same word, and neither is "SPF failed" and "SPF fails at the mailbox." A legitimate relay can quietly re-score a rejection into a pass, and a trusted redirect can hide a hostile host in plain sight. When the brand a message claims to be is contradicted by every domain it actually uses, that contradiction is the strongest signal present, and it is invisible to a pipeline that stops reading once a green checkmark appears. This is why account-takeover protection and behavioral analysis have to sit downstream of the gateway rather than be replaced by it, and why it helps to see that behavior modeled against your own mail flow in a live demonstration.

Indicators of Compromise

• Sending domain (spoofed MAIL FROM): itiffyconsultants[.]com
• Originating IP (first hop, SPF fail): 82[.]152[.]110[.]162 (UK-geolocated, PTR: InfoDomainNonexistent)
• Relay: protection[.]outlook[.]com (SPF pass scored for relay IPv6 2a01:111:f403:c408::1, not the sender)
• Redirect / laundering hop: hxxps://google[.]ki/url?q= (Google Kiribati ccTLD open redirect)
• Final landing domain: owlarms[.]com (Turkey-hosted, PTR mismatch, no DMARC, recently updated WHOIS)
• Landing payload: ~525-byte opaque HTML fake session-check/captcha gate, no real branding
• Tracking: base64-encoded URL parameter decoding to the recipient's own email address
• Sender display name: Digital_Docsx_Authentcation (misspelled), malformed From header
• Authentication: SPF fail (origin) then pass (relay), DKIM none, DMARC bestguesspass (p=none/sp=none), compauth=pass reason=109, SCL=5

MITRE ATT&CK Mapping

• T1566/002, Phishing: Spearphishing Link. The REVIEW & SIGN button delivered the attack.
• T1204/001, User Execution: Malicious Link. The click through the redirect triggered the harvest.
• T1036/005, Masquerading: Match Legitimate Name or Location. The DocuSign brand costume with zero DocuSign infrastructure.