No malicious link. No attachment. No embedded payload of any kind. SPF passed. DKIM passed. DMARC passed. Microsoft's own anti-spam filters scored it clean. The email landed in inboxes at a broadband infrastructure company, dressed as a routine telecom service order, and asked one thing: reply all to confirm receipt.
That was the entire attack.
There was nothing to scan because there was nothing malicious in the email itself. The weapon was the reply button. If any recipient followed the instruction, they would confirm a live, monitored mailbox to an unknown sender, hand over their email signature and internal contact details, and open a trusted reply thread the attacker could exploit for weeks.
The email arrived on a Friday afternoon, formatted as a telecom drop request (a fiber or copper line installation order). It referenced a specific street address, a MetaSolv ticket number, a cost center code, an exchange name, and a construction due date. The language was fluent operational jargon. Recipients included a mix of internal employees and external contractors across multiple domains, plus a Gmail address.
The subject line followed a recognizable pattern: Re: Request # 351426 - 3443 HICKORY HILL RD. The Re: prefix suggested this was a reply in an existing thread, not a cold outbound message. That detail matters. People treat replies differently than new messages. A reply implies prior context, prior trust.
The body closed with a single instruction: "Please reply all to this email to accept and confirm receipt of this drop request."
No urgency. No threat. No link to click. Just a polite, professional-sounding request that, if followed, would complete the reconnaissance.
Every email authentication check returned green. The SPF record confirmed the sending IP (2a01:111:f403:c107::1) was authorized to send on behalf of the sender's domain. DKIM signatures verified the message body had not been tampered with in transit. DMARC alignment passed with a policy of p=none (monitor only, no enforcement).
This is the core problem with authentication-only security models. SPF, DKIM, and DMARC answer one question: "Was this email sent from infrastructure authorized by the domain owner?" They do not answer: "Does the person controlling this account have legitimate intent?"
When an attacker compromises a real account (or registers one through a legitimate provider's abuse-prone onboarding), all three protocols validate perfectly. The Microsoft Digital Defense Report 2024 documented this pattern extensively, noting that threat actors increasingly use authenticated infrastructure to bypass gateway-level controls. According to the Verizon 2024 DBIR, the human element is involved in 68% of breaches, and social engineering remains the top attack pattern, with phishing as the dominant vector.
The sending account routed through Microsoft Exchange Online Protection and multiple Microsoft SMTP relays. ARC (Authenticated Received Chain) seals were intact. Every relay hop was legitimate Microsoft infrastructure. To any content-scanning gateway, this was a clean, authenticated message from a real organization's real email tenant.
This is not a standalone attack. It is Phase 1 of a multi-stage campaign mapped to MITRE ATT&CK T1589 (Gather Victim Identity Information). The reply-all mechanic serves three purposes:
The FBI IC3 2024 Internet Crime Report recorded over $2.9 billion in BEC losses. Many of those campaigns started with exactly this kind of low-friction reconnaissance: a harmless-looking email designed to build a target list before the real payload arrives.
The MITRE framework also maps this to T1586 (Compromise Accounts), reflecting the likelihood that the sending account was compromised rather than legitimately operated.
No content scanner could have caught this. There was no URL to detonate in a sandbox. No attachment to hash-check. No embedded form, no JavaScript, no redirect chain. The body was plain operational text that would pass any natural language analysis for phishing intent.
What did catch it was behavioral analysis. IRONSCALES Adaptive AI flagged the message based on a combination of signals that no individual check would have surfaced alone:
Within seconds of delivery, four mailboxes were quarantined. The message was reverted before any recipient could act on the reply-all instruction.
See Your Risk: Calculate how many threats your gateway is missing
CISA's phishing guidance recommends email authentication as a foundational control. It is. But this case demonstrates that authentication is a floor, not a ceiling. When the attack carries no payload and the sending account is legitimately authenticated, the entire content-inspection layer of your security stack becomes irrelevant.
The defenses that matter here are behavioral:
Zero-payload attacks are not new. But they are getting better. The operational specificity in this email (ticket numbers, exchange codes, construction dates) suggests the attacker had access to real operational data, either through a prior breach or through the compromised account's own mailbox history. The days of "just don't click the link" are long past. Sometimes there is no link to click.
| Type | Indicator | Context |
|---|---|---|
| Sender Email | Conner.DiPersio@tdstelecom[.]com | Likely compromised or abuse-registered account |
| Sender Domain | tdstelecom[.]com | Legitimate telecom domain (authenticated via SPF/DKIM/DMARC) |
| Sending IP | 2a01:111:f403:c107::1 | Microsoft Exchange Online Protection (outbound relay) |
| Reply-To Thread | Re: Request # 351426 | Thread-hijack prefix to imply existing conversation |
| Report ID | 44b1cdbf2e51b61f5b1a86e7dddde0a0 | IRONSCALES incident reference |