Your Own Name, Someone Else's Server: A Compromised Sender Turns a File-Share Into an Invoice Trap

A staff member at a textile company received a notification that colleagues had been given access to a spreadsheet. The subject line named their coworkers. The message was branded with their own organization's name. The call to action was a green button labeled "Payment Details."

The authenticated sender was not their organization. It was a compromised mailbox at an external company whose mail infrastructure passed every standard authentication check.

This is the structural problem with account takeover as a delivery mechanism. The attacker did not need to register a new domain, construct a lookalike, or spoof anything. They used a real account with a real authentication record to deliver a lure that impersonated the recipient's own organization from the inside out.

How the message was assembled

The subject line named real employees at the textile company as if they had been granted access to a shared spreadsheet. The body asked the recipient to review the details of a December payment and confirm acknowledgement so a billing team could finalize the process. A Payment Details.xlsx attachment accompanied the CTA button.

This structure runs two lures at once. The file-sharing notification is familiar from collaboration platforms. The payment-review request is familiar from accounts-payable workflows.

The display name inside the message body attributed the spreadsheet to the recipient organization itself, not to any external vendor. The authenticated sending domain was a different company entirely. That mismatch was the only behavioral signal at the point of delivery. There was no malicious URL to scan because the CTA resolved to a subdomain of the compromised sender's domain. There was no macro because .xlsx files in the OpenXML format do not carry VBA. Anti-spam scoring came back low-risk.

Authentication passed because the sender was real

SPF, DKIM, and DMARC all returned clean results for the sending domain. That is not a failure of the authentication system. Authentication checks one thing: was this message sent from infrastructure authorized for the claimed sending domain. The compromised organization had a properly configured mail server, published valid SPF records, signed messages with DKIM, and maintained an active DMARC record, all of which remained true when the attacker used the account.

This is the central problem with business email compromise launched from a compromised account rather than a spoofed one. Every control built on authentication verdict gives the attacker a clean pass. The message does not look like a threat to any system that treats authentication as the primary trust signal.

The relay chain confirmed the message came directly from the external organization's own Exchange server, not through a third-party marketing platform or a gateway. Delivery was direct and clean into the recipient tenant.

The .xlsx is the lure, not the payload

Attachment scanning of the Payment Details.xlsx returned a clean verdict. An OpenXML spreadsheet cannot carry traditional VBA macros without being saved in a macro-enabled format. This is well known, and it is part of why .xlsx is a preferred attachment type in social-engineering campaigns: it clears scanners while reinforcing the credibility of the lure.

The practical attack surface was the CTA button, not the file. The links and unsubscribe headers in the message all resolved to a subdomain of the compromised sender's own domain. The attacker controlled that infrastructure. A recipient who clicked the button would land on pages the attacker designed, potentially including a credential-harvest form or a secondary redirect.

The fabricated thread quoted in the message body showed additional construction work. A named contact appeared as admin[@]my.com, an address that does not correspond to any party in the actual conversation. Character encoding errors in the quoted text, garbled multi-byte sequences where accented characters should have been, suggested the thread was stitched together rather than genuinely forwarded.

The impersonation ran in the wrong direction

Most vendor-impersonation attacks look outward: an attacker pretends to be a supplier or partner in order to redirect payments or access. This attack ran inward. The message claimed to be from the recipient organization to its own staff. The subject line named real employees. The body referenced an internal payment process.

That inward framing removes the skepticism a recipient applies to external communications. An accounts-payable staffer who receives a message branded with their own company's name asking them to confirm a December payment does not default to checking the From domain the way they might for a message from an unfamiliar vendor. The internal brand framing is the social engineering. The compromised external sender just delivered it.

This maps to the invoice fraud pattern at the behavioral level even though there is no external invoice: an attacker uses financial workflow framing to pressure a target into taking an action, in this case clicking a payment-review CTA, without verifying the underlying transaction through an independent channel.

Indicators of compromise

What actually caught it

Authentication did not catch it. Attachment scanning returned clean. Spam scoring came back low-risk. Detection came through community intelligence matching the message structure to confirmed phishing resolutions, combined with content analysis that recognized the invoice lure pattern even without a flagged URL.

The behavioral confidence was moderate, which reflects the genuine ambiguity: the authentication was clean, the attachment was clean, and the payload sat behind a sender-controlled link dressed as a collaboration notification. Surfacing the display-name impersonation of the recipient's own organization required relationship-level analysis, not signature matching.

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

A gateway checking authentication verdicts and attachment hashes would find nothing to block here. The attack lived in the gap between a clean authentication record and a fabricated organizational identity. That gap does not close with better signature rules. It closes with behavioral analysis that treats a mismatch between the authenticated sending domain and the claimed organizational brand as the threat signal it is.

The attacker borrowed a real company's reputation to walk through a door that authentication held open.