Skip to content Skip to footer

Anatomy of a Targeted Phishing Attack: How We Caught a DocuSign Impersonation Campaign

Not all phishing emails are created equal. While most organizations deal with mass-blast spam that security tools catch routinely, targeted phishing, also known as spear phishing, is a different beast entirely. Recently, our team analyzed a sophisticated attack that combined brand impersonation, multi-layer redirect infrastructure, and anti-analysis techniques to steal Google Workspace credentials. Here’s a full breakdown of how it worked and how we stopped it.

The Lure: A Fake DocuSign Notification

The email arrived with the subject line “CONFIRMATION: New document ready for nt@underdefense.com today,” a classic social engineering hook that creates urgency and personalizes the message to the victim. It was sent from booking@hzmbparking.com.hk, but the display name mimicked DocuSign, the widely trusted e-signature platform.

What made this tricky: the email passed SPF, DKIM, and DMARC checks. It was technically delivered through legitimate Google infrastructure, which meant standard email authentication gave it a clean bill of health. The red flag was the mismatch between the trusted brand name in the display field and the completely unrelated sender domain, a textbook brand impersonation technique.

A Message Trace in Google Workspace confirmed the email reached only one recipient, with no evidence of broader distribution within the organization.

The Infrastructure: A Multi-Layer Attack Chain

The attack didn’t use a single malicious server. Instead, it built a layered chain of legitimate and compromised services to complicate detection and attribution:

The sending domain hzmbparking.com.hk resolves to an Azure-hosted IP (20.239.43.41, Microsoft Hong Kong) and is itself a legitimate domain, suggesting it was either compromised or deliberately abused as part of the delivery chain.

The link inside the email routed through a SendGrid tracking URL, then redirected through a compromised website, then to giotaitra.app, with additional interaction with another endpoint returning a 404 response. This is the signature of a Traffic Distribution System (TDS), an infrastructure that dynamically routes traffic to different payloads depending on the user’s identity, the source of their connection, and whether they appear to be a researcher or analyst.

The Payload: Obfuscated JavaScript and Anti-Analysis Tricks

Dynamic analysis of the intermediate page revealed heavily obfuscated JavaScript using Base64 and XOR encoding. The script functioned as a loader with several capabilities:

  1. It extracted a victim identifier from the URL, including the target’s email address either in plaintext or Base64, and constructed a unique request to the TDS.
  2. It deployed a full suite of anti-analysis defenses: detecting navigator.webdriver (used by headless browsers), checking for PhantomJS and Burp Suite, blocking DevTools shortcuts (F12, Ctrl+Shift+I), disabling the right-click context menu, and detecting debuggers through performance.now() timing checks.
  3. If anything suspicious was detected, the script redirected to a benign, legitimate website to avoid raising flags, in this case, choosing a Chinese food delivery platform.
  4. For real victims who passed these checks, the final destination was a fake Google login page designed to harvest credentials.

The Goal: Google Workspace Account Takeover

The endgame here was credential theft. A compromised Google or Google Workspace account gives attackers access to email, documents, and, critically, Single Sign-On (SSO) access to any connected corporate systems. In a business context, that’s a skeleton key.

Threat Intelligence: A Fresh, Targeted Campaign

Cross-referencing the infrastructure against PhishTank, VirusTotal, and URLScan.io turned up no prior reports of this campaign. The VirusTotal detection rate was just 1 out of 92 engines, consistent with a newly deployed or narrowly targeted attack that hasn’t yet been cataloged by the security community.

Several indicators pointed to this being spear phishing rather than bulk spam: the victim’s email appeared in both the subject line and the payload URL; the document lure referenced a “Revised Financial Statement” — a plausible, business-relevant pretext; and the overall infrastructure complexity (TDS, obfuscation, anti-analysis) is characteristic of deliberate, targeted effort rather than a spray-and-pray campaign.

Response and Remediation

The following blocking actions were taken immediately:

The sender address booking@hzmbparking.com.hk was blocked in Google Workspace. All domains and URL patterns involved in the attack chain, including birrificioottozampe.it/uonmscomo*, giotaitra.app/, and http://driojoodoo.com/, were blocked at both the FortiGate firewall level and in Google Workspace policies.

Key Takeaways

  • Passing email authentication (SPF/DKIM/DMARC) does not mean an email is safe; display name spoofing bypasses all three.
  • TDS-based phishing makes URL analysis unreliable, since the malicious destination is only revealed to real victims.
  • Low VirusTotal scores on fresh campaigns are expected and shouldn’t be taken as a sign that a threat isn’t serious.
  • Personalization details, like a victim’s email in the subject or URL, are strong indicators of targeted intent.
  • Layered defenses across the email gateway, firewall, and endpoint are essential for catching what any single tool misses.

The post Anatomy of a Targeted Phishing Attack: How We Caught a DocuSign Impersonation Campaign appeared first on UnderDefense.