Business Email Compromise is an old-fashioned type of spear-phishing that CSIRT Synacktiv is continually confronted with despite the various security mechanisms and the (assumed) secure Microsoft 365 environment. Several materials already describe this type of attack, this document is an operational feedback from the CSIRT Synacktiv on several BEC incidents based on Microsoft 365 service. It is published in two parts:

• part 1: description of BEC incidents, search for suspicious Azure sign-in & first Exchange investigations
• part 2: facing typosquatting, recovering the phishing with MessageTrace/eDiscovery and threat hunting

The tools and methods mentioned is this blogpost work with the most basic license in Microsoft 365 environment. While those requiring an advanced Microsoft/Office 365 license are highlighted. Extracts from PowerShell scripts are provided so that one can parse for the appropriate processing.

Introduction

The FBI webpage dedicated to BEC describes the timeline and the general status of these attacks quite well. More over recent news reports refer to a group that clearly practices such attacks and has been indicted in the US and around the world. One significant change that has been identified is the use of legitimate M365 account to send the initial spear-phishing so that it appears more trustworthy to the recipient (SPF/DKIM appears legitimate). Then the attacker bounces from compromised mailboxes to others with a better and accurate understanding of the targeted sector. Some mailboxes are really valuable like large suppliers ones because of the number of potential new targets.

The most appropriate French translation for BEC is FOVI (Faux Ordre de VIrement) as described by Cybermalveillance.gouv: once again French wording is more accurate ;) Indeed the ultimate goal of such an attack is not to compromise a mailbox but to obtain funds transfer: compromising a mailbox or using a spear-phishing is just a way to lure the victim. Some of BEC incidents processed by Synacktiv involve a typosquatting domain to get the money transfers with limited usage of the compromised mailbox. The address book and business context are more valuable than the mailbox itself.

It is noteworthy that real victims of such attacks are not those who have their mailboxes compromised, the compromised mailbox is just a mean to make a bank transfer and, aforementioned, sometimes no compromised mailbox is needed. Thus, the initial detection of such an attack may be through an external alert (just before the wire transfer) or unfortunately when it is too late (the wire transfer has occurred and has been identified as fraudulent by the accounting department). When the mailbox is taken over by the attacker (eg. mailbox rules, see below), a phone call or text message from another recipient is the most common way to reveal and start investigations.

Are BEC advanced attack ?

Most of the so-called advanced attacks observed involved advanced techniques to compromise a system. From a technical standpoint, BEC attackers cannot be compared with ransomware or state-sponsored attackers. Most of them do not use malware (no malware use was observed by CSIRT Synacktiv in recent cases even if some editors reported it) or exploits. At best, they use a bug-free phishing kit and the most technically challenging part is building a well-formed spear-phishing messages without (too many) grammatical errors (a fairly good detection method in some languages).

However, one must keep in mind that if most of nowadays ransomwares are sophisticated, this has not always been the case: static keys embedded within binaries, faulty implementation of cryptography, no lateral movement capabilities, etc. Attackers keep improving and as soon as their profitability decreases due to technical reasons or target shifts, we can assume that they will get even better. Taking this into account, one can imagine that BEC attacks could get more and more sophisticated in the future.

From an OPSEC perspective, BEC attackers are also a far cry from what you can read in cyberattacks. They only seek to stay undetected for the duration of an attack (usually one to two weeks): once the spear-phishing scheme is detected, recovering much of the attackers' infrastructure(s) is very easy, even if you are not a CTI expert. However, attackers move fast, very fast. The way they operate their attack (spear-phishing domain, usage of legitimate mailboxes, etc.) is very effective and easily repeatable. One can suppose that most of attacks are automated.

What makes BEC an advanced attacks is the deep understanding of how companies work and how money flows between companies within an industry (venture capital, banking, insurance, funds, etc.). Even if we can predict that some of the attacks are opportunistic, the early stages of a cyberattack (reconnaissance) are advanced and opposite to a massive approach. For example, they can adapt their spear-phishing to the tools used by the IT department (or shadow-IT of the users): DocuSign, WeTransfert, Dropbox, etc.

Some might ask why the M365 anti-phishing gateway and similar products do not catch them all... well, most of the time they actually do :) but they are often highly configurable and some settings may prevent them from identifying threats. Another case would be a phished mailbox which is well-known and/or trusted by employees. We also noticed in some cases that some anti-phishing features are disabled by administrators because of false-positives. Why doesn't the same security product catch fraudulent money transfer email? It simply can't: this type of email has nothing to do with technical malicious activity and most of the time it is a plain text email asking to change the IBAN or a real fake invoice sent from a legitimate mailbox in response to a well-chosen conversation. These characteristics suggest the attacker is fluent in the target language.

