Microsoft lost its key !

Written by Yves



September 7, 2023

Introduction

Coincidence or not, the discussions between Tony Blinken and Chinese government representatives about important business affairs took place at the same time as a hacking group got access to email accounts of US governmental agencies.

The extent of the later communicated flaw can be larger than we think, and it demonstrates how crucial cloud-based identity provider became.

Storm-0558 is known to be focusing on Western Europe government agencies espionage, data theft and credential access (1) (5), and historically interested in targeting media companies as well as telecommunications equipment and service providers. This group is also used to work with token-theft patterns with Microsoft Accounts since August 2021.

But, what happened, what does this mean, and, more importantly, what must we do to mitigate or avoid this type of attack ?

That is what we are going to see in this post.

Summary

May 15th, a Chinese supposed hacker group, called by Microsoft storm-0558, got access to around 25 accounts of US-government agencies.

But it’s only 1 month later that one FCEB (Federal Civilian Executive Branch) agency reported the suspicious activities to the CISA (3), triggering the analysis and investigation by Microsoft of the events.

Since this time, Microsoft contacted and worked with all the impacted organizations via the tenant administrator contact, providing guidance on how to investigate and to lift the threat.

After having found that the hackers were using forged authentication token, using a compromised signature, Microsoft took the remediation actions, ending the fraudulent activities the 4th of July by blocking the usage of the token forged by the stolen key in OWA to protect enterprise organizations, and replaced the master key to prevent the attackers to forge new tokens. Finally, they blocked the usage of tokens issued previously for consumers.

How was it done ?

To get access to the accounts mailboxes, the storm-0558 group used the Outlook Web Access (OWA) APIs. However, in order to access these APIs, you – or the application calling the API – must be authenticated first. To guarantee the authentication, the APIs require an access token, which is signed by an identity provider. This mechanism is called OAuth2 Auth Code Flow, and the schema below shows how such access token can be generated and validated.

(image from : https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow)

The web API – here, the OWA API – validates the access token by checking the signature. For this, it uses one of the published public key, which will confirm, or not, the validity of the token. Also, remember that the public key corresponds to a private key, that is supposed to be……secret.

Unfortunately, this is such a private key that storm-0558 was able to get, even though, this key was expiring the 4th of April 2021 (9). As a consequence, the hackers were in the position to sign the access tokens to get access to the OWA APIs, which deemed to be legitimate.

In addition, they used a private keys which should only be working for Microsoft Accounts (MSA – for consumers using outlook.com), and not for AAD accounts (for enterprises) as they are issued and managed by separate systems and which are supposed to validate only their respective signatures.

In the technical details, when accessing the mailbox, the MailItemsAccessed event is recorded by the audit systems of Microsoft, and what raised the interest of the FCEB agency was that an unexpected ClientAppID and AppID was used to access the mailbox.

Unfortunately – or, fortunately for this agency – these records are only available for analysis to the G5/E5 level of the Office 365 subscription, so the highest level of subscription, which includes Microsoft Purview Audit Premium.

This access to these logs has a price, 21$, and only a limited number of customers subscribed to E5 (12% in FY22- (7), 50%+ of 10M$+ of M365 bookings from E5 (6) ). Indeed, lower level of subscription, such as E3, don’t give access to these detailed logs and, moreover, limit their age to 7 days (8).

Is it the end ?

Since this event, Microsoft released several elements to inform and support organizations to either get rid of this unauthorized access or to ensure similar other attacks were not ongoing.

The first element is a playbook (10) with a decision tree, which guides the organization step by step to identify such potential attack and including a configuration guide for Microsoft Sentinel in order to add the detailed event logs to be analyzed in case of such attack.

They also released a new version of the Microsoft.IdentityModel (12) and Microsoft.Identity.Web (13) libraries, used by the developers to integrate and use federated identity providers, such as the Microsoft Identity platform.

In July, Microsoft added more than 30 events and increased the logs default retention period from 90 days to 180 days into Purview Audit Standard at no additional cost (14), which will not make it an exclusivity for the highest subscriptions.

As Microsoft has immediately contacted the impacted organizations, this keeps several questions open, and this will certainly not help Microsoft in a context where the US government is working on a cyber security strategy for the cloud (SCuBA project – Secure Cloud Business Applications Project – (2)) and is working with Microsoft on this topic (4)

The essential question is how storm-0558 got access to the private key they used to forge the access tokens ?

This is only yesterday, 6th of September, that Microsoft issued the last results of their investigation. In the article (11), it is explained that two distinct and not related elements put together made the attack possible :

1.- A crash of a system which generated a dump containing the key, AND, a compromised engineer’s corporate account in their debugging environment which enabled the exfiltration of the key by Storm-0558

2.- No automatic scope validation in the libraries used for token validation, which made enterprise email APIs accepting a consumer key.

Both of these items got corrected, but do we know if only email accounts were impacted ?

At this stage, none of the articles published by Microsoft mentions other applications than the email system. But, because 3rd party applications may have used the previous version of the Azure SDK, these might have been vulnerable too.

To the least, these applications must be updated in order to use the latest version of these packages.

Also, applications storing locally public AAD keys may still be at risk if the cache has not been dumped since the attack. The practice would be to clean this kind of cache every day.

Key Take Away

What needs to be taken away from this experience :

Check if your organization is compromised, even though Microsoft should have contacted it.
Now use the Microsoft Purview Audit Premium.
Ensure that the latest SDK versions are used in the applications.
Do not locally cache the keys.
Think about the criticality of the cloud identity providers.