In our modern world, businesses has become way more intertwined than before. Due to this need, collaboration across businesses is more vital than ever. This demand for collaboration has made vendors push for smarter ways to collaborate and exchange information. In Azure, Azure B2B / Microsoft Entra B2B is a big deal. Unfortunately, the use of Azure B2B / Microsoft Entra B2B has introduced security risks that is not intended. These risks are related to Collaboration and Guest settings, which - if not handled properly - could cause hackers to get a foothold and escalate privileges and move laterally in the system.
Throughout this blog, I will dive into Collaboration and Guest settings which poses a significant risk, and I’ll explain in some details why they are dangerous and recommend which configuration should be utilized to enhance the security posture of your tenant. I will not deep dive into specific attack paths or scenarios, but primarily focus on the settings you should secure to avoid the common pitfalls of Azure configurations.
These are the following topics I will cover in this tech blog:
Ensure That 'Guest users access restrictions' is set to 'Guest user access is restricted to properties and memberships of their own directory objects'
Ensure That ‘Users Can Register Applications’ Is Set to ‘No’
Ensure that ‘User consent for applications’ is set to ‘Do not allow user consent’
Ensure that 'Users can add gallery apps to My Apps' is set to 'No'
Ensure that 'Guest invite restrictions' is set to "Only users assigned to specific admin roles can invite guest users"
Ensure That 'Restrict access to Azure AD administration portal' is Set to 'Yes'
Ensure that 'Restrict user ability to access groups features in My Groups' is Set to 'Yes'
Ensure that both the settings 'Users can create “Security” & “Microsoft 365” Groups in Azure portals, API or PowerShell' is set to 'No'
Ensure that 'Owners can manage group membership requests in My Groups' is set to 'No'
Ensure that collaboration invitations are sent to allowed domains only
Ensure that 'Guest users access restrictions' is set to 'Guest user access is restricted to properties and memberships of their own directory objects'
Distinguishing between Member users and Guest users is crucial, as they possess distinct default permissions. Notably, there exists a higher level of security configuration surrounding guest users by default compared to member users. However, in Azure, there is a particular configuration, namely the "Guest user access setting," that demands a security-oriented approach. If this setting is configured to be overly inclusive, it can potentially expose the tenant to multiple attack paths from the perspective of attackers. (Refer to the image below for details about the setting).
Enabling this setting grants guest users the same default permissions as member users, providing an attacker with the possibility to collect additional information and exercise some control over users, contacts, groups, and applications. This expanded access allows the attacker to be more resourceful when initiating lateral movement, as a result potentially increasing their ability to gain further access within the tenant.
Ensure that ‘Users can register applications’ is set to ‘No’
Even though it seems smart to have users register applications to avoid IT operations in small tasks like this, it can unfortunately unfold a security risk, that enables attackers to abuse this configuration. This is because, when an application is created, user becomes the owner of this application and thereby enables them to configure tenant specific configurations like Single Sign-On (SSO).
You can find the setting under “Users > User Settings” - Make sure that the setting is so to “No”.
Ensure that ‘User consent for applications’ is set to ‘Do not allow user consent’
Before an application can access the organizations data, a user must grant permissions to the application. By default, all users are allowed to consent to applications for permissions that don’t require administrator consent. An example would be consenting the application to give access to your own mailbox, and not give it Read and Write permissions to resources or files etc., in the organization.
To avoid attackers from attempting to trick users into granting access to your organization, it’s recommended that only specific administrators can consent to the applications. Furthermore, it’s important that the publisher has been verified[1].
Finding this specific setting can be tricky since it’s a user setting. To find it, navigate to Enterprise Applications > Consent and permissions – Make sure you set it to ‘Do not allow user consent’.
Ensure that 'Users can add gallery apps to My Apps' is set to 'No'
Enabling the option "Users can add gallery apps to my apps" in Azure, specifically in the context of Azure Active Directory (Azure AD) / Microsoft Entra ID app registrations, can introduce security risks to your environment. This option allows end-users to add applications from the Azure AD App Gallery to their tenant. While it might seem convenient, there are potential dangers associated with this feature. This could be lack of control, application trustworthiness, authentication and authorization risks like third-party apps implemented without secure authentication and authorization practices. Which could lead to unauthorized access to your organizations resources or potentially leak sensitive data.
To configure this setting, go to Enterprise Applications > User settings:
Ensure that 'Guest invite restrictions' is set to "Only users assigned to specific admin roles can invite guest users"
The setting "Guest invite restrictions" being set to "Only users assigned to specific admin roles can invite guest users" is crucial for maintaining a controlled and secure environment within your organization. This setting helps manage the process of inviting external guest users to your digital platforms and services.
There are many potential attack vectors, if guest users can invite guest users, this could be attackers tricking end users in your organization to get an invitation. This setting in combination with Guest users having the same access as members will then increase the likelihood for an attacker to enumerate and gain insight into many different aspects of the infrastructure setup. Exploiting Dynamic groups to get membership is a critical pitfall in many organizations. Make sure that collaboration between business is controlled in a secure manner.
Make sure you set this restriction to ‘Only users assigned to specific admin roles can invite guest users’ – This will prohibit attackers in exploiting many of the early lateral movement use cases.
It is also advised that you enable Collaboration Restrictions to only allow invitations to specified domains, that you have whitelisted.
Ensure that 'Restrict access to Azure AD administration portal' is set to 'Yes'
(Not a security Feature but can help with making it harder for an attacker to execute whatever malicious intent, by having them to use other interacting tools like graph API or Azure CLI).
Basically, there are multiple ways for an attacker to go about connecting to Azure. When utilizing this feature, it becomes harder for an attacker to enumerate and find potential weak configurations. An attacker needs to use Azure CLI or Microsoft Graph API to interact with Azure and its resources.
To enable this configuration, go to Azure AD / Microsoft Entra ID > User settings:
Ensure that 'Restrict user ability to access groups features in My Groups, is set to 'Yes'
It’s important to restrict the ability for users to access group features in My Groups, if they are able to access these features, they can request for group invitations and get access to applications like SharePoint, which could potentially open a door for an attacker to get sensitive information. To avoid this potential data breach, we want to restrict users to access these features. To do so, go to Groups > General and set the following setting to ‘Yes’.
Ensure that both the settings 'Users can create “Security” & “Microsoft 365” Groups in Azure portals, API or PowerShell' is set to 'No'
It’s important to take control of whom, is creating the security groups in Azure, that being through the Azure Portal, API, or PowerShell. No users should be able to do so. The problem with this setting is that, if users can create security groups, they can consent to malicious apps on behalf of the organization and group members. These apps are dangerous and can demand any permissions they want. E.g., Mail, Profiles, Files, calendars etc. Any information given to an attacker is time well spent, this information can then be used to further escalate privileges due to enumerating more. To take this further, it’s also possible for an attacker to create publicly available azure apps and pass the URL to multiple “targets”. Using this technique, the victims can be brought to an official Microsoft Page that lists the permissions and potentially has buttons like ‘Accept’ or ‘Cancel’. Since the webpage looks credible, the victims often fall into this trap, and then the environment is in danger. (It only takes 1 person to click) – Of course the above attack scenario requires multiple configurations to be misconfigured. The app registration and consent are necessary. Non the less, let’s not miss out on improving our security here.
Go to Groups > General and set the Security Groups to “No”.
Ensure that 'Owners can manage group membership requests in My Groups' is set to 'No'
To avoid group manipulations with group memberships, it’s important that we only let Administrators act on this. Having every group owner, the ability to do what they want with there group membership, increases the likelihood that an attacker could become member of one of these groups, and potentially gain a significant increase in offensive potentials. Maybe the group has assigned roles, or grants access to specific files and data. Because of this potential risk, we advise that you always let Administrators handle this process. To set this setting to No, navigate to Groups > General and set the “Self Service Group Management” to ‘No’
Ensure that collaboration invitations are sent to allowed domains only
To reduce the likelihood of an external collaboration with an attacker, it’s a great idea to whitelist domains that you want to collaborate with. This way, you make sure that it’s only Administrators that can handle the Collaboration part, and that the domains are controlled by your Administrators before whitelisting it.
To enable this setting, go to Azure AD / Microsoft Entra ID > User Settings > under External users click on ‘Manage external collaboration settings’ > Scroll to the bottom of the page:
