Business Email Compromise Detection

Key Points

• ReliaQuest has observed 246% more business email compromise (BEC) attempts over the past year; this highlights the growing risk of fraud or other damage caused by cyber attacks, relevant to all sectors and countries.
• We have developed an advanced detection approach for organizations to identify and counter BEC, surpassing traditional methods by dynamically identifying anomalies.
• Our targeted approach includes advanced correlation techniques, including Kusto Query Language (KQL) queries; visualized authentication sequences; and session replays linked to suspicious activities.
• BEC attacks will almost certainly intensify through 2024, as threat actors increasingly use generative AI and sophisticated phishing kits to evade such defenses as two-factor authentication (2FA).
• To reinforce the detection strategies described in this report, we recommend that organizations shield against BEC by securing administrative accounts, enforcing strict location-based access, adopting advanced multifactor authentication (MFA) and regularly refining access policies.

The compromise of an employee’s email account, to defraud the company or launch more attacks, presents a growing threat to all sectors and countries. ReliaQuest has observed 246% more BEC attempts over the past year (See Figure 1), likely because phishing kits tailored for BEC have become more available, as have stolen account credentials leaked on criminal marketplaces. More than 36 billion credentials have been leaked, including more than 6 billion over the past year alone.

Figure 1: BEC attack attempts on ReliaQuest customers, by detection type (February 2023–24)

BEC can lead to significant financial losses and extend beyond fraud by allowing unauthorized access to critical services, such as VPNs and single sign-on (SSO) applications. With the right detection strategies, organizations can protect themselves from stealthy BEC attacks. This report explains how to reinforce businesses’ cyber defenses by moving beyond traditional detection practices, which have limited potential to catch all BEC attempts.

Traditional Detection Practices in Review

The stealthy nature of BEC leads to it often going unnoticed until the damage is done. Although useful for identifying known threats, traditional detection practices are less effective against sophisticated attackers who continuously adapt their strategies. For example, static detection relies on spotting anomalies, such as email rules with unexpected names or actions. But attackers are using techniques that mimic expected and legitimate activities, making them harder to detect and leading to potential security breaches.

Case Study: Defense Evasion

Not only are there more means to conduct BEC, but threat actors are also becoming increasingly aware of organizations’ security measures—and finding ways to evade them. In a BEC attack we analyzed this year, a threat actor posed as an employee of a ReliaQuest customer and created an email rule in the employee’s Outlook account. When we flagged the action as suspicious to the client’s security team, the “employee” then claimed it was intentional. Despite the claim, we recommended the customer to communicate with the employee through a different channel, which confirmed the activity was malicious.

Static Detection Falls Short

Static detection operates on a set of unchanging rules or signatures to identify malicious activities, which is akin to using an outdated map in a constantly changing landscape. Attackers can easily bypass such a detection approach. For example, an adversary stealthily taking over a company’s email system can name rules and folders to mimic legitimate ones and slip past the usual static detections.

Attackers have also learned to alter their strategies to circumvent static defenses, making those defenses less reliable. Static detection measures remain valuable, but organizations must be agile in detection approach, and attempt to focus on the variability of techniques rather than arbitrary technique implementation. For instance, a rule designed to detect “powershell -encoded” must also consider variations, such as “powershell -enc”, to enhance threat visibility.

Below are some common examples of email anomaly detection rules:

Email Rule Names: 

• Single-character rule names (e.g., “a”, “.”)
• Repeated-character rule names: (e.g., “..”, “eeeeeee”)

Email Rule Actions:

• A message is moved to an uncommonly used folder (e.g., Rss-Feeds, Conversation History)
• Certain actions are performed, including: messages being marked as “read,” all emails are deleted, other inbox rules are blocked, etc.

Email Rule Properties: 

• A search is initiated to find sensitive keywords in message subjects or body text (e.g., invoice, statement, bank)
• Security alerts are filtered, which would have alerted a user of account compromise (e.g., spam;alert;security;hack;hacked;phish)

