Microsoft (unintentionally?) exposes inactive mailboxes content via the EWS API

There has been some fuzz in Exchange Online lately, largely due to some upcoming deprecations. EWS is going away, and so are some of the audit-related cmdlets. In turn, Microsoft has been busy updating the backend to enforce these deprecations. But where there is change, there is also the possibility for undesired behavior to creep in… especially given the poor quality controls we’ve come to be accustomed with in the cloud service.

Whether intentionally or not, we can now access the content of Exchange Online inactive mailboxes via the EWS API. As a refresher, inactive mailboxes are mailboxes that were put on hold before the corresponding user account is deleted. They are positioned as an alternative to the “convert this mailbox to shared one to keep data around” type of scenarios, compared to which they offer some benefits. Not the least important one of them being that inactive mailboxes are free of charge, and you can keep data stored in them indefinitely.

On the other hand, inactive mailboxes cannot be accessed by end users and cannot be configured in email clients. Thus, they are not a good fit for scenarios where you need frequent access to the content held in them. In addition, inactive mailboxes cannot be used to receive or send messages. You can think of them as “cold” storage, with data kept for compliance purposes only, as opposed to having it readily available to work with. Inactive mailboxes are transparent to most admin tools, too. The only way to access the content within an inactive mailbox is by executing an eDiscovery query or Content search. Admins can also restore or recover inactive mailboxes to enable access to their content.

So that’s the theory. As it turns out however, at the time of writing this article we can use the EWS API to access inactive mailboxes content, without having to bother with admin or compliance tools. Well, you still need to have an application with sufficient permissions configured, specifically the EWS impersonation scope. Other than that, there are no prerequisites. I suppose you should also know the SMTP address of the mailbox(es) in question, as we need it for the impersonation bits.

To illustrate how you can leverage the EWS API to access content stored in inactive mailboxes, we can use the standard flow: obtain an access token for the ExO resource, create an Exchange service object and stamp the token on it, then impersonate the user and run some queries against the mailbox. In the example below, we will be leveraging application permissions, as authentication is easier to handle with those. Plus you still need to impersonate the user either way.

#Load the MSAL binaries
Add-Type -Path "C:\Program Files\WindowsPowerShell\Modules\MSAL\Microsoft.Identity.Client.dll"

#Obtain an access token
$app = [Microsoft.Identity.Client.ConfidentialClientApplicationBuilder]::Create("xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx").WithClientSecret("xxxxxxxxxxxxxxxxxxxxxxxx").WithTenantId("tenant.onmicrosoft.com").Build()

$Scopes = New-Object System.Collections.Generic.List[string]
$Scope = "https://outlook.office365.com/.default"
$Scopes.Add($Scope)

$token = $app.AcquireTokenForClient($Scopes).ExecuteAsync().Result

#Load the EWS binaries
Add-Type -Path 'C:\Program Files\Microsoft\Exchange\Web Services\2.2\Microsoft.Exchange.WebServices.dll'

#Create Exchange service
$global:exchangeService = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService([Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2013)
$exchangeService.Url = "https://outlook.office365.com/EWS/Exchange.asmx"
$exchangeService.Credentials = New-Object Microsoft.Exchange.WebServices.Data.OAuthCredentials -ArgumentList $token.AccessToken

#Impersonate the user
$exchangeService.ImpersonatedUserId = New-Object Microsoft.Exchange.WebServices.Data.ImpersonatedUserId([Microsoft.Exchange.WebServices.Data.ConnectingIdType]::SmtpAddress, "inactive@domain.com")

From here on, you should be able to use any of the standard EWS methods to work with items stored in the inactive mailbox. For example, we can enumerate all the folders under the Top of Information store via the FindFolders method:

$RootFolderID = New-Object Microsoft.Exchange.WebServices.Data.FolderId([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::MsgFolderRoot)
$RootFolder = [Microsoft.Exchange.WebServices.Data.Folder]::Bind($exchangeService,$RootFolderID)
$View = New-Object Microsoft.Exchange.WebServices.Data.FolderView(10000)
$View.Traversal = [Microsoft.Exchange.WebServices.Data.FolderTraversal]::Deep
$res = $RootFolder.FindFolders($View)

The screenshot below gives us a quick comparison between the set of folders obtained using the above method and the set of folders obtained via the Get-MailboxFolderStatistics cmdlet (remember to use the –IncludeSoftDeletedRecipients switch). In both cases I have applied a filter to only show folders with non-zero items.

In the same manner, you can leverage the FindItems method to fetch items stored within a given folder within the inactive mailbox. This includes items in the RecoverableItems subtree. For example, to query the contents of the Purges folder, we can use something along these lines:

$SearchFilter = New-Object Microsoft.Exchange.WebServices.Data.SearchFilter+IsEqualTo([Microsoft.Exchange.WebServices.Data.EmailMessageSchema]::ItemClass, "IPM.Note")
$View = New-Object Microsoft.Exchange.WebServices.Data.ItemView(1000) 
$Result = $exchangeService.FindItems([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::RecoverableItemsPurges,$SearchFilter,$View)

$Result.Items[0]
$Result.Items[0].Load()
$Result.Items[0].Body.Text

Keep in mind that the Top of information store/user-accessible subtree might be a bit barren, depending on retention policy processing and whether the mailbox had an Online archive provisioned (as MRM processing on inactive mailboxes was still happening back in the day). Either way, as shown in the example above, we can use the same method to cover the  content of the RecoverableItems subtree, where any items on hold are kept. Similarly, if the mailbox has an Online archive, you can query the ArchiveRecoverableItemsRoot subtree instead.

It is also worth noting that access is not limited to read-only operations. In fact, you can move and delete existing items and folders, create new ones and so on. The good news is that the compliance checks and controls still apply – you cannot remove items from the Purges folder for example. On the same note, you can use (most) other EWS methods, such as the GetDelegates one. A somewhat worrying fact is that you can also access the content of the Audits folder, which was never possible thus far.

Unlike using the EWS methods, none of the oddities listed above can be reproduced via the Graph API. Interestingly though, some of the calls made via Graph result in 504 Gateway Timeout response, which leaves some room for interpretation. Then again, the Graph API is not known for being very consistent in the error handling department, is it…

So in summary, something fishy is going on with EWS in Exchange Online, as the API now allows you to access content that that has historically been inaccessible. All signs point to this being an unintentional change, and frankly one that makes zero sense, given the upcoming deprecation of EWS API support in the service. Whatever the reason, the fact remains that we can currently use the EWS API methods to access content stored within inactive mailboxes, which I strongly believe is something Microsoft 365 customers should be aware of!

P.S. If you prefer not to use code-based examples, the good old EWS Editor tool should give you a simple way to test this.