A Real Procurement Platform, a Hijacked Reply-To

An accounts payable mailbox at an IoT and cellular connectivity hardware manufacturer received a forwarded reminder about an overdue invoice, addressed by name to a senior executive. Everything about the message's plumbing was clean. The sending address was support@demandstar[.]com, and DemandStar is a real government and municipal procurement platform that pushes bid notifications to vendors and public agencies as a matter of routine. SPF passed. DKIM passed and signed on the sending domain. DMARC passed. Microsoft's composite authentication returned a pass with reason 100, the strongest verdict it issues. There was no attachment. There were no malicious links. The only three URLs anywhere in the body pointed at Microsoft's own help pages about identifying senders.

The fraud was sitting in a header that no authentication standard is designed to evaluate.

Authentication that was telling the truth

Most phishing that wears a trusted brand is spoofing it, and the authentication stack usually says so. This message was different, and that difference is the whole case. The email did not claim to come from a procurement platform. It genuinely traveled through one. The first hop in the chain was o1[.]ptr3447[.]www[.]demandstar[.]com at 149[.]72[.]175[.]94, a host inside the platform's own SPF-authorized sending range, with a return path on the platform's em5936 bulk mailer subdomain. From there it was handed to the manufacturer's inbound gateway and into a Microsoft 365 front end in the EU region.

That is a legitimate notification path being used to carry an illegitimate message. Whether the operator abused an account on the platform or a self-service notification feature exposed by it, the outbound leg was real, so every check on the sending identity passed honestly. Nothing was broken. SPF verified that an authorized host sent the mail, and it had. DKIM verified that the signing domain owned the signature, and it did. This is the uncomfortable part of leaning on authentication as a trust decision: it verifies the path a message traveled and says nothing at all about who wrote it or why.

The header DMARC never looks at

RFC 7489 defines DMARC as an evaluation of identifier alignment against the domain in the visible From header. That is the entire scope. The Reply-To header is not part of the assessment, is not aligned, and is not checked. An attacker who can get a message delivered through an authenticated path can therefore point every reply somewhere else with no authentication consequence whatsoever.

Here, the Reply-To carried two addresses on two attacker-registered domains: rebecca@careermp-us[.]info and admin@oreumails[.]com. The first is a hyphenated regional variant of a talent and career-transition coaching firm's real corporate domain, lifted onto a .info top-level domain. It has no A record and no web presence at all. Its MX points at generic third-party hosting, its SPF record simply delegates to titan[.]email with a soft-fail qualifier, it publishes no DMARC policy, and no DKIM selectors exist for it. Those records were never evaluated at delivery, because that domain never sent anything. It only had to receive.

The two-address detail matters more than it looks. A single click of reply fans the conversation out to both attacker mailboxes at once, giving the operator a warm inbound thread from a finance team and a spare channel if one address burns. Registering thin, purpose-built infrastructure for exactly this is T1583.001 in MITRE ATT&CK, and dressing it in a real vendor's identity is T1656.

A paper trail that never existed

The body did the rest of the work. It was built as a nested, three-layer forwarded thread: an original request attributed to a senior executive, a reply from a purported account representative at the coaching firm, and a final forward landing in the finance queue. None of those messages ever happened. The quoting structure was authored in a single pass to manufacture the impression that this payment had already been discussed, questioned, and approved further up the chain, and that the recipient was simply the last hand it needed to pass through.

Layered on top was ordinary pressure. The invoice was described as overdue by more than sixty days, with late fees said to be accruing, and the closing ask was to "treat this payment as a top priority and process it at your earliest convenience." No credential harvest, no malware, no landing page. The intended outcome was a reply, a bank-detail exchange, and a wire.

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

That shape is the most expensive category in email crime, not the loudest. The 2024 Verizon Data Breach Investigations Report puts pretexting, largely business email compromise, as the leading social-engineering type, with a median transaction of roughly $50,000, and finds the human element present in 68 percent of breaches. The 2023 FBI IC3 Internet Crime Report counts about $2.9 billion in reported BEC losses. This is T1566 reduced to its cheapest possible form, which is also what NIST's definition of phishing describes at its core: a message engineered to make a person act, with no technical exploit required.

What actually caught it

Every automated signal in this case was clean by construction. The sender was authenticated on real infrastructure. There was no payload to scan, no domain reputation to fail, and no destination to sandbox. Our Adaptive AI analyst, Themis, recorded the message but produced no verdict of its own, which is an honest reflection of how little technical surface the attacker left exposed.

What broke it was a person. A finance employee in the vendor-payment workflow looked at a forwarded invoice reminder from a procurement platform and reported it with a blunt question: is the sender legit? That report opened an analyst review, internal discussion followed, and the message was confirmed as phishing and quarantined across all four affected finance mailboxes. CISA's phishing guidance makes reporting a control rather than a courtesy, and this is why. When the technical layer has nothing to say, the reporting loop is the detection layer, and every report it collects becomes signal that trains what the platform recognizes next time. That feedback path is what the human element side of the platform exists to capture, and it is also why business email compromise protection has to be behavioral rather than reputational.

Indicators of Compromise

MITRE ATT&CK Techniques

The takeaway

A green light on SPF, DKIM, and DMARC is a statement about the route, not the writer. When an attacker sends through a platform that is genuinely authorized to send, those checks pass because they are working correctly, and the only thing left to inspect is the behavior: a reply address that does not match the sender, a thread with no history in any mailbox, and a payment request that arrives already claiming to be approved. Authentication had nothing to flag here. A person did.