BEC-ware the Phish (part 3): Detect and Prevent Incidents in M365

TL;DR

• Take lessons learned from investigation, such as reviewing how emails evaded existing phishing controls to update anti-malware policies.  
• Configure Defender for Office and Defender for Cloud Apps threat and alert policies to prevent and detect email-based attacks. 
• Don’t rely on out-of-the-box (OOTB) configuration, use KQL to identify noisy polices and adjust rule scope or sensitivity. 

Introduction

This is the last of a three-part series (part one here, part two here) looking at effective investigation, response, and remediation to email threats in M365, with the final blog focussed on native detection and prevention options in M365.

BEC attacks typically leverage the compromise of a trusted third party to conduct a phishing attack against a partner organisation. Given that email traffic from this third-party domain is expected, phishing emails can sneak past defensive tools.  

Once a mailbox has been compromised, attackers often create inbox rules to remain undetected, often launching a new phishing campaign. Having missed the earliest detection opportunities, security teams are then alerted by the affected users noticing unexpected responses to phishing emails sent from their compromised mailbox.  

Configuring good detection and prevention policies can “raise the bar” for compromise, and alert security teams earlier in the attack chain before significant damage is done. This blog discusses a few options in M365, such as guidance on configuring threat and alert policies and how to deal with these alerts downstream in the SIEM. 

What is the role of end users in detecting phishing?

Historically, a lot of focus has been placed on users to protect their organisations from phishing. To complete anti-phishing training, and to identify and report simulated attacks. Defender for Office has a feature to implement attack simulation training.

However, a recent study on the efficacy of phishing training found no significant relationship between users that completed awareness training and their likelihood of failing a phishing simulation. Overall, it concluded that in current forms, anti-phishing training doesn’t offer any significant practical value in reducing phishing risks.

Even the most security aware user can be phished. Perhaps caught off guard, or spear-phished by an internal sender with highly relevant information obtained from a compromised mailbox.

User awareness should be considered the last line of defence.

One of the incident investigation questions should be to identify how a malicious email evaded existing email filters and use these findings to update email detection and prevention capabilities.

Update Email Protection Policies

EOP and Defender for Office protections

Mailbox protections in M365 are provided by Exchange Online Protection (EOP) or Microsoft Defender for Office 365 depending on the organisations plan. EOP customers get basic anti-phishing policies.

Figure 1: EOP stack https://learn.microsoft.com/en-us/defender-office-365/eop-about?view=o365-worldwide&viewFallbackFrom=o365-worldwide

 

1. Connection filtering checks the sender’s reputation, by enforcing an allow, block and safe list of email server IP addresses.
2. Anti-malware protection in EOP control the settings and notification options for malware detections. This includes Common attachments filter, which blocks specified file types based on leading and trailing bytes.
3. Mail flow rules (transport rules) are then evaluated in transit. The use for these rules goes beyond security but these can be effectively used to block emails based on more precise criteria.
4. Messages finally pass through anti-spam and anti-spoofing (found in anti-phishing policies) to categorise harmful messages as spam or phishing.

Defender for Office

More advanced email protections are available in Defender for Office 365 https://learn.microsoft.com/en-us/defender-office-365/protection-stack-microsoft-defender-for-office365.

Figure 2: Defender for Office stack https://learn.microsoft.com/en-us/defender-office-365/protection-stack-microsoft-defender-for-office365

 

Defender for Office Threat policies

Threat policies are the preventive controls like anti-phishing policies, safe links, safe attachments, and anti-malware.

Figure 3: Defender Threat Policies

 

Three preset security policies are available:

• Standard preset security policy
• Strict preset security policy
• Built-in protection preset security policy (default policies for Safe Attachments and Safe Links protection in Defender for Office 365)

Figure 4: Microsoft provide a configuration analyser or PowerShell module to check threat policies against recommended settings.

 

Quick wins for Email protections

Configure common attachments filter

Figure 5: Additional file types available for the common attachments filter available in Defender for Office 365. Source: https://learn.microsoft.com/en-us/defender-office-365/anti-malware-protection-about#anti-malware-policies

 

Custom mail flow rules

Can be configured in the Exchange admin center to block or restrict messages that meet defined requirements. These can be configured more granularly than simply blocking based on a file extension, with conditions and actions. Take account of variables like email subject, email origin and recipient to make decisions on whether to block, forward for approval or classify. Rules can be created in a test mode prior to deployment to test their impact.

