Using the Blue team app for Office 365 & Azure for a BEC investigation

In this post, I will show you how to investigate a BEC attack with my new app. 

Download my Splunk app here:  

Splunkbase: splunkbase.splunk.com/app/4667/ 

Github: github.com/PwC-IR/Blue-team-app-Office-365-and-Azure

This app was built for several reasons, one is that I've been helping out a lot of organizations that fell victim to a BEC attack. And I've noticed that most of the BEC attacks follow certain steps to accomplish their goals. With that in mind it should be possible to detect present and ongoing BEC atacks and that's what I have tried to built into my app. Another reason for this app is that it will help with analysis of the Office Unified Audit Log (UAL), which can be quite challenging because of the format of the data and the level of detail that is recorded. 

The App

So how can we detect a BEC attack based on the UAL with my Splunk app? I have built around 20 unique searches and categorized them into four domains. So far, I have been able to identify (ongoing) BEC attack(s) with this app for all variants I have seen. 

I have created four domains in the Splunk app that all have their own dashboard. The idea is that activity related to a BEC attack is visible in at least one of the four domains, giving you a chance to detect and block it. When you open the app, the four domains are visible in the top bar. 

Email Forwarding Rules

There are several ways to setup email forwarding rules. This dashboard contains multiple panels that will show you information on all the different rules found in the audit logs. When you have identified a rule, you can drilldown to investigate the rule with the Mail Rule Investigator. This is what it looks like; I have redacted the email address and the IP-address in this picture.

All details for the forwarding rule are visible in the Mail Rule Investigator.

In the left panel, you will find the forward address for the rule, in this example it's a Gmail address. The right panel shows all parameters of the email forwarding rule and its values. The email forwarding rule dashboard and the Mail Rule Investigator helped me a lot in my cases to find out what happened. 

Permission Changes

The second domain of interest is permission changes. This is a broad topic and there are many ways for an attacker to elevate privileges. I have added events here that I have seen used by attackers to escalate their privileges. The dashboard contains events related to the following permission changes:

• Mailbox, this can be used to change the permissions for a mailbox.
  Example: An attacker grants himself access to the mailbox of the CEO.
• SendAs, with this permission you can impersonate someone else.
  Example: An attacker sends out an email to the whole company with a malicious link from the email address of the CISO.
• Mailbox folder, this permission allows you to share a specific folder with another user.
  Example: An attacker uses this to get access to the 'Clients' folder of the sales mailbox. 
• Role & Group changes, these types of permissions are used to add people to groups and roles.
  Example: An attacker adds himself to the group of Exchange Administrators, so that he can modify all settings. 

In the example below the attacker has added a new user to the Company Administrators group.

Login Activity

This dashboard contains many panels related to user activity and this is great for identifying various attacks related to gaining access to the environment such as brute force attempts or password spraying. One method to identify activity of interest is looking at the geo location of login attempts. For that purpose, I created a panel with the geo map in Splunk. When you look at the successful logins per country, you can immediately identify outliers. If your company does not have a location in South America and you see accounts, logging in from there you might want to investigate. Of course, an IP-address can be spoofed easily or a VPN service can be used.

Another indicator that something might be going on is looking at login attempts with non-existing accounts. Sometimes an attacker tries to guess account names and uses a dictionary with common passwords to login. I have built a panel that will identify these types of attacks based on the logon error that Microsoft returns. 

Other panels included in this dashboard are:

• Failed login attempts from multiple IP-addresses, you should filter the IP-addresses belonging to the company to get rid of the noise. 
• Successful logins from multiple IP-addresses, you should filter the IP-addresses belonging to the company to get rid of the noise. 
• Password resets, see if there is an unusual high number of password resets.
• Rare logins based on the user-agent of a login.
• Multi Factor Authentication disabled events, MFA can be challenging an attacker to bypass, and thus events where MFA is disabled should be investigated.

Other suspicious activity

This dashboard is a collection of 'other' events; events that are interesting and should be followed up, but do not fit in the other three categories. Some examples:

• Audit log disabled, it is possible for an administrator to disable the audit log, however from a security perspective it is a big red flag if someone disables audit logging.

• Sharing items with individuals outside of an organization, information in this panel is very useful when you are searching for traces of data exfiltration.

• eDiscovery activity, I have seen cases where an attacker uses the eDiscovery functionality in the Office 365 suite to search for interesting data such as passwords and project data. This panel provides you with an overview of all eDiscovery activity.

I hope this post has inspired you to test out my Splunk app, and please do let me know what your experiences are. Also any suggestions or bugs you find for this app are more than welcome.