After numerous Microsoft cloud tenant security assessments, we present the top-10 risky Microsoft cloud security configurations. Microsoft released Active Directory (AD) with the Windows 2000 server editions in 2000 as the successor of the Windows NT directory. And as some of you remember, security was not always the most crucial topic at this time. This mainly led to insecure configurations such as numerous day-to-day user account assignments to privileged groups such as the Domain Admins.

However, over the years, bad AD security practices were reduced as it became general knowledge that AD must be better protected. For Example it became a common practice to have a minimal set of dedicated domain admin accounts operating only within their allowed security boundary. Why are we telling you that? Because, during cloud assessments, it sometimes feels like taking a time machine back to the year 2000 by experiencing mistakes that were made in this time.

The Top-10 Riskiest Configurations

The following top-10 list brings you “back to the future” by describing basic risky configurations or practices that should be avoided. In addition, a list of links and ressources are provided for further reading. The identified risks are based on our experience during various Microsoft cloud security assessments.

Risk 1 – Global Administrator Role Assigned to Day-to-Day User Accounts

Comparing all our Microsoft cloud assessment from the past years, 8 out of 10 had one or more day-to-day user account permanently assigned to Tier-0 roles in Azure AD. Tier-0 roles in the cloud can be interpreted as all roles or entities that can directly or indirectly become Global Administrators, such as members of the Privilege Role Administrators or identities with the AppRole RoleManagement.ReadWrite.Directory. The discovered day-to-day user accounts were mainly hybrid identities synchronised from Active Directory. The rationale of the assignment was often comfort, unawareness or the fear of getting locked out of Azure AD. Surprisingly the companies with this finding often try to follow the Active Directory least privilege concept, such as using a dedicated account or even following the Microsoft tiering model to administrate their Active Directory. But for the Microsoft cloud, the principle was not anymore applied.

Using day-to-day user accounts for administrating Tier-0 unnecessary increases the attack surface and can lead to a compromise of the Microsoft cloud tenant. Adversaries will try to abuse the security exceptions, which are mostly in place for day-to-day user accounts, such as widespread Internet access, password reset capabilities, :social engineering_, weak hardening measures, MFA fatigue attack and more. Therefore, we recommend adhering to the least privilege model by using dedicated cloud-only user accounts to administrate the Microsoft cloud. The Tier-0 cloud-only user accounts must be part of a Joiner-Mover-Leaver (JML) process. A manual JML process such as a ticket is sufficient to avoid promoting an Identity & Access Management (IAM) system to Tier-0, as the number of Tier-0 user accounts should be kept low. The argument that hybrid identities are already included in the JML process is not always valid. It can lead to the above-described scenario where day-to-day user accounts are assigned to Tier-0 because Active Directory Tier-0 users are mostly not synchronised to the cloud. Suppose Azure AD hybrid identities must be used for Tier-0 cloud access rights for whatever reason. In that case, we recommend creating a new dedicated Active Directory identity pattern for cloud administration and again including it in a JML process. This will allow setting restrictive access policies in AD and in the cloud for this hybrid identity type. Additionally, we always recommend using the Microsoft cloud feature Privilege Identity Management (PIM) for privileged accounts. To activate the role, multi-factor authentication (MFA) should be used.

Further readings:

• Introduction to delegated administration and isolated environments
• Securing privileged access for hybrid and cloud deployments in Azure AD
• Privilege Identity Management
• Securing privileged access
• Azure Attack Paths: Azure AD Roles
• MITRE ATT&CK tectics and rechniques
• AAD & M365 kill chain
• @_wald0 Tier-0 definition examples

Risk 2 – Weak Azure AD Service Principal and Cloud Application Management

