The security of active directory will always be a hot topic. AD contains all your identities/structure and isn’t something you want anyone accessing. In traditional models, a common threat was that your users could query AD using net /domain commands.
A default control to help limit this would be that you were required to be on the network (Client > Domain Controller). This control somewhat removed the external threat as they would need to compromise a network joined device or VPN account.
What happens if we move to the cloud though?
If you are using Azure AD, you would have most likely chosen to restrict access to administrators only. This is an obvious control you would want in place as you don’t want anyone querying your identities.
Something you may or may not have read though is the small print. This control only restricts access through the portal and not PowerShell or Visual Studio. Essentially what this means is that any identity that you manage within AzureAD, has read only access to your environment (sometimes with greater privilege).
This may not seem much, but how many identities do you have, and do you manage them all securely?
AzureAD guest accounts that have been invited seem to be an exception as when testing I received an unauthorised error. Even If I connect with the tenantID:
Connect-AzureAD -TenantId XXXXXXXXXXXXXXXXX and authenticate, I still get denied.
What it does mean is that any user (excluding guests), anywhere can install the module on their machine and could potentially query your AzureAD.
The steps would be as simple as:
- Install-Module AzureAD
- Authenticate with an account
- Run commands such as: (Get-AzureADUser -Top 100).UserPrincipalName
*This would pull the UPNs of the top 100 AzAD accounts which could be used to brute force.
A restriction that you could put in place would be to set a location requirement on a conditional access policy. The policy would need to be applied to the app, Microsoft Azure Management.
As of today, I can’t see a dedicated cloud app for Azure Active Directory PowerShell which is the app name logged against the Sign-In log.
Remember that even if you enforce MFA, those accounts would have to have their authentication methods setup. If not, an attacker could do this for you with disposable services and could then bypass the MFA prompt should they have compromised credentials.
If you are wanting to read more, I’ve covered Azure and PowerShell here: https://securethelogs.com/2020/03/03/why-control-powershell-in-azure/
Question to Microsoft tracked here: https://docs.microsoft.com/answers/questions/12035/azure-management-breakout-powershell.html