How to respond to a Business Email Compromise - Part 3

This three-part blog series is about Business Email Compromises (BEC) targeting Office 365 environments and our insights as incident responders. The first post can be found here and contains an introduction to BEC attacks and the challenges that often arise in these types of investigations. The second post can be found here and includes an open source script that acquires audit logs from an Office 365 environment. In this post we examine several use cases and explain how to identify suspicious behavior in the Office 365 audit logs. The intent of sharing our knowledge, tooling and experiences of BEC investigations is to help disrupt threat actors, contribute to building trust in society, and encourage other organizations to share their knowledge and help those in need of assistance.


Analyzing the complete Office 365 Unified Audit Log (UAL) is often a challenge because it contains millions of events with no clear indication of where to begin the investigation. This notion begs the question, “what is worth your time to analyze”? Fortunately, our experience with BEC attacks can provide insights into common BEC-style tactics that may be suspicious. These tactics include:

  1. Creating email forwarding rules;
  2. Lateral movement; and
  3. Suspicious login activity.

These tactics are analyzed below, and include how to detect them in the UAL. However, it is first necessary to process the UAL in a log management solution, so that the data can then be queried for suspicious behavior. Processing the data also includes understanding the format in order to help identify relevant pieces of information.

Processing the Office 365 Extractor output file(s) in a log management solution is relatively easy but it is useful to understand the format of the output file. The output file is comma separated and contains all the audited activities for the desired time period. An example of the output is shown in the following image:
Audit log in csv format

The first row contains the field names, which can be used for filtering and identifying relevant pieces of information. The following field names and their functions can be quite helpful in analyzing the processed data:
  • RecordType: contains the type of audit data present in the dataset (e.g. Sharepoint, Active Directory or Exchange).
  • CreationDate: contains the timestamp of the event in UTC time format.
  • Operations: contain the operation that was logged and this is the main method for filtering (e.g. ‘FileUploaded’ or ‘FileDownloaded’).
  • AuditData: contains detailed values of audited actions in JavaScript Object Notation (JSON) format. JSON format is ideal for processing because it is a universal format that is specifically designed for machines. This field is very important as it contains all details about the executed Operations.
  • UserIds: contains the ID of users that carried out the action.

Processing the output file(s) is accomplished by using a log management solution, such as Splunk or Elastic. In our investigations we often use Splunk to process and analyze the data. The steps for inputting logs into Splunk are straightforward:
  1. Go to ‘add data’ in Splunk;
  2. Specify an index; and
  3. Set the sourcetype of the data to ‘csv’.

There is a second option for log onboarding in Splunk using a so-called inputs file. This is an example inputs file that can be used to onboard the output file(s).

disabled = false
index = auditlog 
sourcetype = csv 
host = office365

A final detail to be aware of before processing the data is the log retention policy. The availability of logs are dependent on the type of Microsoft Office 365 licence. For example, an E3 licence retains logs for the last 90 days and an E5 licence retains logs for the last 365 days. In our experience entities usually have the last 90 days and thus, it is important to act quickly in investigating a BEC attack because the limited availability of records may mean it is not possible to determine any suspicious activity. However, if the compromise occurred within the log retention period, it is possible to observe the suspicious activity.

The inputting of logs into Splunk is relatively easy and awareness of certain field names and their functions are quite helpful in analyzing the processed data. Furthermore, awareness of the specific license is important context for analyzing events, as limited records may mean it is not possible to determine suspicious activity. After processing the data, it is now possible to analyze the data for any suspicious behavior.


Email Forwarding Rules

A threat actor is able to convince victims to transfer money by sending an email that includes previous conversations, often as proof and verification. This tactic is accomplished through creating an email forwarding rule. Once the victim's account is compromised, a new forwarding rule is created, which forwards all incoming emails to the threat actor's email account. Therefore, analysis of new or modified existing forwarding rules is a good place to discover suspicious behaviour.

New Forwarding Rules

Searching the UAL for newly created forwarding rules is accomplished by querying the following Operations:
  • New-InboxRule
  • New-TransportRule

According to Microsoft, inbox rules process messages in the inbox, which can include moving a message to a specified folder or deleting a message. Mail flow rules are similar to inbox rules but mail flow rules take action on messages while they're in transit, and not after the message is delivered to the mailbox. Let's examine an example of how to identify suspicious activity when a new forwarding rule is created.

Example: Rebecca is the CEO of SmallCorp and is a suspected victim of a BEC attack. The incident response team queries the InboxRule to determine if there is any unauthorized forwarding rules, as observed in the following image:
New-InboxRule event

Analysis of the log output indicates that a New-InboxRule is created for the account r.perez@gehim[.]onmicrosoft[.]com (Rebecca). Examination of the Parameter fields shows that the forwarding address is itcornpany[.]gmail[.]com. This specific rule is interesting, because it forwards to an external email address. And the threat actor uses a trick with the letters 'rn' to make it look like the word 'company', but in reality it is 'cornpany'.

Another example below shows a forwarding rule where the threat actor first forwards the mails to itcornpany[.]gmail[.]com and then sets the value for 'DeleteMessage' to true. This causes the forwarded emails will be deleted after they have been forwarded.
New-TrasnportRule event

Modifying Existing Forwarding Rules

