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.
- Initial Access – Password Spray On The Test Environment.
- Authenticated Enumeration – Enumerate Roles and Permissions.
- Lateral Movement – Pivoting From Test To Production Environment.
- Persistence & Privilege Escalation – Illicit Consent Grant Attack
- Goal – Read Corporate Employee Emails.
Microsoft & RBT Security Enviroment
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 Environment
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 the below user by typing in the commands below.
#User : newdeveloper@testrbtsecurity.onmicrosoft.com
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 holds the privileged role of 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.
MultiTenantProdApp – API permissions
- AppRoleAssignment.ReadWrite.All – This permission enables reading and writing of app role assignments across all resources in an Azure AD tenant. It is typically used 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.
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 MultiTenantProdApp might have access to the product environment, we will create a set of keys to authenticate access to the production environment.
AppID: 2db432c1-4cc5-4ce2-8339-0fb2a9ec0275
TenantID: b65e7a93-8720-4c56-9116-f2b83073f205
SecretID: _y28Q~DICirCXVYK.GOM~a1slIFnf6OsHRYmDbjQNext, 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-configurationProd Tenant ID: b65e7a93-8720-4c56-9116-f2b83073f205
Lateral Movement – Pivoting From Test To Production Environment
Now that we have obtained all the necessary information, use the command below to authenticate the production environment and verify the secret key.
App ID:2db432c1-4cc5-4ce2-8339-0fb2a9ec0275
Secret ID:_y28Q~DICirCXVYK.GOM~a1slIFnf6OsHRYmDbjQ
Tenant ID:b65e7a93-8720-4c56-9116-f2b83073fUse 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-subscriptionsIt 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 reading and writing of app role assignments across all resources in an Azure AD tenant. It is typically used for applications or services that require programmatic management of app role assignments in 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 – Illicit Consent Grant Attack
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 below permission to assign the user h4ck3d a Global Administrator role.
RoleManagement.ReadWrite.DirectoryRequirements:
PrincipalId: 7a113e4e-255d-4861-b932-299225c0c0bb
Global-Administrator-roleDefinitionId: 62e90394-69f5-4237-9190-012177145e10Obtaining 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 be abused to send spam, phishing emails, or other malicious content. This can result in reputational damage, legal consequences, and potentially the 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
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-4ce636b519f2https://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=12345We 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 ‘PersistApp‘ appID 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 underscores the importance of conducting penetration tests at least twice a year or engaging in adversary emulation assessments to confirm that 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.
Looking for a team to critically test your environment using real-world attack techniques? Explore RBT Security’s red team and penetration testing services.
Detections & Mitigations :
- 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
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.