eCheck Retrieval Fraud: url.emailprotection.link Rewrapping and DMARC Fail Under a p=reject Policy

The email did not ask for credentials directly. It told the recipient what to expect next, and who would be sending it. That conditioning is the mechanism.

A property management-sector organization received a message framed as professional claims correspondence. The sender displayed as "Shawn Cabral" at communityfirstpm[.]com, a domain registered in August 2024 with no publicly verifiable organization behind it. The body described a claims thread referencing specific claim identifiers and named parties in the insurance chain. The level of professional detail was deliberate: it created plausibility for the payment instruction that followed.

The payment instruction told recipients they would receive an email from noreply@vitesse.io with the subject "Action Required: eCheck Payment from Accelerant National Insurance Company" and a "Retrieve eCheck" link. Vitesse is a legitimate fintech payment platform. Its name was borrowed here as a trust prop, and the attacker named a recognizable, real service to prime victims before the payment retrieval step arrived.

How URL Rewriting Hides the Destination

The two actionable links in the message were both rewritten through url.emailprotection[.]link, Proofpoint's URL Defense proxy endpoint. The display text for one link showed "BAI-ONLINE.COM"; the actual href routed through the Proofpoint wrapper. The display text for the second showed "www.athensadmin.com"; same wrapping. Both resolving through the same proxy infrastructure, both flagged as high-risk by the incident scanner.

This is URL rewriting abuse. Proofpoint URL Defense legitimately rewrites links in inbound email to pass clicks through its inspection proxy, a standard inline defense technique. Attackers exploit the rewriting in two ways: by sending mail through an environment where Proofpoint already processes it (which rewrites attacker links automatically), or by pre-wrapping links in the Proofpoint URL format before delivery. Either way, automated reputation systems evaluating the href see Proofpoint infrastructure rather than the attacker's landing destination.

Content extraction from the wrapped links failed at scan time. The true landing URL was not resolved, meaning the final credential-collection destination was not observed. The flagged-malicious verdict came from intelligence on the wrapper behavior and the specific URL patterns, not from successfully crawling the endpoint.

MITRE ATT&CK T1566.001 and T1566.002 cover spearphishing via attachment and link respectively; this attack uses both the professional claims framing and external links. T1036 (masquerading) applies to the combined use of a recognized fintech brand name (Vitesse) and plausible claims-industry terminology to disguise the payment fraud intent.

Authentication Failure Under p=reject

The DMARC policy on the sending domain is p=reject. At a key hop in the relay chain (specifically the Barracuda outbound relay, 209.222.82.250) headers recorded: SPF softfail, DKIM fail (body hash did not verify), and DMARC fail with action=quarantine. Multiple outbound security gateway products were in the relay path: Inky PhishFence and Barracuda Essentials both modified the message in transit. Each gateway transformation (rewriting links, appending footers, modifying headers) risks breaking DKIM's body hash, which depends on message integrity between signing and verification.

A separate upstream hop recorded SPF pass, DKIM pass, and DMARC pass for the same message, reflecting validation at a different point in the chain before the gateway transformations occurred. The result is a mixed authentication chain: a message that passed at one evaluation point and failed at another. The failure at the DMARC-reject-policy hop is the operationally significant result, because it reflects what the final receiving server was supposed to act on.

The invoice fraud playbook has converged on this pattern: send from a domain with some authentication configured but break it at a gateway hop, use legitimate service brands in the body to establish context, and route the malicious CTA through a trusted rewriting proxy.

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

The Two-Step Conditioning Play

The sophistication of this attack is not in the infrastructure. It is in the sequencing. The initial email does not ask the victim to do anything immediately. It tells them what will happen: they will receive a specific email, from a specific address, with a specific subject, containing a specific button. When a second email arrives (or when the attacker sends a crafted follow-up), the victim has been pre-briefed. The expected communication matches the malicious one. The cognitive friction that might cause a victim to pause and verify is already reduced.

This is business email compromise refined beyond a single message into a multi-step conditioning sequence. The first message establishes the payment context. The second, whether real or attacker-crafted, delivers the retrieval link. Defending against either in isolation misses the coordinated play.

IRONSCALES flagged the message on first contact. The risk signals were present without waiting for the follow-up: DMARC failure under a reject policy, a recently-registered sender domain with no verifiable public profile, two high-risk wrapped links displaying trusted brand names but routing through an obfuscated proxy, and a payment-retrieval instruction naming a real fintech to add false credibility. The combination of authentication failure and attacker-favorable link wrapping, against the backdrop of a professional social-engineering pretext, met the threshold for a phishing classification before the eCheck follow-up had a chance to arrive.

Indicators of Compromise