The Button Text Was the Weapon: Unicode RTL Obfuscation Inside a DocuSign Lure

TL;DR A credential-harvesting campaign combined two underappreciated evasion techniques: Unicode right-to-left (RTL) marks (U+200F) embedded inside the clickable button text itself, and Constant Contact tracking infrastructure used as the first redirect hop to present a trusted domain to URL scanners. The email impersonated DocuSign using a DocuSign-style template, but linked to a Turkish-hosted harvest page at sync.bursatasdunyasi[.]com whose TLS certificate did not match its hostname. The sender domain passed DMARC via DKIM alignment, sent through Amazon SES, suggesting a compromised or abused marketing workflow. Themis flagged the campaign with 89% confidence on credential theft and VIP recipient risk signals.
Severity: High Credential Harvesting Phishing Brand Impersonation MITRE: {'id': 'T1566.002', 'name': 'Phishing: Spearphishing Link'} MITRE: {'id': 'T1027', 'name': 'Obfuscated Files or Information'} MITRE: {'id': 'T1036', 'name': 'Masquerading'}

The button said "REVIEW DOCUMENT." It looked exactly right. The color, the layout, the DocuSign branding, the fake security code in the footer. Nothing was visually off.

But embedded inside the button label text were dozens of Unicode right-to-left marks (U+200F), invisible to the human eye and devastating to the NLP pipelines that parse email content for threat signals. The string that rendered as clean English to every reader was a scrambled mess of zero-width control characters to every automated scanner trying to classify it.

That was only the first layer.

What the Scanner Saw at the Link

The CTA button resolved to cmopv9hbb.cc.rs6.net, a Constant Contact tracking domain. To most URL reputation engines, that URL is fine. Constant Contact is a legitimate email marketing platform used by thousands of companies. The domain has a long history. It's on nobody's blocklist.

That's exactly why attackers use it.

The Constant Contact redirect existed solely to absorb the first inspection. Behind it, the actual destination was sync.bursatasdunyasi[.]com, a subdomain hosted on IP 78[.]135[.]106[.]170 in Turkey. The PTR record for that IP resolves to west.ajansay.com, a web services provider. The TLS certificate presented by the server did not match the hostname. Standard browsers would flag this as an error. Most automated link scanners following the chain would already have marked the upstream hop as trusted and moved on.

A second redirect variant was also present in the same email body, routed through Mailjet tracking infrastructure (10o9o.mjt.lu/lnk/...) with the destination base64-encoded in the URL path. Same harvest endpoint. Two marketing platform redirect chains, two trusted first hops, one credential page waiting at the end.

See Your Risk: Calculate how many phishing emails your gateway is missing each month

The Unicode Obfuscation Technique (and Why It Works Here)

Unicode obfuscation is not a new concept. Security teams have known about homoglyph attacks (substituting visually similar characters from other scripts) for years. What this campaign did differently is worth a closer look.

The RTL marks were not in the domain name. Not in the URL path. Not in the sender address. They were inside the button label text rendered to the recipient.

Every character in "REVIEW DOCUMENT" had a U+200F right-to-left mark injected after it. From the HTML source: R‏E‏V‏I‏E‏W‏ ‏D‏O‏C‏U‏M‏E‏N‏T‏. The rendered output is visually identical. The string an NLP classifier receives is not.

This technique maps to MITRE ATT&CK T1027 (Obfuscated Files or Information). The target is not a human's eyes, it's the feature extraction layer of a machine learning model. By fragmenting the token boundary, the attacker reduces the probability that the classifier matches the string against known phishing phrases like "REVIEW DOCUMENT" with high confidence.

The same technique extended beyond the button. Nearly every text string in the email body, from the subject line to the footer disclaimer to the DocuSign boilerplate, was saturated with RTL marks. The body text that read "Confirm your disbursement details" was the same interleaved pattern. The attacker applied it uniformly, not just to the CTA.

The Authentication Paradox

The email passed DMARC. Not with a soft alignment or a policy override. A clean dmarc=pass on bigpineconsultants.com, backed by a valid DKIM signature. Amazon SES eu-west-1 sent it. SPF for the MAIL FROM subdomain was none, but DMARC authenticated on DKIM alignment, which is valid.

This is worth dwelling on. The organization whose domain was used had done everything right: M365 MX records, strict SPF with -all, active DKIM selectors, DMARC at p=reject. Their email infrastructure was properly configured. The evidence points to a compromised marketing automation workflow or an abused SES integration, not a spoofed domain. The attacker sent through authorized infrastructure.

