Signed, Delivered, Stolen: An Adobe Acrobat Sign Lure Routes Through Five Redirect Wrappers to a Newly-Registered Harvest Domain

TL;DR An attacker sent a convincing Adobe Acrobat Sign notification from a compromised legitimate domain (17 years old, full SPF/DKIM/DMARC pass via Zoho) that invoked a government legal office and a well-known security vendor as authority signals. The 'Open agreement' CTA traversed a five-hop redirect chain through Hornetsecurity ATP scan, Monday.com tracking, SendGrid click-tracking, and a cloud-security wrapper before depositing the victim at loginmandatoryteamrequest[.]recreatoininsites[.]com, a domain registered 2024-11-26 on NameSilo with privacy protection and unsigned DNSSEC. The fresh attacker domain never appeared in the visible URL path, and the authenticated sender gave content filters nothing to fault.
Severity: High Credential Harvesting Impersonation Phishing MITRE: T1598.003 MITRE: T1566.002 MITRE: T1078

The email looked like every other Adobe Acrobat Sign notification: the familiar blue header, the "Open agreement" button, the footer suggesting you add Adobe's notification sender address to your address book, the copyright line. Two named parties lent the agreement extra weight: a government legal office and a well-known security vendor's name. The implicit message was that this agreement had been vetted by institutions the recipient would not question.

The sending display name contained a spelling error. The actual "Open agreement" button led to five consecutive redirect hops before landing on a domain registered four months before delivery. The final destination was not hosted by Adobe, the government legal office, or the security vendor. It was a credential-harvest page sitting on a NameSilo domain with privacy-protected WHOIS and unsigned DNSSEC.

This is impersonation at two layers simultaneously: the message impersonates a trusted e-signature platform, and the sender is a compromised legitimate organization that authenticated the delivery.

Why the sender passed every authentication check

The sending domain belongs to a construction firm registered in 2008. By the time this message was sent, the domain was 17 years old, had a clean reputation history, and was configured with full email authentication. The message passed SPF (the sending IP was permitted), passed DKIM (signed under the domain), and passed DMARC. ARC seals confirmed the message preserved authentication across relay hops through Zoho sending infrastructure and Microsoft Office 365 frontends before delivery.

The analysis flagged the domain as a compromised legitimate sender. The domain did not register the malicious content. An account on the domain did, or an attacker used credentials to send through Zoho's transactional mail infrastructure on the domain's behalf. Either way, from the authentication layer's perspective, the message was sent by an authorized party.

This is the core detection problem. Operations built on credential harvesting that use compromised aged domains get the authentication pass for free. The 17-year reputation absorbs suspicion. The fresh attack domain stays hidden behind wrappers. The content filter sees a passing sender and a well-known brand template, and there is no cryptographic evidence of wrongdoing.

The display name did betray the attack: it read "Shared Docunent Notification" with a transposed letter. Genuine Adobe Acrobat Sign notifications do not contain spelling errors in the display name. That single character was the most honest signal in the entire message header.

Five hops between the button and the attacker's page

The "Open agreement" button's target URL did not point to Adobe. It pointed into a redirect chain that traversed five legitimate services before reaching the attacker-controlled endpoint.

The chain ran in this order: an ATP scanning proxy at atpscan[.]global[.]hornetsecurity[.]com passed the URL through security inspection; a Monday.com tracking link at trackingservice[.]monday[.]com collected engagement data; a SendGrid click-tracking URL at u46509964[.]ct[.]sendgrid[.]net recorded the click; a cloud-security wrapper at securelinks[.]cloud-security[.]net added one more layer; and the final encoded destination parameter resolved to hxxps://loginmandatoryteamrequest[.]recreatoininsites[.]com.

Each intermediate service is a legitimate platform with a strong reputation. A security filter that evaluates the URL at any point before the final hop is evaluating a trusted hostname, not the attacker's endpoint. The Hornetsecurity ATP proxy is itself a security product; a scanner that treats a security vendor's wrapping URL as a safe pass is particularly blind to this pattern.

The final domain, recreatoininsites[.]com, was registered on 2024-11-26 through NameSilo with a privacy service masking the registrant and unsigned DNSSEC. It was less than five months old at delivery, a typical lifespan for a single-campaign harvest domain. The subdomain prefix loginmandatoryteamrequest was constructed to suggest a mandatory authentication action in the same pattern as the agreement theme in the body. This layered redirect approach maps to Acquire Infrastructure: Domains in MITRE ATT&CK for the fresh harvest domain, and Phishing: Spearphishing Link for the CTA delivery mechanism.

