The DocuSign Lure That Used Google as a Trust Shield (And Encoded Your Email in the Link)

The link in the email looked like it went to Google.

That is not a metaphor. If you hovered the "REVIEW & SIGN DOCUMENTS" button in this DocuSign impersonation, your email client would have shown you a google.com URL. URL scanners checking the visible href would have seen a Google domain and moved on. The actual destination, a two-month-old .ink credential harvesting page, was buried inside a google.com/url?q= redirect parameter where most tools never look.

That was layer one. Layer two was worse.

The CTA URL contained a base64-encoded token appended to the query string. Decoded, it resolves to the recipient's exact email address. The attacker did not just know where to send the phishing email. They built a mechanism so the harvest page would know precisely who clicked, pre-populate the fake login form, and record a confirmed credential attempt tied to a named target. This was not spray-and-pray. It was spray-and-track.

Why the Google Wrapper Works as a Trust Signal

Google operates a URL redirect service at google.com/url?q= that forwards users to external destinations, originally designed for tracking outbound clicks. Attackers recognized that embedding a malicious URL inside this redirect gives the visible link a google.com domain with valid HTTPS.

Two common defensive behaviors fail against it:

1. Hover-to-check is the single most-repeated user advice in phishing awareness training. "Before you click, hover the link and see where it goes." With a Google redirect wrapper, hovering shows google.com. The advice is technically correct but contextually useless.

1. URL reputation scoring tools evaluate the displayed domain. They see google.com, assign high trust, and pass the message. The actual payload URL, hxxps://z1.manxo[.]ink/ducfact/sytechin/, is never inspected unless the security tool follows redirect chains all the way to the final destination.

Across IRONSCALES platform data, redirect-chained credential harvest campaigns like this one account for a growing share of the emails that survive traditional gateway filtering. SEGs miss an average of 67.5 phishing emails per 100 mailboxes per month (IRONSCALES, 2025 SEG analysis). Redirect laundering is a significant reason why.

See Your Risk: Calculate how many threats your current email security is missing

The Base64 Recipient Token: What It Tells Us About the Attacker

The full CTA URL in this email included a fragment appended after the Google redirect:

`` hxxps://www.google[.]com/url?q=hxxps%3A%2F%2Fz1.manxo[.]ink%2Fducfact%2Fsytechin%2F&sa=D&sntz=1&usg=[hash]#?2217507521Farnlly=a3NjaGxhdHRlckBpcm9uc2NhbGVzLmNvbQ== ``

The string a3NjaGxhdHRlckBpcm9uc2NhbGVzLmNvbQ== is standard base64. Decoded: the recipient's full email address.

This encoding pattern serves the attacker in two ways. First, the harvest page pre-fills a login form with the victim's username, making the fake portal feel authentic without requiring the user to type anything. Second, every click is logged against a named target. The attacker's backend does not see an anonymous hit. It sees a confirmed email address and a timestamp. If credentials are entered, they are immediately attributed to that specific account.

According to the 2024 Verizon Data Breach Investigations Report, phishing remains the leading initial access vector, with stolen credentials implicated in 31% of all breaches. When attackers know exactly whose credentials they captured, account takeover attempts follow quickly.

Visible Template Failures: An OPSEC Mistake That Does Not Reduce the Threat

The email body contained two raw, unfilled template placeholders:

• {kschlatter@ironscales.com} (the recipient's email address, in plain text, as a failed substitution token)
• {jPETwmbJLMNJdxXeFPXnYHmvXcoqZLFWXuRruUdMXZatodFAdp} (a raw token string, likely intended to be an alternate signing code or campaign ID)

Broken mail merge is a classic attacker OPSEC failure. A properly configured phishing kit substitutes these values before delivery. When it does not, the email looks broken. Do not let that give you false comfort.

The malicious link still works. The base64 token is still in the URL. A broken template makes the email look amateurish. It does not make it safe.

CISA has documented this pattern in phishing guidance: visual imperfections in phishing emails are not indicators of reduced risk. The underlying payload mechanics operate independently of rendering quality.

The Infrastructure: A Spoofed Sender and a Domain Named to Be Forgotten

The sender address was mcobbs@brownhutchinson.com, a real law firm with a registration dating back to 2000. Legitimate-looking, established domain. But the originating IP, 51.38.109.129 (a French-hosted server), produced an SPF failure against brownhutchinson.com. The connecting host was not authorized to send for that domain. The message then entered Microsoft 365 infrastructure, was re-signed with a DKIM signature for BrownHutchinsonLLP.onmicrosoft.com, and produced passing authentication results at subsequent ARC evaluation hops.

This relay pattern, initial unauthorized injection followed by Microsoft re-signing, lets phishing messages arrive with passing authentication results at the receiving end. The Microsoft Digital Defense Report 2024 notes this class of abuse as a persistent challenge in tenant-level email security.

The harvest domain, manxo[.]ink, was registered September 23, 2025, two months before delivery. Privacy-protected WHOIS, nameservers at ns1/ns2.all-harmless[.]domains. A domain registered fresh and burned on a single campaign. The FBI IC3 2024 Internet Crime Report documented over $2.9 billion in BEC losses tied to exactly this class of short-lived infrastructure.

Themis, the IRONSCALES AI analyst, flagged this message at 90% confidence before any user interaction. Key signals: the CTA link mismatch between DocuSign branding and an off-brand destination, the newly registered .ink domain, and community intelligence from similar campaigns across the IRONSCALES customer base. The message was automatically quarantined. See how Themis handles behavioral detection at scale.

Indicators of Compromise

What Defenders Should Change After Seeing This

The hover-to-check mental model is not wrong. It is just insufficient for redirect-wrapped attacks. Three specific changes address this campaign class:

1. Require security tools that follow redirect chains. URL inspection that stops at the visible domain cannot detect this technique. Your gateway or inline security layer needs to dereference google.com/url?q= redirects and scan the final destination, not the wrapper. See how layered URL analysis works in the IRONSCALES platform.

2. Build detection logic around newly registered destination domains. manxo[.]ink was 55 days old when this email landed. Domain age is a reliable signal for disposable phishing infrastructure. A two-month-old .ink domain appearing as the final destination of a DocuSign notification should automatically elevate risk scoring regardless of what redirect wrapped it.

3. Update user training to include the redirect exception. "Hovering shows google.com" is not a safe signal anymore. Users who report suspicious DocuSign emails they did not request, regardless of what the hover shows, provide the human detection layer that complements automated tools. IRONSCALES phishing simulation testing includes redirect-wrapped lures in its exercise library for this reason.

The attacker in this case made one visible mistake: the template placeholders. They made zero mistakes with the link chain itself. The Google wrapper worked as designed. The base64 token was correctly formatted. The harvest domain was live. Detection came from behavioral analysis, not from anything visually wrong with the URL.

That is the gap worth closing.