One Dell Order, Two Companies, One Signature

Two companies with nothing in common received the same email earlier this month, about two minutes apart. Not the same campaign. The same message. Identical signature value, identical message identifier, identical attachment hash, identical purchase identifier, identical outbound gateway tracking identifier. One was a commercial cleaning and property restoration franchise organisation. The other was an unrelated professional-services firm. Neither had ordered anything.

The email was a genuine Dell order acknowledgement. Dell rendered it, generated its PDF, scanned it through its own outbound gateway, and signed it with its production key. Everything in it is real except the buyer, the destination and the reason it existed.

One Signature, Many Strangers

We have written about brand-signed lures before, including messages a vendor's own platform composed on an attacker's behalf and then relayed onward through a throwaway Microsoft 365 tenant. That mechanic is the setup here, not the story. An order was submitted under a mailbox at an attacker-controlled tenant, no-reply@Dynamic535[.]onmicrosoft[.]com. Dell's platform did what it is designed to do with the values it was given, produced a signed acknowledgement, and delivered it to that mailbox.

What happens next is the part no reputation control is built for. That tenant relayed the finished, signed message onward to a second Microsoft 365 tenant, which relayed it to a target. Relaying rewrites the SMTP envelope and nothing else. Not one signed header was touched, so the body hash still matched and the signature still verified. Each hop added a passing seal on top.

Then the rig did it again, in parallel, through a different second-hop tenant, to a completely different company. Same signed bytes. One relay tenant per target. Two unrelated organisations, two minutes apart. One order acknowledgement became a distribution list, and every copy carried the vendor's real cryptographic endorsement.

At the final hop, each recipient's mail system reported the same thing: sender policy pass, DKIM pass on the vendor's domain, DMARC pass under a reject policy, composite authentication pass with the maximum reason code. There is no failing mechanism anywhere in either chain.

The Tell Was Signed, Free And Ignored

The signature's covered-header list included the recipient field. And that signed recipient field still read the attacker-controlled tenant's mailbox, not the person who received the mail. The actual recipient's address appears in no signed header at all; only the envelope named them.

That is a genuinely useful primitive. Because the field is inside the signed set, a relay cannot have inserted or altered it without breaking the signature. So a signed recipient identity that names a stranger is cryptographically protected proof that the message was not generated for the mailbox holding it. It costs nothing to check.

DMARC does not evaluate it. DMARC, as specified in RFC 9989, aligns the visible sender domain with an authenticated identifier. It answers whether the brand sent this. It was never designed to answer whether the brand sent this to you, and here that is the only question that mattered.

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

The Payload Was Seven Address Fields

There is no attacker domain, link, file or hash in this message. All 22 scanned links resolve to the vendor's own domains or to Microsoft support boilerplate, every verdict clean. The single attachment is the vendor's own order acknowledgement PDF, also clean. No embedded codes, no scanned text artifacts.

The entire actionable payload sits in the order's shipping and billing address blocks, seven structured fields each. The buyer name field reads Confirmed Order. The first address line reads Helpline 803 357 5134. The second reads Call Our Sales Team. The phone fields repeat the digits. The city, state and postal code point at the vendor's own corporate headquarters in Round Rock, Texas, the same address printed in the message footer, so the order has no real delivery destination at all. The postal field reads 78682-Round Rock.

The area code does not match the address sitting beside it. What that number is, or who answers it, the record does not establish, and we will not guess. What it is, structurally, is the only thing in the email a human can act on. That is the definition of a callback lure under MITRE ATT&CK T1566, and it maps to the pattern the 2026 Verizon Data Breach Investigations Report shows gateways blocking least often: contributing-vendor gateway telemetry puts callback-style mail at roughly 5% of a median month's blocks, against 80% for conventional phishing. The report also puts phishing at 16% of initial access vectors and the human element in 62% of breaches. Nothing here needed a payload.

Every field substituted correctly. The template was not broken, the platform was not bypassed, and no input validation failed. The order form accepted advertising copy where a name and street belong, and the rendering engine printed it.

Authentication Outvoted Two Humans

Our agentic SOC analyst wrote down both tells: the area code and address mismatch, and the recipient's own report of having placed no order. It then concluded that those signals were outweighed by header-level authentication and clean artifact scans, and labelled the message safe. The copy at the second company got the same reasoning and the same label.

Two independent human reviewers, at two unrelated companies, on the same message, overrode it to malicious. Both incidents closed as manual approvals. IRONSCALES also quarantined four sibling messages into the same tenant group within one to three seconds of receipt, at a point when only behavioural signals existed: a first-time sender to the organisation despite a claimed existing purchase relationship, a signed recipient identity naming a third-party tenant, and a phone number as the sole actionable content in a receipt.

The same rig kept minting fresh brand-signed mail across at least three distinct purchase identifiers and all three lifecycle stages, order received, shipped and out for delivery, into that tenant group across the following days. The vendor's own lifecycle automation supplied the follow-up cadence for free.

That inversion, authentication outranking content, is the lesson. Our Adaptive AI exists to weigh behaviour and relationship history alongside headers precisely because headers alone cannot see intent. CISA guidance and the NIST definition of phishing both frame the attack around deception of the recipient, not the technical origin of the mail. Compare the signed recipient identity against the delivery mailbox. Treat an unsolicited transactional first contact as unverified regardless of authentication. And when an employee reports an order they did not place, that is evidence, not noise.

Indicators of Compromise

The order itself, for completeness: one mid-range office printer, quantity one, line total $640.00, estimated tax $52.80, total $692.80.

MITRE ATT&CK Mapping