Microsoft Direct Send abuse exposes the limits of trusted email

At a glance

What this is: This is an Abnormal AI webinar analysis of Microsoft Direct Send abuse, showing how attackers use trusted Microsoft infrastructure to bypass secure email gateways and hide malicious payloads.

Why it matters: It matters because email and IAM teams cannot rely on sender trust alone when abuse occurs without stolen credentials and arrives through infrastructure many controls already trust.

Context

Microsoft Direct Send is a legitimate Microsoft 365 mail flow path, but that trust can be turned into a delivery mechanism for malicious email when attackers understand how inspection controls make routing assumptions. The security problem is not authentication failure alone; it is the mismatch between trusted infrastructure and the controls expected to catch abuse inside it.

For identity and security programmes, the issue sits at the intersection of email security, cloud trust boundaries, and the limits of legacy secure email gateways. When a delivery path is assumed to be low-risk because it is native to the platform, defenders can miss payloads that arrive through otherwise trusted channels.

Key questions

Q: Where does trusted email abuse fail in practice?

A: It fails when defenders equate a trusted delivery path with a trustworthy message. If a native platform route such as Direct Send is not independently risk-scored, malicious content can bypass perimeter assumptions and reach users even without stolen credentials. The control gap is in how trust is assigned, not only in how the mail is delivered.

Q: Why do QR codes and CAPTCHA-hidden payloads increase email risk?

A: They shift malicious intent out of plain text and into forms that reduce the effectiveness of standard text, URL, and attachment inspection. That makes it harder for traditional email controls to recognise the threat before a user interacts with it, so detection has to account for concealment techniques as well as sender reputation.

Q: How should security teams evaluate trusted-infrastructure email flows?

A: They should test whether trusted-infrastructure paths are being exempted from the same inspection standards as ordinary inbound email. The right test is whether the control stack still scores content, links, and behavioural cues when the mail arrives through a legitimate platform path, because that is where abuse often hides.

Q: What should organisations do when a mail control assumes native delivery is safe?

A: Treat that assumption as a policy defect, not a tuning issue. Reclassify the delivery path, verify which inspection stages still run, and confirm whether users can receive malicious payloads through the trusted route without triggering the same response workflow used for external phishing.

Background and context

How Direct Send abuses trusted email routing

Direct Send is intended to let Microsoft 365 systems deliver mail within a tenant without the same user-driven authentication path as normal mailbox sending. Attackers exploit that trust boundary by using the mechanism as a mail transport rather than by stealing a mailbox session. The practical security problem is that some inspection stacks treat platform-native delivery as inherently safer, so messages can reach inboxes even when the content is clearly malicious. When a control optimises for authenticated sender trust, abuse of a native delivery path can slip through because the abuse is in the transport assumption, not the login flow.

Practical implication: Inspect platform-native mail flows as a separate trust class instead of assuming tenant-local delivery is low risk.

Why QR codes and CAPTCHAs reduce content inspection value

QR codes and CAPTCHAs are effective concealment techniques because they shift the malicious intent out of plain text and into image-based or interaction-based payloads. Traditional email security often relies on signature matching, URL inspection, or text parsing, all of which become less effective when the payload is embedded in a visual code or behind a human challenge. That does not make the email benign. It means the detection problem moves from message content alone to the behaviour the message is trying to induce, which is why static inspection can be outpaced by social-engineering wrappers.

Practical implication: Add image, link, and behaviour analysis to email inspection so concealed payloads are not evaluated only as static text.

Why legacy secure email gateways miss trusted-infrastructure abuse

Secure email gateways were built to filter untrusted inbound traffic, but trusted infrastructure abuse blurs that boundary. If the sender path is seen as internal or legitimate, the gateway may apply lighter scrutiny or fail to correlate the message with known abuse patterns. That creates a detection gap between authentication posture and actual risk. The article’s core point is that the control failure is architectural: the gateway is being asked to judge trust from transport context alone, while the attack succeeds by making the transport itself look trustworthy.

Practical implication: Re-tune email controls to score message risk from content and behaviour, not just from source reputation.

NHI Mgmt Group analysis