Service principals represent the identity of an Microsoft cloud application. A freshly created Azure AD tenant has around 390 pre-configured service principals who correspond to cloud applications such as Microsoft Teams, SharePoint Online, Exchange Online or Microsoft Graph. For example, by creating a custom Microsoft cloud application in the Azure AD portal or over API, two entities are created: an application object and a service principal. The application object is considered the global representation of the organisation’s application across all tenants, and the service principal is the local representation of a specific tenant. Service principals or managed identities in Azure ARM are also heavily used for Azure’s IaaS and PaaS services to provision new services, managed services, or in general, for automation tasks. The takeover of service principals is an interesting target for adversaries. Service principals can be granted a vast set of permissions and are ideal for privilege escalation scenarios or backdooring Azure AD or Azure ARM.

Cloud applications are built by composing various IaaS and PaaS services. An application in the Microsoft cloud has typically a service principal assigned. For example, if a cloud application requires access to a database, the application’s service principal is granted access to the database. Application consumers are usually accessing cloud applications over OAuth 2.0 authorisation flows. Granted permissions to applications can become critical as some applications can hold highly privileged access rights.

In most of our assessments, we find privileged service principals or cloud applications with a day-to-day user account as an owner. An owner can manage or impersonate the service principal. Therefore, if a user can control an application with higher privileges than the user itself, a privilege escalation over the service principal is possible. We also often find, besides the ownership, that assigned permissions are not actively tracked. Often we find overprivileged service principals with app role rights such as *.ReadWrite.All, *.ReadWrite.Directory or direct assignments to the Global Administrator or Exchange Administrator roles. Reviewing who can manage applications, including application and delegation permissions, is crucial in a Microsoft cloud environment to prevent unwanted credential pivoting paths. For example, owners of privileged service principals or applications should never be a day-to-day user account.

Further readings:

• Azure Privilege Escalation via Azure API Permissions Abuse
• Azure Privilege Escalation via Service Principal Abuse
• Managed Identity Attack Paths, Part 1-3: Automation Accounts
• Azure AD built-in roles

Risk 3 – Too Many Administrators

All too often, one result of a Microsoft cloud assessment is that the Microsoft cloud tenant has too many administrators. Be it in Azure AD, Azure ARM, Azure DevOps or the M365. The rationales are various but the main reason behind this practice is that different IT teams started with independent projects and tight timelines. The outcome is many administrators, for example, which have to configure Conditional Access, Azure AD permissions, create service principals, create Azure ARM resources, and so forth. Silos should have no space in the cloud as everything is far more interconnected than on-premises. Misconfigurations can have severe consequences. Therefore, it is crucial to have a plan to avoid assigning project-related user accounts to random roles without understanding the entitlement implications or the resulting access rights. Similar to Active Directory, the number of administrators should be kept to a minimum.

Further readings:

• Least privileged roles by task in Azure Active Directory
• Understand roles in Azure Active Directory
• Classic subscription administrator roles, Azure roles, and Azure AD roles
• Microsoft cloud Adoption Framework for Azure

Risk 4 – Risky Exceptions for Global Administrators or Other Privileged Roles

We found exceptions in every Microsoft cloud assessment, particularly for Global Administrators in Conditional Access policies. Unfortunately, the rationale is all too often to circumvent security controls or to take a shortcut. Especially for privileged roles such as Global Administrators, no exception should be made, with one exception: Breakglass accounts.

It may happen that day-to-day user accounts require an exception for different reasons. In this case we recommend using the Microsoft cloud feature Access Review if an exception is necessary. Access Reviews can be set on a particular Azure AD group that enforces, for example, a monthly review of all group members that are part of the exception. The goal should be to replace the exception with a more secure solution in the near future.

Further readings:

• Plan an Azure Active Directory access reviews deployment
• Common Conditional Access policies
• The Attackers Guide to Azure AD Conditional Access
• Manage emergency access accounts in Azure AD

Risk 5 – Missing Management Restrictions for Privileged Roles