Initial statement

Most of the time, targeted companies ask Synacktiv to deal with their compromised mailbox: they feel like the victim of the attack because one of their mailboxes has been compromised, but remember the real target is the one who were asked to do the transfer. They want to understand how the mailbox was compromised and the impact on them: who was contacted (it could be very damaging in case of a business partner), when and for what reason. The second type of question is regarding the potentially exfiltrated data (which M365 does not help that much with basic license).

The password of the targeted user is usually reset (PRT is automatically flushed), in the best-case MFA has been activated. In the worst scenario the mailbox has been deleted, which is bad because you lose any chance to recover the attacker's activity. Thanks to the Exchange Online recovery scenario.

Import-Module ExchangeOnlineManagement
Connect-ExchangeOnline -UserPrincipalName <admin_UPN>
Undo-SoftDeletedMailbox <email@to_recover> -WindowsLiveID <email@id> -Password (ConvertTo-SecureString -String 'T3mp-Pa$$word1' -AsPlainText -Force)

If you focus only on the compromised account, you may be missing some important aspects of the incident. In 2021, you need to take into account both incident response and compromise assessment ways, specifically in the case of a cloud intrusion. Since the default retention policy is at best 90 days, the earlier you start incident response, the more likely you are to understand the intrusion: are there other compromised mailboxes? How many spear-phishing was sent in how many waves and when did it really start?

Prerequisite

Incident response to SaaS applications is highly dependent on the logs, API and tools provided by the cloud provider. Microsoft exposes a lot of APIs permitting to query the M365 application, which have advantages and disadvantages on Web GUI. Long story short: you will need to use both API and Web GUI to get a clear picture of the incident. You should be careful with the date and time format: sometimes UTC is used (API) and sometimes it is converted to the time zone of the user (marked Local in Azure). Ho! And of course, things get more complicated if you merge an on-premise system (like Exchange) :)

Msportals.io enumerates all of the Web portals - some references you should at least known:

• Azure portal
• Office 365 Security & Compliance center: protection.office.com merges a subset of the features from Microsoft 365 Defender, the Compliance center and Exchange Online. Understanding the location of some key features takes a little practice
• PowerShell offers various libraries & API: AzureAD, ExchangeOnlineManagement and Graph API for the most common ones
• Microsoft admin portal is not useful during the incident response, but you should always check the health status of the services to avoid losing time and keep reliable result.

At Synacktiv we are fond of Linux environment and were happy to use PowerShell for Linux. While pwsh works for some libraries, day-to-day operational use could be challenging. Thus, we recommend always keeping a PowerShell based on Windows 10. Note that another easy way to get a robust PowerShell is to use the Cloud shell (in Linux :)), you are guaranteed that all the data stays in Microsoft Azure.

Of course, you need a privileged account to perform an incident response. The easiest way for the administrator is to give you a Global Admin account but it could be dangerous as it gives you more permission than you need. Tenant-wide incident response requires privileged access: most of the incidents could be processed with Global Reader in Azure AD role & Compliance Management in Exchange Online. If you need access to mails, Discovery Management role is also required. Even though it is less powerful than Global Admin role, you should stay caution, it is a lot of power: the good news is that you only need read operations on user data and tenant logs.

Unified logs are a convenient way to view on audit log events for M365. However, mailbox logs are not sent by default to the unified logs. Incident response without unified logs are quite challenging because they contain all logs related to mailbox operations. The best you can do is to activate unified logs for the next incident.

Install-Module ExchangeOnlineManagement  ## if not already installed
Connect-ExchangeOnline
Get-AdminAuditLogConfig | FL UnifiedAuditLogIngestionEnabled
Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true
Get-OrganizationConfig | Format-List AuditDisabled  ## ie should be False

It could take many hours before first records are ingested by the unified logs in large tenant. Mailbox audit is enabled by default (once the unified audit log activated): it can be checked per mailbox.

Get-Mailbox -Identity <user> | select-object -property "AuditEnabled"

Tenant recognition

First of all, don't rush on the compromised mailbox: take time to understand Azure usage and get the big picture. Of course, if you are an internal incident response team, you should already know this, right?

You should understand what events are considered as legit, which is often done by asking the IT department or the user involved in the incident. Some organizations have a fairly simple usage of their M365 account with solely clients connected to the Exchange Online server and a very low remote connections rate. On the other hand, some organizations have road warrior and massive remote connections from multiple locations. Of course, hybrid usage is also possible. Such data could simplify your investigation: remember that you are looking for the abnormal. Among the other interesting information: does the company have a specific netblock, what kind of VPN/Web Gateway is used, is there a country where business/travel is absolutely impossible (ex: the US during the COVID travel ban), mobile usage, does IT only use Web GUI.

