nOAuth Microsoft Azure AD Vulnerability

On June 20, 2023, Descope published research detailing how a combination of a flaw in Azure Active Directory and poorly integrated third-party applications — dubbed “nOAuth” — could lead to full account takeover. nOAuth is the latest in a large number of vulnerabilities and architectural weaknesses in Microsoft software and systems like Active Directory that can be exploited and put organizations at risk. 

While Microsoft has responded to the vulnerability, until developers make code changes in their applications, the proposed mitigation relies on organizations having strong identity protection capabilities to protect privileged accounts from misuse by rogue administrators. 

The Architectural Limitations of the Microsoft Identity Ecosystem Persist

The architectural weaknesses in Active Directory and Azure Active Directory (Azure AD) have been well documented over the years. These structural weaknesses and vulnerabilities have become a modern attack surface for the adversary. Despite this, Active Directory and Azure Active Directory continue to serve as the identity infrastructure for a large number of organizations. According to a Frost & Sullivan report, 90% of Fortune 1000 companies use Active Directory. 

Azure AD was Microsoft’s opportunity to start with a clean slate and build a modern, secure identity and access management (IAM) solution. However, the repeated vulnerabilities in its identity infrastructure can make organizations susceptible to breaches. While Microsoft recently changed the name of Azure AD to Entra ID, the security concerns remain.

As nOAuth, exposed flaws from Azure AD’s integration with Active Directory, and vulnerabilities associated with session theft show, the identity security problem has shifted to the cloud. It is worth noting that the response Microsoft issued for nOAuth on June 20 was more than two months after the vulnerability was disclosed to the company. This leads to two primary questions organizations need to consider:

• How many more of these vulnerabilities exist that are yet to be discovered? 
• Can you really afford to wait two months for mitigation of a risk that could lead to total account takeover? 

This consistent discovery of vulnerabilities, coupled with the architectural limitations of Active Directory and Azure AD, calls for comprehensive identity security that should be:

• Abstracted from the identity provider: A person or workload may have many accounts spread across different identity providers. Therefore, centralized visibility, detection and prevention is the only way to stop identity-based attacks. 
• Correlated and contextualized with the rest of the security stack: Only by blending endpoint, identity and third-party telemetry can you understand the full attack chain and detect all adversary activity whilst also reducing complexity and tool sprawl. 
• Independent of detecting “known vulnerabilities”: Identity protection should combine CVE-based detections with real-time behavioral analysis to detect adversary activity. 
• Hybrid identity protection extended from on-premises to the cloud: This includes examining credential entitlements to mitigate the impact of a breach if it occurs.
• Capable of monitoring applications for misconfigurations: Typical approaches to identity security focus on analyzing the identity providers for vulnerabilities. While identity providers should provide best-practice implementation advice, if the application is misconfigured, you remain vulnerable. 

What is nOAuth?

As detailed by Descope, nOAuth describes a vulnerability in the trust between an identity provider (in this case, Azure AD) and a relying party (an application). The name “nOAuth” is a play on the authorization protocol “OAuth,” whereby the application is issued a token by the identity provider that contains information about the user and the data they wish to share with the application. These are called “claims.” 

Whether you are familiar with OAuth or not, there is a high probability you’ve used it before! Think about all of the times you’ve registered for a service, where you have an option to “Sign in with Google” or “Sign in with Microsoft” or “Sign in with Facebook.” Does a screen like this look familiar?

After clicking one of those options, you authenticate to the identity provider and are then asked what you want to share with the application — name, address, gender, etc. After selecting preferences, the identity provider issues a token that the application reads so it knows:

• Who you are, which is important so a profile can be created inside the application. For example, if you sign up for an account with a grocery store, you want it to remember your favorite items to build recommendations for what else you might like. 
• Which data the application is allowed to request from the identity provider. For example, you might want the grocery store to have your address (so it knows where to send your shopping), but you might not want them to have your date of birth. 

Coming back to nOAuth, it is the “who you are” claim that is manipulated by the adversary. Many applications that implement OAuth incorrectly use “email” as the user identifier, as opposed to an immutable value, like the object identifier (OID). This means as long as the adversary can generate a claim with the victim’s email address, they gain full access to their account without knowing their password or having to perform multifactor authentication (MFA). 

In the Azure AD scenario, it is much more significant as it’s easy for anyone to generate that claim:

The team at Descope created a powerful demonstration of how effective this is. 

Let’s clearly frame where the problem lies with nOAuth and Microsoft:

• Microsoft allows anyone with an Azure AD account to modify the email attribute of an account to any email address — whether that tenant had proved they “owned” the domain or not. For example, even though you own the domain mycompany.com, an adversary could change a user account in their own Azure AD tenant to have a mycompany.com address too. 
• When developers were building OAuth integration with Azure AD, they opted to use email as the user identifier, as opposed to an immutable value like OID.

Microsoft Response to nOAuth

On June 20, Microsoft released guidance on how to manage the nOAuth vulnerability:

• To mitigate the risk for existing applications, you can modify the authenticationBehaviors API (which currently has beta status) to reject unverified email claims. 
• When developers are ready to update their code and migrate users to an immutable identifier, like OID, they can use the “xms_edov” claim to verify the email address is verified in the Azure AD tenant before the user identifier is changed. 

Developer Security Awareness

Developers must abide by best practices and recommendations for securing modern identity protocols like OAuth. This is a reminder that security training provided by organizations must span beyond non-technical staff. Developers, infrastructure engineers, architects and support staff are all responsible for building and maintaining the next generation of business-critical applications. They need to be aware of the ramifications of how a weak implementation of an authentication journey in an application can undo much of the great work IAM teams may have done to secure the identity provider itself. 

Despite the Response, the Problem Remains

As of Thursday, July 13, it is still possible to create a free Azure AD account and map any email address to a user account, without any validation of domain ownership. Therefore, until developers update their code to use immutable values as the user’s primary identifier, all organizations can do is mitigate the risk. 

The mitigation step, which involves using a beta Microsoft Graph API, is vulnerable to modification by a rogue Azure AD administrator. 

Therefore, the solution to this problem is securely transitioning applications from an email-based identifier, which requires developers to update code within homegrown apps. The same applies for developers who work for third parties that provide the business-critical, modern applications you use. Making this change also isn’t as simple as it sounds — it could have a downstream impact on the application experience, which may extend the length of time it takes to implement the change.

The question now becomes, “What countermeasures can you put in place in the interim to mitigate the rogue administrator risk and proactively protect against future vulnerabilities in your hybrid identity ecosystem?”

Countermeasures for Identity-Based Attacks in AD and Azure AD

CrowdStrike Falcon Identity Threat Protection, fully integrated with the CrowdStrike Falcon platform, provides organizations with comprehensive protection against identity-based attacks. It detects attacks and prevents lateral movement, stopping breaches stemming from vulnerabilities in Active Directory and Azure AD. In the context of nOAuth, this allows you to detect rogue administrator activity that could be an indication of intent to exploit nOAuth.

Correlate Audit and Access Events

An email address change is a perfectly legitimate activity. However, that activity correlated with other telemetry occurring around the same time, such as privilege escalations and anomalous access to resources, could indicate rogue administrator activity. CrowdStrike gives you this visibility, transforming the threat hunting experience for SOC and IAM teams by linking all of the events in the kill chain into a single incident view:

Detect and Prevent Hybrid Lateral Movement 

While many organizations use Azure AD for conditional access and single sign-on (SSO), Active Directory is often the “true” identity provider. User objects are created and modified in on-premises Active Directory then synchronized to the cloud via Azure AD Connect. Therefore, an adversary inside your network with sufficient permissions in Active Directory can create accounts and modify email addresses, which replicate to Azure AD, all without the adversary having administrative access to the Azure AD portal. They can also exploit known vulnerabilities in AD, such as Overpass-the-Hash attacks, to move laterally into Azure AD without being challenged for authentication. 

To understand how Falcon Identity Protection identifies risks, and detects and prevents lateral movement, please see this video. We demonstrate how CrowdStrike detects and prevents adversaries from moving laterally from Active Directory to Azure AD.

Monitor Unusual Activity

Building behavioral baselines across all of your accounts is critical, but reviewing these single events in isolation often leads to false positives. For example, if a user who has worked in the organization for a long time is granted access to an application due to a role change, how can you determine the difference between anomalous and malicious activity? 

Therefore, it is important to combine anomalous events with other telemetry you have about the user to determine whether an action is malicious, as opposed to just anomalous. In this example, we show geographical anomalies occurring alongside the anomalous application access:

Define and Monitor Privileged Accounts

Privileged accounts are often defined as those that have administrative privileges in the identity store — for example, a domain administrator in Active Directory or a Global Admin in Azure AD. However, a user who is the global administrator in your CRM solution is privileged as well, and the impact to your business if that account is compromised could be devastating. CrowdStrike allows you to map business privileges to the potential business impact of a specific account being compromised. This elevates the risk score associated with those accounts, meaning detections are raised with a higher priority, prompting the SOC and IAM teams to prioritize review and remediation.

Correlate Application and Identity Store Audit Logs

Correlating audit logs between the identity provider and the application can be a powerful way to detect malicious activity. For example, seeing an authentication event at the identity provider that does not correlate with an access event in the application logs, can be an indication a user’s account has been compromised. 

By combining the power of CrowdStrike Falcon Identity Threat Protection and Falcon LogScale, you could use a scheduled query like this that will correlate login events between the identity provider and the application audit log to highlight anomalies.

Proactively Identify Vulnerable Applications 

Identifying the weak points and the assets you need to protect is the critical step in protecting your organization. However, the process of identifying vulnerable applications can be difficult. External attack surface monitoring tools, like CrowdStrike Falcon® Surface, have the capability to identify applications, such as those using OAuth or OIDC, so you know which applications need to be reviewed. 

Additional Resources