If you follow me on Twitter, you may have seen the following tweet passing by

This brings me to the following story, where we were involved in a migration of certain Azure resources from one tenant to another one. While this process used to be cumbersome, we’ve seen significant improvements in resource and group migration over the last few years, making it much more streamlined. Azure now offers the ability to move resources to other groups, subscriptions, and regions within the same tenant.

However, in this particular scenario, we were required to transfer resources to a new tenant. Since this was a non-production environment and the data in the existing data stores were not critical for business, we decided to purge the environment and use our CI/CD pipelines to rebuild the environment and data stores from scratch.

While doing so, we got a PreflightValidationCheckFailed error message stating that our storage account name was already taken, which was unexpected given the fact we had just purged the entire environment.

##[error]PreflightValidationCheckFailed: 
Preflight validation failed. Please refer to the details for the specific errors. 
[
    {
       "code":"StorageAccountAlreadyTaken",
       "target":"storagedemoglenn",
       "message":"The storage account named storagedemoglenn is already taken."
    }
 ]

Running an additional check on the environment using Azure CLI also yielded no results, indicating that the storage account was not present in the old environment.

So… why were we unable to create a storage account based on a name that no longer existed – or we assumed it no longer existed.

Recovering a deleted storage account

Azure provides an option to recover a deleted storage account in certain situations.

A deleted storage account can be recovered if it was deleted within the past 14 days, created with the ARM deployment model, and a new storage account with the same name has not been created since the original account was deleted (within the same tenant – more on that later 😉).

Recovery of a deleted storage account is not guaranteed. Recovery is a best-effort attempt. Microsoft recommends locking resources to prevent accidental account deletion.

The option to restore a deleted storage account is available through the portal. However, this soft-delete/restore option also implies that the name of that storage account is reserved for the duration of the recovery period, meaning 14 days. In our case, this was the cause of our validation check failure explained above.

Next to the above screen that gives an overview of accounts that are eligible for deletion, you can also use the Storage API Endpoint to query for deleted accounts. More details on that endpoint can be found here:

https://learn.microsoft.com/en-us/rest/api/storagerp/deleted-accounts

When taking a closer look at the endpoint, you’ll notice that no DELETE operation is present, making it impossible to PURGE (hard delete) a storage account from a user’s point of view.

Back to the drawing board….

Security by Design

At this point, we’ve reached out to the internal MVP distribution list and we received the following interesting view and explanation on why this DELETE is not accessible to users. The name reservation applies for creations in another tenant and has been implemented for security reasons, mainly to prevent subdomain takeovers.

A subdomain takeover is a type of attack where an attacker takes control of a subdomain that belongs to a legitimate organization. This attack can occur for various reasons such as an expired domain, an abandoned subdomain, or misconfigured DNS settings. Once the attacker gains control of the subdomain, they can launch attacks such as phishing, data exfiltration, and malware distribution.

In Azure a subdomain takeover can occur when a DNS record points to a de-provisioned Azure resource, creating a “dangling DNS” entry. If a CNAME record isn’t removed, it can be advertised as an active domain, but it doesn’t route traffic to an active Azure resource, making it vulnerable to subdomain takeover. This allows a malicious actor to redirect traffic intended for an organization’s domain to a site performing a malicious activity, resulting in a loss of control over the content of the subdomain, negative press, and brand damage, among other things.

If you want to read more about how this applies to many services within Azure, please check out this link.

Conclusion

Depending on the cloud service model, there is variable responsibility for who is responsible for managing the security of the application or service. In some cases, we, without being fully aware, will take certain security risks, as the one explained above.

In these types of cases, it’s great to see that the Azure Platform is here to assist us in meeting some of these responsibilities through built-in features, organized into six areas: Operations, Applications, Storage, Networking, Compute, and Identity.

If you want to learn more about how to secure your cloud solutions and best practices and guidance around cloud security, you might want to check out Azure Security Fundamentals Documentation.

Thanks for reading!