Chinese-Linked DocuSign Phishing Campaign Targeting Google Workspace Credentials

An employee received what looked like a routine DocuSign notification. SPF, DKIM, and DMARC all came back clean. Google’s own infrastructure had delivered the message. Everything checked out – except the user, who clicked Report Phishing and forwarded it to our SOC.

What we found behind that one click was a targeted spear-phishing operation traced to Chinese-linked infrastructure, built on a multi-layer redirect chain that hid a fake Google login page from automated scanners and analysts alike. This is a write-up of the case, with the facts up front so any defender facing the same email can move fast.

At a Glance: Who, What, When, Where, Why

What Happened

A single user received a phishing email styled to look like a DocuSign signature request. The lure pretended to be a Revised Financial Statement awaiting signature – a plausible business-context pretext, not a generic one.

• Subject line: CONFIRMATION: New document ready for [recipient-email] today
• Sender address: [email protected]
• Display name shown to user: DocuSign
• Email authentication: SPF, DKIM, and DMARC all valid
• Delivery path: via legitimate Google infrastructure

A Google Workspace Message Trace confirmed the email reached only one mailbox inside the organization. No similar messages, no broader campaign artifacts. The available evidence indicates this was a single, hand-picked target – not a bulk send.

Three signals separate this from generic mailbox spam: the victim’s email address appears in both the subject line and the payload URL parameter; the lure is built around a specific business pretext (Revised Financial Statement); and the back-end infrastructure is operationally complex (TDS, obfuscated loader, anti-analysis). That combination is the fingerprint of a deliberate spear-phishing operation.

Why We Attribute This to a Chinese-Linked Threat Actor

Three independent infrastructure and behavioral indicators tie this campaign to a China-nexus operator. None is conclusive on its own; together they form a consistent profile.

1. Hong Kong sender domain. hzmbparking.com.hk is a .com.hk Hong Kong-registered domain whose name references the Hong Kong–Zhuhai–Macao Bridge (HZMB). The domain itself is otherwise legitimate, indicating that it was either compromised or repurposed as a delivery asset in the chain rather than being a throwaway phishing domain.
2. Microsoft Azure Hong Kong hosting. The sender domain resolves to 20.239.43.41, which belongs to Microsoft’s Hong Kong Azure region. Operating delivery infrastructure from inside a Chinese-territory cloud region is a typical operational choice for China-nexus campaigns.
3. Decoy redirect to a Chinese consumer platform. When the malicious JavaScript detects a sandbox, headless browser, or live analyst, it does not show an error page – it redirects the visitor to Meituan (美团), one of China’s largest consumer/food-delivery platforms. Using a Chinese-language consumer site as the “safe” decoy is a recurring signature of China-language threat actors operating TDS-based phishing kits. Researchers and automated scanners therefore see a harmless Chinese consumer site and may classify the URL as clean.

Taken together, an HZMB-themed Hong Kong domain, Azure Hong Kong hosting, and a Meituan decoy is not a defender pretending to be Chinese. It is a Chinese-linked operator building a phishing chain that benefits from being misclassified as Chinese-domestic traffic.

How the Attack Chain Worked

The attacker did not host the phishing page on a single malicious server. They chained legitimate, abused, and compromised infrastructure to make takedown harder and to evade signature-based detection.

1. Email delivery. Sent through legitimate Google infrastructure (which is why SPF/DKIM/DMARC passed), with DocuSign in the display name and a mismatched sender domain.
2. First-hop link: SendGrid tracking URL. The link in the email body routes through a SendGrid tracking URL. This gives the attacker click telemetry and launders the click through a trusted email-marketing service.
3. Compromised website redirect. The SendGrid link forwards the victim to a compromised legitimate Italian website, used as a stepping stone in the chain: birrificioottozampe.it/uonmscomo*.
4. Traffic Distribution System (TDS). Traffic then routes through giotaitra.app, with associated interactions to driojoodoo.com returning a 404 Not Found for non-victim profiles. A TDS decides what each visitor sees based on browser fingerprint, IP geolocation, and behavior – real victims, researchers, and sandboxes all see different things.
5. Final landing page. A high-fidelity fake Google login page, designed to capture the victim’s Workspace credentials and hand them back to attacker-controlled infrastructure.

The TDS is what makes this campaign especially dangerous. Researchers, sandboxes, and automated URL scanners get served harmless content (or the Meituan decoy). Only the intended human victim sees the credential trap.

How the Email Bypassed SPF, DKIM, and DMARC

This is the most important defender takeaway from this incident.

The email was delivered through Google’s own outbound infrastructure, so the cryptographic checks (SPF, DKIM, DMARC) all returned valid. None of those protocols verify the display name – they verify the underlying envelope sender domain. The attacker put “DocuSign” in the display name and used [email protected] as the actual sender. A user glancing at their inbox saw DocuSign. The authentication chain saw a clean delivery.

Passing SPF, DKIM, and DMARC is not a guarantee that an email is safe. It only confirms that the sending server is allowed to send for that domain. Display-name impersonation slips through the gap.

Indicators of Compromise (IOCs)

Use these to search your own email logs, firewall logs, and EDR telemetry.

Email indicators

• Subject line pattern: CONFIRMATION: New document ready for [recipient-email] today
• Sender address: [email protected]
• Display-name spoof: DocuSign
• Lure theme: “Revised Financial Statement” awaiting signature
• Personalization marker: recipient email appears in both subject and URL (plaintext or Base64)

Network and URL indicators