Azure AD recognition includes number of users, type of license (per user), administrative roles, unknown registered applications.

Install-Module AzureAD
Connect-AzureAD
$usr = Get-AzureADUser

OnPremisesSecurityIdentifier is set when the user is synced to on-premise: it is worth looking for new cloud-only account created during the incident timeframe.

$usr | ForEach-Object {
if(![bool]($_ | select -exp "OnPremisesSecurityIdentifier")) {
Write-Host $_.UserPrincipalName ":"  (Get-AzureADUserExtension -ObjectId $_.ObjectId).Get_Item("createdDateTime")
}}

Licence can be extracted from PowerShell or the admin center portal. "Premium" licenses are valuable because of a better retention policy and features (i.e. threat hunting, etc.).

$usrs | ForEach-Object {
$lic = (Get-AzureADUserLicenseDetail -ObjectId $_.ObjectId)
if ($lic -ne $null) {
Write-Host $_.UserPrincipalName ":" $lic.SkuPartNumber
}}

High privilege roles should be watched. First with Azure AD then Exchange Online. (role members are not shared)

Get-AzureADDirectoryRole | ForEach-Object {
$admm = (Get-AzureADDirectoryRoleMember -ObjectId $_.ObjectId)
if ($admm -ne $null) {
Write-Host "`n" $_.DisplayName ":"
$admm | ForEach-Object { Write-Host $_.UserPrincipalName }
}}

Install-Module ExchangeOnlineManagement
Import-Module ExchangeOnlineManagement
Connect-ExchangeOnline
Get-RoleGroup | ForEach-Object {
$exadm = (Get-RoleGroupMember $_.Name)
$name = $_.Name
if ($exadm -ne $null) {
Write-Host "`nRole Group : " $name
$exadm | ForEach-Object { Write-Host  $_.Name ":" $_.WhenChanged }
}}

Microsoft Security & Compliance center produces some helpful dashboards. Sure you will investigate by your own, but some detections are real-time and you can't get a log or treatment so quickly. Among the interesting dashboards:

• Identity Protection:  Risky users and Risky Sign-in dashboards (accessible via the Security item in Azure AD) highlight users identified by Azure with potential security issue and a valid authentication. If the user's risk policy is not configured, expect some false-positive (again the retention period for sign-in do not exceed 7/30/90 days depending you are Free/P1/P2 subscription). It is not uncommon to discover a security breach that is unrelated to the original BEC incident.
• Incident & alerts in Microsoft 365 Defender: this is a useful aggregation of various alerts. You can start to cross-reference the alert with users already seen in the Identity Protection dashboard. Exchange Online alerts should be noted because linked with BEC incident.

Azure AD

The Azure Web GUI can help you investigate but you would better automate the search provided large tenants and limited time of investigation. You can extract the sign-in logs from Azure (the API response is pretty fast). Some interesting investigations are:

• Success sign-in from risk detection:  anonymizedIPAddress (TOR, various VPN software, well-known vps providers, etc.), maliciousIPAddress, leakedCredentials. Microsoft Cloud App Security adds the following detection pattern: mcasImpossibleTravel, mcasSuspiciousInboxManipulationRules. Users with administrator's role must be investigated first.
• Unexpected and expected netblock. You should ask the corporate network and the approximate location of the compromised account(s) (especially during vacation). Suspicious network appears more clearly. In some scenarios most of the signs during work hours come from corporate netblocks. New netblock during the timeframe of the incident should be investigated.
• User-agent of the sign-in is sometimes very specific to the attacker. So you can "follow" his activity across the time and the IP. You can use it to pivot and locate other targeted or compromised account. Be careful to retrieve all the logs from the API in order to get the exact version of the user-agent (not just the browser name)
• GeoIP can help you monitor alerts like "impossible travel": such alert is already available but could be fine-tuned for specific users (border worker) or group/OU (country-specific users). If there is no business within some countries: it could trigger some alerts for specific regions (Nigeria as an example - remember poor opsec section).
• IP reputation: in BEC incidents, most of the malicious sign-in come from VPN so it's helpful to get such information from your best CTI feeds.
• Working hours: morning interactive sign-in should state most of user behavior.

Compromised shared mailbox is the most challenging scenario due to the diversity of events (geoip, use-agent, etc.), manual processing to focus on the timeframe of the incident is necessary. For the other mailboxs a per user processing is the most straightforward way to handle large tenants.

Suspicious sign-in are very precious pieces of information to build the root of the incident timeline. Most of the (more) advanced intrusions techniques are based on malicious applications to impersonate users' identities. Such techniques have not been seen (yet) in the BEC incidents we investigated, but they are likely unavoidable.