Secure cloud management was found in many assessments to be inexistent. We frequently concluded that login with Global Administrator or other privileged roles is possible from any device. For example, only the M365 portal was restricted by Conditional Access but not the Azure AD Portal or the old Azure AD Graph Explorer. Why? Because the project team that set up Conditional Access was, for example, only responsible for M365 but not Azure ARM. In the past, there were few options to restrict management access to the Microsoft Cloud. We recommended only allowing management from a specific company admin proxy with a dedicated public IP address. But nowadays, Conditional Access allows defining on which device a user with a particular role is allowed to log on. Therefore, we highly encourage using Privileged Access Workstations (PAW), at least for Tier-0 administrators.

Further readings:

• Securing devices as part of the privileged access story
• Conditional Access: Filter for devices
• Abusing Azure AD SSO with the Primary Refresh Token
• Death from Above: Lateral Movement from Azure to On-Prem AD

Risk 6 – Knowledge Gaps

During assessments, we often witness that the responsible IT personnel have a knowledge gap regarding how the Microsoft cloud functions. It goes hand-in-hand with the silo mentality, which is, in our opinion, not beneficial in a cloud setup. One frequently misunderstood example is the different role types in the Microsoft cloud. Summarised the Microsoft cloud architecture knows four main locations where roles can be found. The first location is Azure Resource Manager (ARM), which hosts IaaS and PaaS workloads. The roles in that location are described as Azure RBAC roles and grant access to various services like virtual machines, storage accounts, key vaults and more. The second location is Azure AD. Azure AD hosts superordinate roles that have direct and indirect access to ARM and SaaS applications. The most powerful role in the Microsoft cloud, the Global Administrator, can be found here. This role can control all entities in a tenant. Most of the roles found in Azure AD have the purpose of managing the M365. The third location are roles within cloud applications. Examples are Microsoft Graph, Exchange Online, Defender for Endpoint or Azure DevOps. In such roles, Azure AD roles, groups, service principals or users can sometimes be found as members. The last location is the Azure EA portal, in which the subscriptions for ARM are managed if your company has an enterprise agreement. The enterprise administrator and the account owner role in the EA portal have full indirect access to all subscriptions governed by the EA portal. The cloud application and EA portal roles are often overlooked and therefore are missing in the Identity & Access Management (IAM) processes. Adversaries can use such roles to avoid detection and may gain widespread access to different cloud services. We recommended, therefore, including such roles in the IAM processes. For the EA Portal, only dedicated Microsoft cloud work accounts should be used and ensured that organizational and security measures similar to other privilege accounts such as Global Administrators are applied.

Further readings:

• Microsoft Security Best Practices
• Enterprise billing and Azure AD tenants
• Security considerations of Azure EA management and potential privilege escalation

Risk 7 – AAD Connect Misunderstandings

AAD Connect is an on-premises solution that can synchronise a subset of identities from Active Directory to the Microsoft cloud. The synchronised objects in the cloud are referred to as hybrid identities. The JML process that is already implemented in the existing on-premises IAM solution is therefore supposedly guaranteed. Unfortunately this is not really the case, since AAD Connect can not manage all cloud entities such as cloud-only users, guest accounts and service principals. These entities are mostly forgotten and also require a JML process. Therefore a connector, preferably over the Microsoft Graph API should be established to cover non-synchronised entities. Additionality, the AAD Connect solution must be treated as Tier-0 and should therefore be managed only by Tier-0 Active Directory administrators.

Further readings:

• Unnoticed sidekick: Getting access to cloud as an on-prem admin
• Azure AD Connect for Red Teamers
• Azure Active Directory Pass-Through Authentication Flaws

Risk 8 – DevOps Solutions and Their Hidden Risks

In the article Attack Path Analysis – An effective method to gain advantage over adversaries, we described a possible attack path that abuses a day-to-day user account in Azure DevOps to gain access to a privileged service principal. To mitigate such Attack Paths, we recommend ensuring that similar organizational and security measures are applied as for other privileged accounts, e.g. Global Administrators. Furthermore, the DevOps solution used should be hardened according to available security recommendations.

Further readings:

• Attack Path Analysis – An effective method to gain advantage over adversaries
• Security groups, service accounts, and permissions in Azure DevOps
• Security best practices
• Azure DevOps: Recommended Practices for Secure Pipelines
• Microsoft Security Code Analysis
• Development security strategy

