Office 365 – Exchange rules

Office 365 – Exchange rules

13 mei 2020 #CES2021 Erik Remmelzwaal

This blog is part of our Office 365 attack & defense series. We also maintain a Github page where we share our Office 365 tools and queries.

Exchange rules can be useful in managing the emails we receive on a daily basis. For example, it allows users to automatically respond or move specific emails to specific folders. The same rules can also used to exfiltrate information. A hacker adds a rule to forward specific emails. This method is sometimes used to gain information or to intercept specific email communication in order to manipulate internal payment procedures. We’ve encountered companies that became victim of a scam where the invoices were intercepted and modified just before being delivered to the intended destination. The attackers just changed the bank account number where the money had to go to. This can become quite costly; we’ve seen one instance where attackers were able to do this with a payment for multiple vehicles. As you can imagine this was an expensive lesson for the company. These types of scams are part of what they call Business Email Compromise (BEC) scams.

The way they are executed differs per type of scam. One of the tricks is to intercept emails sent, this gives the ability to modify emails before sending to the intended recipient. There are different ways to forward emails. Most of them can be done with user privileges, others require admin privileges on the exchange server itself. Using the admin privileges, it’s possible to steal emails for the entire organization. The user privileges only allow an attacker to steal the emails for the compromised user.

User

  • Rules:Forward to
  • Rules:Forward as attachment
  • Rules:Redirect to
  • Forwarding: Forward all email

Admin

  • Mail flow: rules
  • Mail flow: connectors

Depending on your Office 365 license you have you’ll be able to use Office 365 Advanced Threat Protection (ATP). ATP is an effective solution because it already detects many of the tricks you can use to steal emails. If ATP is included in your license, make sure the alert emails are sent to someone or a group of people that can check on alerts from the system. For the purpose of this blog we assume your organization does not have ATP. Which is not a problem we can detect any of these threats with limited resources.

Enabling audit logging

For companies that have an enterprise E3/E5 license there is no need to enable logging. Without an E3 or E5 license, audit logging has to be enabled. Next to this an additional step is required. In that case, auditing has to be enabled on every individual mailbox manually. In order to do so, we have written a PowerShell script that retrieves all available mailboxes, loops over all mailboxes to individually enable the logging per mailbox. For more information see: https://docs.microsoft.com/en-us/microsoft-365/compliance/enable-mailbox-auditing?view=o365-worldwide.

We’ve added 2 scripts to fix your logging:

Connecting Exchange audit logging to Sentinel

Although using Sentinel in combination with Office 365 is free, it does require an Azure subscription. Adding Sentinel is easy, navigate to Azure portal, search for “Azure Sentinel” and select add. The wizard will guide you through, make sure to add everything to a unique resource group, it will allow you to see all related components and to see any cost you might incur. Instead of us re-iterating how to add sentinel exactly, its better to go to the source: https://docs.microsoft.com/en-us/azure/sentinel/quickstart-onboard

Creating Rules

Luckily, we don’t have to build all of the rules ourselves. Microsoft publishes some detection rules on their GIT repository. (https://github.com/Azure/Azure-Sentinel/blob/master/Detections/OfficeActivity/Office_MailForwarding.yaml) However i havent seen any complete set of rules to detect all different types. Let’s reiterate the things we want to detect.

User

  • Rules:Forward to
  • Rules:Forward as attachment
  • Rules:Redirect to
  • Forwarding: Forward all email
  • Mail Flow via ExchangeAdmin center (Administrator privileges required)

In order to build proper rules to detect the above tricks, its easiest to just create the rules and then see what type of logging shows up. So we know what we are dealing with. Using the ‘search “rulename”’ command will allow you to find entries pertaining to your rule creation. Looking for our rules the most important operations to look for are:

  • New-InboxRule with ruletype being one of the following:
    • ForwardTo
    • ForwardAsAttachmentTo
    • RedirectTo
  • Set-Mailbox with type: “ForwardingSmtpAddress”
  • New-TransportRule

Just detecting one of the above activities might incur allot of false positives as these mail rules are often used for legitimate purposes. One of the ways to reduce the number of false positives would be to filter out any internal mail forwards.

  let TimeFrame = 1d;
  let domains = dynamic(["zolder.io" "rwxsecurity.nl"]);
  OfficeActivity
  | where TimeGenerated >= ago(TimeFrame) 
  | where Operation == "Set-InboxRule"
  | extend details = parse_json(Parameters)
  | extend ruletype = tostring(details[0].Name) 
  | where ruletype in ( "ForwardTo" , "ForwardAsAttachmentTo", "RedirectTo")
  | extend forwardaddr = tostring(details[0].Value) 
  | extend forwarddomain = tostring(split(forwardaddr, "@")[1])
  | where isempty(forwarddomain) == false and forwarddomain !in (domains)
  1. Create an array of valid forward domains
  2. Parse the forward address
  3. Only trigger if the forward domain is not in our whitelist

There is a disadvantage to doing this, its unclear if Microsoft ever chooses to modify the order of the Parameters object. Once this changes we would not trigger. Unfortunately, the parameter order changes per operation.

Caveat

While testing a rule to detect the creation of multiple forwarding rules across different users within one organization. So, I asked Wesley to add some extra rules. After waiting for a couple of minutes my rule failed. I asked Wesley if he added a rule and asked the rule-name. Turns out Wesley didn’t want to add new rules, so he copied an existing one. Those are modified using the “Set-InboxRule” function which is not part of our and the Microsoft provided rule. Turns out the ATP suite has a broader set of detections and already detects rules created via “Set-InboxRule”. For those that don’t have the luxury of ATP we can create a set of different rules.

Based on our experience a more complete set of operations to detect would be:

We could create one rule-to-rule them all, but it would be easy to make a mistake. Better to have atomic rules that detect one specific thing. This makes testing easier and the rules are easier to understand. The rules are available in our Github repo, dont forget to change the valid domains.

Yet another caveat: As if there aren’t enough deviations we have to contend with there is another way of adding rules. The EWS API has the “UpdateInboxRules” operation. Logging for this operation lacks information, there doesnt seem to be a way to have propper logs for this. A way to solve this would be to log into our Exchange instance and query them with the “Get-InboxRule” cmdlet. Unfortunately it only returns the name of the rule but often lacks any additional information. The only way to get those is through the EWS API and for each user search through their inbox to find the rules. There is a usefull script in the O365-InvestigationTooling Github repo that dumps all rules and forms. A nice future project would be to create a playbook that triggers once the “UpdateInboxRules” operation is spotted, queries the rules and checks for irregularities.

Conclusion

Mailbox rules are just one of the methods criminals try to maintain access to your emails. Storing audit logging in a tool like Sentinel will give your organization the ability to look back once something goes wrong. Using Sentinel in combination with Office 365 is free and even has 90 days retention, it’s a no brainer for any organization using Office365[1]. In future blogs we’ll discuss other detection methods related to BEC fraud. And how to respond once an attacker has gained access to one or more user accounts. In a future blog we’ll go more into the BEC fraud tactics, we plan on releasing rules and scripts to detect BEC-specific abuse.

[1] Storing different logs or creating playbooks can incur additional cost.