Azure private endpoint removed
A private endpoint or a storage/SQL network restriction was removed.
What it detects
A private endpoint or a storage/SQL network restriction was removed.
A private endpoint is the reason an Azure SQL database or a storage account is reachable only from inside the virtual network. Deleting it, or opening the resource's firewall to allow public access, does not change a single permission — it changes WHO CAN REACH the resource, from "hosts on our network" to "the internet". Every credential that was already sufficient now works from anywhere.
It is exposure created by a network change, which is why it survives reviews that look at identity: nobody was granted anything. The data itself is untouched and the resource keeps working normally, so there is no operational symptom either.
MITRE ATT&CK mapping
False positives and triage
Infrastructure teams delete endpoints during decommissioning and re-architecture, and both are planned with a change record — that record is the fastest way to resolve this. Escalate when the deletion has no change ticket, when it targets a resource holding production data rather than something being retired, and when the same actor made identity or role changes nearby. A Sql/servers/firewallRules/write is worth reading in full before judging: the finding is a rule whose range is 0.0.0.0, not the existence of a firewall rule. If the resource genuinely was exposed, treat every credential valid against it as reachable from the internet for the whole window between this event and the fix.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 70%. Source: rules/cloud/azure_private_endpoint_removed.yaml, licensed under the Apache License 2.0.
id: cloud.azure.private_endpoint_removed
version: 1.0.0
status: stable
severity: critical
confidence: 0.7
platforms: [application]
mitre_techniques: [T1562.007, T1133, T1530]
description: |
A private endpoint or a storage/SQL network restriction was removed.
A private endpoint is the reason an Azure SQL database or a storage account is
reachable only from inside the virtual network. Deleting it, or opening the
resource's firewall to allow public access, does not change a single permission —
it changes WHO CAN REACH the resource, from "hosts on our network" to "the
internet". Every credential that was already sufficient now works from anywhere.
It is exposure created by a network change, which is why it survives reviews that
look at identity: nobody was granted anything. The data itself is untouched and
the resource keeps working normally, so there is no operational symptom either.
match:
provider: AzureActivity
event_action_contains_any:
- "Microsoft.Network/privateEndpoints/delete"
- "Microsoft.Network/privateEndpointConnections/delete"
- "Microsoft.Network/privateDnsZones/delete"
- "Microsoft.Sql/servers/firewallRules/write"
- "Microsoft.Sql/servers/firewallRules/delete"
correlation_keys: [user_name]
false_positive_guidance: |
Infrastructure teams delete endpoints during decommissioning and re-architecture,
and both are planned with a change record — that record is the fastest way to
resolve this. Escalate when the deletion has no change ticket, when it targets a
resource holding production data rather than something being retired, and when
the same actor made identity or role changes nearby. A `Sql/servers/firewallRules/write`
is worth reading in full before judging: the finding is a rule whose range is
`0.0.0.0`, not the existence of a firewall rule. If the resource genuinely was
exposed, treat every credential valid against it as reachable from the internet
for the whole window between this event and the fix.
Related detections
Run this rule on your own logs — offline
KIROSEC runs this rule and the rest of the library over Windows, Linux, macOS and cloud audit logs on the analyst's own machine. Every alert links to the events that raised it, and nothing leaves the device.