Azure Attack Detection and Prevention Strategies

Azure attack detection and prevention requires a multi-layered approach to stay ahead of threats.

Implementing Azure Advanced Threat Protection (ATP) can help detect and prevent attacks by analyzing network traffic and endpoint activity.

Regularly updating Azure Security Center (ASC) threat intelligence feeds ensures the latest threat information is available to protect your cloud resources.

Monitoring Azure Active Directory (AAD) for suspicious sign-in activity helps prevent unauthorized access to your cloud environment.

Implementing Azure Sentinel, a cloud-native security information and event management (SIEM) solution, can help detect and respond to threats in real-time.

Detecting an Azure attack requires a keen eye for unusual activity.

A better way to detect this kind of attack is to check for unexpected assignment of a Microsoft.ManagedServices registration.

Check the hunting query for this, as it can be a telltale sign of an attack.

In the target tenant, you can also check which service offers are currently active through PowerShell or in the Azure Portal.

Azure Lighthouse is a legitimate way to manage resources in other tenants, but it can be exploited by attackers.

An attacker can trick an administrator or use a hijacked account to accept delegated permission requests.

The attacker creates a custom template with the needed role definition, but can't use Owner or any built-in role with DataActions permissions.

A separate deployment is necessary for each subscription, and the attacker can use Azure Policy to deploy this in an automated fashion.

After deployment, the attacker can access resources in the target tenant subscription from their own tenant.

With Contributor access, an attack path like Invoke-AzVMRunCommand becomes possible.

Detection is key to catching Azure attacks in their tracks. A better way to detect this kind of attack is to check for unexpected assignment of a Microsoft.ManagedServices registration.

You can do this by hunting for this specific query. In the target tenant, you can also check which service offers are currently active through PowerShell or in the Azure Portal.

The activity logs will show all actions initiated by the attacker, making it easier to track their movements. However, there is a catch – in the current preview state of the service, the RBAC view for the attacked subscription might not show the additional Contributor.

Here are some resources to help you detect Azure attacks:

Guest Configuration Policy can be a powerful tool for attackers to gain persistence in your Azure environment.

The Guest Configuration extension runs in the SYSTEM context, giving the attacker elevated privileges on the target machine.

To avoid this, it's essential to monitor Azure Policies closely, as attackers can hide in plain sight by deploying custom configuration packages through native Azure capabilities.

Azure Policy with Guest Configuration Service is the successor of Azure Automation State Configuration service, using the new platform-independent version of PowerShell.

Any admin users should not be synced between AD and AAD to prevent lateral movement in the environment.

Try to establish a trust boundary between the two directories.

Here are some key points to keep in mind:

The Hybrid Runbook Worker is a machine, either on-prem or in the cloud, that executes your Azure Automation runbooks without the limitations of the native Azure runbook worker.

It requires a certificate-based authentication, which is created automatically for easier usage in your automation runbooks.

This certificate must be exported to the Hybrid Runbook Worker machine.

An attacker with access to this machine could extract the certificate and use it to authenticate against the Azure environment.

This could lead to privilege escalation and access to additional resources.

To mitigate this risk, you should treat your Entra ID (Azure AD) connect server as a Tier 0 machine, similar to a domain controller.

This means exercising caution when managing this server and limiting access to authorized personnel only.

Here are some additional resources to learn more about this topic:

Delegated administrative privileges can be a double-edged sword, as seen in Example 1, where Cloud Solution Providers (CSPs) gained Global Admin permissions, putting customer data at risk.

To mitigate this, Microsoft released granular delegated admin privileges (GDAP) in February 2022, allowing customers to control which user of the partner accesses their data.

Customers should regularly check their partners in the Microsoft Admin Center and remove unneeded permissions to prevent potential attacks.

The Global Admin role, as described in Example 2, grants the person who holds it "God-like" permissions in the tenant, making it a prime target for attackers.

To detect changes to this role, customers should monitor the Entra ID (Azure AD) audit log and switch from "Activity" to "Directory Activity" to view changes.

In Example 3, granting an application app permissions can give the app access to sensitive data, and customers should watch out for permissions like Application.ReadWrite.All, AppRoleAssignment.ReadWrite.All, and RoleManagement.ReadWrite.Directory.

These permissions can potentially harm the environment, and customers should remove them if possible.

Similarly, in Example 4, granting the wrong Entra ID (Azure AD) roles to a user or application can result in an attack path to global admin, and customers should monitor changes to the most privileged roles in their environment.

Here are some specific roles to watch out for:

Delegated Administrative Privileges can be a double-edged sword. Microsoft's Cloud Solution Providers (CSPs) can offer licenses and services to customers, but they also gain Global Admin permissions in the customer's tenant. This can be a problem if the customer can't control which CSP user has access to their data.

CSPs can implement a role-based access concept, but it's mostly an all-or-nothing approach that doesn't allow for differentiation between customers. This lack of control can have serious consequences, as seen in the case of NOBELIUM targeting CSPs with delegated administrative privileges.

