Since joining TrustedSec, I have gotten to work numerous cases, and each of them is like unraveling a mystery to get at the truth—especially the situations that have involved business email compromise (or BEC). Unfortunately, these cases have not only involved intrusion into cloud email accounts. There have also been situations where the attackers manage to get in, lurk (or persist) for a while to understand who can be victimized in a financial sense, and then make a move to redirect money or do some form of bank account takeover that hurts the organization.

I have also been witness to substantial time differences between when the initial intrusions were performed by the attacker(s) and when they were detected. For this article, I would like to talk about what can be learned in those times when the duration is prolonged, as well as when the dwell time of the attacker is relatively short, and how that delta in time can be further reduced. I feel that by examining these scenarios, we as a cybersecurity community can better understand what pitfalls to watch out for and find practices that can be adopted to deny attackers from getting in or staying for too long if they were successful in breaching.

The Criticality of Logs

In my job in IR, I get to look at logs and spreadsheets a lot. Sometimes, it figuratively feels like a mountain of work to go through just to separate the benign activities (usually by the user or systemic functions of a cloud email service) from those that are harmful or clearly show that some uninvited guest has gotten into an account that does not belong to them.

However, a sad-but-true consideration is that if you know for a fact that an intrusion happened, then you have a starting place to work from. Think about it like starting to work on a 500-piece jigsaw puzzle on the kitchen table over the weekend. Perhaps, to get rolling on it, you may want to lay all the pieces out so you can see them, and then work to identify the corners. Then, maybe match the straight margin edges and sort out which sides of the picture they come from using the picture on the box for a reference, and then start looking for patterns inside from the margins that can make the whole picture come together.

I would venture to say that starting a BEC investigation is sort of like that. I usually like to know if the customer has a specific person who reported their account being hacked into, if there are several accounts, or if they belong to a group. Lately, we have frequently seen a collection of people who get their accounts hacked into, such as part of a company finance team. If I can have it my way, I like to evaluate who is in a position of having something of value to the attacker(s) before searching for authentication events that are odd-looking or outside the normal locations where someone signs into their cloud account. My reason is that attackers are drawn to hitting their objectives, and there are good odds that the end goal is to get paid somehow, so they are drawn to the money. If I see that the accounts are in the same finance group AND were targeted or breached, then I can be certain of the financially driven goals of the attacker, which will extend to other probable investigative leads to follow.

When looking at user accounts for BEC cases, the logs are a critical form of information to work with. They tend to be essential sources of information on face value alone. Some cloud email services such as Microsoft also offer additional detections for things like ‘impossible travel’, and those are great events to look for in the logs that can reduce how long attacker(s) control an account they breached.

However, before diving headlong into a pile of log data extracted from a cloud service provider (take Microsoft M365, for the sake of argument), getting an exhibit into my hands can help with the investigation. This usually means that there is some form of a phishing email that the organization will point to as being crucial to their initial detection. It can be an email that comes from someone in the organization, or it can be an email message that was received by someone via a third party, such as a supplier or vendor. Those are usually helpful when looked over, as they may yield clues as to the times when suspicious messages went out and account IDs were used.

When I get this kind of exhibit and compare it to ones within the unified access logs or message trace logs, I will usually find a flood of emails that had gone out, and this helps me understand the genesis of the attack. The email message header details, especially, can tell IR practitioners a lot, so be sure you extract the message headers. The URLs or links in the message can also provide good Indicators of Compromise (IOC) tidbits to look for. Therefore, from my viewpoint, obtaining relevant phishing email message(s) can be helpful for the analysis of a BEC incident.

Clues Within Inbox Rules

In BEC cases, I think, in general terms, that attackers like to entrench themselves. One (1) of those ways of getting in deep with an organization is to find out what emails can be scooped up by the attacker, redirected to an unassuming or otherwise neglected mailbox folder for later review, and then studied by the attacker in a way that will help them with their ultimate objective. Examples of this would bethe RSS Subscriptions, Junk, and sometimes, the Archive folders.

One (1) regularly observed way this is done is when the attacker creates inbox rules that parse the subject or content of messages for specific terms in league with their objectives (let’s go with bank account takeover). Then, a copy of the message is sent into a folder that, like a spy novel ‘dead drop’ box, is already set up for the attacker to come back and see if any loot has appeared. Another purpose of the creation of the rules is to keep certain communications hidden from the legitimate account user.

