Introduction

Azure has an insecure default guest user setting, and your organization is probably using it. The default settings Azure provides would allow any user within the organization (including guest users) to invite guest users from any domain, bypassing any central identity management solutions (e.g. Okta, Auth0) and onboarding processes. Additionally, an attacker may use this default capability to maintain persistent access by inviting their Microsoft account to the environment.

What are Guest Users?

Azure Active Directory (Azure AD) business-to-business (B2B) collaboration is a feature within External Identities that lets organizations invite guest users outside of the organization to collaborate. Organizations often utilize this feature to provide access to contractors who belong to a different Azure AD directory. By utilizing guest users, organizations need not provision users in their Azure AD directory. Instead, organizations can utilize existing identities in contractor Azure AD directories.

Azure provides configuration settings that limit who has the permissions of guest users. However, the default settings offered by Azure are insecure and expose the environment to unnecessary risks.

Risks Related to Guest Users

Guest users are convenient; however, Praetorian advises against utilizing guest users in enterprise environments or environments with a separate main third-party identity provider such as Okta or Auth0. Praetorian has observed the following issues caused by widespread usage of guest users in enterprise environments:

1. Limited control over guest user policies as they belong to a different Azure AD directory

As guest users belong to a different Azure AD directory and would be authenticating to their identity provider, security policies such as password policy cannot be enforced. For the same reason, organizations can’t force a password reset for guest users to ensure password rotation policy compliance.

2. Guest users could invite other guest users, encouraging shadow IT

Depending on the external collaboration settings (in the next section), a guest user could invite other guest users and potentially guest users from any domain. This includes personal Microsoft accounts utilizing domains such as `gmail.com`. This leads to a rise in shadow IT as guest users may bypass the organization’s identity provisioning process and add new users to the environment directly without oversight. Praetorian often observes developers creating such users and assigning permissions to the guest users bypassing the identity management team as the identity provisioning process was tedious. Additionally, an attacker with initial access could utilize this feature to persist access.

3. Guest users bypass central identity providers

Guest users represent an unmanaged resource for organizations with a separate central identity provider such as Okta and Auth0. As these users were created directly on Azure AD, other central identity providers may not have visibility into these users.

4. Guest users are often left longer in the environment than they should

Praetorian frequently observes environments with thousands of inactive guest users. It is hard to tell if a contractor still requires access to an environment, and organizations often give the benefit of the doubt. However, this leads to many inactive guest users, which needlessly enlarges an organization’s risk.

Guest User Insecure Defaults

Azure provides several settings to lock down guest users. Praetorian found the default configuration provided by Azure to be inadequate. The default configuration looks like the following:

Figure 1: The default Guest User settings provided by Azure.

• Guest invite restrictions

When creating a new Azure AD tenant, Azure defaults the external collaboration settings to “Anyone in the organization can invite guest users including guests and non-admins (most inclusive)”. This would allow any user within the organization to invite guest users. As mentioned previously, this feature is often misused and encourages shadow IT. Additionally, an attacker who has successfully obtained initial access to the environment could utilize this feature to create a new user to maintain access.

• Collaboration restrictions

Azure external collaboration restrictions limit the domains which could be invited to the Azure AD directory. By default, Azure permits any domain including personal Microsoft Accounts created from `@outlook.com` and `@gmail.com` personal email addresses. This would allow anyone to add their own Microsoft account to the Azure AD directory and access the organization’s Azure AD through their personal Microsoft account. Without domain restrictions, an attacker with initial access could also invite their own Microsoft account to the environment.

• Guest user access restrictions

When creating a new Azure AD tenant, Azure defaults the Guest User access restriction settings to “Guest users have limited access to properties and memberships of directory objects”.  Limited access is defined by Azure to include read access to non-hidden groups, including membership and ownership (even non-joined groups) and read access to registered and enterprise applications.

However, Praetorian found that a guest user could still enumerate users through direct object reference even if the guest user could not list users. By conducting research through OSINT sources, an attacker could utilize guest users to determine which emails had access to the Azure environment and retrieve other information such as secondary email addresses to inform other attacks.

Figure 2: The Guest User could not list all users in the environment.

Figure 3: Utilizing direct object reference, a guest user could retrieve information about a user and verify the user’s existence in Azure AD.

Figure 4: Error message when the email does not exist within Azure AD.

Mitigating Guest User Risks

Praetorian recommends auditing guest users in the environment. Next, Praetorian recommends removing guest users and modifying the external collaboration settings to prevent future unauthorized guest users from being invited to the environment.

Praetorian recommends the following settings:

1. Set “Guest user access restrictions” to “Guest user access is restricted to properties and memberships of their own directory objects”.
2. Depending on business needs, set  “Guest invite settings” to “No one in the organization can invite guest users including admins” or “Only users assigned to specific admin roles can invite guest users”.
3. Set “Collaboration Restrictions” to “Allow invitations only to the specified domains (most restrictive)” and only specify the corporate domain

How to do remediate via the Azure Console

1. Go to Azure Active Directory
2. Go to User settings
3. Select `Manage external collaboration settings`
4. Ensure that `Guest user access restrictions` is set to `Guest user access is restricted to properties and memberships of their own directory objects (most restrictive)`
5. Ensure that `Guest invite restrictions` is set to `No one in the organization can invite guest users including admins (most restrictive)` or `Only users assigned to specific admin roles can invite guest users`
6. Ensure that `Collaboration Restrictions` is set to `Allow invitations only to the specified domains (most restrictive)`

Bottom line

Guest users have legitimate use cases, but Azure’s default settings are insecure. Using guest users in production increases an organization’s risk for a particularly sensitive area of an organization, identity. Praetorian advises against utilizing guest users in enterprise environments or environments with a centralized third-party identity provider such as Okta or Auth0. Praetorian hopes that this article has informed readers about the potential risks of guest users. At a minimum, organizations should update the default guest user settings and harden who has access to guest users and who can be invited to the environment.

References

https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/users-default-permissions