In February 2022, Microsoft released Granular Delegated Admin Privileges (GDAP) to mitigate the far-reaching permissions. This is a step in the right direction, but it's still crucial to check your partners in the Microsoft Admin Center and remove unneeded permissions.

Here are some steps you can take:

Microsoft recommends these steps to their partners, so it's worth taking a closer look at your own setup.

API Permissions are a fundamental part of Entra ID (Azure AD) and play a crucial role in application management.

Granting an application app permissions gives the app access to Graph Endpoints and related data sets, regardless of whether a user is logged in or not.

Some permissions, like Application.ReadWrite.All, are potentially harmful as they grant extensive permission and can be used by an attacker to add a custom app registration and gain additional privileges.

This can lead to a backdoor into the tenant, making it essential to remove such permissions if possible.

You should watch out for the following permissions and remove them if possible:

Elevate Subscription Access is a legitimate method of gaining elevated permissions in your Azure environment, but it can be misused by attackers who already have extended access.

The Global Admin role provides God-like permissions in the tenant, similar to a Domain Admin in on-premises Active Directory.

To achieve this, the attacker must enable the setting “Access management for Azure resources” in the Entra ID (Azure AD) properties.

This adds the current user to the “User Access Administrator” role on the Tenant root, allowing them to add additional role permissions for malicious applications.

The change will not show up in the subscription audit log or Entra ID (Azure AD) audit log, but it will be logged in the “Directory Activity” log, which can be accessed through “Monitor”.

To view changes, switch from “Activity” to “Directory Activity” in the log.

You can also use PowerShell to check if there are any users with this kind of role assignment on the root scope.

Unfortunately, there is no native way to forward these logs to a Log Analytics workspace or Microsoft Sentinel to hunt for suspicious activity.

Ad Roles can be a major security risk if not managed properly. The "Privileged Authentication Administrator" role is particularly concerning, as it essentially grants the user Global admin permissions, allowing them to reset passwords, modify MFA settings, and take over accounts.

Granting the wrong Entra ID (Azure AD) roles to a user or application can lead to a significant attack path to global admin. The "Privileged Role Administrator" role is another high-risk role that grants the entity holding it the permission to add additional Entra ID (Azure AD) roles to any user, including the Global Administrator role.

Monitoring changes to the most privileged roles in your environment is crucial. You should also use the Entra ID (Azure AD) audit log to detect changes to those roles.

Here are some key roles to keep an eye on:

AAD Connect Password Reset is a critical concern for organizations using Azure Active Directory (AAD) Connect. An attacker with admin permissions on the Entra ID (Azure AD) Connect server can extract a user's password and authenticate against AAD to reset passwords.

This vulnerability can be exploited if an on-prem admin account is synced and has been granted global admin permissions. The attacker can then use this as an entry point to your AAD.

In the on-prem environment, the MSOL user typically has the ability to reset passwords and even read passwords using DCSync. This means the attacker can request the password of the krbtgt user and use it to create golden or silver Kerberos tickets.

To mitigate this risk, you can limit the capabilities of the MSOL user to specific organization units and users that must be synchronized. The krbtgt user is not one of those users, so it's essential to exclude it from the sync process.

By taking these precautions, you can significantly reduce the risk of an attacker exploiting the AAD Connect password reset vulnerability.

With a foothold in an Azure subscription and a role assignment of Virtual Machine Contributor, an attacker can execute scripts or PowerShell commands on any virtual machine within the subscription. This allows them to laterally move within the cloud environment.

The script sent to the VM resides in the attacker's computer or directly in Azure Cloud Shell. This makes it easy for the attacker to access and execute malicious scripts.

All activity will be logged in the Subscription activity log as well as on the target machine.

Desired State Configuration is a built-in configuration capability of Windows Server with at least Windows PowerShell v4, which relies on a central service and an agent on the server to apply configurations.

It's essential to be aware that this technique can be used to deploy malicious configurations or backdoors to your servers, making it a potential security risk.

To mitigate this risk, it's crucial to monitor Azure Automation State Configuration closely, as it can be used to deploy configuration changes to every Windows server in your environment.

Here are some key references to consider:

In fact, when installing Entra ID (Azure AD) Connect, a user called MSOL_[0-9a-f]{12} is created in both directories, which has extensive permissions in your on-prem and cloud environment, making it a potential target for attackers.

This user is also excluded from security defaults and most companies exclude it from their conditional access policies, which can further increase the risk of a security breach.

Active Directory Federation Server (ADFS) is a critical component in many organizations' identity and access management systems. It's a powerful tool that enables single sign-on (SSO) to cloud applications, but it also poses a significant risk if not properly secured.

If an attacker gains access to the private key material on your ADFS, they can create forged SAML responses that are accepted by any service that trusts the ADFS service. This is why this attack was initially named "Golden SAML", in reference to the golden ticket attack when using Kerberos.

Any user synced from on-prem to the cloud, which is redirected to the ADFS for authentication, can be impersonated without even knowing the password. This is a serious security risk, as it allows attackers to gain unauthorized access to sensitive data.

Here are some key facts about the Golden SAML attack: