January 30, 2024 •Thijs Lecomte
On the 17th of January, Microsoft published a very short and vague article on how a Russian Threat Actor, Midnight Blizzard, was able to access emails from Microsoft’s senior leadership team by receiving access to a legacy, non-production test tenant by executing a password spray attack.
After this was published, there was much discussion within the community about the attack details. It made no sense that a non-production environment had access to the production mailbox of the upper management team. This conversation was spiked by another article released on the 25th of January. This article went into some more detail on how the threat actor was able to access emails after the initial password spray.
What happened exactly?
There are some interesting statements in this article, that cause more questions than answers:
- Midnight Blizzard leveraged their initial access to identify and compromise a legacy test OAuth application that had elevated access to the Microsoft corporate environment.
- The actor created additional malicious OAuth applications. They created a new user account to grant consent in the Microsoft corporate environment to the actor controlled malicious OAuth applications.
- The threat actor then used the legacy test OAuth application to grant them the Office 365 Exchange Online full_access_as_app role, which allows access to mailboxes.
These statements are incredibly vague and don’t provide a great level of detail. My interpretation is as follows:
- The legacy environment contained an existing OAuth application that had the permission to create applications and users in the Microsoft production environment.
- With a newly created admin account, they provided admin consent to an application that had full Exchange permissions.
Both steps require a great deal of elevated permissions and are devastating to any organization. Within the next paragraphs, I want to go into more detail on each step and what the impact is.
Creating the application
After they breached the test environment, the threat actor identified a connection to the Microsoft production environment. This connection consisted of the option to create applications and users. The exact details of this connection are unknown. This was most likely achieved by an application that holds the ‘Application.ReadWrite.All’ permission.
The fact that a test environment within Microsoft has permissions to create new applications is not that abnormal. The entirety of Microsoft 365 is a multi-tenant configuration and Microsoft needs to be able to test certain configurations before putting them into production. The fact that these permissions were there was expected.
However, this does not mean no mistakes were made. The fact that this test environment was not monitored and unprotected by MFA is inexcusable. Those are steps that every organization should take.
Additionally, it appears Microsoft doesn’t do any regular auditing of their applications and their current use. Every organization should have a process in place to regularly review all permissions and revoke them if they are not valid anymore.
With the application created, the only step remaining was to grant consent to those permissions.
Providing consent
Within the article, Microsoft mentioned that the threat actor had access to ‘Office 365 Exchange Online’. This is important as Microsoft Graph permissions need to be consented to by a Global Administrator or Privileged Role Administrator. Office 365 Exchange Online permissions can be consented by a user with the Application Administrator role. While this role is still highly privileged, it’s less noisy than using a Global Administrator.
The threat actor was able to create a privileged account in the Microsoft corporate environment and use that to execute the consent. The details on how this happened are still unclear, but I suspect they used an attack similar to the script I provided in my previous article, where I discussed privilege escalation using OAuth applications. It seems strange that this was not flagged, as assignments of highly privileged roles should be closely monitored.
After they were able to create the user, they logged into the Microsoft corporate environment, granted consent and used the applications to gain access to mailboxes of senior leadership.
A heap of misconfigurations and monitoring gaps…
This attack was made possible by a series of misconfigurations and gaps in monitoring. Within this article, I want share some of these and provide you with tips and tricks on how to avoid the same happening in your own environment.
Missed Opportunity #1 – Regularly Audit Application Usage
There is no good reason for an unused application to remain in your tenant as it increases your attack surface. The first misconfiguration here pertains to a dormant application in the Microsoft production environment that allowed the legacy tenant to create new app registrations. Applications with those kinds of permissions should be reviewed regularly. The review should contain a check of whether the application is still in use.
How to Address:
Auditing usage within the Entra ID Admin Center is not easy as you need to verify the sign-in logs of an application manually. This is possible within Microsoft’s App Governance portal, but that part of the functionality is hidden behind a different license ‘Microsoft Entra Workload identities’, which is not included in a Microsoft 365 E5.
A more convenient way to audit unused applications is with ENow’s App Governance Accelerator and the ‘Suspected Stale Apps’ report, which provides visibility into the number of apps and app registrations in your Entra ID tenant, their permissions and settings, and sign-in activity. Using this App Governance Accelerator report, you can identify applications that are no longer in active use and remove them from your tenant. For organizations without Entra ID premium licenses, the ENow report includes information beyond Microsoft's 7-day retention period for audit logs and sign-ins.
Figure 1: App Governance Accelerator Suspected Stale Apps Report
Missed Opportunity #2 – Rigorously monitor roles that can consent to applications
Next, after creating an application, the threat actor created a new user with administrative rights. There are a limited number of roles (four in total) that can consent to applications. These roles should be rigorously monitored, and new assignments should be investigated.
How to Address:
A quick way to review what applications, users and privileged groups have permissions to interact with applications, is to use the ENow App Governance Accelerator ‘Accounts with Administrative Application Privileges’ report. This report provides a complete list of user objects and service principles with administrative application privileges in the Entra ID Tenant. It shows the Role Name, Role Type, Object Type, and Assignment Type for each. Using this report, you can apply mitigating measures to minimize the risk of these user objects through Conditional Access, Entra ID Protection, and other means. You could also use a KQL query on top of the Entra ID Audit Logs within Microsoft Sentinel to get role data.
Missed Opportunity #3 – Audit Full-Access Permissions
This third mistake is related to missed opportunity #1 as far as the need to audit your Entra ID data regularly. Each application that is consented, with permissions granting full access to Exchange Online, should be audited. At the very least, you should be able to correlate it to an approved change request. If you find these full access permissions with no change request, the permissions should be promptly investigated and removed if suspicious.
How to Address:
This audit process can be achieved by utilizing the ‘App registrations created in last 30 days’ report within ENow’s App Governance Accelerator solution. This report allows you to immediately see important details such as the creation date, publisher, notes and sign-in activity. An application with Exchange permissions is rated as a ‘high risk’ application within the product.
One of the standout features within App Governance Accelerator that is not possible within native Microsoft tooling is the ability to search by specific permissions used by an application. Within the ‘API permissions’ report, you can search and filter for any permissions and in return, all applications with that permission will be provided.
Figure 2: App Governance Accelerator All API Permissions Report, highlighting the Search/Filter capability.
Missed Opportunity #4 – Monitor Changes in Usage and Sign-In Activity
The fourth and final mistake I want to mention is the lack of monitoring for the usage of the malicious OAuth application. An OAuth application with application permissions is typically run as a background process. This means the origin of the sign-ins is predictable.
How to Address:
You can create KQL queries within Microsoft Sentinel to alert you when a new or unexpected sign-in happens; however, there’s an additional cost to retain historical data in Microsoft Sentinel.
Using the Sign-Ins and Suspected Stale Apps reports within App Governance Accelerator, you will see what the regular usage of an application is and if there is a change. App Governance Accelerator queries the sign-in logs in the backend and stores the history, removing the need for the additional cost Microsoft Sentinel requires.
Figure 3: Verifying recent sign-in activity
It’s not as simple as it seems.
Of course, it’s easy to provide feedback to something like this after the fact, but we cannot forget the complexity of this attack. Microsoft itself is one of the biggest companies worldwide, with an extremely complicated setup involving multiple production and test environments. Each of them interconnected to test the flow before moving into production.
Another complication is the skill of the threat actor, which resulted in a complex attack scenario. Microsoft described that Midnight Blizzard proxied their traffic through residential networks. This complicated the detection opportunities. Besides that, I imagine that other steps were taken to fly under the radar. The entire attack would be executed in the time span of a couple of weeks, to avoid executing too many noisy events in a short time span.
Strengthen your security posture immediately!
Within Microsoft’s latest article, a clear list of recommendations is present. Below, you will find an overview on how you can easily retrieve that kind of information using Microsoft tools, ENow’s free AppGov Score, and ENow’s upgraded version, App Governance Accelerator:
This hack showed how complex OAuth applications within Entra ID are and how they can create a big threat to every organization; even Microsoft fell victim to it. Security and governance around applications needs to be taken seriously and integrated into day-to-day operations.
Jumpstart your application security efforts today.
ENow has produced a community-driven free tool that can quickly examine your tenant and compare your application settings to Microsoft recommended practices and give you a quantifiable score. As it relates to helping ensure your organization does not fall victim to a similar hacking attempt, the tool will help you determine if your tenant’s consent settings are configured in the best way. Sign up to receive your AppGov Score to uncover how many risky apps exist, how many were created in the last 30 days, how many apps do not have role assignment, what % of apps have not been admin consented and more. Quantify your organization's overall Entra ID application governance position so you can immediately begin improving security. ENow’s AppGov Score can quickly get you on the right track by providing crucial insight into your current configuration by identifying any potential misconfigurations.
Do you know what apps are lurking in your tenant? The ENow AppGov Score is a free security assessment tool that will quantify your application governance state quickly. In addition to providing your AppGov Score, the tool will provide a comprehensive Application Governance Assessment report that includes each test, your result and why the test matters. Sign up to get your score and assessment report in just a few minutes - Get Your AppGov Score today!
Written by Thijs Lecomte
Thijs is a security consultant out of Belgium, working at The Collective, an MSSP with a Microsoft-focused Security Operations Center. He work consists out of leading the SOC team and implementing Microsoft Security solutions (such as Microsoft Sentinel and Defender) as a consultant. He is an MVP in the Security category and is a regular speaker at events and user groups. His best-known publication is as co-author of the 'Microsoft 365 Security for the IT Pro' ebook.