Microsoft Authentication: A Gateway to Session Compromise

Microsoft’s session management for cloud application services presents vulnerabilities that BEC operators can exploit. Sessions can persist for extended periods, which is convenient for users but presents a risk if an attacker gains access to a session token or cookie, allowing them to conduct operations unnoticed.

The two applications most commonly observed as the initial point of a compromise are Outlook Web App and Microsoft Entra ID, which is used by Office and Microsoft 365 applications. These applications have varying session timeout lengths (by default), as shown in the table below.

Microsoft Service	Default Session Timeout
Outlook Web App	6 hours (can be reconfigured by modifying the ActivityBasedAuthenticationTimeoutInterval parameter)
Microsoft Entra ID	Initial JSON Web Token (JWT) is valid for 1 hour and a refresh token is also provided, which is valid for 90 days and extended by continuous use; both are valid until revoked

Sessions originating from token and cookie theft represent a risk for organizations if the sessions do not time out within a reasonable amount of time (8-9 hours, or a full working day). This can be challenging for organizations, as mitigating by restricting session length may annoy or inconvenience legitimate users and impede productivity.

Advanced BEC Detection

Advanced correlation and the analysis of authentication sequences can be used to combat sophisticated BEC threats. This includes using KQL for intricate session analysis and anomaly detection. Below we describe that suggested approach, along with two others that can form a comprehensive defense against BEC by enhancing the fidelity of detections.

Advanced Correlation

Suggestion: Use KQL to correlate session IDs with authentication flows, to identify anomalies like sessions with varying IP addresses or user agents.

Benefit: Tools like KQL make it possible to detect suspicious patterns that indicate a compromised session.

Example:

let timeSpan = 5m;
let KmsiEvents = AADSignInEventsBeta
| where EndpointCall == "Kmsi:kmsi"
| where IPAddress matches regex @"^\d{1,3}(\.\d{1,3}){3}$"
| project SessionId, AccountUpn,AccountObjectId,EndpointCall,IPAddress,Timestamp;
let ReprocessEvents = AADSignInEventsBeta
| where EndpointCall == "Login:reprocess"
| where IPAddress matches regex @"^\d{1,3}(\.\d{1,3}){3}$"
| project SessionId, AccountUpn,AccountObjectId,EndpointCall2=EndpointCall, IPAddress2 = IPAddress, Timestamp2 = Timestamp;
KmsiEvents
| join kind=inner ReprocessEvents on SessionId
| where IPAddress != IPAddress2
| where Timestamp <= Timestamp2 and Timestamp2 <= Timestamp + timeSpan
| project SessionId, AccountUpn, AccountObjectId,IPAddress, EndpointCall, Timestamp, IPAddress2, EndpointCall2, Timestamp2;

Query 1- Search for anomalous session re-use

The example above uses the AADSignInEventsBeta table for querying. To correlate Session IDs with various authentication flow types with this method, an organization must have a Microsoft Entra ID P2 license. This license gives a tenant beta access to the AADSignInEventsBeta table. Eventually, all sign-in schema will migrate to IdentityLogonEvents, but currently this is a limiting factor in being able to hunt for anomalies using these specific data fields.

Authentication Sequence Analysis

Suggestion: Depict authentication sequences visually to discern attack patterns. This approach is invaluable for spotting when a legitimate MFA request is hijacked, indicated by such anomalies as sessions originating from an unusual IP address. This is a hallmark of a malicious session replay—by an attacker using stolen credentials.

Benefit: Visually depicted authentication sequences helps analysts scrutinize them for suspicious activity, and can be vital for safeguarding against unauthorized access

Example:

Figure 2: Anomalous flow example

The screenshot above clearly shows an inflection point at which the same session token was replayed from vastly different IP addresses and user-agent strings.

