Recently threat actors like Midnight Blizzard use the OAuth applications in tenants that they can misuse for malicious activity. Actors use compromised user accounts to create/ modify and grant permissions to OAuth applications in tenants and move across test and production tenants.

Commonly the actor created additional malicious OAuth applications to maintain access to applications, even if they lose their initial access.

This blog includes some basic hardening tips related to app registrations/ OAuth applications and sources to protect against similar attacks.

The situation related to Microsoft

Recently the Microsoft security team detected a nation-state attack targeted at corporate systems on January 12, 2024, Microsoft identified the threat actor as Midnight Blizzard, the Russian state-sponsored actor also known as NOBELIUM.

Interesting are the steps related to the attack and the use of the OAuth application to move from the test tenant to the production tenant. Below are the high-level steps from password spraying to access to the mailboxes in the Microsoft production environment:

NOTE: This is all based on the publicly available documentation; not 100% sure if this method was used during the recent Microsoft Attack. All it gives an idea of how the flow works.

Step 1: Password spraying to compromise a legacy non-production test tenant account without MFA.

Step 2: Use the identity foothold to identify and compromise a legacy OAuth application with elevated access to the Microsoft corporate environment.

Step 3: The actor then created additional malicious OAuth applications and created a new user account to grant consent in the Microsoft corporate environment to the actor-controlled malicious OAuth applications or use additional API permissions for app consents.

Step 4: The threat actor used the test OAuth application to grant the full_access_as_app role as part of Office 365 Exchange online, which allows access to the mailboxes.

As seen in the steps above the actor uses two main components; password spraying and the use of a malicious OAuth with elevated access to different tenants.

More information (must read): Microsoft Actions Following Attack by Nation-State Actor Midnight Blizzard & Midnight Blizzard: Guidance for responders on nation-state attack | Microsoft Security Blog

Another interesting topic (X): https://twitter.com/cnotin/status/1751028257405665773

Simulating the attack

Simple attack overview

Important: This is based on a simulation and is not the same as the attack that happens within the Microsoft tenants since not all details are publicly available, all it gives an idea of how the flow works from one dev/test environment to production with the use of OAuth apps.

It is quite simple to pivot from one tenant to another tenant with the use of OAuth applications. When we read the report Midnight Blizzard leverages via initial access (password spraying) a legacy test oAuth application that had elevated access to the Microsoft corporate tenant.

Test tenant

Let’s assume the app is created in the test tenant with the name (Test OAuth application) the following will be visible in the tenant:

The app with the name Test OAuth application is scoped to multiple organizations as the supported account types

The app is not consented with the powerful Directory,ReadWrite.All app. As you can see the status is showing “Not granted for tenantname”

When the app is compromised via Application Administrator Entra built-in roles it is possible to add additional credentials to the app via the compromised user. With this, we can add credentials to the app.

With the collected credentials it is possible to authenticate the identity of the application via the Service Principal. Since the app is not granted for the tenant there are no permissions consented. So it is not possible to perform any actions like creating a group or users via the collected Service Principal.

The message; New-MgGroup_CreateExpanded: Insufficient privileges to complete the operation.

Switch to a different tenant (production)

Now the interesting part is with the switch from the “test tenant” to “production”. For this simulation, we are switching to production and sign-in as a legit admin and consenting to the requested permissions in the tenant via: 

https://login.microsoftonline.com/common/adminconsent?client_id=<client ID of app from test tenant>

As a result, the admin can consent to the application. NOTE: The image below is from the “production” tenant, and not the tenant where the Test OAuth app is created.

After hitting Accept the Service Principal/ Enterprise application is created in the “production” tenant. The same applicationID is used as visible in the other tenant. So now we consented to the app located across multiple tenants.

Now the interesting part; the API permission “Directory.ReadWrite.All” granted in the app is now part of the production tenant. Since the admin consented to the application, it is automatically assigned.

Production tenant

Status: Permissions granted via admin

Test tenant where the OAuth app is created

Status: Permissions not granted

Now you can see how “easy” it is to reuse the OAuth app and include the permissions. Now we can authenticate via the same app ID and credentials and target the production tenant.

