Securing Your Microsoft Environment After the Midnight Blizzard Attack

Originally published by Reco.

Written by Oz Wasserman.

Introduction

The attack on Microsoft's SaaS-based Entra environment by Midnight Blizzard (aka Nobelium, Cozy Bear or APT29) was notably one of the most sophisticated attacks seen on similar platforms. This incident, spanning from November 2023 to January 2024, targeted Microsoft's corporate email through a vulnerable Entra test tenant. The lack of Multi-Factor Authentication (MFA) was a key weakness that allowed the attackers unparalleled access to the corporate emails, underscoring the urgency for robust security measures in SaaS environments.

In this blog post, we'll go over the details of the attack thoroughly. While some aspects of the attack remain undisclosed by Microsoft, our goal is to provide you with a comprehensive analysis that includes actionable recommendations on how to protect from these type of attacks.

‍

Analysis of the attack

The attacks were generated following steps and maneuvering between the Microsoft test tenant and the Microsoft corporate tenant, all with sophisticated evasion techniques and high leverage of the Microsoft Entra permission mechanism.

Diagram visualizing the origin of the attack on Microsoft's Entra environment by Midnight Blizzard.

Step 1: Initial Access

The report by Microsoft suggested that the initial access of the attack by the adversary group was achieved by a password spray to find an account with a weak password that is guessable and can be broken into using password guessing techniques. The group eventually got their hands on an account that had access to a legacy application that was installed on a Microsoft test environment.

In order to understand the next steps of the attack, it's important to be familiarized with Microsoft’s Azure Entra ID permission mechanism to 3rd party applications registered on the tenant.

• Registering an application with Microsoft Entra involves creating an identity configuration for it within a tenant, allowing integration for identity and access management. This process involves specifying the application's operational context as either single or multi-tenant.
• Upon registration, an application object and service principal are automatically generated in your home tenant.
• An application object defines the identity for a software application within its registered tenant, serving as a foundational structure for authorization and access control in cloud resources.
• A service principal is an instance of the application within a directory or tenant, granting it specific permissions to access resources or perform tasks under that application's identity.

This setup facilitates controlled access to resources, with further customization available through secrets, certificates, and branding adjustments. In the attack situation however - this allowed the adversary to evade detection on the Microsoft corporate tenant

The user likely created a secret to be authenticated as the legacy app, and perform action on the app’s behalf.

Step 2: Privilege Escalation

Given the mechanism of applications and service principals, and despite the test environment being separate from the corporate environment, that same legacy application that compromised account had access to also had elevated permission to the corporate tenant in Microsoft. That means that the legacy application from the test tenant was instantiated as a service principal in the Microsoft corporate tenant. It seems that the same service principal has given the adversary global administrator rights in the Microsoft corporate tenant. (the results were one of the following MS graph app roles: AppRoleAssignment.ReadWrite.All or RoleManagement.ReadWrite.Directory).

A view of the legacy app permissions.

‍Step 3: Lateral Movement

‍After gaining elevated permissions in the Microsoft corporate tenant, the attacker registered additional OAuth applications. It remains unclear whether these were initiated by the initially compromised account or a secondary application, and whether they were set up in the test environment or the corporate environment. Given the sophistication of this nation-state APT group, it's reasonable to believe that they avoided the corporate environment to evade detection, since that environment is much more monitored than the test tenant.

Additional apps registered in the test tenant.

Step 4: Lateral Movement

After creating the OAuth applications in the Microsoft test environment, the adversary created a new user in the corporate tenant, using the service principal from the second step. Since the service principal had a AppRoleAssignment.ReadWrite.All MS Graph app role, the service principal could grant itself any app role and bypass the consent process required to grant access at a high permission.

‍

Step 5: Lateral Movement

The adversaries then leveraged the newly created user with the high privileges to consent the newly created applications on the test tenant. In OAuth, users can permit apps without admin rights, resulting in elevated permissions in the Entra test tenant, which lead to creating service principals for these apps in the Microsoft corporate tenant. This enables attackers to use credentials from a test tenant to authenticate as these apps in a production tenant, leveraging this mechanism for unauthorized access.

‍

Step 6: Persistence

‍The adversary assigned the "full_access_as_app" exchange web services role to the newly created service principals, enabling extensive control over the Microsoft corporate tenant. This level of access required high-level Entra privileges, typically reserved for roles like Global Administrator. Through specific MS Graph API endpoints, they could grant themselves any role, achieving total control over Microsoft's environment and reading all email inboxes.

The “full_access_as_app” permission of one of the malicious apps. The newly created service principals used these roles in the corporate tenant.

Step 7: Exfiltration

The adversary leveraged newly obtained permissions to infiltrate Microsoft employee email inboxes. By employing malicious OAuth applications and the "full_access_as_app" role assigned to service principals, they gained unrestricted access to the email communications of Microsoft employees, indicating a significant breach of privacy and security. This step marks a critical point in their access capabilities, highlighting the severity and sophistication of their intrusion into the corporate environment.

‍

Recommendations

This attack sophistication and depth can be challenging to detect. However, it is important to ensure that attackers will not leverage the same TTPs on your environment. Below are a few recommendations to defend against similar attacks.

• MFA Enforcement: Multi-factor authentication (MFA) in Entra ID tenants adds a layer of security that could prevent password spray attacks by requiring additional verification beyond just username and passwords.
• Unauthorized Application Consent Prevention: Restricting user consent for third-party applications reduces the risk of malicious access, ensuring only verified apps can be granted access to organizational data.
• Threat Detection Monitoring: Continuously keeping an eye on unusual activities, such as granting high-level permissions to OAuth apps, unexpected role assignments, unusual creation of secrets or certificates, consent to third-party apps, and the addition of new service principals, helps identify and mitigate potential security threats in Microsoft.

‍

Conclusion

The Microsoft Entra breach serves as a stark reminder of the constant threat to SaaS applications. In this ever-evolving landscape, SSPM solutions are vital for proactively securing your Microsoft environment, detecting suspicious activities, and preventing unauthorized access and data breaches. Monitoring and alerting capabilities provided by SSPM enable organizations to protect their identities and data against emerging threats.