• hzmbparking.com.hk – sending domain (legitimate, abused or compromised)
• 20.239.43.41 – Microsoft Azure Hong Kong IP for the sender domain
• birrificioottozampe.it/uonmscomo* – compromised Italian website used as redirector
• giotaitra.app – Traffic Distribution System (TDS) domain
• driojoodoo.com – TDS-associated endpoint (returns 404 for non-victims)
• Decoy / “safe” redirect: Meituan (美团) – meituan.com
• Final stage: fake Google / Google Workspace login page

Detection signals

• VirusTotal detection at time of analysis: 1 of 92 engines
• No prior listings in PhishTank, VirusTotal, or URLScan.io
• Recipient email address embedded in URL query string, plaintext or Base64-encoded
• JavaScript loader uses Base64 + XOR obfuscation (see technical deep dive below)

Detection and Response

Once the campaign was confirmed, UnderDefense’s SOC took the following actions:

• Blocked the sender [email protected] at the Google Workspace tenant level.
• Blocked the full URL chain – birrificioottozampe.it/uonmscomo*, giotaitra.app/, and http://driojoodoo.com/ – at both the FortiGate firewall and inside Google Workspace policies.
• Notified the targeted user and confirmed no credentials were submitted.
• Expanded internal tooling access. T2 and T3 SOC analysts now have direct Google Workspace Message Trace access, so future investigations are not bottlenecked by the incomplete email telemetry available in Splunk alone. Native Message Trace was the difference between a 5-minute scoping decision and a multi-hour investigation in this case.

A fully generalized detection rule for this exact campaign is currently constrained: the visible alert came from a user report rather than a full email-telemetry pipeline. Where defenders have email-gateway visibility, we recommend combining display-name impersonation analysis with URL-chain analysis against compromised-domain feeds.

Technical Deep Dive: Inside the Obfuscated JavaScript Loader

This section is for readers interested in the malware-analysis layer of this campaign. The headline facts and IOCs above are sufficient for response and detection – the rest of this article unpacks what dynamic analysis of the TDS payload revealed.

Base64 + XOR-obfuscated loader

The intermediate page in the TDS chain served heavily obfuscated JavaScript using Base64 plus XOR encoding. After de-obfuscation, the script behaves as a staged loader with three responsibilities: victim identification, anti-analysis, and credential capture.

Victim identification

The loader extracts a victim ID from the URL – the recipient’s email address is passed as a URL parameter, sometimes in plaintext and sometimes Base64-encoded. It uses that ID to construct a unique request back to the TDS at giotaitra.app to fetch the next stage, tailored to that victim. If the URL is opened without a valid victim ID (for example, by a researcher copying the link without the parameters), the TDS returns benign or error responses.

Anti-analysis defenses

The loader ships with a suite of checks designed to spot sandboxes, automated crawlers, and live researcher inspection:

• Reads navigator.webdriver to detect headless and automation frameworks
• Looks for PhantomJS, Burp Suite, and other proxy or instrumentation signatures
• Intercepts F12, Ctrl+Shift+I, and other DevTools-opening keyboard shortcuts
• Disables the right-click context menu
• Uses performance.now() timing differentials to detect a paused or attached debugger

If any of these checks trip, the loader breaks the attack chain and redirects the visitor to a benign destination – in this campaign, Meituan (美团), a major Chinese consumer platform. Researchers and sandboxes therefore see a harmless food-delivery site and may classify the URL as clean. This is the cleanest way to spot China-nexus TDS kits in the wild: when a sandbox runs a suspicious URL and lands on a Chinese consumer site for no obvious reason, that is the kit deliberately hiding from you.

Credential capture

For visitors who pass every check, the loader hands off to the final stage: a high-fidelity fake Google login page. Credentials entered here are submitted to attacker-controlled infrastructure. Because the user is then redirected to a real Google login flow on submission, the victim often does not realize anything went wrong.

The end-state objective is to harvest Google or Google Workspace credentials. In any organization using Google Workspace for SSO, those credentials are a master key into Slack, Atlassian, Notion, GitHub, internal admin consoles, and much more – which is why this kind of campaign is more dangerous than its surface looks.

Key Takeaways for Defenders

• Email authentication is not enough. SPF, DKIM, and DMARC do not stop display-name impersonation. Treat valid authentication as one signal, not a verdict.
• Display-name vs sender-domain mismatch is the cheap, reliable detection. If “DocuSign” sends from a .com.hk parking domain, that should never reach the inbox.
• TDS infrastructure beats URL scanners. Don’t rely on sandbox verdicts alone – the malicious payload is only served to the intended victim.
• A Chinese consumer site as a decoy is a fingerprint, not a coincidence. If a suspicious URL ends up on Meituan, Taobao, or similar with no business reason, treat it as a China-nexus TDS signal.
• Personalization in the URL is targeted intent. Victim email in both subject and URL parameter is not bulk spam behavior.
• Give Tier 2/3 analysts native email-log access. Splunk is useful, but raw Google Workspace Message Trace data is often the difference between a fast scoping decision and a slow one.

If you suspect your organization received a similar email – same subject pattern, same .com.hk sender domain, or any of the listed redirect domains – preserve a full copy of the email headers, block the sender and the URL chain across email and firewall, and review Message Trace for additional recipients. UnderDefense’s SOC is available to support live incident response if you need a second pair of eyes.

Protect Your Organization Before the Next Attack Lands

Targeted phishing campaigns like this one are designed to slip past conventional defenses – and they’re only getting more sophisticated. If you’re unsure whether your current security stack can detect and respond to spear phishing, credential harvesting, or TDS-based infrastructure, UnderDefense can help. Our team provides 24/7 managed detection and response, phishing investigation, and threat intelligence tailored to your environment. Contact UnderDefense to talk through your exposure and find out how we can strengthen your defenses before attackers find the gap.