False positives, such as those generated by corporate proxies, can obscure such indicators. However, with precise KQL filtering, defenders can refine detection parameters to focus on genuine threats, improving the accuracy of analytics.

Session Replay Links to Suspicious Activities

Suggestion: Correlate session replay query results with other observable indicators of suspicious activity, such as the creation of inbox rules or modifications to MFA settings.

Benefit: By linking session replay data to other indicators of compromise, potential security incidents are more likely to trigger alerts, strengthening enabling more accurate and timely responses to potential security incidents.

Example: The following query feeds the result of a potential session replay into the CloudAppEvents table to identify instances of high-risk activity by users with suspicious sessions; this strategy upgrades a moderate-fidelity detection to produce a higher-fidelity signal.

let timeSpan = 5m;
let KmsiEvents = AADSignInEventsBeta
| where EndpointCall == "Kmsi:kmsi"
| where IPAddress matches regex @"^\d{1,3}(\.\d{1,3}){3}$"
| project SessionId, AccountUpn,AccountObjectId,EndpointCall,IPAddress,Timestamp;
let ReprocessEvents = AADSignInEventsBeta
| where EndpointCall == "Login:reprocess"
| where IPAddress matches regex @"^\d{1,3}(\.\d{1,3}){3}$"
| project SessionId, AccountUpn,AccountObjectId,EndpointCall2=EndpointCall, IPAddress2 = IPAddress, Timestamp2 = Timestamp;
let JoinedEvents = KmsiEvents
| join kind=inner ReprocessEvents on SessionId
| where IPAddress != IPAddress2
| where Timestamp <= Timestamp2 and Timestamp2 <= Timestamp + timeSpan
| project SessionId, AccountUpn, AccountObjectId,IPAddress, EndpointCall, Timestamp, IPAddress2, EndpointCall2, Timestamp2;
let DistinctAccountObjects = JoinedEvents
| distinct AccountObjectId;
CloudAppEvents
| where AccountObjectId in (DistinctAccountObjects)
| where ObjectName == "New-InboxRule"

Query 2 – Correlates an anomalous session to Inbox rule creation

Targeting False Positives

In this section, we discuss the complexities of simple session tracking in dynamic IP environments and the importance of a targeted approach in identifying a truly anomalous session amid common false positives. We’ll examine the impacts of network behavior on session tracking and how focusing on authentication endpoints can significantly refine the detection process in cloud applications.

Oversimplified Session Tracking

Tracked instances of an IP address of a session ID changing within the same session typically account for a substantial portion of authentication logs. This is owing to the nature of OAuth

Common scenarios in which an authenticated user may legitimately change their IP address include:

• Network changes: The user may change networks during a single session. For example, if a user starts a session at their office on the corporate network and then moves to a coffee shop and continues their session on public Wi-Fi, the IP address will change.
• VPN use: Users may connect to or disconnect from a VPN service during a session. VPNs can assign a different IP address each time they are connected.
• Mobile network use: If the user is on a mobile device, moving between cell towers or switching from Wi-Fi to mobile data (or vice-versa) can cause the IP address to change. A common false positive is triggered by Apple’s iCloud Relay system, which can generate a temporary IP address for every HTTP request.
• Load balancers and proxy use: Sometimes, corporate networks or internet service providers (ISPs) route traffic through load balancers or proxy servers, which can result in the user appearing to have different IP addresses.
• IP address renewal: Dynamic Host Configuration Protocol (DHCP) can cause a device to get a new IP address if the lease expires and a new address is assigned.
• Travel: A user traveling among different locations (such as the branches of an organization) may acquire different IP addresses as they connect from different places.

It’s important to take these into account when developing a detection strategy. Software-as-a-service (SaaS) platforms that use token-based authentication will typically account for common false positives, such as mobile networks, corporate VPNs, and corporate proxies. But organizations should take ownership and proactively manage their identity and access systems, as a critical component in safeguarding the enterprise.

A More Targeted Approach