This is the scenario your DMARC management tools are not built to catch, because the sending was authorized. DMARC tells you the domain is who it says it is. It cannot tell you the domain's marketing automation was hijacked.

The identity mismatch that did surface was in the content: the From address belonged to one US-based consulting firm while the email signature claimed a UK engineering company, including a real UK phone number and a forwarded internal email thread used as legitimacy padding. Two real organizations, neither of them the attacker, stitched together into one convincing wrapper.

The Attack Chain, Step by Step

This campaign used MITRE ATT&CK T1566.002 (Spearphishing Link) as the primary delivery technique, with T1036 (Masquerading) covering the DocuSign brand spoofing.

  1. Delivery: Email sent via Amazon SES using a DMARC-passing domain, routed through Microsoft EOP into the target's M365 mailbox.
  2. Social engineering: DocuSign-style HTML template with settlement/MOU subject line. Recipient's email address displayed inside the email body to personalize the lure.
  3. Obfuscation: RTL marks (U+200F) injected into every text string in the email body, including the CTA button label.
  4. First redirect hop: CTA resolves to Constant Contact tracking URL (cc.rs6.net). TLS mismatch at this hop already signals the final destination.
  5. Second redirect hop (Mailjet variant): Base64-encoded destination embedded in Mailjet tracking URL provides a parallel delivery path with identical destination.
  6. Harvest page: sync.bursatasdunyasi[.]com presents a bot-gate interstitial ("verify you are human"), consistent with credential harvest pages that filter automated sandbox traffic before presenting the actual form.
  7. Infrastructure anchor: Domain registered 2018 via Turkish registrar Isimtescil Bilisim A.S., nameservers under ajansay.com. Aged domain reduces new-registration heuristic penalties.

Themis flagged the campaign at 89% confidence on credential theft, correlating the first-time sender status, malicious link behavior, and community signals from similar incidents across the IRONSCALES customer base. The email was automatically resolved as phishing and mitigated across affected mailboxes within 48 hours of delivery.

What to Do With This

According to the Verizon 2024 Data Breach Investigations Report, 74% of breaches involve the human element, with phishing and credential theft as primary vectors. The techniques in this campaign were designed to neutralize both automated defenses and human recognition simultaneously. That combination is the actual threat model.

Three things this case illustrates for security teams:

Follow the full redirect chain. URL reputation on the first hop is not sufficient. Constant Contact, Mailjet, and other legitimate ESP redirect domains are regularly abused as laundering infrastructure. Your link inspection needs to resolve the final destination, not stop at the first trusted domain.

Parse for control characters in display text. Unicode RTL marks in button labels and body text are inspectable. NLP models that do not account for zero-width character injection in their feature pipelines will assign lower confidence to well-known phishing phrases. This is a known, correctable gap.

DMARC pass is not a clean bill of health. A message can be authenticated and malicious at the same time. Credential harvesting protection that relies on authentication results as a positive signal will miss this class of attack. Layer behavioral analysis and link-chain inspection on top of authentication, not instead of it.

The IBM 2024 Cost of a Data Breach report puts the average breach cost at $4.88 million, with phishing-initiated incidents carrying some of the highest remediation costs due to dwell time and credential reuse (IBM, 2024). The cost of catching this email before any credentials were entered: zero.

---

Indicators of Compromise

TypeIndicatorContext
Domainbursatasdunyasi[.]comHarvest infrastructure, Turkish-hosted
Subdomainsync.bursatasdunyasi[.]comCredential harvest endpoint
IP78[.]135[.]106[.]170Hosting IP, Turkey (PTR: west.ajansay[.]com)
URLhxxps://cmopv9hbb.cc[.]rs6[.]net/tn.jsp?...Constant Contact first-hop redirect
URLhxxps://10o9o.mjt[.]lu/lnk/AcUAACKe6kA...Mailjet second-hop redirect (base64 destination)
Sending IP54[.]240[.]3[.]21Amazon SES eu-west-1
Domainbigpineconsultants[.]comSending domain (DMARC-passing, likely compromised workflow)
UnicodeU+200F (RIGHT-TO-LEFT MARK)Injected between every character in button label and body text
Email Attack of the Day is a daily series from IRONSCALES spotlighting real phishing attacks caught by Adaptive AI and our community of 30,000+ security professionals. Each post breaks down one attack — what it looked like, why it worked, and what you can do about it.

Explore More Articles

Say goodbye to Phishing, BEC, and QR code attacks. Our Adaptive AI automatically learns and evolves to keep your employees safe from email attacks.