Risk 9 – Missing Clean Source Principal Practices

“The clean source principle requires all security dependencies to be as trustworthy as the object being secured” (Microsoft – Clean source principle). In on-premises environments and even more in the cloud this fundamental principle is often forgotten/ignored. A frequently heard rationale during assessments is “Our Microsoft cloud Tenant is not yet productive” which obviously violates the just named principle. An Azure AD Tenant is, in our opinion, productive when requesting the Azure AD Tenant on the Microsoft website. Therefore, the principles such as least privilege and clean source should be followed from the beginning. Otherwise, who can guarantee that the Tenant was not compromised during the process of the setup or during the pilot phase?

Further readings:

• Clean source principle

Risk 10 – Lack of Cloud Defender/Attacker Mindset

The old security architecture before cloud computing looks a lot like the structure of a medieval castle. Everything was placed on a trusted internal network, and all security configurations were set around the perimeter. With cloud computing, this architecture has become more and more obsolete. Furthermore, the concept of perimeter security is not practical when services are on shared infrastructure connected to the Internet. To overcome these new challenges, innovative models for security architecture and a mindset change are required. One example of a questionable mindset is when the rationale for a security finding is “But Microsoft will take care of it”. Unfortunately, with such a mindset, the chance of a compromise is high. To put it simply, cultivating a defender’s mindset starts with the understanding of who is responsible for what in a cloud environment. According to Microsoft, “cloud services are a shared responsibility”. From the Microsoft perspective, shared means basically Microsoft is provding the platform and the tools, but you are responsible for configuring, monitoring and securing your Tenant. Therefore, it is crucial to have an end-to-end understanding of how a Microsoft cloud tenant has to be secured, monitored and administrated. Regular configuration reviews and adaptations using Microsoft security capabilities, such as the Microsoft Secure Score, Defender for Cloud Recommendations, Azure Monitor Workbooks and others, are recommended. Also, using 3rd party assessment tools such as AzureHound, ROADtools, AzureADAssessment or AAD Internals, to name a few, can be valuable in assessing the security posture of an Azure AD Tenant.

Further readings:

• Shared responsibility in the cloud
• Attack Path Analysis – An effective method to gain advantage over adversaries
• Introducing the Adversary Resilience Methodology
• Defender’s Mindset

Assessment Tools:

The clean source principle should be kept in mind. Tools used should be reviewed first and, if possible, used with the required least privileges.

• AzureHound
• BloodHound Enterprise
• ROADtools
• Azure Stormspotter
• Azure AD Exporter
• Azure Review Checklists
• Azure Threat Research Matrix
• Azure ARM Governance Visualizer
• Azure Tenant Security Solution
• MicroBurst: A PowerShell Toolkit for Attacking Azure
• BloodHound Attack Research Kit
• Microsoft Azure AD Assessment
• AAD Internals

Conclusion

This Risks Top-Ten is not to be considered exhaustive, as more risky aspects could be added to the list, such as missing security monitoring, unawareness of credential pivoting and extraction of access or refresh tokens from browser sessions. Nonetheless, our idea was to promote more awareness about security best practices, as in the cloud, it is even more essential to adhere to these at it is on-premises. Following such best practices is sound advice when operating cloud platforms, as by default, they are not secure without hardening measures and continuous security adaptations. All in all, the fundamentals of securing a cloud environment are not significantly different from securing an on-premises environment. Therefore, it is crucial not to repeat mistakes from the past and invest in a rock-solid fundament before leveraging the vast, lucrative possibilities a cloud platform can offer.

About the Author

Marius Elmiger is a security professional since the early 2000’s. He worked in various IT roles such as an administrator, engineer, architect, and consultant. His main activities included the implementation of complex IT infrastructure projects, implementation of security hardening concepts, and compromise recoveries. Later he transitioned to the offensive side. As a foundation, in addition to numerous IT certificates, Marius graduated with an MSc in Advanced Security & Digital Forensics at Edinburgh Napier University. (ORCID 0000-0002-2580-5636)