For example, following an uptake in a particular attack vector, such as OneNote files in phishing campaigns, transport rules could be used to block OneNote attachment from external senders, or notify an admin to release the email.

Figure 6: Mail flow rule example https://learn.microsoft.com/en-us/exchange/security-and-compliance/mail-flow-rules/common-attachment-blocking-scenarios

 

Tune OOTB Defender alert policies for the environment

Unlike Threat policies, Defender for Office alert policies won’t take any direct actions but generate alerts for Defender. Out the box, alert policies are likely to generate too many alerts to review and should be tuned to suit the environment. 

Figure 7: Defender alert and threat policies

 

For example, the standard Defender for Office policy will alert each time a user reports an email as phishing. Reviewing all low and informational alerts can lead to alert fatigue, or obscure more important alerts.

Figure 8: OOTB low and informational alert policies, includes “Email reported by user as malware or phish”

 

KQL can be used to work out which alert policies generate the most alerts to focus tuning efforts.

AlertInfo
| where DetectionSource contains "Defender for Office"
| summarize count() by Title, Severity
| sort by count_ desc

Defender for Cloud Apps BEC Protections

Whilst Defender for Office protects against threats in email, links (URLS), file attachments, Cloud Apps focuses on broader M365 services like SharePoint, Teams, OneDrive as well as Exchange.

Some of the most effective Defender for Cloud Apps policies for BEC are detailed below.

Suspicious inbox manipulation rule	Inbox rules are set to move emails so that victims remain unaware of the compromise
Suspicious inbox forwarding	Anomalous forwarding rules suggests an attacker trying to exfiltrate information
Malicious OAuth app consent	Detects if a potentially malicious OAuth app that has been authorised, indicative of OAuth phishing
Malicious detection	Scans files in your cloud apps, such as files uploaded to SharePoint for known malware
Impossible travel	Detects user activities (such as logins) from geographically distant locations in a short time frame
Activity from suspicious IP addresses	Activity from IP addresses Microsoft Threat Intelligence deems risky
Activity from anonymous IP address	Activity originating from IPs associated with proxy services.
Suspicious email deletion activity (by user)	Flags suspicious email deletion activities in a single session
Unusual addition of credential to an OAuth app	Detects unusual addition of credentials to an OAuth app activities indicative of OAuth phishing
Suspicious file access activity by user	Looks for uncommon file access in SharePoint indicative of reconnaissance.

 

Most of these are anomaly detection policies which are enabled automatically, but the mysterious ‘machine-learning’ can be quite noisy.

Figure 9: Configuring Defender for Cloud App policies

 

How to maintain anomaly detection policies?

Maintaining detections like impossible travel can be a battle. These can be good at detecting AiTM frameworks since the stolen token generates login events in short succession from different locations.

Anomaly detection policies have an option to adjust the sensitivity or restrict the scope of the rule, e.g. to apply only to risky users or groups.

Cloud Apps impossible travel detection does its best to ignore obvious false positives, if you add in known VPNs Defender can ignore expected IP ranges. (Settings. Then choose Cloud Apps. Under System, select IP address ranges. Select Add IP address range to)

If all tuning attempts fail and there is no mechanism to handle alerts downstream, you might opt to replace the policy a custom rule better suited to your environment.

A SIEM (such as  Sentinel) is great for and corelating Defender’s rich visibility with Entra or third-party data sources such as web proxy logs to reduce noise For example, the following Sentinel query uses both interactive and non-interactive sign in data to detect when a sign in has occurred from an IP address that has not been observed in the last X days and is in proximity to a user’s latest sign in.

Sentinel rules can also be used to only generate incidents when an alert quantity is above a particular threshold, such as an increase in user reported phishing emails suggestive of an organisation-wide campaign.

Summary

• Users should be considered the last line of defence, but not relied upon to detect phishing attacks
• The forensic investigation should review the as reviewing how emails evaded existing phishing controls to update anti-malware policies.
• EOP protection
• Configure Defender for Office and Defender for Cloud Apps threat and alert policies to prevent and detect email-based attacks.
• Leverage KQL to identify and tune noisy alert polices by adjust rule scope or sensitivity.
• Forward alerts to Sentinel for a “single pane of glass” that takes advantage of bidirectional alert syncing with defender.