DFIR O365RC is the easiest way to download sign-in logs and the API has a pretty good performance. The documentation is pretty self-explanatory so you can download in json file the content of the sign-in. jq linux cli can filter the result so you can process data.

Note: Azure Monitor can be used to increase the retention and search capabilities.

Exchange & mailbox

General configuration of Exchange Online should be audited in the early stages of the compromise assessment. A per mailbox approach is then advised.

• Autoforward dashboard could reveal malicious activities and at least some bad user's practice.
• Transport rules to understand all rules applied before the processing of the mailbox (i.e. add blind copy on all email).
• Delegation policy should be reviewed: the owner of the mailbox should sometimes be involved in the assessment because of business/organizational constraints (vacation, assistant, etc.). The SendAs and Send on behalf delegation can be reviewed with PowerShell.

Install-Module ExchangeOnlineManagement
Import-Module ExchangeOnlineManagement
Connect-ExchangeOnline
Get-Mailbox -ResultSize unlimited | Where {($_.ForwardingAddress -ne $Null) -or ($_.ForwardingsmtpAddress -ne $Null)} | FL DistinguishedName,DeliverToMailboxAndForward,ForwardingAddress,ForwardingSmtpAddress

The ForwardingsmtpAddress setting could be an external email address.

Get-TransportRule | fl

Transport rules at Exchange Online level should be known by the Exchange admin.

Get-RecipientPermission
Get-Mailbox | where {$_.GrantSendOnBehalfTo -ne $null} | select Name,Alias,UserPrincipalName,PrimarySmtpAddress,GrantSendOnBehalfTo

The infamous inbox rule is the main setting BEC's attacker used to abuse because it does not require a privilege access and it is awfully effective to keep undetected while performing the spear-phishing. The per mailbox autoforward rule is less likely to be encountered because it is now a popular technic known by administrators.

$users = Get-Mailbox -resultsize unlimited
ForEach ($user in $users) { Get-InboxRule -Mailbox $user.Name }

The previous PowerShell script gives a real-time view of effective inbox rules. For a historical search, you will need to query the unified log. The Web GUI (audit log search in the compliance center) gives you the opportunity to figure out new and modify inbox rules in Exchange Mailbox Activities categories: New-InboxRule/Set-InboxRule. You need the unified log enabled (again that's not the default setting) and limited to 90 days by default.

PowerShell command Search-UnifiedAuditLog can help you automate the extraction for such events in the logs but the performance of the API is very poor and results are limited (from 5000 to 50000 depending on the session command method used): so you would better query only the required events. The following link gives you the workflow used to parse relevant information (see Exchange-Mailbox-Activities section).

To query the unified logs you need the view-only audit log permission or the audit log role on the Exchange Online's permission page.

$enddate = get-date
$startdate = $enddate.addDays(-2)   (ie 2 days ago)
Search-UnifiedAuditLog -EndDate $enddate -StartDate $startdate -Operations "New-InboxRule,Set-InboxRule"

Some features depend on the license of your Office 365 subscription: this link gives you some details about the features included in your subscription. Inbox rules are not the only valuable records to search within: the cheatlist in this document written by PwC has a very complete list of interested events you should definitely query. You can also extend the previous investigation (ForwardingAddress) by querying the unified logs in the same way you did for inbox rules.

Search-UnifiedAuditLog -EndDate $enddate -StartDate $startdate -Operations "New-InboxRule,Set-InboxRule"

On large tenants, tools like DFIR O365RC is preferred to catch all the results in a reliable way.

By default the audit policy does not include every is different between the owner (AuditOwner) of the mailbox, admin user (AuditAdmin) and delegation (AuditDelegate). It does only include a subset: you should query the audit policy with PowerShell for compromised mailbox, so you can take accurate conclusion. CSIRT Synacktiv schedule the publication of a guide to set the most appropriate audit policy.

Get-Mailbox -Identity <user> | select-object -property "AuditEnabled"    (true if audit are enable)
Get-Mailbox -Identity <user> | Select-Object -ExpandProperty AuditOwner
Get-Mailbox -Identity <user> | Select-Object -ExpandProperty AuditDelegate
Get-Mailbox -Identity <user> | Select-Object -ExpandProperty AuditAdmin

For troubleshooting purposes, you can check the volume of logs stored.

Get-MailboxFolderStatistics -Identity user1_office -FolderScope RecoverableItems | Where-Object {$_.Name -eq 'Audits'} | Format-List FolderPath,FolderSize,ItemsInFolder

In the next part of this publication, we will go deeper in the investigation: facing the typosquatting, usage of the threat hunting feature and recovering the phishing from MessageTrace & eDiscovery.