Trusted-infrastructure abuse creates an email security blind spot. Microsoft Direct Send is not the problem by itself. The problem is that defenders often assign a lower risk score to messages that arrive through native platform paths, even when the payload is clearly adversarial. That turns trust in the delivery mechanism into a detection weakness, and the practical conclusion is that routing trust cannot be treated as content trust.

Content concealment now matters more than sender impersonation in many email attacks. QR codes and CAPTCHAs let attackers hide intent in formats that frustrate classic text and URL inspection. This does not eliminate phishing, it changes where the inspection burden sits. The field needs controls that evaluate message behaviour and user-path coercion, not only sender reputation and attachment rules.

Trusted email paths should be governed as security controls, not convenience features. When an organisation accepts native delivery paths without independent risk scoring, it creates a governance gap between platform function and security policy. That gap matters across human identity programmes because email remains a primary entry point for credential theft, consent abuse, and downstream account takeover.

Identity trust models fail when transport trust is assumed to equal user safety. Email controls that were designed around external sender filtering do not automatically protect internal or platform-native abuse. The named concept here is trusted-delivery blind spot: a condition where a legitimate mail route is treated as inherently safe even when attackers use it to deliver malicious content. Practitioners should treat that blind spot as a governance issue, not just a filter tuning problem.

Behavioural detection is becoming a control requirement, not an enhancement. The article’s emphasis on behavioural AI reflects a broader shift: static inspection alone cannot keep pace with payloads designed to evade content-based controls. For IAM and security leaders, the implication is that mail security has to be measured by what it catches after trust has already been granted, not only by what it blocks at the edge.

What this signals

Trusted-delivery blind spot: email programmes now need a named governance concept for cases where a platform-native route is treated as safe even though attackers can use it as a delivery mechanism. That is not a niche phishing problem. It is a control-design problem that affects how organisations set inspection rules, risk scoring, and escalation thresholds across their mail stack.

For practitioners, the useful shift is to stop asking only whether an email was authenticated and start asking whether the message was evaluated as hostile after trust was granted. That distinction matters because the abuse model is moving from sender impersonation to trusted-path exploitation, which makes behavioural inspection and content correlation central to effective defence.

For practitioners

• Harden trusted mail paths Classify platform-native delivery paths such as Microsoft Direct Send separately from ordinary inbound mail and apply explicit risk scoring to them.
• Detect concealed payload techniques Add detection logic for QR codes, CAPTCHA-gated links, and lookalike domains because those techniques reduce the value of text-based inspection.
• Re-evaluate secure email gateway assumptions Test whether your secure email gateway actually inspects messages that arrive through trusted infrastructure or whether it implicitly exempts them.
• Correlate email with behaviour signals Use behavioural signals from mailbox activity, link interaction, and message disposition to identify abuse that source reputation alone will miss.

Key takeaways

• Trusted email routes can become delivery paths for malicious content when controls assume the platform context is safe by default.
• The article shows that QR codes and CAPTCHAs help attackers hide payloads from traditional inspection methods.
• Security teams should validate that trusted infrastructure still receives the same content and behaviour scrutiny as ordinary inbound email.

Key terms

• Trusted-delivery blind spot: A trusted-delivery blind spot is the gap that appears when defenders assume a platform-native mail route is safe because it comes from trusted infrastructure. In practice, attackers can use that same route to deliver malicious content, so the trust decision and the inspection decision must be separated.
• Direct Send: Direct Send is a Microsoft email delivery method that can allow messages to be routed in a way that looks internal or trusted to some controls. Security teams need to understand that trusted routing does not automatically mean trusted content, especially when adversaries are abusing the path.
• Content-based email inspection: Content-based email inspection evaluates the message itself, including links, attachments, images, and behavioural cues, rather than relying only on sender reputation or transport trust. It matters most when attackers hide intent in QR codes, CAPTCHAs, or other concealment techniques that reduce the value of static filtering.
• Behavioral Detection: A monitoring approach that looks for unusual activity rather than relying only on static inventories. For SaaS integrations, it detects drift in token use, data movement, timing, and endpoint behavior so teams can spot compromise, misuse, or automation that no longer matches its expected pattern.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.