A threat actor can also modify an existing rule. This action is harder to spot because the rule originally existed for legitimate purposes. Therefore, it is important to check if any forwarding rules have been recently modified. This is accomplished by querying the following Operations:
  • Set-Mailbox
  • Set-InboxRule

In order to determine what emails are currently being forwarded you can search on the following parameters being part of the Set-Mailbox Operations:
  • DeliverToMailboxAndForward
  • ForwardingSMTPAddress
  • ForwardingAddress

Example: Some highly confidential emails of BigCorp are leaked to the press, and the CEO of BigCorp contacts PwC's incident response team to investigate. The incident response team sets out to identify who had access to the confidential emails. It turns out that Max, one of the executives and board members of BigCorp, had access and always forwards his mail to his personal email account max@gmail[.com] because he likes to read them on his private iPad. The incident response team queries the Set-Mailbox Operation to determine if there are any unauthorized forwarding rules, as observed in the following image:
Forwarding rules

The incident response team has queried the Set-Mailbox Operation to determine if there are any unauthorized forwarding rules. In this example, there are two forwarding events. The value belonging to the 'ForwardingSmtpAddress' field contains the address that all emails are being forwarded to and all emails for the mailbox maxt@cyberteamir[.]onmicrosoft[.]com are being forwarded to curt@gmail[.]com. It turned out that this was not the private email account of Max. In this case, the threat actor modified an existing rule to not trigger any alerts of newly created forwarding rules.
Lateral movement

Sometimes a threat actor moves laterally in their attack, such as, getting the content of someone else’s mailbox or getting access to a Sharepoint site containing confidential data. To check for lateral movement and unexpected changes in permissions, search for the following Operations:
  • Set-MailboxFolderPermission
  • Add-MailboxPermission
  • Add-RecipientPermission
  • SendOnBehalf

By searching for changes in the privileges it is possible to spot suspicious behavior from a threat actor trying to give himself or other users more privileges than they are supposed to have.

Example: A threat actor is suspected of accessing Joey's email account. Joey is an administrative assistant for Max, who is the CFO of a MediumCorp. The threat actor likely uses the administrative assistant's account to send phishing emails on behalf of the CFO. Since the emails are sent from within the company, they appear more legitimate than using an outside email account. The incident response team queries the SendOnBehalf Operation to determine if there is lateral movement, as observed in the following image:
SendOnBehalf events

The image above shows that the user joey@cyberteamir[.]onmicrosoft[.]com has sent several emails on behalf of maxt@cyberteamir[.]onmicrisoft[.]com. his behaviour may not be suspicious if Joey regularly sends emails on behalf of Max; however, using timestamp analysis and the email subject this might require further investigation. Another interesting piece of evidence that is stored in this record is the 'ClientProcessName'. This operation records the application used to send out emails and when combined with other sources of evidence, such as timelines or artefacts of program execution, it might indicate which system was used to send out the emails.
Suspicious login activity

Suspicious logins from a user's email account may indicate a compromise. Suspicious logins can include multiple failed attempts in a short period of time, logins at unexpected hours of the day, and/or logins from foreign locations. The following operations can be used to search for suspicious logins:
  • MailboxLogin;
  • UserLoggedIn;
  • UserLoginFailed;
  • PasswordLogonInitialAuthUsingPassword;
  • ForeignRealmIndexLogonInitialAuthUsingADFSFederatedToken;
  • PasswordLogonInitialAuthUsingADFSFederatedToken;
  • ForeignRealmIndexLogonCookieCopyUsingDAToken;
  • PasswordLogonCookieCopyUsingDAToken.

Example: It is suspected that a threat actor accessed a shared email account for an organization's finance department and stole a large sum of money. The incident response team queries the operation, UserLoginFailed, to determine if there were multiple failed attempts and if they originated from a foreign location, as observed in the following image:
Failed logins from multiple sources

Analysis of this data indicates a threat actor likely attempted a brute force attack because the failed logins are rapidly sequential. Furthermore, the failed login attempts originate from two IP addresses, which may be considered suspicious if those addresses unknown to the organization.

Another method to detect suspicious login activity is through geo-location analysis. The IP addresses can indicate if they are likely associated with the organization or threat actor based on geo-location. This notion is achieved through a WHOIS lookup to find the location associated with an IP address. For example, if the organization is based in Europe and doesn't have a presence anywhere else, it is not expect to see logins from Asia or North America, as displayed in the map below. Furthermore, the geo-location may provide insights into the location of the threat actor.

World map for showing login locations


We hope that sharing this knowledge, tooling and experiences of BEC investigations is helpful and encourages other organizations to share their knowledge. Analyzing the UAL can be a challenge but hopefully, our insights about identifying and analyzing suspicious behavior in the UAL can support incident responders and their investigations. As mentioned, the majority of BEC attacks likely include at least one of the following tactics: creating email forwarding rules, lateral movement to gain access to other inboxes, and suspicious login attempts. There are additional tools or techniques that can help investigate a BEC attack but the mentioned techniques are some of the most helpful.

This post also concludes our series on Responding to Business Email Compromises and we hope you enjoyed it as much as we did. We have some new and upcoming research on BEC investigations that will be presented later this year at the SANS DFIR Summit 2019 in Prague. If you have any further questions on this topic or want to know more about the awesome stuff we do in our Incident Response team, please reach out.


Popular posts from this blog

Importing Windows Event Log files into Splunk

How to respond to a Business Email Compromise - Part 2