The FedEx Freight Invoice That Came From Inside the CRM

A freight invoice rebill request arrived at a logistics and distribution company, addressed to three employees. The subject referenced a specific case number and FedEx Freight invoice. The sender was "Coordinator23" at coordinator23@fedexfreight[.]com. DKIM passed with a signature aligned to fedexfreight[.]com. DMARC passed. CompAuth returned reason=100. The email was sent through FedEx Freight's own Salesforce CRM instance.

The message contained no malicious links. No attachments. The payload was the text itself: a request to change the bill-to entity on invoice #0584162950.

Legitimate Infrastructure, All the Way Down

The email originated from Salesforce Email-as-a-Service infrastructure (smtp-0e846264ca9e07764[.]core1[.]sfdc-yfeipo[.]mta[.]salesforce[.]com, IP 23[.]23[.]72[.]98). The DKIM signature was signed with selector sfafxfpr03112026 under d=fedexfreight[.]com. The X-SFDC-EmailCategory header was set to quickActionEmail, confirming the message was dispatched via a Salesforce Quick Action, a CRM feature that lets agents send emails directly from case records.

This is not an attacker spoofing FedEx Freight. This is an email that passed through FedEx Freight's actual CRM sending infrastructure, carrying a valid cryptographic signature for their domain. The Salesforce entity ID (500QU00001PKr4X) and the extremely long Salesforce VERP bounce address in the Return-Path both confirm the message was generated inside a real Salesforce org.

The email was then relayed through a Securence gateway (maild8110391[.]static[.]msp[.]securence[.]com, IP 216[.]17[.]3[.]145). SPF passed at the Securence hop for the Salesforce bounce domain, but the final receiving server recorded an SPF softfail at 216[.]17[.]3[.]145 because the Securence relay IP was not in the original sender's SPF record. This is a known artifact of gateway relaying, not a detection signal the attacker introduced intentionally.

The Payload Is the Request

The email asked the recipient to rebill a freight invoice to a different entity. There was nothing to scan. No URL reputation to check. No attachment to detonate. The business email compromise was the message content: a routine-sounding operational request that, if fulfilled, would redirect billing obligations to a third party.

This class of attack is effective precisely because it mirrors legitimate business communication. Freight invoice adjustments, rebills, and bill-to changes are normal operational traffic in logistics. The attacker relied on the context of the request, not a technical exploit, to achieve the objective.

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

What Caught It

Themis scored the message at 83% confidence with an "Invoice Phishing" label. Four mailboxes were quarantined. The Securence gateway's own Bayesian classifier had scored the message at 5.2, an elevated risk signal that did not trigger a block.

The detection was driven by behavioral analysis: a first-time sender addressing multiple recipients with a financial action request, combined with an invoice modification pattern targeting a logistics company. Authentication was clean. Infrastructure was legitimate. The only anomaly was the relationship, or rather the absence of one, between this specific sender and the recipient organization.

What to Watch For

When a freight invoice rebill or bill-to change arrives from a first-time sender, verify the request through a known contact at the carrier, not by replying to the email. Legitimate CRM infrastructure does not make a legitimate request.

Indicators of Compromise

MITRE ATT&CK Mapping