TL;DR A fake eSignature notification failed SPF and DMARC at its origin hop but reached the inbox with DKIM pass, DMARC pass, and compauth pass. An ordinary mailbox auto-forward gave the spoof a new aligned envelope sender, and ARC carried the clean verdict forward. A camouflage legal thread hid one CTA that opened on a Google open-redirect, bounced through an ad-click layer, and landed on an aged Nepal-registered decoy domain. The lesson: authenticated at delivery is not authentic at origin. Read the full Received chain and treat trusted-domain redirects as suspect.
Severity: High Credential Harvesting Spoofing Email Authentication Bypass MITRE: T1566.002 MITRE: T1566

The subject line read AgreementDOC-79488 Is Ready For You. By the time it reached a reporting inbox at a Canadian legal advocacy organization, the message carried a clean authentication record: DKIM pass, DMARC pass, compauth=pass reason=100. Every check a delivery rule would consult said the mail was legitimate.

At its very first hop, the same message had failed SPF and failed DMARC.

Both records are real. The distance between them is the whole attack, and it was created not by a clever forgery but by an ordinary mailbox auto-forward.

The Verdict Flipped in Transit

The message entered from 188[.]215[.]229[.]105 (v519eu[.]mailgun[.]net), a Mailgun sending host with no authorization to send for the domain in the From header. Microsoft recorded the obvious result at ingress: spf=fail, dmarc=fail, and dkim=none (message not signed). That first ARC hop sealed with cv=none. A standard, honest failure.

Then the message did something normal. It landed in a mailbox that auto-forwards to a second, affiliated inbox. The forward handed the message a fresh envelope sender aligned to the forwarding organization, so SPF now passed on the new path. Microsoft sealed each subsequent hop into an Authenticated Received Chain, and by the final hop the receiving tenant recorded spf=pass, dmarc=pass, and compauth=pass. The headers even show DKIM passing for the From domain at delivery, carried forward through the ARC-sealed forwarding path.

ARC exists for exactly this reason. It is meant to preserve legitimate authentication results across forwarding so a message that genuinely passed at the source is not punished when a mailbox relays it. Here the mechanism did its job on a message that never passed at the source. The forward manufactured an aligned envelope, ARC carried the verdict, and a spoof arrived wearing a pass. Call it authentication laundering.

DMARC, now formally specified in RFC 9989, tells a receiver what to do when SPF and DKIM fail against the From domain. It says nothing about how to weigh a verdict that a downstream forward re-established on a different envelope. That is the blind spot, and it is baked into how forwarding and ARC are supposed to work. Any team relying on the final DMARC stamp as ground truth, or feeding it into a mail flow rule, inherits it. This is one reason DMARC management has to be read as a chain of hops, not a single pass or fail at the door.

A Legal Thread Doing the Real Work

Open the body and you find a long, fluent corporate legal exchange: a rights-issue process, references to a specific companies-act clause, an offer timeline, executive sign-offs, bank branding, a formal footer disclaimer, even a marketing banner. It reads like a real thread, because it almost certainly is one, repurposed to build trust.

None of it is the attack.

Sitting above the entire thread is a single blue card: Your Secured documents are ready. View Document Here. One call to action. Everything below it is set dressing whose only job is to make a busy reader trust the one link that matters. This is spearphishing via link (MITRE ATT&CK T1566.002) dressed as an eSignature notification, a lure class that works because document-share and signature alerts are routine and rarely interrogated.

The Chain That Started on google.com

The CTA did not point at a payload. It pointed at google[.]com.