The authority cues and why they work

The body named a government legal office and a well-known security vendor as parties to the agreement. These names appear in the document description, not in any field subject to authentication. The attacker did not need to compromise or impersonate those organizations. Mentioning them as parties to an agreement creates an implicit chain of authority: if a government legal office and a security vendor are involved, the document must be legitimate.

This is ESP abuse by template: the attacker built a visually accurate Acrobat Sign notification, added authority-signaling party names that recipients would not question, and relied on the compromised sender's authentication to deliver it. The recipient's defense posture against this lure is not a filter question. It is a verification question: does the Adobe account that sent this agreement match a real transaction I am party to?

Indicators of compromise

TypeIndicatorContext
Domainloginmandatoryteamrequest[.]recreatoininsites[.]comFinal credential-harvest landing page; registered 2024-11-26, NameSilo, privacy-protected
Domainrecreatoininsites[.]comAttacker-registered harvest domain; unsigned DNSSEC, 5-month-old at delivery
URLhxxps://atpscan[.]global[.]hornetsecurity[.]com/...Redirect hop 1: ATP scanning proxy wrapper
URLhxxps://trackingservice[.]monday[.]com/tracker/link/...Redirect hop 2: Monday.com engagement tracking
URLhxxps://u46509964[.]ct[.]sendgrid[.]net/...Redirect hop 3: SendGrid click-tracking
URLhxxps://securelinks[.]cloud-security[.]net/...Redirect hop 4: cloud-security redirect wrapper
Senderinfo@[compromised-construction-firm]Compromised legitimate domain, 17 years old, full SPF/DKIM/DMARC pass via Zoho
BehaviorDisplay name "Shared Docunent Notification"Spelling error in display name; inconsistent with genuine Adobe notifications
BehaviorNon-personalized body, first-time senderTemplated bulk lure delivered through compromised infrastructure

What actually caught it

The authentication passed. The redirect chain terminated at legitimate services until the final hop. The Adobe template was accurate. What remained as detection surface was the display-name misspelling, the non-personalized body on a lure that claimed to be a specific legal agreement, and the sender's status as a first-time contact with this mailbox. Community reputation analysis flagged the redirect chain's final destination despite its short history, because the multi-service chain terminating at a privacy-protected five-month-old domain matches a known campaign fingerprint even without a prior incident report on that specific domain.

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

The e-signature phishing pattern is difficult to filter at the content layer because the template is copied from a real platform. The sender passes authentication because it is a real domain. The redirect chain is built from real services. Defense requires behavioral analysis that weighs first-time sender status, non-personalization in a supposedly personalized document workflow, and the full resolved destination of the CTA, not just the first recognizable hostname in the chain. A five-hop redirect that terminates at a five-month-old privacy-protected domain is an attack signature, regardless of what the intermediate hops are named. Verizon's 2025 Data Breach Investigations Report found credential theft as the leading outcome in phishing-initiated breaches; FBI IC3 continues to rank business email compromise and credential fraud among the costliest reported crime types. The e-signature lure is a delivery vehicle for both: it extracts credentials that enable downstream account takeover and payment fraud at scale.

Email Attack of the Day is a daily series from IRONSCALES spotlighting real phishing attacks caught by Adaptive AI and our community of 35,000+ security professionals. Each post breaks down a real attack. What it looked like, why it worked, and what to do about it.

Related attacks

Attack What happened
The GitLab Alert That Passed Every Filter (Except One Detail Nobody Checked)A GitLab sign-in alert cleared Proofpoint URL Defense and passed SPF/DMARC — then listed a private RFC1918 IP as the sign-in source.
The Timestamp That Gave It Away: Oracle Identity Cloud Phishing Targets K-12 with a Stale TimezoneA phishing email impersonating Oracle Identity Cloud targeted a Florida school district employee.
The Phishing Simulation Platform That Powered a Real AttackA salary adjustment lure routed through SendGrid and a Carrd landing page used phishing kit images hosted on a commercial phishing simulation vendor's own...
Fake Bounce Notice With Obfuscated 'Keep My Password' Link Routes Victims to a Webmail Credential-Harvesting PageAttackers spoofed a mailer-daemon bounce notification with zero email authentication, hiding a credential-harvesting link behind obfuscated display text.
The Power Automate Failure Alert That Wore Your Own Security Vendor as a DisguiseAn attacker impersonated an internal service account with a test tenant, sent a Power Automate failure alert.

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.