Let’s keep assuming we are discussing Microsoft (M365 cloud email), where some of those folders that inbox rules have sent BEC-related emails to have been RSS Subscriptions, Deleted Items, or Junk Email. Therefore, instead of manually looking through all enterprise accounts for inbox accounts, one right after another, I suggest that scripting through PowerShell can help you gather rules en masse for the organization and list them out so you can see all the inbox rules and determine if anything looks particularly suspicious. 

Recently, I used something like the code snippet below for that exact purpose. It has two (2) parts:

• An initial part to install ExchangeOnlineManagement for PowerShell and make a connection to the M365 tenant the user belongs to
• A second part to deal with the second listing that will list out all the rules found in the M365 tenant in a file, TenantRulesOutput.csv

Here is a walkthrough for both parts:

Install-Module-Name ExchangeOnlineManagement -Force -AllowClobber
Connect-ExchangeOnline -UserPrincipalName [email protected] -ShowProgress $true

After installing the module ExchangeOnlineManagement, the script makes a connection via the user account ID that is provided after the -UserPrincipal parameter.

The next script will require an additional module, ExchangePowerShell, to be loaded. It’s commented out in the first line of the script, just as the line containing the module ExchangeOnlineManagement is, but is included as a convivence, so the reader understands that these two (2) elements are critical dependencies.

# Install-Module ExchangePowerShell -Force -Verbose
# Install-Module ExchangeOnlineManagement -Force -Verbose

Connect-ExchangeOnline

$users = (Get-ExoMailbox -resultsize unlimited).UserPrincipalName
foreach ($user in $users)
{
Get-InboxRule -Mailbox $user -includehidden | Select-Object MailboxOwnerID,Name,Description,Enabled,RedirectTo, MoveToFolder,ForwardTo | Export-CSV TenantRulesOutput.csv -NoTypeInformation -Append
}

Keep in mind, the account that launches this PS cmdlet request will need to have specific permissions to look at all the accounts in the (presumed M365) cloud tenant. So, my advice is to be sure to check for any specific permissions you need to have in place, so the scripting does not (A) fail or (B) set off any false alarms of potential brute-force caused on the inside for a legitimate canvassing. The below screenshot is an example of data that can be produced in the TenantRulesOutput.csv file with the particulars blurred out.

Bear in mind that the account I used had the following membership permissions (roles): 

• View-Only Recipients
• View-Only Configuration

A full-on administrator account may be an overreach for a check like this. You may want to create a specific role group for M365 administration checks that only views the data needed to gather this information and decide on it. Currently, the role group Hygiene Management includes the capability to manage mail flow rules and also includes the roles I had listed above (I think about the principle of ‘least amount of access/privilege’ all the time, so this is consistent with it.) Refer to this page for some good starting steps. 

The MFA Factor

Another thing that IR practitioners who are working on BEC cases will come across is the question of whether a second-factor authentication device (also called multi-factor authentication, or MFA) was somehow bypassed during the attack. During the initial consultation with breached clients, this is a primary question we ask. So, when we look at data from a breached account, we can understand what the attacker was up against and if there is anything they could have done to circumvent it.

In the past, we have heard plenty of sad stories about simple MFA using SMS text message implementations; the weakness comes from the originating phone number, for an SMS text can be spoofed by an attacker. Frankly, the US National Institute of Standards and Technology (NIST) established in Special Publication 800-63 that the SMS-based MFA is not desirable for strong authentication.

Similar to that, push notification MFA has also been reported being bypassed. This happens because the attacker got a toehold into an account with a username and password for the first part and then sent a massive number of prompts from an application asking the user to tap ‘approve’/accept’ without critically thinking about what authentication request they were approving. The targeted user may have gotten worn out from constantly being badgered about denying or approving the MFA requests and opted to accept all going forward, not knowing that this played into the hands of the attacker. This condition is otherwise known as ‘MFA fatigue’, and it’s exploited by attackers.

If the impacted organization has been breached and had registered MFA devices, looking into the M365 device listings may help determine if an attacker took one (1) more step to register their own cell phone or similar MFA device to get the MFA prompt instead of it going to the user. The lesson in this situation is that when a breach happens, be certain the registered phone or MFA mechanisms listed on the cloud service actually match what the user presently has in their possession. Reviewing the configuration for any unexplained OAuth2 applications is also a prudent step to see if anything has been added unexpectedly.

In this writeup, we talked about the elements of investigating BEC incidents. The topic has a lot of depth, and I tried to address much of it that I have seen from direct observation. Before closing, I invite you to check out this link for some additional examples, email authentication tips, and options for protection against these threats. I hope you found this discussion useful and that it encouraged you to consider additional ways that you can practice investigating intrusions of this type.