New research has uncovered continued risk from a known security weakness in Microsoft’s Entra ID, potentially enabling malicious actors to achieve account takeovers in susceptible software-as-a-service (SaaS) applications.
Identity security company Semperis, in an analysis of 104 SaaS applications, found nine of them to be vulnerable to Entra ID cross-tenant nOAuth abuse.
First disclosed by Descope in June 2023, nOAuth refers to a weakness in how SaaS applications implement OpenID Connect (OIDC), which refers to an authentication layer built atop OAuth to verify a user’s identity.
The authentication implementation flaw essentially allows a bad actor to change the mail attribute in the Entra ID account to that of a victim’s and take advantage of the app’s “Log in with Microsoft” feature to hijack that account.
The attack is trivial, but it also works because Entra ID permits users to have an unverified email address, opening the door to user impersonation across tenant boundaries.
It also exploits the fact that an app using multiple identity providers (e.g., Google, Facebook, or Microsoft) could inadvertently allow an attacker to sign in to a target user’s account simply because the email address is used as the sole criteria to uniquely identify users and merge accounts.
Semperis’ threat model focuses on a variant of nOAuth, specifically finding applications that allow for Entra ID cross-tenant access. In other words, both the attacker and the victim are on two different Entra ID tenants.
“nOAuth abuse is a serious threat that many organizations may be exposed to,” Eric Woodruff, chief identity architect at Semperis, said. “It’s low effort, leaves almost no trace and bypasses end‑user protections.”
“An attacker that successfully abuses nOAuth would be able not only to gain access to the SaaS application data, but also potentially to pivot into Microsoft 365 resources.”
Semperis said it reported the findings to Microsoft in December 2024, prompting the Windows maker to reiterate recommendations it gave back in 2023, coinciding with the public disclosure of nOAuth. It also noted that vendors that do not comply with the guidelines risk getting their apps removed from the Entra App Gallery.
Microsoft has also emphasized that the use of claims other than subject identifier (referred to as the “sub” claim) to uniquely identify an end user in OpenID Connect is non-compliant.
“If an OpenID Connect relying party uses any other claims in a token besides a combination of the sub (subject) claim and the iss (issuer) claim as a primary account identifier in OpenID Connect, they’re breaking the contract of expectations between federated identity provider and relying party,” the company noted at that time.
Mitigating nOAuth ultimately rests in the hands of developers, who must properly implement authentication to prevent account takeovers by creating a unique, immutable user identifier.
“nOAuth abuse exploits cross-tenant vulnerabilities and can lead to SaaS application data exfiltration, persistence, and lateral movement,” the company said. “The abuse is difficult for customers of vulnerable applications to detect and impossible for customers of vulnerable applications to defend against.”
The disclosure comes as Trend Micro revealed that misconfigured or overly privileged containers in Kubernetes environments can be used to facilitate access to sensitive Amazon Web Services (AWS) credentials, enabling attackers to conduct follow-on activities.
The cybersecurity company said attackers can exploit excessive privileges granted to containers using methods like packet sniffing of unencrypted HTTP traffic to access plaintext credentials and API spoofing, which uses manipulated Network Interface Card (NIC) settings to intercept Authorization tokens and gain elevated privileges.
“The findings […] highlight critical security considerations when using Amazon EKS Pod Identity for simplifying AWS resource access in Kubernetes environments,” security researcher Jiri Gogela said.
“These vulnerabilities underscore the importance of adhering to the principle of least privilege, ensuring container configurations are scoped appropriately, and minimizing opportunities for exploitation by malicious actors.”
