A Google Redirect, a Monday.com Tracker, and a Fake NDA: Credential Harvesting Through Trusted Infrastructure

The primary call-to-action button said "VIEW COMPLETED DOCUMENT." But the URL behind it never touched DocuSign. It started at Google.com, hopped through Monday.com's tracking service, and landed on a Zimbabwean domain running a credential harvesting page. The entire chain was wrapped in a JWT token that encoded the recipient's email address, meaning the attacker knew exactly who clicked and when.

This attack targeted a regional credit union, impersonating an internal employee and presenting a fabricated NDA completion notice styled after DocuSign templates. Four mailboxes received the message. SPF returned softfail, DKIM was entirely absent, and DMARC failed. None of that mattered. The email still landed in production inboxes with an SCL of 1.

DocuSign Template With a Broken Logo and a Manufactured Access Code

The email body mimicked a DocuSign "All Parties Have Signed The Completed Document" notification. It referenced a fabricated PDF filename ("Executed Agreement_8332454968.pdf"), displayed the spoofed sender's address as the signing party, and included standard DocuSign footer language about electronic signatures and a San Francisco mailing address.

Two details broke the illusion for anyone who looked closely. First, the DocuSign logo used an HTML image tag with src="#" as the source, a placeholder that renders as a broken image icon rather than loading from DocuSign's CDN. Legitimate DocuSign notifications pull branded assets from hosted infrastructure. Second, the email instructed the recipient to click the CTA button and then enter a 33-character "security code" (A6756F11989F4294AD8256DB8CB89D713) on the destination page. DocuSign does not use manually entered access codes in this format for completed document retrieval.

That access code is the credential harvesting mechanism. The destination page prompts for it, establishing a pattern where the victim enters one code, gains a sense of trust in the interaction, and is then prompted for actual credentials under the guise of "verification."

Three Hops Through Trusted Infrastructure

The redirect chain is the core evasion technique, and it follows MITRE ATT&CK T1566.002 (Spearphishing Link):

Hop 1: Google.com. The CTA button pointed to hxxps://www[.]google[.]com/url?q=..., a legitimate Google redirect service. Link scanners that evaluate only the top-level domain see Google and stop. According to the Verizon 2024 Data Breach Investigations Report, phishing remains the primary initial access vector in breaches, and redirect abuse through trusted domains is a growing evasion pattern that defeats static URL filtering.

Hop 2: Monday.com Tracking Service. The Google redirect resolved to hxxps://trackingservice[.]monday[.]com/tracker/link?r=use1&token=.... This is a legitimate Monday.com email tracking endpoint, likely abused through a free or trial account. The URL carried a JWT (JSON Web Token) containing two fields: an originalUrl pointing to the final destination and an emailId uniquely identifying the recipient. Decoding the token revealed the redirect's true target and confirmed per-recipient personalization consistent with T1598.003 (Spearphishing Link for Information).

Hop 3: stands[.]co[.]zw. The final landing page sat at hxxps://stands[.]co[.]zw/settlement, a Zimbabwean domain with no WHOIS data available and no connection to document signing services. The /settlement path was chosen to maintain the NDA/legal signing theme. This is where the "enter your access code" flow executed the actual credential harvest.

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

Authentication Failure That Didn't Trigger a Block

The email was sent from IP 104[.]161[.]48[.]106, whose reverse DNS resolved to therdpsdaddy[.]store. That PTR hostname has no relationship to the spoofed credit union domain. The FBI IC3 2024 Annual Report documented $2.9 billion in BEC and credential theft losses, with spoofed sender identity as a core enabler.

Here is the authentication breakdown:

• SPF: Softfail. The credit union's SPF record includes spf.protection.outlook.com and ends with ~all (softfail, not -all hardfail). The sending IP was not an authorized sender, but the softfail policy merely "discourages" rather than rejects.
• DKIM: None. The message was not signed at all, despite the domain having a DKIM selector published in DNS.
• DMARC: Fail. The domain publishes p=none, which instructs receivers to take no enforcement action on failures. This is a monitoring-only policy that provides zero protection against spoofing.
• compauth: Pass (reason 703). Microsoft's composite authentication passed the message despite the underlying failures, assigning SCL=1.

The self-send pattern added another layer of evasion. The From address and To address were identical, making the message appear as if the employee sent it to themselves. This bypasses impersonation detection rules that compare sender identity against a VIP list or known contacts, since the "sender" is the recipient.

Hijacked Thread as Body Padding

Below the DocuSign template, the attacker appended a complete, unrelated email thread from a community organization's internal discussion about promoting a concert on social media. The thread included real names, a Facebook page link, and a YouTube video URL. This technique (T1036.005, Masquerading: Match Legitimate Name or Location) serves two purposes: it adds volume and apparent context to the message body, and it includes legitimate URLs that dilute the malicious-to-clean link ratio. Automated content analysis that evaluates the overall "feel" of a message can be thrown off by paragraphs of genuine business communication.

Why the Redirect Chain Defeated Static Scanning

Traditional Secure Email Gateways (SEGs) evaluate links at the time of delivery. When the first hop is Google.com, the domain reputation check returns clean. Following the full redirect chain to the terminal domain requires active crawling, and even then, the Monday.com tracker adds a layer of indirection that some scanners treat as a dead end.

IRONSCALES Themis flagged this message at 90% confidence and classified it as credential theft. The detection relied on behavioral signals rather than URL reputation alone: the self-send pattern, the mismatch between the PTR hostname and the spoofed domain, the authentication triple failure (SPF softfail, DKIM absent, DMARC fail despite compauth pass), and the template anomalies in the DocuSign impersonation. The attack was automatically resolved as phishing across all four affected mailboxes.

The CISA phishing guidance recommends treating any email requesting manual code entry on an external site as suspicious. Organizations running DMARC at p=none should recognize that this policy provides visibility into authentication failures but zero enforcement. Moving to p=quarantine or p=reject would have prevented this spoofed message from reaching inboxes at all.