DocuSign Lure, Compromised WordPress Endpoint: When the CTA Goes Nowhere DocuSign Would Ever Send You

The CTA said "View and complete tasks." The href went to a compromised WordPress site's admin path on a domain that has nothing to do with DocuSign. The phishing kit left its template placeholders in plain sight. This attack was not subtle, it was fast and authenticated, banking on the DocuSign brand recognition carrying the recipient to a click before anyone inspected the destination.

A property management firm received what appeared to be a DocuSign document-review request. The subject and body used DocuSign visual branding, referenced a pending agreement document, and presented a single primary call to action to view and complete the linked materials. The From address was info@talleresqueve[.]es with a display name of "DocReq." talleresqueve[.]es resolves to a Spanish automotive repair business, an entity with no plausible connection to a document-signing platform. The message routed through Amazon SES (b224-52.smtp-out.eu-central-1.amazonses.com), and DKIM signatures passed for both talleresqueve[.]es and amazonses.com. SPF passed for the sending IP. This is the ESP abuse pattern at its most efficient: a legitimate cloud delivery platform, authenticated sending credentials, and a completely unrelated brand impersonation riding on the authentication result.

The CTA Destination That Has Never Been DocuSign

The "View and complete tasks" button is where this attack breaks cover completely. The rendered button text implies a DocuSign portal. The underlying href points to hxxps://deltadisplays[.]com//wp-admin/wagger.

deltadisplays[.]com is a long-registered domain (created 2009) with a recent registrant-information update. That combination, established domain age, recent modification, is consistent with a compromised site pressed into phishing infrastructure. The /wp-admin directory tree is WordPress's administrative control panel. Legitimate document-signing services do not route recipients through a third-party site's WordPress admin area. The custom sub-path /wagger indicates a planted phishing kit page rather than any default WordPress functionality.

The scanner could not retrieve the page content at analysis time due to DNS resolution issues for the host, so the exact credential form cannot be confirmed from the scan artifacts. The path pattern, the destination mismatch, and the phishing-kit assembly context are sufficient to classify it. No legitimate service communication routes a "View and complete tasks" CTA to a third-party CMS admin path.

MITRE ATT&CK T1566.002 covers spearphishing via link. T1204.001 (user execution: malicious link) covers the trigger: the recipient clicks the CTA and the browser navigates to the harvester endpoint. T1656 (impersonation) applies to the DocuSign brand identity claim throughout the email body and visual template.

Broken Kit Tokens and What They Reveal About Assembly

The email HTML contained a broken template variable in a link target: href="https://www.%7bdomain%7d/", URL-encoded curly braces wrapping the word "domain." That is a kit placeholder that was never substituted. Production email platforms do not ship messages with percent-encoded template tokens in href attributes. This artifact reveals that the email was assembled from a reused or stolen phishing kit template, distributed through an automated mailing script that failed to replace at least one variable before sending.

Broken template tokens matter beyond being an indicator of authenticity failure. They show what the attacker intended: the kit was designed to insert a domain-specific URL into an additional link target, likely a personalization element referencing the recipient's own organization. The substitution failed, but the surrounding DocuSign impersonation scaffolding was intact enough to send.

The body also referenced a specific document filename tied to the recipient's organization, which would have been a successful personalization. Attackers who assemble kits at volume often get some personalization fields right and others wrong. The failure on the domain substitution did not prevent delivery, authentication, or inbox placement.

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

Amazon SES as the Authentication Layer

The relay path is worth stating precisely because it explains the authentication outcome. The message was injected via Amazon SES's EU-Central-1 infrastructure. Amazon SES requires senders to verify the sending domain and configure DKIM before dispatching. That process produces a DKIM signature aligned to the sending domain and a SPF pass for Amazon's sending IPs, both of which this message carried.

The result is that a message from an unrelated Spanish automotive repair domain, impersonating a U.S. document-signing platform, arrived at a Microsoft 365 environment with DKIM pass, SPF pass, and a DMARC result the receiving infrastructure treated as passing. Authentication confirmed that talleresqueve[.]es authorized the Amazon SES server to send on its behalf. It confirmed nothing about the sender's relationship to DocuSign, the legitimacy of the document request, or the safety of the CTA destination.

Receiving gateways that weight authenticated sender signals heavily are operating on a category error when the message is an credential harvesting attempt: authentication is a deliverability property, not a content-safety verdict. The signal that matters here is the CTA destination mismatch, a DocuSign-branded email whose action link points to a WordPress admin subdirectory on an unrelated domain is not a DocuSign email regardless of what the authentication headers say.

IRONSCALES detected the combination of first-time external sender, brand impersonation from a mismatched sending domain, and CTA href divergence from the claimed service's known infrastructure. The broken template token added a behavioral signal consistent with phishing-kit assembly rather than a production notification system.

Indicators of Compromise