Listen to this Post
Introduction:
Azure Management Locks provide a critical control‑plane defense that prevents accidental or malicious modifications to cloud resources. However, most teams misconfigure them—using `CanNotDelete` when they need ReadOnly—or fail to monitor lock removal, leaving a false sense of security. In a recent adversary emulation exercise, a well‑implemented `ReadOnly` lock stopped a storage‑account logging disable attack dead in its tracks, proving that the right lock type, combined with alerting, can turn a theoretical control into an active breach deterrent.
Learning Objectives:
- Differentiate between `CanNotDelete` and `ReadOnly` locks and apply the correct type for defense‑in‑depth.
- Implement `ReadOnly` locks via Azure CLI, PowerShell, and Infrastructure‑as‑Code (IaC) templates.
- Build detection rules for lock removal attempts using Azure Activity Log and Sentinel.
You Should Know:
- Lock Types: Why `CanNotDelete` Won’t Stop a Defense Evasion Attack
Many Azure admins mistakenly believe any lock blocks all changes. In reality, a `CanNotDelete` lock allows resource modifications (e.g., updating properties, disabling logging) but prevents deletion. Only a `ReadOnly` lock blocks all write operations at the control plane – exactly what stops an attacker from turning off storage account diagnostics.
Step‑by‑step to test the difference:
Azure CLI (Linux/Cloud Shell):
Create a test storage account az storage account create -n testlockstore -g MyRG --sku Standard_LRS Apply CanNotDelete lock az lock create --name test-cannotdelete --resource-group MyRG --resource testlockstore --resource-type Microsoft.Storage/storageAccounts --lock-type CanNotDelete Try to disable logging (this will SUCCEED despite the lock) az monitor diagnostic-settings update --name diagSetting --resource testlockstore --set logs.enabled=false Now apply ReadOnly lock az lock create --name test-readonly --resource-group MyRG --resource testlockstore --resource-type Microsoft.Storage/storageAccounts --lock-type ReadOnly Repeat the disable attempt – it FAILS with "ReadOnly lock prevents modification" az monitor diagnostic-settings update --name diagSetting --resource testlockstore --set logs.enabled=false
PowerShell (Windows/macOS/Linux):
$resource = Get-AzResource -ResourceGroupName MyRG -ResourceName testlockstore New-AzResourceLock -LockName readonlyLock -LockLevel ReadOnly -ResourceName $resource.Name -ResourceType $resource.ResourceType -ResourceGroupName $resource.ResourceGroupName
- Privileged Identity Alerting: Detect Lock Removal Before Attackers Disable It
Attackers with Owner‑level credentials can remove any lock. Therefore, the lock itself is not a silver bullet – you must alert on its removal. Azure Activity Log records `Microsoft.Authorization/locks/delete` events, but most SOC teams lack a dedicated alert.
Step‑by‑step to build a detection using KQL (Azure Sentinel/Log Analytics):
AzureActivity | where OperationName == "MICROSOFT.AUTHORIZATION/LOCKS/DELETE" | where ActivityStatus == "Succeeded" | extend Initiator = tostring(parse_json(Claims)["http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"]) | project TimeGenerated, ResourceGroup, Resource, Initiator, CallerIpAddress | sort by TimeGenerated desc
Create an Azure Monitor alert rule (CLI):
Create action group az monitor action-group create --name LockRemovalAlert --resource-group MyRG --short-name lockalert --email-receiver [email protected] --email-receiver-name lockTeam Create alert rule on Activity Log az monitor activity-log alert create --name LockDeletionAlert --resource-group MyRG --condition category=Administrative and operationName=Microsoft.Authorization/locks/delete and level=Informational --action-group LockRemovalAlert
- Infrastructure‑as‑Code Pitfall: Locks Wiped by Terraform or Bicep Re‑deployments
When you manage resources with IaC, a pipeline re‑deployment that does not explicitly include the lock will remove it. Teams discover this after an incident, not before.
Correct Bicep template (preserve lock):
resource storageAccount 'Microsoft.Storage/storageAccounts@2022-09-01' = {
name: 'securestore123'
location: resourceGroup().location
sku: { name: 'Standard_LRS' }
kind: 'StorageV2'
}
resource readonlyLock 'Microsoft.Authorization/locks@2017-04-01' = {
name: 'readonlylock'
scope: storageAccount
properties: {
level: 'ReadOnly'
notes: 'Prevents logging disable'
}
}
Terraform equivalent:
resource "azurerm_storage_account" "main" {
name = "securestore123"
resource_group_name = azurerm_resource_group.rg.name
location = "westeurope"
account_tier = "Standard"
account_replication_type = "LRS"
}
resource "azurerm_management_lock" "readonly" {
name = "storage-readonly"
scope = azurerm_storage_account.main.id
lock_level = "ReadOnly"
notes = "Prevents disabling of logging"
}
- Deployment Stacks: A Stronger Alternative with Native Lifecycle Management
As noted by Microsoft MVP Eric M., Deployment Stacks with `DenyWriteAndDelete` rules solve the IaC drift problem by automatically reapplying locks after each deployment. This is a game‑changer for persistent cloud hardening.
Create a deployment stack (Azure PowerShell):
New-AzResourceGroupDeploymentStack -Name "SecureStack" ` -ResourceGroupName "MyRG" ` -TemplateFile "lockTemplate.bicep" ` -DenySettingsMode "DenyWriteAndDelete" ` -ActionOnUnmanage "DeleteResources"
How it works: Every pipeline run compares the actual state to the stack definition. If a lock is missing (e.g., manually removed or overridden), the stack automatically reverts it within minutes.
- Windows/Linux Script to Audit All Locks Across Subscriptions
Use this multi‑platform script to generate a compliance report of all locks in your tenant – critical for security audits.
Bash (Linux/macOS/Cloud Shell):
!/bin/bash
for sub in $(az account list --query "[].id" -o tsv); do
az account set --subscription $sub
echo "Subscription: $sub"
az lock list --query "[].{Name:name, Type:level, Resource:resourceId}" -o table
done
PowerShell (Windows/Linux):
Get-AzSubscription | ForEach-Object {
Set-AzContext -SubscriptionId $<em>.Id | Out-Null
Write-Host "Subscription: $($</em>.Name)" -ForegroundColor Cyan
Get-AzResourceLock | Select-Object Name, LockLevel, ResourceId
}
- Attack Emulation: How to Test Your Locks Without Breaking Production
Validate that your `ReadOnly` locks actually block the specific TTPs (e.g., T1562.001 – Disable Cloud Logs). Run this safe test using Azure CLI with a service principal that has Owner rights.
Simulate attacker disabling diagnostics on a locked resource
Precondition: Resource has ReadOnly lock
az monitor diagnostic-settings create --name testDiag \
--resource /subscriptions/{sub}/resourceGroups/MyRG/providers/Microsoft.Storage/storageAccounts/testlockstore \
--storage-account {storageId} --logs '[{"category":"StorageRead","enabled":true}]'
Expected output: "AuthorizationFailed: The resource 'testlockstore' is locked with 'ReadOnly'"
If the command fails (as expected), your SOC should receive an alert from the Activity Log rule created in Section 2. If it succeeds – your lock type is wrong or missing.
What Undercode Say:
- Key Takeaway 1: `ReadOnly` locks stop configuration‑modification attacks (e.g., disabling logs), while `CanNotDelete` locks are nearly useless for defense evasion.
- Key Takeaway 2: Without dedicated alerting on lock removal, attackers with Owner privileges can silently bypass your entire control.
- Analysis: Most cloud breaches today exploit misconfigured or unmonitored controls – not zero‑days. The gap between “having a lock” and “having a lock that works under adversarial conditions” is where real risk lives. Automated adversary emulation (like Mitigant’s approach) is the only reliable way to validate that gap. Additionally, new Azure features like Deployment Stacks close the IaC drift loophole, but adoption remains low. Expect Microsoft to push these as default best practices within 18 months, forcing a shift from reactive “checkbox compliance” to continuous control validation.
Prediction:
Within two years, cloud security will move from static locks to adaptive control‑plane hardening powered by AI. Azure will likely integrate lock recommendations directly into Defender for Cloud, automatically suggesting `ReadOnly` locks based on resource sensitivity and attack path analysis. Simultaneously, SIEM rules for lock removal will become baseline out‑of‑the‑box detections. Organizations that fail to implement and monitor management locks today will face ransomware attacks that explicitly target logging disablement – and their insurance carriers will start denying claims where `ReadOnly` locks were not applied to critical storage and audit resources.
▶️ Related Video (80% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Aondona Redteam – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
