It bypasses many defenses because the message can travel through legitimate Microsoft infrastructure and resemble trusted internal mail. Perimeter gateways may never see it clearly, and static indicators such as URLs or body text may be missing. That leaves rule-based tools with too little evidence to classify the message correctly.
Why This Matters for Security Teams
direct send abuse is hard to stop because it turns email from a perimeter problem into an identity and trust problem. The message can originate from a legitimate Microsoft service path, so secure email gateways, URL rewriting, and content inspection may see too little to flag. That makes mailbox trust, authentication context, and tenant policy far more important than the visible text of the message. Current guidance suggests this is a blind spot whenever defenders assume delivery-path legitimacy equals sender legitimacy. The pattern is closely related to broader credential abuse lessons seen in the DeepSeek breach, where exposed access paths created outsized downstream risk. Microsoft-aligned controls still matter, but they need to be paired with policy, telemetry, and user-risk detection rather than static filtering alone. For control mapping, the NIST Cybersecurity Framework 2.0 remains a useful baseline for detection and response. In practice, many security teams discover Direct Send abuse only after internal-looking mail has already been delivered and acted on.
How It Works in Practice
Direct Send abuse succeeds because the attacker is not always trying to spoof the entire email chain. Instead, they exploit a delivery path that can make the message appear native to the tenant, then rely on trust relationships, misconfigurations, or weak monitoring to get the mail accepted. That means traditional controls that focus on malformed sender domains, suspicious infrastructure, or obvious phishing artefacts can miss the event entirely. The right response is to inspect the path, not just the payload.
Operationally, defenders should look for a layered approach:
- Enforce tenant and connector settings that limit who can send into internal mail flows.
- Correlate message origin, authentication posture, and mailbox anomalies, not just subject line or body indicators.
- Use conditional access, identity telemetry, and post-delivery hunting to catch abuse that passes initial filtering.
- Review mailbox rules, forwarding settings, and internal impersonation patterns after suspicious delivery events.
This is why guidance from the NIST Cybersecurity Framework 2.0 is helpful but not sufficient on its own: teams still need tenant-specific email controls and continuous detection. NHIMG research on the State of Secrets in AppSec also reinforces a broader point, namely that abuse often persists when trust assumptions are stronger than monitoring. These controls tend to break down in Microsoft 365 environments with permissive connectors, inconsistent mail hygiene, and limited visibility into internal delivery paths because the message appears to be normal tenant traffic.
Common Variations and Edge Cases
Tighter mail controls often increase operational overhead, requiring organisations to balance delivery reliability against abuse resistance. Not every Direct Send event is malicious, and some legitimate workflows still depend on low-friction mail routing, so best practice is evolving rather than universally standardised. The main edge case is internal automation: helpdesk tools, alerting systems, and application notifications can resemble abuse if they are not clearly registered and monitored. Another common exception is hybrid email architecture, where on-premises relay rules, cloud connectors, and legacy exceptions create gaps that attackers can exploit.
There is also a practical limit to content-based inspection. If a message contains no obvious link, attachment, or brand lure, static rules may be too weak to help. In those cases, defenders should emphasize source validation, behavioral baselining, and mailbox-level anomaly detection. The lesson from NHIMG research on the LLMjacking threat pattern is that legitimate services can be abused once identity and access are compromised, even when the payload itself looks ordinary. For program-level prioritization, the NIST Cybersecurity Framework 2.0 can anchor governance, but local mail policy still needs tuning. The hardest cases are environments that equate internal routing with trust and have little post-delivery monitoring because abuse blends into routine business mail.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-1 | Direct Send abuse demands continuous monitoring of email and identity anomalies. |
| NIST CSF 2.0 | PR.AC-4 | Abuse exploits weak trust and access assumptions in email routing. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Email abuse often depends on compromised non-human identities and service access. |
Baseline mail telemetry, then alert on internal-looking messages that arrive through unexpected paths.
