Azure's native security stack is robust on paper. Microsoft has invested heavily in Azure Monitor and Defender for Cloud to give enterprises visibility into their cloud environments. But visibility is only as good as what it can actually detect, and sophisticated attackers know exactly where those detection gaps live.
This blog walks through how red teamers and adversaries approach evasion in Azure environments, the specific techniques used to fly under the radar of native tooling, and what defenders need to understand to close those gaps. If your organization relies solely on Azure's built-in security controls without third-party validation, this is essential reading.
If you want your Azure environment tested by experts who think like attackers, Redfox Cybersecurity's pentesting services are built exactly for that.
Before discussing evasion, it helps to understand what you are evading.
Azure Monitor is Microsoft's unified observability platform. It collects telemetry from Azure resources, operating systems, and applications, aggregating logs, metrics, and traces into a central location. Key components include:
The critical weakness here is configuration dependency. If Diagnostic Settings are not enabled on a resource, that resource produces no logs in your workspace. Attackers know this.
Defender for Cloud (formerly Azure Security Center) provides cloud security posture management (CSPM) and cloud workload protection (CWPP). It scores your environment against security benchmarks, surfaces misconfigurations, and generates security alerts when suspicious activity is detected.
Defender plans are subscription-level features. If Defender for Servers, Defender for Storage, Defender for Key Vault, or other per-resource-type plans are not enabled, those workloads generate no Defender alerts whatsoever.
This creates an obvious attack surface: find the unmonitored corners and operate there.
One of the first things a red teamer does during Azure reconnaissance is enumerate which resources have Diagnostic Settings configured and which do not. This is trivially easy using the Azure CLI:
# List all resources in a subscription
az resource list --query "[].{name:name, type:type, id:id}" -o table
# Check Diagnostic Settings for a specific resource
az monitor diagnostic-settings list --resource <RESOURCE_ID>
[cta]
If the output is empty, that resource is a logging blind spot. Attackers will pivot their activity to operate within unmonitored resources wherever possible.
# List enabled Defender plans for the subscription
az security pricing list -o table
[cta]
Look for plans listed as Free rather than Standard. Free-tier resources have no Defender threat detection. An attacker who identifies that Defender for Key Vault is on the Free tier knows they can query secrets from that vault without generating a single alert.
# List all Log Analytics workspaces across resource groups
az monitor log-analytics workspace list --query "[].{name:name, resourceGroup:resourceGroup, sku:sku}" -o table
[cta]
A fragmented workspace setup (multiple disconnected workspaces) means central detection logic cannot correlate events across environments. Red teamers exploit this siloing actively.
Not all Azure resource types support Diagnostic Settings equally. Certain resource types either do not support logs at all or require manual configuration that teams commonly overlook. Attackers can abuse Azure Automation Accounts, Logic Apps, and certain PaaS services with minimal logging if those services are not explicitly configured.
# Check if an Automation Account has diagnostic settings
az monitor diagnostic-settings list \
--resource /subscriptions/<SUB_ID>/resourceGroups/<RG>/providers/Microsoft.Automation/automationAccounts/<ACCOUNT_NAME>
[cta]
If no settings exist, any runbook executed from that account will not appear in a Log Analytics workspace. This is a favorite persistence vector for attackers who gain initial access through compromised service principals.
When attackers gain code execution on an Azure VM or App Service with a managed identity, they can use that identity to authenticate to other Azure resources without a password or client secret. Managed identity token requests do not produce the same logging artifacts as service principal logins.
# From within a VM or App Service - request a token using the managed identity
curl 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/' \
-H "Metadata: true"
[cta]
This token can then be used to call Azure Resource Manager APIs directly. Because the identity is legitimate, Defender for Cloud's anomaly detection must rely on behavioral baselines to flag this, which takes time to tune and is often misconfigured.
If your Azure environment has never been tested for managed identity abuse, Redfox Cybersecurity's cloud pentesting team can walk through exactly these scenarios with you.
An attacker with Contributor or Owner permissions on a resource can delete or modify Diagnostic Settings to cut off log forwarding silently. This is a post-exploitation step that buys dwell time.
# Delete a diagnostic setting to stop log forwarding
az monitor diagnostic-settings delete \
--name <SETTING_NAME> \
--resource <RESOURCE_ID>
[cta]
The Activity Log will record this action, but only if someone is actively monitoring Activity Log alerts. Most environments do not have alerting configured for Diagnostic Settings changes, making this a silent and effective evasion step.
Defensive recommendation: Create an Azure Monitor alert rule specifically for the operation microsoft.insights/diagnosticSettings/delete.
# Create an Activity Log alert for diagnostic settings deletion
az monitor activity-log alert create \
--name "Alert-DiagnosticSettingsDeleted" \
--resource-group <RG> \
--condition category=Administrative and operationName=microsoft.insights/diagnosticSettings/delete \
--action-group <ACTION_GROUP_ID>
[cta]
Azure Monitor has ingestion limits and throttling behaviors. In some cases, attackers who can generate high volumes of legitimate-looking events can cause noise that buries actual malicious activity. This is a more advanced technique but relevant in environments with alert fatigue problems.
The tactic is straightforward: trigger hundreds of benign but noisy operations (read operations against storage, list operations on resource groups) to drown out the signal from actual exfiltration events.
Defender for Cloud's threat detection is strongest against known malicious tooling. It is significantly weaker against attackers who use native Azure tooling (az CLI, PowerShell Az modules, ARM API calls) or legitimate administrative tools in malicious ways. This is "living off the land" applied to cloud environments.
# Using Az PowerShell to enumerate Key Vault secrets without triggering signature-based detection
Connect-AzAccount -Identity # using managed identity, no credential
$vault = Get-AzKeyVault -VaultName "<VAULT_NAME>"
$secrets = Get-AzKeyVaultSecret -VaultName "<VAULT_NAME>"
foreach ($secret in $secrets) {
$value = Get-AzKeyVaultSecret -VaultName "<VAULT_NAME>" -Name $secret.Name -AsPlainText
Write-Output "$($secret.Name): $value"
}
[cta]
If Defender for Key Vault is on the Standard tier, this will generate alerts. If it is on Free, nothing fires. Even on Standard, if the managed identity performing this action has historical access to the vault, behavioral baselines may not flag it immediately.
Azure Policy is commonly used to enforce configurations like requiring Diagnostic Settings or enabling Defender plans. But Policy assignments have exemptions, and attackers who understand the environment can target resources that are exempted.
# List all policy exemptions in a subscription
az policy exemption list --query "[].{name:name, policyAssignmentId:policyAssignmentId, expiresOn:expiresOn}" -o table
[cta]
Exemptions with no expiry date and broad scope are particularly useful for attackers trying to find resources that are both unmonitored and not subject to compliance enforcement.
If an organization's Diagnostic Settings and Defender plans are configured in specific regions, deploying a rogue resource (a VM, a storage account, an Automation Account) in a different region may bypass monitoring entirely depending on workspace and Defender configuration.
# Deploy a storage account in an off-policy region
az storage account create \
--name <ACCOUNT_NAME> \
--resource-group <RG> \
--location southeastasia \
--sku Standard_LRS
[cta]
Check whether your Defender for Cloud setup and Log Analytics workspaces cover all regions where resources can be deployed. This is a gap that professional penetration testing regularly surfaces in enterprise Azure environments.
Redfox Cybersecurity's cloud security assessments specifically include coverage gap analysis across regions, subscriptions, and management groups.
Run the following to get a full picture of your current coverage:
az security pricing list --query "[].{name:name, pricingTier:pricingTier}" -o table
Any resource type showing Free should be evaluated for upgrade. Priority targets for Standard tier: Servers, Key Vault, Storage, Containers, and App Service.
Use the built-in policy initiative Deploy Diagnostic Settings to automatically configure log forwarding at scale. Apply it at the management group level with a DeployIfNotExists effect so that new resources are automatically covered.
# Assign the diagnostic settings policy at management group scope
az policy assignment create \
--name "EnforceDiagnosticSettings" \
--policy-set-definition <INITIATIVE_DEFINITION_ID> \
--scope /providers/Microsoft.Management/managementGroups/<MG_ID> \
--mi-system-assigned \
--location eastus
[cta]
Build KQL queries in your Log Analytics workspace to detect the specific evasion techniques covered above:
// Detect deletion of Diagnostic Settings
AzureActivity
| where OperationNameValue == "MICROSOFT.INSIGHTS/DIAGNOSTICSETTINGS/DELETE"
| project TimeGenerated, Caller, ResourceId, ActivityStatusValue
| order by TimeGenerated desc
// Detect Defender plan downgrades
AzureActivity
| where OperationNameValue == "MICROSOFT.SECURITY/PRICINGS/WRITE"
| where Properties contains "Free"
| project TimeGenerated, Caller, ResourceId, Properties
// Detect managed identity token requests followed by Key Vault access
AzureDiagnostics
| where ResourceType == "VAULTS"
| where OperationName == "SecretGet"
| summarize count() by CallerIPAddress, identity_claim_appid_s, bin(TimeGenerated, 5m)
| where count_ > 10
[cta]
These queries form the foundation of a detection layer that goes beyond what Defender for Cloud provides out of the box.
Microsoft's native tooling is a strong starting point but it has structural limitations. Defender for Cloud's alert coverage is primarily signature and anomaly-based, and it is calibrated against known attack patterns. Novel techniques, living-off-the-land approaches, and configuration-aware attackers who target coverage gaps will routinely bypass it.
The only reliable way to validate your detection posture is adversarial simulation by people who have done this before. Automated scanners and compliance reports will not surface the evasion techniques documented in this post. A skilled red team will.
Redfox Cybersecurity provides cloud-focused penetration testing and red team engagements specifically designed to expose detection gaps in Azure, AWS, and GCP environments. Their assessments go beyond checkbox compliance to test whether your monitoring stack can actually detect sophisticated adversary behavior.
Azure Monitor and Defender for Cloud provide meaningful security coverage when configured correctly. But correct configuration is harder than it looks, and the default state of most Azure environments is full of logging gaps, missing Defender plans, unenforced policies, and unmonitored regions.
Attackers who understand the Azure control plane know exactly how to navigate around native detections. They disable diagnostic settings, use managed identities to avoid credential logging, operate in unmonitored resource types, and use legitimate tooling to stay below the behavioral detection threshold.
The commands and techniques in this post reflect what red teamers actually do during Azure engagements. If any of them surprised you, that is the gap you need to close.
The best way to close it is to have someone test it before an adversary does. Redfox Cybersecurity's penetration testing services are designed to do exactly that, giving your security team a clear, evidence-based picture of what a real attacker could do in your environment and what you need to fix to stop them.
Ready to find your Azure blind spots before attackers do? Engage Redfox Cybersecurity today.
Redfox Cyber Security Inc.
8 The Green, Ste. A, Dover,
Delaware 19901,
United States.
.avif)
