Varonis Threat Labs uncovered a vulnerability in the Azure portal that can lead to sudden and significant data loss. By manipulating the name of server-level firewall rules through TSQL, a threat actor with privileged access to an Azure SQL Server can inject an implant that, based on specific user actions, deletes arbitrary Azure resources that the user has permissions for. The impact of a threat actor exploiting this vulnerability could be large-scale data loss in the affected Azure account.
Varonis Threat Labs disclosed the Destructive Stored URL Parameter Injection vulnerability to Microsoft on August 5, 2024. Microsoft issued a partial patch for this vulnerability on August 30, 2024, and the full patch on April 09, 2025.
A quick brief on Azure SQL Server firewall
Azure SQL Server is a family of cloud database services used to build and scale applications. Firewall rules for the Azure SQL Server help control access to the server and data within.
For Azure SQL Servers, there are two layers of firewall rules: database-level firewall rules and server-level rules.
When a connection is initiated from an IP, network access is first evaluated using the database-level firewall rules. If no rules exist for the IP initiating the connection, then Azure will default to using server-level firewall rules.
Only the server-level firewall rules can be manipulated through the Azure Management API and Azure portal. However, all rules can be edited from the server using TSQL statements by calling the stored procedure sp_set_firewall_rule and sp_set_database_firewall_rule.
Our research
During our research into the network access controls for Azure SQL Server, we noticed that the server firewall rules created using TSQL do not have character limitations and are visible in the Azure Portal.
This should raise concerns because, In general, inputs without character limitations or field sanitization can allow a threat actor to inject all manner of code.
We began testing to see what attacks were allowed via this security gap. The first thing we checked was for a simple (cross-site scripting) XSS by creating a rule with the name:
If successful, this would allow an attacker to inject malicious executable scripts into an application’s trusted code (in our case, an Azure SQL Servers Portal web page).
Surprisingly, the XSS did not work. Instead, the UI displayed the rules with forbidden characters grayed out and provided a prompt explaining that these rules can be edited and deleted via TSQL.
Figure 1: Despite the prompt, these rules can be deleted using the UI.
Figure 1: Despite the prompt, these rules can be deleted using the UI.
The next thing we tried was removing the grayed-out rules from the UI via the delete icon, which was successful, for the most part, despite the prompt implying you can only remove or modify through TSQL. The request to delete the rule with forbidden characters may fail, but most importantly, that request to delete is always sent.
The Varonis team next began investigating the API requests sent when we deleted our malicious rule.
We created a rule named ‘*’ via TSQL and deleted it using the Azure Portal. Upon reviewing the API logs, we found that the rule name is part of the URL when a DELETE request is sent.
Figure 2: Inspecting the API request reveals the URL that receives the deletion request.
Figure 2: Inspecting the API request reveals the URL that receives the deletion request.
The next rule we created was named “../”, and upon deleting that rule, the entire test SQL Server was also suddenly deleted, and we found ourselves in need of a new test server!
The cause of the deletion of our test server can be found in the URL to which the DELETE request is sent. The URL the DELETE request was sent to is:
/subscriptions/<subscriptionId>/resourceGroups/<rg>/providers/Microsoft.Sql/servers/test-4ad9a/firewallRules/../?api-version=2021-11-0.
The firewall rule name “../” within the URL is treated as if it refers to the parent directory and to the SQL Server itself, which leads to the entire server being deleted.
Figure 3: The recipient URL targeted the server instead of the firewall rule when the deletion request was sent.
Figure 3: The recipient URL targeted the server instead of the firewall rule when the deletion request was sent.
With a little effort, it’s possible to create a rule that deletes any resource in the Azure tenant with the following name:
../../../../../../../<theResourceURL>?api-version=<relevant_version>#”.
Each “../” we add “removes” a path from the URL, allowing us to eventually target resources from different services or resource groups in the Azure subscription.
The two identities that can run sp_set_firewall_rule to create firewall rules on the server are the server-level principal login, which is the SQL admin user created while provisioning the server, and an Entra ID principal assigned as a server admin. This means that an entity with privileges solely on the SQL Server can create a malicious rule, that, if deleted by a privileged user, can lead to the deletion of other Azure resources.
Hiding our malicious rules
We now have a pretty good primitive building block of an attack, but our malicious rule is openly displayed in the Azure Portal. We need to conceal our malicious rule to make it less noticeable.
Our Azure best practices blog shows that the “Allow Azure services to access this server” setting adds a rule with both a start and end IP of ‘0.0.0.0’.
By adding a rule with a malicious name and setting the start and end IP to ‘0.0.0.0’, our malicious rule will still exist. It will appear as a checked check box with the text “Allow Azure services to access this server.”
If or when an admin unchecks this box, a DELETE request is sent to all rules with the ’0.0.0.0’ IP Addresses, including our malicious rule, which causes a resource to be deleted.
Figure 4: It would be common practice for an administrator to reject this setting and trigger an attack.
Figure 4: It would be common practice for an administrator to reject this setting and trigger an attack.
This technique enables the simultaneous removal of many resources. It also offers the benefit of being less conspicuous than a new rule that suddenly appears in the UI, which makes it more likely that an unsuspecting admin would uncheck the box and trigger our malicious rule.
Attack scenarios and impact
Theoretical attackers could have abused this exploit to achieve denial of service and data destruction. While Azure SQL resources are recoverable within a certain timeframe, this vulnerability is not limited to the deletion of SQL resources. Below is a plausible attack scenario a threat actor could employ.
- Having gained credentials to an Azure SQL Server through any method, such as through an exploited web server, the attacker could then escalate the damage done when using those credentials by creating the malicious rule targeting key resources.
- From there, an attacker could create rules that damage or impair functionality, causing an IT professional to engage with the firewall rules and encouraging change, which increases the likelihood of a successful exploit.
- Lastly, to further increase the chance of activating the implant, a sophisticated attacker might start a phishing campaign targeting the IT professionals in charge of the affected Azure account with the goal of having them disable the “Allow Azure services to access this server” feature — effectively triggering the exploit.
Summary
Varonis Threat Labs identified the Destructive Stored URL Parameter Injection vulnerability in the Azure portal.
This vulnerability would have allowed a threat actor with privileged access to an Azure SQL Server to alter configurations in such a way that would destroy resources and data upon admin action. Microsoft has resolved the issue, and this vulnerability no longer exists. No action is needed from current customers.
Varonis Threat Lab’s mission is to discover new ways data is at risk and to help build security solutions to detect and stop threats. To learn more about Varonis’ threat research, view our articles.
