A Medicare Attestation Request Sent Through Salesforce, Authenticated by the Victim's Own Domain

The subject line referenced a "Medicare Transaction Facilitator (MTF) Independent Provider Attestation." The email came from a Salesforce CRM organization, passed every authentication check, and linked to what appeared to be a document signing page. The landing page was an Office 365 credential harvesting form hosted on an unrelated domain.

In June 2026, IRONSCALES flagged this attack targeting an employee at a healthcare outcomes management company. The phishing email exploited two things simultaneously: the authority of healthcare regulatory compliance language and the trust that Salesforce infrastructure carries through email authentication.

Salesforce as the Delivery Vehicle

The message was sent through Salesforce Email-as-a-Service infrastructure (smtp-053a43a2c9ecc9b54.core1.sfdc-8tgtt5.mta.salesforce.com, IP 18[.]117[.]31[.]220). X-SFDC headers confirmed an active Salesforce organization with EmailCategory=quickActionEmail, meaning the attacker triggered the send from within the CRM interface itself. SPF passed. DKIM passed (d=a-private-company[.]example). DMARC passed. Composite authentication returned compauth=pass with reason code 100.

The From and To addresses were identical: aryan@a-private-company[.]example. This self-send pattern indicates the attacker had access to the Salesforce org associated with the target's domain and was routing messages internally. It also sidesteps any external sender banners that Microsoft 365 might display.

The Fabricated Thread and the Real Landing Page

The In-Reply-To header referenced a Message-ID from DS0PR11MB7382, a different mailbox server than the actual sender. This is a fabricated thread reference, designed to make the email appear as a continuation of an existing conversation. Recipients who see "RE:" in a subject line are less likely to scrutinize the sender.

The call-to-action button read "Medicare Transaction Facilitator (MTF) Independent Provider Attestation" and linked to nexaroco[.]com/providerrelations/. A screenshot of the landing page revealed a standard Office 365 credential harvesting form, not the Adobe or DocuSign signing page that the Medicare attestation pretext implied. That mismatch between the stated document platform and the actual landing page is a signal that automated URL scanners may miss when the harvesting domain is new and has no reputation data.

Detection

Themis, the IRONSCALES Adaptive AI, flagged the message at 50% confidence. The IRONSCALES community added additional signal, confirming phishing classification. One mailbox was quarantined.

The confidence score is notable. At 50%, this was not a high-conviction detection. The full authentication pass, the legitimate Salesforce infrastructure, and the healthcare compliance pretext all worked to suppress automated risk scoring. What tipped the balance was behavioral context: the self-send anomaly, the first-time CRM message pattern, and the mismatch between the attestation pretext and the landing page destination.

Healthcare organizations processing Medicare compliance documents should treat CRM-originated attestation requests with the same scrutiny as external wire transfer instructions. When the signing page does not match the stated platform, the compliance request is the attack.

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

Indicators of Compromise

MITRE ATT&CK Mapping