Release on Payment: Salvage Fraud Wrapped in a Click-Time URL Rewriter

The email looked like a logistics transaction closing. A salvage sale in progress, a packing list requested, warehouse details exchanged, and one operational requirement: "Once we get the check we will Release the Salvage." Normal commercial language. The kind of message that lands in procurement and accounts-payable inboxes and gets processed without escalation.

The only link in the message was wrapped in url[.]emailprotection[.]link. The automated scanner could not expand the wrapper to see where it actually pointed. It returned a malicious verdict and a block recommendation.

The Mechanics of a Click-Time Wrapper

Click-time URL rewriting encodes the final destination inside query parameters that the wrapping service resolves only when a recipient clicks the link. The visible URL is always the wrapper domain. Passive scanners that follow links at delivery time cannot extract the final destination without performing an actual click in a sandboxed browser -- a dynamic analysis step that most gateway-layer URL scanners do not perform by default.

MITRE ATT&CK T1566.002 covers spearphishing links. In this case the url rewriting technique is the evasion mechanism: the attacker wraps the payment or redirect destination behind a service that makes static inspection impossible. The display text in the message showed the claimed destination as a legitimate salvage marketplace; the wrapper concealed whether the actual click-time target matched that claim.

Defenders cannot confirm the claimed destination from message analysis alone. The choices are either dynamic click-through in an isolated sandbox or blocking the message pending out-of-band verification.

Authentication Passed; ARC Did Not

The sending domain is an established commercial organization registered since 2003 through a Korean registrar with valid SPF, DKIM, and DMARC records. The analysis anonymizes it as a long-established corporate domain, name withheld, because its authentication posture is consistent with either a legitimate business or a legitimate business whose account was compromised. SPF passed on the sending IP. DKIM signature validated for the sending domain. DMARC passed with a p=none policy -- which means the domain publishes authentication but instructs receivers to take no enforcement action on failures.

ARC (Authenticated Received Chain) failed at a later relay hop despite the initial authentication passing. The relay path shows the message moved through on-premise Exchange infrastructure before exiting to Microsoft's inbound protection layer. Security gateways and message sanitizers that modify headers or alter message content can break ARC verification downstream -- this is a documented behavior of Barracuda, Proofpoint, Mimecast, and similar appliances. An ARC failure in this context is consistent with legitimate message transformation, not with simple header spoofing.

The sender risk was rated high by the incident platform based on the combined profile: first-time sender relationship, authenticated but ARC-failed relay path, and the flagged-malicious wrapped link.

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

Payment Fraud Without a Phishing Page

This case does not have a confirmed credential-harvest landing page. The scanner could not resolve the wrapper's final destination and flagged the uncertainty as malicious -- a correct precautionary verdict given the wrapper service's abuse history, but not confirmation of a specific payload type.

The invoice fraud mechanism here operates differently from a credential-harvest campaign. The goal is payment diversion: convince the recipient that a salvage release requires a check or wire transfer, and ensure that payment goes to an attacker-controlled account rather than the legitimate seller. The link may redirect to a payment instruction page, a spoofed invoice portal, or simply to the attacker's banking details. Without dynamic resolution, the specific destination is unknown.

What is known: the release-on-payment instruction creates urgency and transactional legitimacy. The salvage transaction context means the recipient expects to process a payment as the next step. The wrapped link is the mechanism for directing that payment to an unverifiable destination.

The Social Engineering Architecture

The email body contained no spelling errors, no mismatched branding, no login prompts, no credential-request language. It read as a commercial exchange between two parties who have been discussing a transaction. Warehouse addresses, packing list requests, and shipping coordination are all present.

Social engineering at this level relies on context, not on urgency signals. The recipient who processes salvage or logistics invoices operates in an environment where release-on-payment instructions are routine. The attack is not trying to panic the recipient into clicking. It is trying to fit so cleanly into normal operational workflow that no one thinks to verify the payment destination through an independent channel.

IRONSCALES flagged the behavioral profile: first-time sender, wrapped and unresolvable link, payment-instruction body, and ARC failure at the relay layer. The combination of authentication theater and an opaque redirect created enough signal to escalate the message for review before any payment action was taken.

Indicators of Compromise