Links

• https://attack.mitre.org/matrices/enterprise/cloud
• https://blog.xpnsec.com/azuread-connect-for-redteam/
• https://bloodhoundenterprise.io/
• https://cloudbrothers.info/en/azure-attack-paths
• https://danielchronlund.com/2022/01/07/the-attackers-guide-to-azure-ad-conditional-access
• https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token
• https://github.com/Azure/Stormspotter
• https://github.com/Azure/review-checklists
• https://github.com/AzureAD/AzureADAssessment
• https://github.com/BloodHoundAD/AzureHound
• https://github.com/BloodHoundAD/BARK
• https://github.com/JulianHayward/Azure-MG-Sub-Governance-Reporting
• https://github.com/NetSPI/MicroBurst
• https://github.com/azsk/AzTS-docs
• https://github.com/dirkjanm/ROADtools
• https://github.com/microsoft/azureadexporter
• https://github.com/mpeder/azdevopssecurity
• https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/concept-condition-filters-for-devices
• https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/concept-conditional-access-policy-common
• https://learn.microsoft.com/en-us/azure/active-directory/fundamentals/secure-with-azure-ad-introduction
• https://learn.microsoft.com/en-us/azure/active-directory/fundamentals/secure-with-azure-ad-resource-management#enterprise-billing-and-azure-ad-tenants
• https://learn.microsoft.com/en-us/azure/active-directory/governance/deploy-access-reviews
• https://learn.microsoft.com/en-us/azure/active-directory/privileged-identity-management/pim-configure
• https://learn.microsoft.com/en-us/azure/active-directory/roles/concept-understand-roles
• https://learn.microsoft.com/en-us/azure/active-directory/roles/delegate-by-task
• https://learn.microsoft.com/en-us/azure/active-directory/roles/permissions-reference
• https://learn.microsoft.com/en-us/azure/active-directory/roles/security-emergency-access
• https://learn.microsoft.com/en-us/azure/active-directory/roles/security-planning
• https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/
• https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/secure/development-security-strategy-overview
• https://learn.microsoft.com/en-us/azure/devops/organizations/security/permissions?view=azure-devops&tabs=preview-page
• https://learn.microsoft.com/en-us/azure/devops/organizations/security/security-best-practices?view=azure-devops
• https://learn.microsoft.com/en-us/azure/role-based-access-control/rbac-and-directory-admin-roles
• https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility
• https://learn.microsoft.com/en-us/security/compass/compass
• https://learn.microsoft.com/en-us/security/compass/overview
• https://learn.microsoft.com/en-us/security/compass/privileged-access-devices
• https://learn.microsoft.com/en-us/security/compass/privileged-access-success-criteria#clean-source-principle
• https://medium.com/@johnlatwc/defenders-mindset-319854d10aaa
• https://microsoft.github.io/Azure-Threat-Research-Matrix/?s=09
• https://o365blog.com/aadinternals/
• https://o365blog.com/aadkillchain
• https://o365blog.com/post/on-prem_admin
• https://posts.specterops.io/azure-privilege-escalation-via-azure-api-permissions-abuse-74aee1006f48
• https://posts.specterops.io/azure-privilege-escalation-via-service-principal-abuse-210ae2be2a5
• https://posts.specterops.io/death-from-above-lateral-movement-from-azure-to-on-prem-ad-d18cb3959d4d
• https://posts.specterops.io/introducing-the-adversary-resilience-methodology-part-one-e38e06ffd604
• https://posts.specterops.io/managed-identity-attack-paths-part-1-automation-accounts-82667d17187a
• https://secdevtools.azurewebsites.net
• https://twitter.com/_wald0/status/1569831939569324034
• https://www.cloud-architekt.net/azure-ea-management-security-considerations/
• https://www.secureworks.com/research/azure-active-directory-pass-through-authentication-flaws