Detecting Microsoft 365 Phishing and Direct Send Abuse with Elastic

Elastic’s public detection rules offer valuable resources for defending against phishing, spoofing, and other email-based threats in Microsoft 365. While no specific rule targets Direct Send abuse out-of-the-box, Elastic’s detection engine is flexible enough to help you build powerful detections using existing rules, log data, and custom logic.

What Is Direct Send — and Why It’s a Risk?

Direct Send allows devices and applications to send email to Microsoft 365 recipients without authentication, using your organization’s domain. While useful for internal devices like printers and scanners, it’s also commonly abused by attackers to:

• Send spoofed messages that bypass SPF checks.
• Exploit misconfigured smart hosts or open relay settings.
• Impersonate internal users without authentication.
• Launch phishing or business email compromise (BEC) campaigns.

Why it matters: Monitoring and detecting this activity is essential because it bypasses standard email authentication protections like SPF, DKIM, and DMARC.

Core Elastic Detection Rules for Microsoft 365 Threats

Elastic Security includes several prebuilt rules that are highly relevant for identifying phishing, spoofing, and Direct Send abuse in Microsoft 365 environments.

1. Microsoft 365 User Restricted from Sending Email

Rule ID: bf40d000-189f-4c19-84a9-d6b04065a19a
Filename: monitoring_o365_user_restricted_from_sending_email.toml
Description: Detects when a user is restricted from sending email—commonly seen after abnormal activity such as sending bulk phishing messages.
View Rule

2. Microsoft 365 Exchange Anti-Phish Rule Modification

Rule ID: e9001ee6-2d00-4d2f-849e-b8b1fb05234c
Filename: Defense_evasion_microsoft_365_exchange_anti_phish_rule_modified.toml
Description: Triggers when anti-phishing policies are modified or disabled, often indicating pre-phishing setup by an attacker.
View Rule

3. Agent Spoofing – Multiple Hosts Using Same Agent

Rule ID: 8c7e9a83-83c4-49df-9f4f-2b230fbe1263
Filename: agent_spoofing_multiple_hosts_using_same_agent.toml
Description: Detects multiple machines reporting the same agent ID—possibly indicating spoofing, tampering, or relaying.
View Rule

4. O365 Email Reported by User as Malware or Phish

Rule ID: 5930658c-2107-4afc-91af-e0e55b7f7184
Filename: o365_email_reported_by_user_as_malware_or_phish.toml
Description: Relies on user reporting to highlight malicious emails, which can then be correlated with Direct Send characteristics (e.g., invalid SPF or spoofed sender).
View rule

5. Potential PowerShell HackTool Script by Author

Rule ID: 7d3cfcd7-d4b1-41dc-a7e3-fad60ef52e87

Filename: execution_potential_powershell_hacktool_script_by_author.toml

Description: Detects PowerShell-based hack tools—useful when correlating automated email sending from scripts or attacker toolkits.
View rule

How to Create Custom Rules for Direct Send Detection

If you’re using Direct Send or want to catch abuse of your smart host/email relay, consider these custom detection strategies:

• Monitor Received headers for external IPs spoofing internal domains.
• Alert on SPF/DKIM/DMARC failures for emails claiming to come from your own domain.
• Flag PowerShell-based or non-standard user agents in email logs.
• Detect suspicious behaviors:
  • Sender equals recipient.
  • Unusual geolocation or IP.
  • Unexpected attachments or formats.

Example KQL Rule Snippets

kql

event.dataset : "o365.audit" AND
email.sender.domain : "yourdomain.com" AND
NOT source.ip : ("your.known.ip.1", "your.known.ip.2")

kql

email.sender.address == email.recipient.address AND
user_agent : "PowerShell"

These custom queries can help detect signs of spoofing, automation abuse, or misused relay systems.

Going Beyond Detection: Response and Hardening Tips

Detection is only one piece of the puzzle. Here’s how to bolster your defenses:

• Review and restrict Direct Send configurations — only allow trusted IPs to relay.
• Use Authenticated SMTP or Graph API where possible.
• Enforce SPF/DKIM/DMARC policies with “reject” or “quarantine.”
• Enable Microsoft 365 user-reporting integration for phishing.
• Correlate alerts using Elastic Case Management or SOAR platforms.

Summary Table: Key Rules and Detection Approaches

Detection Type	Description	Ref
Microsoft 365 User Restricted from Sending Email	Detects suspicious bulk sending behavior	Link
Exchange Anti-Phish Rule Modification	Indicates pre-attack policy tampering	Link
Agent Spoofing – Same Agent on Multiple Hosts	Possible automation/spoofing activity	Link
O365 Email Reported as Phish by User	User-driven alert on malicious content	Link
PowerShell HackTool Activity Detected	Detects malicious scripting attempts in delivery vectors	Link

MITRE ATT&CK Alignment

The detection techniques outlined in this blog align closely with several tactics and techniques from the MITRE ATT&CK framework, particularly within the Enterprise matrix. For example, phishing and Direct Send abuse relate to Initial Access (T1566.001 – Phishing: Spearphishing Attachment) and Defense Evasion (T1110 – Brute Force / T1556 – Modify Authentication Process). Modifying anti-phishing rules or using spoofed agent IDs also touches on Persistence and Privilege Escalation techniques. Mapping your Elastic detection rules to MITRE ATT&CK helps ensure threat coverage, facilitates adversary emulation exercises, and supports structured threat hunting workflows.

Why Should We Care?

Direct Send abuse isn’t theoretical — it’s happening right now. Threat actors actively leverage misconfigured smart hosts and relay permissions in Microsoft 365 to send spoofed emails that bypass authentication checks like SPF, DKIM, and DMARC. These messages appear to come from internal domains, making them incredibly effective in phishing, business email compromise (BEC), and ransomware delivery.

How It’s Being Exploited

• Initial foothold: Attackers use Direct Send to distribute phishing lures with malicious links or attachments, often as part of broader Initial Access operations.
• Lateral movement & persistence: Once credentials are harvested, adversaries modify anti-phishing policies, disable rules, or inject spoofed traffic for command and control.
• Automation abuse: Scripted tools — often leveraging PowerShell or open-source mailers — automate delivery of messages at scale, blending into normal traffic.

Threat Actor Examples

• FIN7 and other financially motivated groups have used spoofed internal emails in BEC scams to defraud organizations of millions.
• APT29 (Cozy Bear) and similar espionage-focused actors have employed email delivery tactics (including relays and Direct Send-style infrastructure) to phish targets while avoiding perimeter defenses.
• Ransomware affiliates, including those aligned with Conti, LockBit, and BlackCat, have used spoofed executive emails to trick internal users into launching payloads or sharing credentials.

Bottom Line

Without monitoring and detection around Direct Send behaviors, organizations leave a blind spot open in their Microsoft 365 infrastructure. By aligning Elastic detection rules with MITRE ATT&CK and focusing on both known tactics and behavioral anomalies, security teams can close this gap — before attackers exploit it.