Table of Contents
The email arrived at 1:53 PM on a Friday afternoon. A credentialing specialist at a pharmacy benefits company saw the subject line: "Health Insurance." The sender was a pharmacist at a regional healthcare system, someone whose name and email signature looked right for the industry. The message body was three lines long: "HI," a linked spreadsheet filename, and "FYI-Kindly see attached document."
Nothing about the technical plumbing raised a flag. SPF passed. DKIM passed. DMARC passed. The message routed through Microsoft 365 outbound protection infrastructure and landed in the inbox with every authentication stamp a security team could ask for.
Except the pharmacist never sent it.
Three Lines, Zero Context, One Attachment
The email carried all the hallmarks of a document-share phishing attack optimized for speed over sophistication. No personalization. No transaction reference numbers. No context that would make sense for a healthcare remittance workflow. Just a file named REMITTANCE_PAYMENTADVICE.xlsx hosted on the sender's corporate SharePoint and an instruction to open it.
This is a deliberate design choice. Low-context lures cast a wide net. They rely on a single human impulse (curiosity about money arriving or leaving) rather than researching specific targets. The FBI IC3 2024 Annual Report documents that BEC and payment-themed phishing accounted for over $2.9 billion in reported losses, making remittance fraud one of the most reliably profitable attack templates in circulation.
The email signature added credibility. It listed a real pharmacy, a real phone number, and the credential "PharmD." For anyone in the healthcare benefits chain, this looked like a routine document share between organizations that regularly exchange payment information.
Inside the Spreadsheet: A Clean Shell With a Hidden Payload
Static analysis of the attachment told a story in two layers.
On the surface, REMITTANCE_PAYMENTADVICE.xlsx was structurally clean. No VBA macros. No embedded executables. No suspicious formulas using HYPERLINK(), WEBSERVICE(), or ENCODEURL(). Traditional antivirus engines and sandbox detonation would (and did) return a clean verdict.
But OOXML files are ZIP archives containing XML. Buried inside the workbook's package XML was an external reference pointing to hxxps://saishipping[.]in/cjr/sharep-redirect[.]html. That domain, a shipping company website in India, has no business relationship with a North Dakota healthcare system. The redirect page was designed to funnel recipients to a credential harvesting landing page, likely styled to mimic a Microsoft 365 login.
This technique maps to MITRE ATT&CK T1204.002 (User Execution: Malicious File) and T1566.001 (Phishing: Spearphishing Attachment). The file itself does not execute code. It acts as a container, a trust vessel that exploits the gap between what security tools scan (macros, executables, formulas) and what attackers actually embed (package-level XML references that redirect victims outside the document).
The file metadata showed a creation date in 2022 with a last modification timestamp of April 10, 2026, matching the attack timeline. The attacker likely recycled a legitimate template and injected the redirect reference shortly before distribution.
The Compromised Account Problem
The sender's email address, Laura.Morris@EssentiaHealth[.]org, authenticated through Microsoft's outbound protection infrastructure. The DKIM signature was valid for essentiahealth[.]org. ARC chains passed at every hop. This was not spoofing. The message genuinely originated from the healthcare organization's Microsoft 365 tenant.
This points to account compromise (T1078, Valid Accounts) and likely T1586.002 (Compromise Accounts: Email Accounts). The attacker gained access to a real mailbox and used it to send from trusted infrastructure, bypassing every domain-based email authentication control in a single move.
The Microsoft Digital Defense Report 2024 highlights this exact pattern, noting that compromised accounts represent one of the most difficult phishing vectors to detect because they inherit the full trust profile of the legitimate sender. SPF, DKIM, and DMARC become irrelevant when the attacker IS the authenticated sender.
What Stopped It
The receiving organization's security stack flagged the message as incoming document/fileshare phishing and quarantined it. But what specifically made this detectable when every technical authentication signal said "safe"?
Three signals converged. First, the message body was abnormally sparse for the claimed sender context. A pharmacist sharing a remittance document with a credentialing team would typically include context: a patient ID, an invoice reference, a note about what the payment covers. Three generic lines with punctuation anomalies (the misplaced period after "document") deviated from normal business correspondence patterns.
Second, the attachment behavior was anomalous. The SharePoint-hosted file linked from a personal OneDrive path, which is unusual for inter-organizational document sharing in healthcare. Legitimate business file shares typically route through shared drives or dedicated document management systems.
Third, Adaptive AI analysis identified the embedded external redirect inside the OOXML package. The presence of saishipping[.]in inside a spreadsheet purporting to come from a U.S. healthcare system created a geographic and contextual mismatch that pure reputation scoring would miss but behavioral analysis catches.
The system quarantined the message across all four affected mailboxes within seconds of detection.
See Your Risk: Calculate how many threats your SEG is missing
What This Attack Teaches
Authentication is not trust. SPF, DKIM, and DMARC verify that a message came from authorized infrastructure. They say nothing about whether the person controlling that infrastructure is the person they claim to be. Organizations that treat authentication passes as safety signals are building on a false foundation. The Verizon DBIR 2024 reports that stolen credentials remain the top initial access vector, which means authenticated phishing will only increase.
OOXML files need deeper inspection. Macro detection is necessary but insufficient. Attackers increasingly embed redirectors and external references in package-level XML, a layer that most endpoint security tools skip entirely. Security teams should add OOXML package inspection to their file analysis playbooks.
Low-context messages from high-trust senders are the most dangerous combination. The attack did not need to be sophisticated because the sender's reputation did the heavy lifting. When a message from a verified healthcare organization asks you to open a remittance document, the social engineering is already complete before the recipient makes a conscious decision.
Friday afternoons are not a coincidence. This email landed at 1:53 PM on a Friday, when attention spans are lowest and urgency to clear inboxes before the weekend is highest. Timing is part of the weapon.
IOC Summary
| Indicator | Type | Context |
|---|---|---|
Laura.Morris@EssentiaHealth[.]org | Sender (compromised) | Authenticated via SPF/DKIM/DMARC |
REMITTANCE_PAYMENTADVICE.xlsx | Attachment | OOXML with embedded redirect |
hxxps://saishipping[.]in/cjr/sharep-redirect[.]html | Redirect URL | Embedded in workbook package XML |
essentiahealth-my.sharepoint[.]com | SharePoint host | Personal OneDrive path for sender |
b8936529917db430240cf07b1d96c064 | MD5 hash | Attachment file hash |
MWHPR1301MB2048.namprd13.prod.outlook[.]com | Origin server | Microsoft 365 outbound node |
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.