Blog: Cloud Security

Azure AD. Attack of the Default Config

Jan Masters 12 Jan 2021

Uncloaking dangerous and default configurations within Azure.

TL; DR

There are several default configurations within the admin portal of Azure. The main affected area is Azure Active Directory (Azure AD) which is the primary area that controls user authentication, group memberships and privileges. The utilisation of these configurations can create several attack vectors that could be chained together to compromise the environment. The most significant issues concern app registrations that allow users to register and give permissions to third-party apps.

Introduction

With the cloud taking over the information technology world, it is easy to overlook the default, out of the box configurations that can be hard to find or appear innocent and low risk/impact. Pilgrims on the cloud journey are often aware and regularly reminded of the risks that come with such accessible technology. Are there enough clear, concise and updated resources on how to mitigate these new dangers? Is it possible when the platform undergoes as many updates and feature releases such as Microsoft’s cloud platform?

This blog will outline and discuss several troublesome default configurations that can undermine the security and control of your environment(s). It should be noted that this is not a step-by-step tutorial on how to attack Azure tenants – it is a guide on how defenders can improve their security to restrict their ever-growing threat landscapes. Lastly, I am not aiming for this to be a definitive list, but a list of the most significant configurations/issues.

AZURE AD

PORTAL ACCESS

Configuration Name: ‘Restrict access to Azure AD administration portal’

Configuration Location: Azure Active Directory -> User settings

Default Setting(s): No

