Once again, non-human access manifests as a significant blindspot in organizations’ identity layer. Midnight Blizzard, the Russian state-sponsored actors, were abusing OAuth applications as part of their attack against Microsoft’s corporate environment. Microsoft’s Office 365 email server was breached, and internal email correspondences of Microsoft employees’ were exposed.
In the initial disclosure of the incident, Microsoft revealed that the threat actors achieved initial access via password spraying. However, the initial access only granted them limited permissions to the Microsoft tenant. A few days later, Microsoft published a thorough analysis of the techniques that allowed the threat actors to achieve and maintain access to Microsoft’s own Office 365 Exchange server. This blog provides a summary of the attack flow and recommendations on how to ensure your environment is not vulnerable to such OAuth abuse.
Abusing deprecated OAuth application for Privilege Escalation
The Midnight Blizzard APT group was able to find an unused, deprecated OAuth application with the full_access_as_app role to the Office 365 Exchange server.
This kind of application essentially allows any user in the tenant, even one with very limited permission, to generate valid access tokens to Microsoft’s own Exchange server and access the mailboxes of other Microsoft employees in the Office 365 tenant.
The threat actors abused this application to generate tokens and target Microsoft corporate mailboxes.
How to protect yourself against this attack technique?
- Security posture review: start by reviewing all the non-human identities in your organization’s Microsoft tenant to detect deprecated unused OAuth apps. This can be done on Azure Entra ID’s “Enterprise Applications” page. Deprecated applications should have their permissions limited or removed.
- Certain permissions to different Microsoft services essentially allow a non-human identity, in this case, an OAuth app, to impersonate users and access the service in their stead. In this attack, the application received the ApplicationImpersonation permission, allowing full impersonation to the Office 365 Exchange server. Enabling applications to impersonate users is very risky. Permission to use such applications should be closely monitored and reviewed.
- Anomaly detection: Non-human identities such as OAuth apps, API keys, and service accounts should be monitored continuously – any anomalous behavior should flag these identities for immediate review. In the Microsoft attack, Anomaly detection could have alerted about the abuse of the OAuth app earlier, and the attackers could have been caught faster.
To learn how the OAuth framework works, the inherent downsides of OAuth, and what makes it so lucrative for attackers to try and exploit register to a live workshop: How attackers exploit non-human access.
Backdooring the Microsoft tenant using OAuth applications
The threat actors knew that user accounts are heavily monitored, and thus, their access through compromised users is short-timed.
They overcame this obstacle by creating new OAuth applications and consenting to them using newly-created users. The attacker abused this to circumvent remediation efforts and maintain their access to the compromised tenant by utilizing this backdoor.
How to protect yourself against this attack technique
- Consider whether users can freely consent to OAuth applications and require administrator approval for the process.
- Block users from creating new App registrations within the tenant.
How did the threat actors access private corporate email accounts?
In their report, Microsoft claims that the threat actors managed to initially compromise only an unused Azure test tenant. So, isn’t it strange that by abusing a simple OAuth app, the threat actors were able to escalate privileges from a test account to reach corporate email accounts of Microsoft executives?
Below we will illustrate one of the possible scenarios in which a threat actor would be able to read emails of one tenant using an OAuth app from a different tenant.
Let’s say we have two Azure tenants: a test tenant named test.cloud, a production tenant named prod.cloud and a few other production tenants. One of the company’s programmers creates an OAuth app whose goal is to serve all of the production tenants. For testing purposes, the developer first creates the OAuth app in the test.cloud tenant, before deploying the same app in the prod.cloud tenant. In order for the app to function properly, it requires the full_access_as_app Office 365 Exchange Online permission, so the programmer configures this permission for the app.
To test the OAuth app and make sure it works properly, the programmer installs it on test.cloud and checks with their test user. After verifying that it works successfully, the programmer wants to make sure that the app functions properly cross-tenant, before deploying it to production. So they log in to the prod.cloud tenant and give admin consent to the app. They check that the app works properly, and after they’ve done that, they deploy it in prod.cloud and connect it to the other tenants.
All’s well that ends well, right? Not really.
The programmer forgot to delete the OAuth app from the test.cloud tenant, and now anyone who has permissions to this app has full access to all of the mailboxes both in test.cloud and prod.cloud.Â
This is a possible scenario (and not an uncommon mistake) of what happened in Microsoft’s environment. The Midnight Blizzard APT group managed to gain access to one of the users in Microsoft’s test tenant via password spraying, which had permissions to manage the test app. This means that all the threat actors needed to do was to access the OAuth application’s secret and gain access to the mailboxes on the production tenant.
Non-human access is again the path of least resistance
Non-human identities rapidly become the go-to target for attackers, who know these identities are usually over-privileged and under-monitored. We see security features offered by the Microsoft platform are underutilized, even by Microsoft themselves in this case. Non-human identities are not subject to the same scrutiny as human (user) accounts are – they do not undergo periodic review and their activity goes unmonitored.
Azure Entra ID and Office 365 environments are not the only ones susceptible to OAuth abuse or non-human attacks. Most environments today utilize non-human identities, particularly OAuth applications. This includes corporate directories, engineering platforms, intra-org workflow builders, chat applications, CRMs and others.
Unfortunately, it is very difficult to properly maintain these security practices in the world of non-human identities. Most environments and platforms do not offer ways to easily manage these identities, let alone monitor their continuous activity.
Astrix can help you avoid OAuth attacks
The Astrix security platform enables you to gain control over the non-human identity layer by monitoring your core systems for rogue, over-privileged, and redundant connections (external or internal). It also provides you with real-time behavior analysis alerting you immediately when an access token is compromised or abused. If you have any questions or would like to learn about how Astrix can help you stay protected from such vulnerabilities, let’s chat.
To learn how the OAuth framework works, the inherent downsides of OAuth, and what makes it so lucrative for attackers to try and exploit, register to the live workshop: How attackers exploit non-human access.
