By default, Microsoft Teams offers the option of integrating external users with a Microsoft account that does not belong to your own Microsoft Azure Tenant as guests in a team. Although these guests have limited rights, they can still access information that should not normally be intended for them in the default settings of the Azure Tenant. In the finding described here, guests have the option of enumerating all accounts and groups within the Azure Tenant via Azure PowerShell. This can also be automated by a script.
A PowerShell with the module AzureAD (Azure Active Directory PowerShell for Graph) is required for the enumeration. The PowerShell module installation command for this is Install-Module AzureAD. Note that PowerShell must be run with administrative rights.
Microsoft Docs: https://docs.microsoft.com/en-us/powershell/azure/active-directory/overview?view=azureadps-2.0
Note: The predecessor module of AzureAD is "MSOnline PowerShell" and the successor module is/will be "Microsoft Graph PowerShell". In our test, we still use the AzureAD module, as we could not find any limitations with it.
If the enumeration is now also to be carried out automatically, the DCToolbox module by Daniel Chronlund can be used for this. We carry out the installation with the PowerShell command "Install-Module DCToolbox".
GitHub: https://github.com/DanielChronlund/DCToolbox
Since DCToolbox is not an official package for PowerShell, depending on the execution policy area, its use must subsequently be allowed by the "Set-ExecutionPolicy Bypass -Force" command. After executing the script, the execution policy area can be reset with "Set-ExecutionPolicy Default".
The tenant ID of the Azure to be enumerated is required so that an enumeration is possible via a guest access. This can be found out as follows;
1. In the browser version of Microsoft Teams in which guest access is available, the tenant ID is part of the URL called.
3. Or via the website: https://www.whatismytenantid.com
A friend who knows a friend who knows a friend...
The theory behind it is quite simple, if a bit confusing at first. Via PowerShell, the guest user first enumerates an Azure user of the team in which he is located. Then it asks for the group memberships of the Azure user. In these groups, in turn, he can also enumerate the users and with these users new groups and thus new users. With this procedure, large parts, in the worst case even the entire Azure Active Directory, can be enumerated.
In practice it looks like this:
1. First you have to log in to the guest Azure Tenant via PowerShell with the installed AzureAD module. For this, the command ...
Connect-AzureAD -TenantId TENANT-ID
… used
2. After a successful login, the enumeration can already begin. To do this, a user of the Azure Tenant is first created with ...
Get-AzureADUser -ObjectId AZURE-BENUTZER-EMAIL
… requested.
Proof of concept: Direct enumeration of Azure users is forbidden for guests by default.
3. With the command ...
Get-AzureADUserMembership -ObjectId (Get-AzureADUser -ObjectId OBJECT-ID-BENUTZER).UserPrincipalNAame
... the group memberships of the user can be listed.
4. The users of the individual groups are then listed with...
Get-AzureADGroupMember -All:$true -ObjectId OBJECT-ID-GRUPPE
... enumerated.
5. And then the whole thing starts all over again.
With the command...
Get-DCAzureADUsersAndGroupsAsGuest -TenantId TENANT-ID -AccountId GAST-BENUTZER-EMAIL -InterestingUsers AZURE-BENUTZER-EMAIL
the Azure Active Directory can be enumerated automatically as far as possible.
In the administration area of the Azure Tenant under: https://portal.azure.com/#blade/Microsoft_AAD_IAM/AllowlistPolicyBlade the setting "Guest user access is limited to properties and memberships of their own directory objects (most restrictive setting)" must be selected. As a result, guests no longer have access to information about other users and groups in the tenant.
In most cases, it is recommended to completely prevent guest accounts from accessing the tenant via Azure PowerShell. This can be achieved by configuring "Conditional Access". This requires an Azure AD Premium P1 license or higher. As shown in the screenshot, "Conditional Access" policies can be created that allow or deny certain user groups access to apps (via white or blacklist procedures).
When correcting the finding, it can also be discussed whether access to the Azure PowerShell should also be restricted for Azure AD users, since each user also has permission for the enumeration by default. If this is the case, access to the Azure AD administration portal for non-administrators should also be blocked. The implementation takes place via the selection "Yes" in the setting "Access the Azure AD management portal".
