Azure Storage Accounts are a core part of many cloud deployments, providing the ability to store unstructured data, including files, blobs, queues, and tables. However, their flexibility and ease of use can lead to serious security oversights. When storage accounts are misconfigured, they may inadvertently expose sensitive data to the public internet or allow unauthorised access through compromised credentials.
Real-World Exploits
One of the most common issues is the public exposure of blob containers. By default, Azure does not make containers publicly accessible, but misconfigurations during setup or continuous delivery processes can override these defaults. Attackers can use automated tools to scan for open containers and download data without authentication. This has occurred in numerous real-world incidents, including cases where internal documents, personally identifiable information (PII), and source code were publicly accessible.
Another serious problem is the leakage of storage account access keys. These keys act as master credentials, allowing full access to the storage account’s data. If access keys are accidentally committed to public code repositories, such as GitHub, attackers can immediately exploit them. This scenario is especially common in CI/CD pipelines where credentials are hardcoded or poorly managed. Once discovered, attackers can use these keys to extract, modify, or delete data at will.
Misconfigured storage is often low-hanging fruit for attackers. Even organisations with advanced cloud deployments may overlook these simple but critical vulnerabilities.
Mitigation Tips Disable anonymous access unless absolutely required. Use Shared Access Signatures (SAS) with scoped permissions and expiration. Regularly rotate access keys and scan repositories for credential leaks using tools like Microsoft Defender for DevOps.
Role Assignment and Privilege Escalation
In Azure, Role-Based Access Control (RBAC) is designed to manage who can access what resources and at what level. However, mismanagement of these roles often leads to excessive permissions being granted. When users or service principals are assigned broad roles such as “Contributor,” it can result in unintended privilege escalation paths, which attackers are quick to exploit.
Attack Path
A typical scenario involves an attacker gaining access to an account with “Contributor” rights. While this role doesn’t directly grant administrative privileges, it allows the user to assign roles to other accounts. This loophole enables the attacker to elevate privileges by assigning the “Global Administrator” role either to themselves or to a newly created malicious identity. Once in possession of this elevated access, the attacker has near-total control over the Azure environment, including identity systems, virtual machines, and data storage.
This kind of escalation often goes unnoticed due to weak auditing practices or the absence of real-time monitoring. In large organisations, where many roles and accounts exist, these dangerous pathways can remain hidden until they’re exploited.
Tools
- AzureHound: A tool used to map out Azure AD and RBAC relationships, making privilege escalation paths visible.
- PowerZure: A post-exploitation framework designed specifically for enumerating and exploiting Azure role misconfigurations.
Mismanaged role assignments are one of the most overlooked yet impactful security risks in Azure. Tightening these controls is critical for any organisation using Azure services.
Mitigation Tips
Create custom roles tailored to specific job functions. Monitor role changes using Azure Monitor. Implement Just-In-Time (JIT) access through Azure Privileged Identity Management (PIM) to reduce the window of exposure.
Logic App and Function App Abuses Azure’s serverless offerings like Logic Apps and Function Apps are powerful, but often misconfigured.
Exploits
- Triggering Logic Apps externally via exposed HTTP endpoints
- Accessing function code and environment variables via unsecured SCM endpoints
Mitigation Tips
Implement IP restrictions and authentication for all triggers. Validate inputs and sanitise data. Secure your deployment pipelines and avoid hardcoding secrets in code or config files.
