P
Pete Bryan
Business Email Compromise (BEC) attacks continue to be some of the most prevalent and costly attacks facing organizations worldwide. Between April 2022 and April 2023, Microsoft Threat Intelligence detected and investigated 35 million BEC attempts with an adjusted average of 156,000 attempts daily[1]. In just the last 30 days we have observed potential BEC attack related activity in over 150 customers.
Microsoft 365 Defender has comprehensive prevention, detection, and disruption options for BEC attacks across Microsoft’s products and solutions. Using Microsoft Sentinel’s ability to collect data across all users, devices, applications, and infrastructure, both on-premises and in multiple clouds, we have now extended this level of detection and response to areas outside of Microsoft’s own platforms and to where your organization operates.
Our recently released Solution for Business Email Compromise - Financial Fraud provides detection and hunting content to allow you to detect and respond to BEC threats at multiple stages of the attack cycle. In this blog we will discuss each stage of this cycle and how the Solution combines with Microsoft 365 Defender (M365D) to provide comprehensive coverage. To cover this scenario as fully as possible there are 21 Analytic Templates and 19 Hunting Queries across a range of data sources.
The Microsoft Sentinel Solution
The Attack Cycle
The Attack Chain
Stage 1 – Credential Access
Credential theft via phishing is one of the most common ways in which an attacker gains access to an environment to conduct BEC attacks. Microsoft 365 Defender has a wide range of coverage for phishing attacks including detection of phishing emails being delivered to users, as well as detection of users clicking on those links from managed devices. Using Microsoft Sentinel’s ability to integrate logs from network devices we have extended this coverage to include instances where a user clicks on a URL in a phishing email from an un-managed device on your network.
Analytic Templates:
Possible Phishing with CSL and Network Sessions
Phishing link click observed in Network Traffic
Stage 2 – Initial Access
Once an attacker has stolen user credentials, they can use this to access your environment. Azure Active Directory has a comprehensive set of security controls and detection options to prevent and detect unauthorized authentication attempts. We have further extended these in Microsoft Sentinel through combining these signals with UEBA signals from a user's environment to provide enriched detection and hunting options. In addition, we have extended the detection capability for this stage to cover sign in events for Okta for those organizations using Okta as their authentication provider.
Analytic Templates:
Okta Fast Pass phishing Detection
MFA Rejected by User
User Accounts - Sign in Failure due to CA Spikes
Sign-ins from IPs that attempt sign-ins to disabled accounts
M365D Alerts Correlation to non-Microsoft Network device network activity involved in successful sign-in Activity
Hunting Queries:
Login attempts using Legacy Auth
Successful Signin From Non-Compliant Device
User Accounts - New Single Factor Auth
User Accounts - Unusual authentications occurring when countries do not conduct normal business operations.
User Login IP Address Teleportation
Azure Active Directory signins from new locations
User Accounts - Unusual authentications occurring when countries do not conduct normal business operations.
Sign-ins From VPS Providers
Sign-ins from Nord VPN Providers
Suspicious Sign-ins to Privileged Account
Stage 3 – Defense Evasion
As well as needing credentials to log in an attacker also need to bypass other controls such as Multi-Factor Authentication (MFA). A common technique observed recently is to generate multiple MFA requests in the hope that a user will approve a request. To supplement Microsoft 365 Defenders coverage of this attack stage on Azure Active Directory, we have extended detection of such attacks to Okta to provide coverage across multiple identity providers.
Analytic Templates:
MFA Fatigue (OKTA)
MFA Rejected by User
Stage 4 – Persistence
Once an attacker has access to an environment its common for the next action, they take is to establish persistent access. Often what we observe with BEC attacks is the registration of a new MFA method to provide an MFA method that that attacker controls. Our Microsoft Sentinel content helps identify suspicious account changes that relate to MFA method modifications and extends this coverage to include Okta.
Analytic Templates:
Device Registration from Malicious IP
High-Risk Admin Activity
New Device/Location sign-in along with critical operation
Account Elevated to New Role
Authentication Method Changed for Privileged Account
Privileged Account Permissions Changed
User Added to Admin Role
User Assigned Privileged Role
User added to Azure Active Directory Privileged Groups
Hunting Queries:
New device registration from unfamiliar location
Risky Sign-in with new MFA method
User detection added to privilege groups based in Watchlist
Stages 5 & 6 – Discovery & Collection
Before being able to have a conduct a successful BEC attack the threat actor needs to understand the payment and invoice processes of the target organization including identifying currently open invoices, key personnel, and potential debtors. We have created a set of content that looks for attackers searching for and accessing documents associated with financial process and that we have observed BEC attackers commonly attempting to access. To leverage Microsoft Sentinel’s ability to ingest and process logs from a wide range of sources this content is applicable to a number of common documents and data sources including Microsoft 365, Azure Storage, AWS S3, Dynamics 365 and SAP systems.
Analytic Templates:
Suspicious access of BEC related documents in AWS S3 buckets
Suspicious access of BEC related documents
Hunting Queries:
S3 Bucket outbound Data transfer anomaly
Suspicious Data Access to S3 Bucket from Unknown IP
Email Forwarding Configuration with SAP download
High count download from a SAP Privileged account
Additional Dynamics 365 Analytic Templates related to these stages will be released as part of an upcoming premium Dynamics 365 solution.
Stage 7 & 8 – Defense Evasion & Collection
Before launching the final BEC attack threat actors often take steps to hide their activity from target organizations. The most common steps taken involve the creation of mailbox rules that look for specific keywords or email chains and forward, and then move emails. This provides the threat actor ongoing access to the emails whilst also preventing the targeted organization for easily observing the emails associated with BEC attack. We have Microsoft Sentinel content that helps identify the creation of such mailbox rules within Microsoft 365.
Detections:
Malicious BEC Inbox Rule
Malicious Inbox Rule
Mail redirect via ExO transport rule
Hunting Queries:
Office Mail Forwarding - Hunting Version
Office Mail Rule Creation with suspicious archive mail move activity
Stage 9 - Impact
Once the threat actor has completed all the preparatory steps, they can launch the BEC attack itself by sending emails requesting payment with updated payment details, or by requesting updates to payroll information. M365D provides comprehensive detection of this stage of BEC attacks. The integration of Microsoft Sentinel with M365D brings together these detections with the content covering the rest of the attack chain to give analysts a complete end to end view of the attack.
How to use this content
The Microsoft Sentinel content needed to detect each stage of this attack cycle is made up of new and existing content. As such some of the content appears in the new BEC solution, whilst others appear in other data source specific solutions. To access all the content, you will need to install all the associated solutions.
Depending on the configuration of an environment and the technologies used not all of this content may be relevant to all environments. As such only the relevant content should be deployed. In addition, the analytic templates can be further scoped and refined by limiting some of the scope of some queries to specific users accounts, hosts, or IP addresses specific to an environment or organization.
You can also choose to create an analytic that brings together the various stages of the attack chain into an overall BEC Financial Fraud Incident. It is recommended that you create this using the specific analytic templates deployed in your environment. Below is an example of a KQL query to do this:
let credential_access_tempaltes = dynamic(["6c3a1258-bcdd-4fcd-b753-1a9bc826ce12", "2fed0668-6d43-4c78-87e6-510f96f12145"]);
let initial_access_tempaltes = dynamic(["78d2b06c-8dc0-40e1-91c8-66d916c186f3", "d99cf5c3-d660-436c-895b-8a8f8448da23", "3a9d5ede-2b9d-43a2-acc4-d272321ff77c", "500c103a-0319-4d56-8e99-3cec8d860757", "779731f7-8ba0-4198-8524-5701b7defddc"]);
let defense_evasion_templates = dynamic(["c2697b81-7fe9-4f57-ba1d-de46c6f91f9c", "d99cf5c3-d660-436c-895b-8a8f8448da23"]);
let persistence_templates = dynamic(["e36c6bd6-f86a-4282-93a5-b4a1b48dd849", "9f82a735-ae43-4c03-afb4-d5d153e1ace1", "41e843a8-92e7-444d-8d72-638f1145d1e1", "c1c66f0b-5531-4a3e-a619-9d2f770ef730", "694c91ee-d606-4ba9-928e-405a2dd0ff0f", "0433c8a3-9aa6-4577-beef-2ea23be41137", "2a09f8cb-deb7-4c40-b08b-9137667f1c0b", "050b9b3d-53d0-4364-a3da-1b678b8211ec", "4d94d4a9-dc96-410a-8dea-4d4d4584188b"]);
let discovery_templates = dynamic(["f3e2d35f-1202-4215-995c-4654ef07d1d8", ""]);
let collection_templates = dynamic(["8ac77493-3cae-4840-8634-15fb23f8fb68", "7b907bf7-77d4-41d0-a208-5643ff75bf9a", "9891684a-1e3a-4546-9403-3439513cbc70"]);
// materialize our base Alert collection rule for performance
let Alerts = materialize(SecurityAlert
| where ProviderName == "ASI Scheduled Alerts"
// extend out the Analaytic Template ID to match on
| extend AnalyticRuleIds = parse_json(ExtendedProperties).["Analytic Rule Ids"]
// extend out Entities to join on
| extend Entities = parse_json(Entities)
| mv-expand Entities
| extend Entity = tostring(Entities)
// strip out $id which may vary across alerts for the same entity, can't use bag_remove_key due to $ in $id
| extend Entity = substring(Entity, 11));
Alerts
| where AnalyticRuleIds has_any (credential_access_tempaltes)
| join kind=inner (Alerts | where AnalyticRuleIds has_any(initial_access_tempaltes)) on Entity
| join kind=inner (Alerts | where AnalyticRuleIds has_any(defense_evasion_templates)) on Entity
| join kind=inner (Alerts | where AnalyticRuleIds has_any(persistence_templates)) on Entity
| join kind=inner (Alerts | where AnalyticRuleIds has_any(discovery_templates)) on Entity
| join kind=inner (Alerts | where AnalyticRuleIds has_any(collection_templates)) on Entity
Automating your response with SOAR
You can also use Microsoft Sentinel’s SOAR capabilities to automatically respond to specific attack phases. Below is a suggested matrix of Analytic Rules to SOAR playbooks that should be considered:
Other BEC Attacks
BEC attacks are varied in nature and can take many different paths and forms. This solution aims to provide coverage in key areas for some of the most common attack patterns observed. However, there are many other areas where coverage may be required to address every angle. One example is the modification of an Azure tenant preceding launching attacks against other organizations, such as by the creation of a new domain from which to send phishing emails from. We recommend reviewing the entire catalog of Microsoft Sentinel Analytics and Hunting Queries to identify content that is relevant to your environment and threat model.
[1] Cyber Signals: Shifting tactics show surge in business email compromise | Microsoft Security Blog
Continue reading...
Microsoft 365 Defender has comprehensive prevention, detection, and disruption options for BEC attacks across Microsoft’s products and solutions. Using Microsoft Sentinel’s ability to collect data across all users, devices, applications, and infrastructure, both on-premises and in multiple clouds, we have now extended this level of detection and response to areas outside of Microsoft’s own platforms and to where your organization operates.
Our recently released Solution for Business Email Compromise - Financial Fraud provides detection and hunting content to allow you to detect and respond to BEC threats at multiple stages of the attack cycle. In this blog we will discuss each stage of this cycle and how the Solution combines with Microsoft 365 Defender (M365D) to provide comprehensive coverage. To cover this scenario as fully as possible there are 21 Analytic Templates and 19 Hunting Queries across a range of data sources.
The Microsoft Sentinel SolutionThe Attack Cycle
The Attack ChainStage 1 – Credential Access
Credential theft via phishing is one of the most common ways in which an attacker gains access to an environment to conduct BEC attacks. Microsoft 365 Defender has a wide range of coverage for phishing attacks including detection of phishing emails being delivered to users, as well as detection of users clicking on those links from managed devices. Using Microsoft Sentinel’s ability to integrate logs from network devices we have extended this coverage to include instances where a user clicks on a URL in a phishing email from an un-managed device on your network.
Analytic Templates:
Possible Phishing with CSL and Network Sessions
Phishing link click observed in Network Traffic
Stage 2 – Initial Access
Once an attacker has stolen user credentials, they can use this to access your environment. Azure Active Directory has a comprehensive set of security controls and detection options to prevent and detect unauthorized authentication attempts. We have further extended these in Microsoft Sentinel through combining these signals with UEBA signals from a user's environment to provide enriched detection and hunting options. In addition, we have extended the detection capability for this stage to cover sign in events for Okta for those organizations using Okta as their authentication provider.
Analytic Templates:
Okta Fast Pass phishing Detection
MFA Rejected by User
User Accounts - Sign in Failure due to CA Spikes
Sign-ins from IPs that attempt sign-ins to disabled accounts
M365D Alerts Correlation to non-Microsoft Network device network activity involved in successful sign-in Activity
Hunting Queries:
Login attempts using Legacy Auth
Successful Signin From Non-Compliant Device
User Accounts - New Single Factor Auth
User Accounts - Unusual authentications occurring when countries do not conduct normal business operations.
User Login IP Address Teleportation
Azure Active Directory signins from new locations
User Accounts - Unusual authentications occurring when countries do not conduct normal business operations.
Sign-ins From VPS Providers
Sign-ins from Nord VPN Providers
Suspicious Sign-ins to Privileged Account
Stage 3 – Defense Evasion
As well as needing credentials to log in an attacker also need to bypass other controls such as Multi-Factor Authentication (MFA). A common technique observed recently is to generate multiple MFA requests in the hope that a user will approve a request. To supplement Microsoft 365 Defenders coverage of this attack stage on Azure Active Directory, we have extended detection of such attacks to Okta to provide coverage across multiple identity providers.
Analytic Templates:
MFA Fatigue (OKTA)
MFA Rejected by User
Stage 4 – Persistence
Once an attacker has access to an environment its common for the next action, they take is to establish persistent access. Often what we observe with BEC attacks is the registration of a new MFA method to provide an MFA method that that attacker controls. Our Microsoft Sentinel content helps identify suspicious account changes that relate to MFA method modifications and extends this coverage to include Okta.
Analytic Templates:
Device Registration from Malicious IP
High-Risk Admin Activity
New Device/Location sign-in along with critical operation
Account Elevated to New Role
Authentication Method Changed for Privileged Account
Privileged Account Permissions Changed
User Added to Admin Role
User Assigned Privileged Role
User added to Azure Active Directory Privileged Groups
Hunting Queries:
New device registration from unfamiliar location
Risky Sign-in with new MFA method
User detection added to privilege groups based in Watchlist
Stages 5 & 6 – Discovery & Collection
Before being able to have a conduct a successful BEC attack the threat actor needs to understand the payment and invoice processes of the target organization including identifying currently open invoices, key personnel, and potential debtors. We have created a set of content that looks for attackers searching for and accessing documents associated with financial process and that we have observed BEC attackers commonly attempting to access. To leverage Microsoft Sentinel’s ability to ingest and process logs from a wide range of sources this content is applicable to a number of common documents and data sources including Microsoft 365, Azure Storage, AWS S3, Dynamics 365 and SAP systems.
Analytic Templates:
Suspicious access of BEC related documents in AWS S3 buckets
Suspicious access of BEC related documents
Hunting Queries:
S3 Bucket outbound Data transfer anomaly
Suspicious Data Access to S3 Bucket from Unknown IP
Email Forwarding Configuration with SAP download
High count download from a SAP Privileged account
Additional Dynamics 365 Analytic Templates related to these stages will be released as part of an upcoming premium Dynamics 365 solution.
Stage 7 & 8 – Defense Evasion & Collection
Before launching the final BEC attack threat actors often take steps to hide their activity from target organizations. The most common steps taken involve the creation of mailbox rules that look for specific keywords or email chains and forward, and then move emails. This provides the threat actor ongoing access to the emails whilst also preventing the targeted organization for easily observing the emails associated with BEC attack. We have Microsoft Sentinel content that helps identify the creation of such mailbox rules within Microsoft 365.
Detections:
Malicious BEC Inbox Rule
Malicious Inbox Rule
Mail redirect via ExO transport rule
Hunting Queries:
Office Mail Forwarding - Hunting Version
Office Mail Rule Creation with suspicious archive mail move activity
Stage 9 - Impact
Once the threat actor has completed all the preparatory steps, they can launch the BEC attack itself by sending emails requesting payment with updated payment details, or by requesting updates to payroll information. M365D provides comprehensive detection of this stage of BEC attacks. The integration of Microsoft Sentinel with M365D brings together these detections with the content covering the rest of the attack chain to give analysts a complete end to end view of the attack.
How to use this content
The Microsoft Sentinel content needed to detect each stage of this attack cycle is made up of new and existing content. As such some of the content appears in the new BEC solution, whilst others appear in other data source specific solutions. To access all the content, you will need to install all the associated solutions.
Depending on the configuration of an environment and the technologies used not all of this content may be relevant to all environments. As such only the relevant content should be deployed. In addition, the analytic templates can be further scoped and refined by limiting some of the scope of some queries to specific users accounts, hosts, or IP addresses specific to an environment or organization.
You can also choose to create an analytic that brings together the various stages of the attack chain into an overall BEC Financial Fraud Incident. It is recommended that you create this using the specific analytic templates deployed in your environment. Below is an example of a KQL query to do this:
let credential_access_tempaltes = dynamic(["6c3a1258-bcdd-4fcd-b753-1a9bc826ce12", "2fed0668-6d43-4c78-87e6-510f96f12145"]);
let initial_access_tempaltes = dynamic(["78d2b06c-8dc0-40e1-91c8-66d916c186f3", "d99cf5c3-d660-436c-895b-8a8f8448da23", "3a9d5ede-2b9d-43a2-acc4-d272321ff77c", "500c103a-0319-4d56-8e99-3cec8d860757", "779731f7-8ba0-4198-8524-5701b7defddc"]);
let defense_evasion_templates = dynamic(["c2697b81-7fe9-4f57-ba1d-de46c6f91f9c", "d99cf5c3-d660-436c-895b-8a8f8448da23"]);
let persistence_templates = dynamic(["e36c6bd6-f86a-4282-93a5-b4a1b48dd849", "9f82a735-ae43-4c03-afb4-d5d153e1ace1", "41e843a8-92e7-444d-8d72-638f1145d1e1", "c1c66f0b-5531-4a3e-a619-9d2f770ef730", "694c91ee-d606-4ba9-928e-405a2dd0ff0f", "0433c8a3-9aa6-4577-beef-2ea23be41137", "2a09f8cb-deb7-4c40-b08b-9137667f1c0b", "050b9b3d-53d0-4364-a3da-1b678b8211ec", "4d94d4a9-dc96-410a-8dea-4d4d4584188b"]);
let discovery_templates = dynamic(["f3e2d35f-1202-4215-995c-4654ef07d1d8", ""]);
let collection_templates = dynamic(["8ac77493-3cae-4840-8634-15fb23f8fb68", "7b907bf7-77d4-41d0-a208-5643ff75bf9a", "9891684a-1e3a-4546-9403-3439513cbc70"]);
// materialize our base Alert collection rule for performance
let Alerts = materialize(SecurityAlert
| where ProviderName == "ASI Scheduled Alerts"
// extend out the Analaytic Template ID to match on
| extend AnalyticRuleIds = parse_json(ExtendedProperties).["Analytic Rule Ids"]
// extend out Entities to join on
| extend Entities = parse_json(Entities)
| mv-expand Entities
| extend Entity = tostring(Entities)
// strip out $id which may vary across alerts for the same entity, can't use bag_remove_key due to $ in $id
| extend Entity = substring(Entity, 11));
Alerts
| where AnalyticRuleIds has_any (credential_access_tempaltes)
| join kind=inner (Alerts | where AnalyticRuleIds has_any(initial_access_tempaltes)) on Entity
| join kind=inner (Alerts | where AnalyticRuleIds has_any(defense_evasion_templates)) on Entity
| join kind=inner (Alerts | where AnalyticRuleIds has_any(persistence_templates)) on Entity
| join kind=inner (Alerts | where AnalyticRuleIds has_any(discovery_templates)) on Entity
| join kind=inner (Alerts | where AnalyticRuleIds has_any(collection_templates)) on Entity
Automating your response with SOAR
You can also use Microsoft Sentinel’s SOAR capabilities to automatically respond to specific attack phases. Below is a suggested matrix of Analytic Rules to SOAR playbooks that should be considered:
Analytic Template | SOAR Playbook |
Other BEC Attacks
BEC attacks are varied in nature and can take many different paths and forms. This solution aims to provide coverage in key areas for some of the most common attack patterns observed. However, there are many other areas where coverage may be required to address every angle. One example is the modification of an Azure tenant preceding launching attacks against other organizations, such as by the creation of a new domain from which to send phishing emails from. We recommend reviewing the entire catalog of Microsoft Sentinel Analytics and Hunting Queries to identify content that is relevant to your environment and threat model.
[1] Cyber Signals: Shifting tactics show surge in business email compromise | Microsoft Security Blog
Continue reading...