This configuration restricts access to the Azure AD administrative portal within the Azure Portal (https://portal.azure.com). However, the default value is ‘No’, which allows any user within the tenant to enumerate various configurations, users, groups, devices and interconnected apps. This information may not result in a direct compromise, but it would assist an attacker as they can see what safeguards are in place, who to target and what avenues are available.

This unrestricted access is not typically necessary in daily operations as users who require access can be granted via administrative roles/groups.

On another note, this configuration only restricts access to the Azure AD section of the Azure Portal, meaning that users can still browse to https://portal.azure.com. This is not ideal if you do not use Azure or if you have not correctly configured RBAC (Role-based Access Control) on your Azure management groups/subscriptions. I have had several experiences where I have managed to sign customers up to the free trial of Azure using a non-privileged account without having to specify billing information as the clients had active Office 365 subscriptions.

Signing up for a trial will give the attacker full admin rights to the Azure environment, which can be utilised to implement various services such as Azure Virtual Machines. The repercussions of this can lead to financial and/or reputational damage as an attacker could create VMs to mine cryptocurrencies, to attack other targets or to host malicious files/resources. Restricting access to the entire portal can only be achieved with the use of Conditional Access Policies within Azure. Please see external references for a link on how to implement such a policy.

GUEST INVITE SETTINGS:

Configuration Name: ‘Members can invite’

Configuration Name: ‘Guests can invite’

Configuration Location: Azure Active Directory -> External Identities -> External collaboration settings

Default Setting(s): Yes

This setting allows anyone in your Azure AD tenant to create guest accounts for external users, which adds to the theme of the IT department losing control of their platform. Guest users could be utilised to view sensitive data if there are lax data protection configurations and/or if other misconfigurations exist in the environment. Guest user accounts are typically used as ‘backdoor’ accounts if their access is detected and blocked. Furthermore, these users can also enumerate users, groups and various other information if abused.

Remediating this issue is as easy as switching the toggle to ‘No’. This setting will not entirely remove this functionality as admins and users with the ‘guest inviter’ role can invite guests.

GROUP CREATION:

Configuration Name: ‘Users can create security groups in Azure portals’

Configuration Name: ‘Users can create Microsoft 365 groups in Azure portals’

Configuration Location: Azure Active Directory -> Groups -> General

Default Setting(s): Yes

This might appear innocent but infuriating to organised IT departments with a well-designed AD structure, however, this issue can be leveraged with another default configuration to cause mass exploitation of the environment(s). An attacker could create a security group that contains all Azure AD users or just a handful of administrative users to start a chain-of-attack, which will be expanded upon in the next section.

APP REGISTRATION + CONSENT:

Configuration Name: ‘Users can register applications’

Configuration Location: Azure Active Directory -> User settings

Default Setting(s): Yes

Configuration Name: ‘Users can consent to apps accessing company data on their behalf’

Configuration Name: ‘Users can consent to apps accessing company data for the groups they own’

Configuration Location: Azure Active Directory -> Enterprise applications -> User settings

Default Setting(s): Yes

Configuration Name: ‘User consent for applications’

Default Setting(s): ‘Allow user consent for apps’

Configuration Name: ‘Group owner consent for apps accessing data’

Default Setting(s): ‘Allow group owner consent for all group owners’

Configuration Location: Azure Active Directory -> Enterprise applications -> Consent and permissions

These default settings open the users and environment up to dangerous attack vectors, which can easily be manipulated and leveraged to compromise users and your platform. There are two main angles I want to cover – the insider threat and the outside phishing threat, but ultimately these can go hand-in-hand.

INSIDER THREAT:

Insider threats could access the ‘Microsoft Azure Management’ app (Azure portal, Azure PowerShell and others) to create a security group (already mentioned in the past point) and consent to a malicious app on behalf of the organisation and group members. “It’s just an app, nothing that serious can happen?”. These applications can request whatever permissions they want. For example, the app could demand read and write permissions to your mail, profile, files, calendars — the list goes on. The repercussions could be massive if the attacker has the right imagination.

PHISHING/SOCIAL ENGINEERING:

Similar to before, an attacker can create a publicly accessible Azure app and pass the URL to a victim via several methods such as vishing, phishing, and DNS tampering on a local network. Once the user is directed to the page, they are presented with an official Microsoft page that lists the permissions and has an ‘Accept’ or ‘Cancel’ button. Users are more than likely to click accept due to several factors. For example, the UI pushes the user into clicking the vibrant blue button on the page, and because it is an official Microsoft page. All it takes is for one user to click accept then the account is compromised, and the environment is in danger.

Legacy authentication

This section I want to dedicate to Legacy Authentication, which is supported by default* but cannot be remediated without an Azure AD license that grants access to ‘Conditional Access policies’. There are several available licenses, but the primary ones are Azure AD P1 and P2. Please refer to Microsoft’s official documentation (one listed in ‘External References’) for a full list of each subscription and its features.

Conditional Access policies’ are a fundamental part of cloud security in Azure as it allows you to set strict rules and restrictions within your tenant. For example, you can dictate authentication and access to specific resources by IP address, geographical locations and other factors.

Legacy authentication is the support for users to authenticate against Azure AD and other services using less secure and legacy protocols/applications, which typically lack modern security capabilities such as multi-factor authentication (MFA). For example, Autodiscover, Exchange Online PowerShell, MAPI and POP3 are a sample of legacy authentication protocols. Therefore, this makes it the most popular victim for brute-force attacks as Azure cannot enforce modern security implementations.

There are a few different ways to detect the usage and support for legacy authentication. My preferred method is heading to this location Azure AD -> Sign-ins and adding two filters (Client App and Status). Once you have selected the necessary information, it will show you a list of all sign-ins using such protocols.

Microsoft announced the end of support for Basic/Legacy Authentication back in 2019 but Microsoft and the world (COVID) had different plans, which has resulted in it still being supported (partially). Microsoft has planned a soft date for the second half of 2021, but more news is yet to come. I have created the below table to easily explain this partial support.

Tenant Type/Creation	Support by Default?
Tenant created before October 2019	Yes
Tenant w/o any recorded legacy usage from October 2020	No

Either way, I would not trust Microsoft to secure your environment for you – I would recommend that you implement these configurations yourself.

Conclusion

There is a lot of information here regarding dangerous default configurations that come with every new Azure tenant – it is baffling but it also understandable from a high-level perspective. It seems like Microsoft give you (the customer) a blank slate that is fully customisable to your needs and your risk appetite. However, the lack of guided instructions when you create an account, or the lack of clear and concise documentation fertilises the growth of unsecured cloud environments.

Following on from the section regarding social engineering, I personally believe that cloud-focused social engineering attacks such as phishing are more successful than generic pretexts due to the lack of awareness and training around ‘the cloud’ and social engineering attacks using Microsoft apps.

The same advice applies for cloud platforms as it does for other areas of IT security – regular penetration testing, monitoring and auditing form a major part of cloud security. There’s more about cloud and DevOps security here.