Specifically, a Google open-redirect (hxxps://www[.]google[.]com/url?q=) that forwarded into a nested ad-click redirect on adservice[.]google[.]com[.]ar, which carried the true destination as an encoded parameter: ruslanstudio[.]com, with the recipient's address base64-encoded in the URL fragment so the landing page could pre-fill the victim's identity.

Every hop bought the attacker something. Beginning on a Google domain defeats URL reputation, because the first thing any scanner sees is google.com. The ad-click layer hides the final host. And the destination domain was not a fresh throwaway. WHOIS puts ruslanstudio[.]com at a 2022 registration to a registrant in Lalitpur, Nepal, unrelated to any party named in the email. Domain-age heuristics, the ones that flag lookalikes registered last Tuesday, had nothing to bite on. A four-year-old domain reads as established.

The message was also wrapped by Safe Links, so the URL was rewritten for time-of-click inspection. The automated scan of the wrapped destination came back clean at delivery. Reputation, wrapping, and age all pointed the wrong way.

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

What Actually Caught It

Authentication and reputation both cleared this message. Behavior did not.

The sender was a first-time correspondent using a query-string display name, the authentication posture was internally contradictory (a hard origin failure buried under downstream passes), and the redirect chain matched patterns already reported across the community. Themis, the IRONSCALES Adaptive AI analyst, scored the message at 87% confidence and the platform auto-resolved it, moving it to junk roughly seven seconds after delivery. The signal that mattered was not any single header. It was the shape of the whole thing, which is where behavioral credential harvesting protection earns its place and why Adaptive AI is evaluated on cross-corpus behavior rather than a static verdict.

The teachable gap is simple. Authenticated at delivery is not the same as authentic at origin. A forward plus ARC can carry a message that failed SPF and DMARC at the source into an inbox with a clean pass, and neither reputation nor domain age will necessarily contradict it.

Three things follow for defenders:

  • Read the full Received chain, not the final stamp. The origin hop here failed cleanly, and that failure survives in the headers even after ARC seals a pass downstream. Alert on divergence between origin and delivery authentication.
  • Treat trusted-domain redirects as suspect. A link that opens on google.com and immediately bounces through an ad-click redirect is not a Google link. Inspect the decoded chain, not the first hop.
  • Do not lean on domain age alone. The destination here was four years old. Age gates and lookalike heuristics both missed it.

According to the 2026 Verizon Data Breach Investigations Report, phishing remains the initial access vector in 16% of breaches, and gateway telemetry still shows roughly 80% of malicious email as plain phishing rather than malware. IBM's 2024 Cost of a Data Breach report puts the average breach at $4.88 million, with stolen credentials among the most common and costly entry points. The Microsoft Digital Defense Report 2024 documents the same shift toward identity-based attacks that lean on trusted infrastructure. CISA phishing guidance is blunt about the limit of authentication controls: they raise the cost of spoofing, but they do not close the behavioral gap a well-forwarded, well-branded lure walks straight through.

Authentication told the recipient this message was safe. It was wrong, and it was wrong for reasons that were working exactly as designed.

Indicators of Compromise

TypeIndicatorContext
SubjectAgreementDOC-79488 Is Ready For YoueSignature lure
Origin IP188[.]215[.]229[.]105 (v519eu[.]mailgun[.]net)Mailgun sending host; failed SPF/DMARC for the From domain
Redirecthxxps://www[.]google[.]com/url?q=...Google open-redirect wrapper (CTA); fragment carried base64 recipient email (redacted)
Redirectadservice[.]google[.]com[.]ar/ddm/clk/...Nested ad-click redirect layer
Domainruslanstudio[.]comDecoy landing domain, registered 2022, Lalitpur NP registrant
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 Redirect Chain Ran Through Stripe. Every Scanner Said Clean.A phishing email used Stripe's click-tracking subdomain and a legitimate AI persona platform to build a redirect chain that every automated scanner marked...
The Lab Result Notification That Every Security Check Approved (Because the Platform Was Real)A credential harvest targeting healthcare portal logins arrived through bridgeinteract.io, a legitimate HIPAA-adjacent patient engagement platform.
Sign Here, Get Phished: Inside an Adobe Sign Lure With a Multi-Hop Redirect to Credential TheftAn Adobe Sign e-signature lure routed recipients through a multi-hop redirect chain ending at fameklinik[.]com.
When SPF, DKIM, and DMARC All Pass. And the Email Is Still PhishingA fully authenticated phishing email (SPF pass, DKIM pass, DMARC pass) used a legitimate nonprofit platform to deliver credential-harvesting links with...
When the Safety Wrapper Becomes the Disguise: Brazilian NF-e Phishing via Safe Links RewriteA Portuguese-language invoice lure authenticated through a compromised Brazilian domain used is.gd to hide its payload.

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.