As outlined earlier in this report, our alternative to identifying anomalous sessions is specifically evaluating the authentication endpoints being requested (rather than just looking at sessions with multiple IP address assignments). As an example, the following query results in reaching the log output cap and will likely use a large portion of search quotas:

let timeSpan = 5m;
let KmsiEvents = AADSignInEventsBeta
| where Timestamp > ago(24h)
| where IPAddress matches regex @"^\d{1,3}(\.\d{1,3}){3}$"
| project SessionId, AccountUpn,AccountObjectId,EndpointCall,IPAddress,Timestamp;
let ReprocessEvents = AADSignInEventsBeta
| where Timestamp > ago(24h)
| where IPAddress matches regex @"^\d{1,3}(\.\d{1,3}){3}$"
| project SessionId, AccountUpn,AccountObjectId,EndpointCall2=EndpointCall, IPAddress2 = IPAddress, Timestamp2 = Timestamp;
KmsiEvents
| where Timestamp > ago(24h)
| join kind=inner ReprocessEvents on SessionId
| where IPAddress != IPAddress2
| where Timestamp <= Timestamp2 and Timestamp2 <= Timestamp + timeSpan
| project SessionId, AccountUpn, AccountObjectId,IPAddress, EndpointCall, Timestamp, IPAddress2, EndpointCall2, Timestamp2;

Query 3 – Identifies a session ID that has two different IP addresses

This query uses the same base logic as Query 1, with the exception of removing the authentication endpoint call component. In general, only using disparate IP addresses within a single session can generate false positive alerts, especially for large enterprises that use multiple network appliances (e.g., VPN, load balancers, proxies). However, when accounting for specific authentication endpoints, we reduced log outputs significantly, down to a few dozen within a large enterprise environment.

Threat Forecast

We predict that BEC attack attempts will continue to escalate throughout 2024. The US FBI reported adjusted losses of over $2.9 billion connected to BEC in 2023, and we expect that number to exceed $3 billion in 2024. The BEC threat is strengthened by threat actors using new technologies, such as generative AI (GenAI), to facilitate BEC, and by an ever-lower barrier of entry for nascent BEC operators: Phishing kits and other BEC attack tools are widely available on dark-web platforms, such as the W3LL Store. Some kits can bypass 2FA and employ adversary-in-the-middle (AITM) techniques with a high level of automation. It’s crucial for companies to understand these evolving threats and implement detection rules that prevent unauthorized access or raise alerts of malicious activity.

What ReliaQuest Is Doing

In addition to the steps described in this blog, ReliaQuest offers our GreyMatter customers detection rules to mitigate BEC threats. Implementing these rules will allow defenders to identify tool abuse and unauthorized software that violates policy obligations. Organizations can calibrate these rules to their particular environment for higher fidelity of results and fewer false positives.

Recommendations and Best Practices

Building on the detection rules cited above, we offer the following general recommendations and best practices to establish a secure foundation against BEC threats mentioned in this report.

• Strengthen administrative account security: Decouple administrative access from common user interfaces and email accounts. Administrative accounts should not be used for generic email activity.
• Enhance access enforcement: Implement strict location-based policies for continuous access enforcement.
• Upgrade MFA methods: Move away from less secure MFA methods, like SMS, and adopt stronger alternatives, such as FIDO2 hardware factors.
• Optimize access policies: Regularly scrutinize and adjust conditional access policies to close any gaps in defenses.
• Monitor high-risk users: Develop detection rules for high-risk users when creating email inbox rules, allowing for a “tuning period” of at least 30 days to increase the rule fidelity.
• Verify transaction requests: Implement a dual authorization policy whereby a manager or co-worker must authorize large payments or banking changes. Require that employees have an alternative line of communication (not email) with individuals requesting transactions, to prevent unauthorized transfers.

Block newly registered domains: Configure forward proxy devices to block domains, using categories like “newly registered domains.” This helps prevent BEC operators from using recently registered domains.