Bingo! The group is created in the production tenant authorized via the service principal collected during the earlier steps in the first tenant. Now this is just a group; all you can do is anything much worse when the permissions are available (create users/ new accounts/ new apps) and more dangerous stuff.

When the MS Graph API permission Application.ReadWrite.All consent it is possible to create additional malicious OAuth applications in the production tenant and leverage access based on new OAuth applications.

New OAuth applications created

Based on the report from Microsoft the attackers created new OAuth applications in the production tenant with elevated/ new permissions.

There is a change in the OAuth app in the production tenant including the AppRoleAssignment.ReadWrite.All permission.

With the Graph API permission in prod, it is possible to add new OAuth apps and grant permissions to useful permissions like the Office 365 Exchange Online full_access_as_app role, which allows access to all mailboxes in the tenant.

IMPORTANT: The AppRoleAssignment.ReadWrite.All MS Graph app role bypasses the consent process. This is by design, which allows the creation of new apps with all the permissions. As it allows granting any app-only permissions, including the RoleManagement.ReadWrite.Directory. This can be used to give anyone or an app higher privileges including administrator rights.

Protection/ Mitigations

Entra ID basics

The following mitigations can be changed/ configured in the tenant to limit the risk of the creation of OAuth applications.

By default, each/ any user can create app registrations and consent to the Microsoft Graph permissions. When this control is hardened, the ability to create app registrations requires the following roles:

  • Application Administrator
  • Cloud-Application Administration
  • Global administrators

Administrators are needed to consent to permissions used by the application in the tenant. To restrict the attack surface the following is important to check:

Disable user consent to apps

Via the Microsoft 365 admin center, it is possible to disable the consent of apps. If you turn this setting off; then admins must consent to the apps.

  • Go to admin.microsoft.com
  • Go to settings -> Org settings
  • Open the setting “User consent to apps“
  • Make sure the checkbox is disabled, ideally, this is configured with the app consent workflow.

Result: normal users are not able to consent to applications.

User settings

In Entra ID it is important to check the default user role permissions. To check the user settings follow the following steps:

  • Go to entra.microsoft.com
  • Open Identity -> User -> User settings

Check that the following checkboxes are configured with the value No. This means normal users are not able to register applications/ security groups.

Configure the following setting to Yes. The value Yes Restricts non-administrators from browsing the Microsoft Entra administration portal. Non-administrators who are owners of groups or applications are unable to use the Azure portal to manage their resources. This setting does not block access via PowerShell/ Graph API or other clients.

User App consent settings

In EntraID/ Azure check the following settings, most of them will be already configured with the correct settings; since the above settings interface with each other. All good to verify.

User consent settings

Go to portal.azure.com -> Enterprise applications -> Consent and permissions

Configure the user consent for applications with the value “Do not allow user consent”. With this, an administrator will be required for all apps.

Group owner consent

Configure the group consent with the value “Do not allow group owner consent”. Please read the documentation for the configuration and of these settings can be enabled in the tenant without any impact. My recommendation is to keep it disabled, when possible.

App consent workflow

With the above settings, the method to grant permissions is automatically disabled for users. To streamline the approval process of apps it is recommended to implement the app consent workflow. This will give a secure way to grant access to applications that require admin approval.

When a user tries to access an application but is unable to provide consent, they can send a request for admin approval. The admin needs to approve the request with the correct permissions.

More information: Configure the admin consent workflow – Microsoft Entra ID | Microsoft Learn

Go to portal.azure.com -> Enterprise applications -> Consent and permissions -> Admin consent settings

What is important?

Consent of apps

As already explained in this blog the most important part is the process around app registration/ service principals and the consent of apps. The following is important in the first line of defense:

  • Disable consent for normal user accounts
  • Configure app consent
  • Train admins to learn how to view bad consent applications (only well-trained admins can consent) following a good flow

MFA/ Phishing resistant MFA for admins

All admin accounts should have phishing-resistant enabled. Since phishing-resistant MFA will protect against the first layer of the stolen identity (an example is AiTM). Make sure the accounts are well protected.

And stop signing in from unmanaged devices with privileged accounts. Each admin should have access from dedicated secured devices to access the cloud of Microsoft.

