Table of Contents
An email reached the shared accounts receivable mailbox of a mid-size industrial manufacturing company under the subject line [EXT]: A/R Updated Report. It came from a European university's administrative mailbox. SPF passed. DKIM passed and aligned to the sending domain. DMARC passed. Microsoft composite authentication returned its maximum score. There was no link in the message, no attachment, and no request for money.
What it asked for was a spreadsheet: "Is it possible to have our most recent aging report with customer ap emails included in a spreadsheet. Send me a copy of the file."
That request is the entire attack. Not a wire transfer, not a credential page, just a list of the people who pay invoices.
The Sender Was Genuine and the Authentication Proved It
Start with what was real. The sending address belonged to a departmental service mailbox at a European university, the kind of shared account a reprographics and administrative team uses for routine correspondence. It was not a lookalike domain, not a display-name spoof, and not a freshly registered domain wearing a familiar name. The mail left the institution's own SPF-authorized host, carried a valid DKIM signature for that domain, and satisfied DMARC alignment on the way in. Composite authentication scored 100.
How the attacker got there is not something the record settles. The message was either sent from a mailbox being operated by someone other than its owner, or relayed through infrastructure that mailbox is trusted to use. Either way the outcome is identical. The attacker was borrowing decades of institutional sending reputation, and no protocol check in the delivery path had a reason to object.
That is what DMARC is built to answer, and all it is built to answer. It confirms that the domain in the visible From header authorized the message. It says nothing about the intent of whoever composed it.
One Header Pointed Somewhere Else Entirely
The divergence was one line down. The Reply-To header did not point back to the university at all. It pointed to a mailbox at securemailsender[.]management, a domain with no relationship to the sender, the recipient, or anything in the pretext. The name is doing deliberate work. It reads like a mail-hygiene service, the kind of string a busy person's eye files as infrastructure and skips.
Mail clients make that easy. Most render a friendly display name and hide the addressing underneath it, so a recipient who hits reply never sees where the answer is going. Authentication applied to the sending domain, not to the reply path. The conversation would have moved onto attacker-controlled ground on the first response, silently, without a single check firing.
The display name pushed the same way. It paired an invented personal name with the recipient organization's own web domain, so the sender read as someone adjacent to the business rather than a stranger writing from a university in another country. The tenant's external-sender banner was sitting right there in the body, which is the control many organizations rely on for exactly this case, and which most recipients stopped seeing years ago.
The Ask Was Reconnaissance, Not a Payday
An accounts receivable aging report is an internal finance document. Add "customer ap emails" to it and it becomes something else entirely: a roster of the named humans who approve and pay invoices at every customer the manufacturer bills, with their addresses, their companies, and their outstanding balances attached.
That is a target list, and it is worth far more than one fraudulent payment. Holding it, an attacker can write to a customer's accounts payable clerk citing a real invoice number, a real balance, and a real vendor relationship, then supply new remittance details. The pretext no longer has to be plausible in the abstract. It is accurate.
MITRE ATT&CK separates this step from the attack it enables. Harvesting the list is T1598 (Phishing for Information). The wave it stages is T1566 (Phishing), delivered from a position of unearned credibility. The 2024 Verizon Data Breach Investigations Report puts pretexting, largely business email compromise, at the top of the social engineering category with a median transaction of roughly $50,000, and the FBI Internet Crime Complaint Center attributed about $2.9 billion in reported losses to BEC in its 2023 IC3 report. Campaigns at that scale start with homework. This message was the homework.
See Your Risk: Calculate how many threats your SEG is missing
A Fabricated Thread Did the Corroborating
The body did not make the request cold. Pasted beneath it sat a forwarded-message block attributed to a collections specialist at an outside debt-collection consultancy, complete with a sent timestamp several months older than the message carrying it.
There were no genuine RFC 822 headers behind that block. Nothing had been forwarded. It was typed, and it exists to manufacture continuity, so the recipient reads the request as the next step in an exchange already underway rather than an unsolicited demand from a stranger. It also supplies a second voice vouching for the first. CISA phishing guidance makes the same point about the strongest lures. They borrow an existing business process instead of inventing urgency.
Why the Gateway Had Nothing to Grab
Inventory the detection surface. No URL to scan, resolve, or blocklist. No attachment to sandbox. No macro, no archive, no encoded payload. Authentication uniformly green, from a domain with a long and clean history. Content filtering sees a short, polite, grammatically plain request for a report that finance teams genuinely produce.
A gateway built to catch forgery and payloads finds nothing here, because there is no forgery and there is no payload.
What remained was behavior. Themis, the agentic AI analyst on the IRONSCALES platform, weighed the pattern rather than the protocol: a first-time sender into this environment, a Reply-To domain diverging from the authenticated sending domain, an external request for a structured list of third-party contacts landing in a finance mailbox, and a reply domain with no history anywhere across the IRONSCALES community. The resulting confidence score was modest, 53 percent, and that number is an honest reflection of a message carrying no technical evidence to weigh. It was enough. The email was quarantined across the four mailboxes in that finance environment that received it.
Reply-To divergence is also the cheapest signal to watch at scale. Teams already running DMARC monitoring on their own domains have the reporting habit; extending the same scrutiny to inbound reply paths costs nothing and catches this class of message on the header alone.
MITRE ATT&CK Mapping
- T1598 (Phishing for Information): soliciting an accounts payable contact roster as staging for a later fraud campaign.
- T1566 (Phishing): social engineering delivered over email from an authenticated sender.
- T1078 (Valid Accounts): a legitimate institutional mailbox supplying the authentication and the reputation.
Indicators of Compromise
| Type | Indicator | Context |
|---|---|---|
| Sender | A European university departmental mailbox (withheld) | Administrative service account, fully authenticated, not a spoof or lookalike |
| Sending host | 158[.]227[.]0[.]66 | SPF-authorized sending host for the sender's mail domain |
| Authentication | spf=pass, dkim=pass, dmarc=pass action=none, compauth=100 | Every protocol check green, so authentication-based filtering had nothing to act on |
| Reply-To | mail@securemailsender[.]management | Diverts every reply off the authenticated sending domain |
| Domain | securemailsender[.]management | Attacker-controlled reply destination, named to read as mail infrastructure |
| Subject | [EXT]: A/R Updated Report | Finance pretext behind the tenant external-sender tag |
| Data request | Aging report with customer accounts payable email addresses, as a spreadsheet | The actual payload, a target list for later invoice fraud |
| Body artifact | Pasted forwarded-message block attributed to an outside collections consultant | Fabricated thread, no genuine RFC 822 headers behind it |
| Sender behavior | First-time sender to the environment, display name pairing a personal name with the recipient's own web domain | Manufactured familiarity with no prior correspondence history |
Treat Contact Lists Like Money
The instinct that protects a finance team is trained on payment instructions. This message never asked for one, which is exactly why it traveled as far as an inbox. Reconnaissance requests are cheap, low-risk, and unremarkable, and the data they collect is what makes the expensive request believable weeks later.
Three habits close the gap. Classify customer and vendor contact rosters as controlled data, so exporting one is a decision rather than a favor. Verify any inbound request for a list of people over a channel you trusted before the email arrived, using a number you look up instead of one you were handed. And compare the Reply-To domain against the authenticated sending domain in front of your mail flow, because a legitimate correspondent almost never needs replies to land somewhere else.
Authentication told the truth about this message. It came from the domain it claimed to come from. That is the whole of what a green check means, and it was never the question worth asking.
Related attacks
| Attack | What happened |
|---|---|
| Salesforce Pardot Infrastructure Weaponized in Fabricated-Thread CRM Consulting Phish | A phishing campaign abused Salesforce Pardot and ExactTarget infrastructure to deliver a fabricated-thread CRM consulting lure with full SPF, DKIM. |
| Microsoft Bookings as a Weapon: When DMARC Says Trust Me and ARC Quietly Disagrees | A phishing email sent from bookings.microsoft.com passed every authentication check. |
| The Payload Was a Phone Number: How a Google Calendar Invite Weaponized Vishing | A Google Calendar invite with a fake $399.77 charge and a toll-free callback number. |
| The Intuit Payroll Phish That Quickbase Delivered | A payroll payment confirmation branded as Intuit arrived through Quickbase's own notification infrastructure. |
| Fake AI Conference, Real Authentication: How Attackers Weaponized Lu.ma to Bypass Every Email Check | Attackers registered a fake AI conference on lu.ma and sent phishing emails through the platform's own Amazon SES pipeline. |
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.