Review/ detect OAuth applications

It is important to detect and track potential malicious OAuth applications. Since it is hard to find it is important to audit the current privilege level of all identities, both for the user and service principals.

  • Check all existing OAuth applications/ service principals
  • Review the current permissions
  • Review of app registrations with permissions/ roles assigned
  • Review of app registration is used in Azure RBAC
  • Develop a good process for new OAuth applications/ Service principals
  • Document, document, and start doing governance
  • Review OAuth apps with the AppRoleAssignment.ReadWrite.All permission

More tips (must read): Midnight Blizzard: Guidance for responders on nation-state attack | Microsoft Security Blog

App governance

App Governance as part of Defender for Cloud Apps can be used in the detection phase of existing apps. App Governance gives insights into the apps/ overprivileged apps and highly privileged apps.

Extract data from the Graph

Personally; I prefer to extract all apps via PowerShell/ Microsoft Graph and filter based on resources. The script created by Github/Michevnew is really useful in the start to keep as the first inventory for app permissions. More information: Reporting on Entra ID integrated applications (service principals) and their permissions

KQL

A good example is the use of KQL to query when a consent grant is initiated with full_access_as_app in Entra ID. https://github.com/rootsecdev/Microsoft-Blue-Forest/blob/master/PurpleTeam/MidnightBlizzard.kql

Of course; KQL can be used more to detect potential misuse of OAuth apps and assigned permissions, the above KQL query is a good example.

Detections

The following Microsoft Entra ID Protection alerts can help with the indication of Midnight Blizzard attacks:

Stolen user identity

  • Unfamiliar sign-in properties – This alert flags sign-ins from networks, devices, and locations that are unfamiliar to the user.
  • Password spray – A password spray attack is where multiple usernames are attacked using common passwords in a unified brute force manner to gain unauthorized access. This risk detection is triggered when a password spray attack has been successfully performed. For example, the attacker has successfully authenticated in the detected instance.
  • Threat intelligence – This alert indicates user activity that is unusual for the user or consistent with known attack patterns. This detection is based on Microsoft’s internal and external threat intelligence sources.
  • Suspicious sign-ins (workload identities) – This alert indicates sign-in properties or patterns that are unusual for the related service principal.

OAuth flow

The following Microsoft Defender for Cloud Apps alerts can help indicate associated threat activity:

  • App with application-only permissions accessing numerous emails – A multi-tenant cloud app with application-only permissions showed a significant increase in calls to the Exchange Web Services API specific to email enumeration and collection. The app might be involved in accessing and retrieving sensitive email data.
  • Increase in app API calls to EWS after a credential update – This detection generates alerts for non-Microsoft OAuth apps where the app shows a significant increase in calls to Exchange Web Services API within a few days after its certificates/secrets are updated or new credentials are added.
  • Increase in app API calls to EWS – This detection generates alerts for non-Microsoft OAuth apps that exhibit a significant increase in calls to the Exchange Web Serves  API. This app might be involved in data exfiltration or other attempts to access and retrieve data.
  • App metadata associated with suspicious mal-related activity – This detection generates alerts for non-Microsoft OAuth apps with metadata, such as name, URL, or publisher, that had previously been observed in apps with suspicious mail-related activity. This app might be part of an attack campaign and might be involved in exfiltration of sensitive information.
  • Suspicious user created an OAuth app that accessed mailbox items – A user that previously signed on to a medium- or high-risk session created an OAuth application that was used to access a mailbox using sync operation or multiple email messages using bind operation. An attacker might have compromised a user account to gain access to organizational resources for further attacks.

The following Microsoft Defender XDR alert can indicate associated activity:

  • Suspicious user created an OAuth app that accessed mailbox items – A user who previously signed in to a medium- or high-risk session created an OAuth application that was used to access a mailbox using sync operation or multiple email messages using bind operation. An attacker might have compromised a user account to gain access to organizational resources for further attacks.

Source: Microsoft

Sources

Microsoft: Midnight Blizzard: Guidance for responders on nation-state attack

X/EricaZelic: https://twitter.com/EricaZelic/status/1750774236707217811

X/Cnotin: https://twitter.com/cnotin/status/1751028257405665773