4.6 Defender for Storage, SQL, and App Service

Defender for Storage, SQL, and App Service

Introduction

Beyond servers, organisations run databases, store data in cloud storage, and host applications — each with a different threat profile. An attacker who compromises a storage account does not execute malware — they download data. An attacker who targets a SQL database does not use lateral movement — they use SQL injection. An attacker who exploits a web application does not install persistence — they abuse application logic. Each workload type requires specialised detection.

This subsection covers the three most common non-server workload protections: Defender for Storage, Defender for SQL, and Defender for App Service.

Defender for Storage

Defender for Storage monitors Azure Storage accounts (Blob, File, Queue, Table, Data Lake) for suspicious access patterns, malware uploads, and data exposure risks.

What it detects:

Access from suspicious IP addresses — connections from known malicious IPs, Tor exit nodes, or IPs associated with cryptocurrency mining. This detects attackers who have obtained storage account keys or SAS tokens and are accessing data from their infrastructure.

Anomalous data extraction — unusual download volumes, access from geographic locations that have never accessed the account before, or access patterns that deviate from the account’s historical baseline. This detects data exfiltration: an attacker who has a storage key downloading the entire contents of a blob container.

Malware upload — files uploaded to storage accounts are scanned for malware. If malware is detected in an uploaded blob, Defender for Storage generates a “Malware was uploaded to a storage account” alert. This is critical for storage accounts that accept uploads from untrusted sources (customer portals, file submission systems).

Publicly exposed storage — detection of storage accounts or containers that are configured for anonymous access, potentially exposing sensitive data. This overlaps with CSPM (which also identifies public access misconfiguration) but adds runtime monitoring for access from anonymous sources.

Alert investigation for storage: Storage alerts include the storage account name, the container and blob path (which specific data was accessed), the client IP address, the authentication method (storage key, SAS token, Entra ID), and the operation type (read, write, delete, list). During investigation, determine whether the storage key or SAS token was compromised (rotate the key immediately), whether the access pattern indicates data exfiltration (check the volume of data downloaded), and whether any uploaded malware was subsequently downloaded by legitimate users (scope the impact).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// Defender for Storage alerts in Sentinel
SecurityAlert
| where TimeGenerated > ago(7d)
| where ProviderName == "Azure Security Center"
| where AlertType has "Storage"
| extend StorageAccount = tostring(ExtendedProperties.["Compromised entity"])
| extend ClientIP = tostring(ExtendedProperties.["Client IP"])
| extend AccessType = tostring(ExtendedProperties.["Authentication type"])
| project TimeGenerated, AlertName, AlertSeverity,
    StorageAccount, ClientIP, AccessType
| order by TimeGenerated desc

Defender for SQL

Defender for SQL monitors Azure SQL Database, Azure SQL Managed Instance, and SQL Server on Azure VMs for database-specific threats.

What it detects:

SQL injection — detects queries that exploit input validation vulnerabilities to execute unauthorized SQL commands. Defender for SQL analyses query patterns and identifies injection attempts including UNION-based injection, error-based injection, and blind injection techniques.

Anomalous database access — logins from unusual IP addresses, at unusual times, or from unusual applications. This detects compromised database credentials being used by an attacker from their infrastructure.

Brute-force attacks — repeated failed login attempts indicating credential guessing against the database server.

Data exfiltration indicators — unusual query patterns that read large volumes of data, bulk export operations, and SELECT queries against tables not normally queried by the connecting application.

Potential SQL injection — detects application vulnerabilities by identifying queries that include user input directly in SQL statements without parameterisation. This is a proactive alert that identifies vulnerable application code, not just active exploitation.

Alert investigation for SQL: SQL alerts include the database server and database name, the client IP address, the SQL query (or query pattern) that triggered the alert, the user account, and the application that connected. During investigation, determine whether the SQL injection was successful (did the attacker extract data?), whether the database credentials were compromised (check for anomalous logins from other IPs), and what data the attacker could access (which tables and columns are in the affected database).

Defender for App Service

Defender for App Service monitors Azure App Service web applications for web-specific threats.

What it detects:

Web shell detection — identifies files uploaded to the web application that function as web shells (backdoors that give attackers remote command execution through the web server). Common web shell patterns include PHP shells, ASPX shells, and JSP shells.

DNS analysis — detects when the App Service communicates with known malicious domains or command-and-control infrastructure. This detects compromised web applications that have been modified to communicate with attacker servers.

Suspicious user agent detection — identifies access from automated tools, vulnerability scanners, and known malicious crawlers. This detects reconnaissance and scanning activity against the web application.

Application anomaly detection — identifies unusual request patterns, unusual response codes, or unusual data volumes that deviate from the application’s baseline. This detects exploitation attempts and active attacks against application logic.

Alert investigation for App Service: App Service alerts include the App Service name, the URL path that was accessed, the client IP address, the HTTP method and response code, and the user agent. During investigation, check the web application’s file system for unauthorized files (web shells), review application logs for evidence of exploitation, and assess whether the application has known vulnerabilities that the attacker could exploit.

Enabling workload-specific plans

Each plan is enabled independently in Environment settings. When deciding which plans to enable, consider the data sensitivity and exposure of each resource type.

Enable Defender for SQL if your databases contain sensitive data (customer PII, financial records, healthcare data). SQL injection is one of the most common and most damaging attack vectors against web applications — detecting it requires database-level monitoring that network-level controls cannot provide.

Enable Defender for Storage if your storage accounts accept uploads from untrusted sources (file upload portals, data submission endpoints) or contain sensitive data that could be exposed through misconfigured access controls.

Enable Defender for App Service if your web applications are internet-facing and handle sensitive transactions. Web applications are the most targeted resource type on the internet — they face continuous scanning and exploitation attempts.

Storage account security: keys vs Entra ID

The most effective posture improvement for storage accounts is eliminating key-based access entirely. Storage account keys are shared secrets — anyone who has the key has full access to all data in the account. Keys do not expire, cannot be scoped to specific containers, and do not support conditional access. If a key is leaked (hardcoded in source code, exposed in a configuration file, or stolen from a compromised admin account), the attacker has unlimited access until the key is rotated.

The recommended model: Use Entra ID RBAC for all storage access. Instead of storage keys, assign the “Storage Blob Data Reader” or “Storage Blob Data Contributor” role to specific identities. Entra ID access supports conditional access (location, device compliance, MFA), is audited in sign-in logs, and can be revoked instantly. Disable key-based access entirely on storage accounts that do not need it: Storage account → Configuration → Allow storage account key access → Disabled.

When investigating a Defender for Storage alert, the authentication method is the critical first data point. If the access used an account key, the key is compromised — rotate immediately. If the access used Entra ID, the identity is compromised — investigate through sign-in logs and conditional access evaluation.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

// Storage access patterns — identify key-based vs Entra ID access
StorageBlobLogs
| where TimeGenerated > ago(7d)
| extend AuthMethod = iff(AuthenticationType == "SAS" or AuthenticationType == "AccountKey",
    "Key/SAS", "Entra ID")
| summarize RequestCount = count(),
    DataVolume = sum(ResponseBodySize),
    UniqueIPs = dcount(CallerIpAddress)
    by AuthMethod, AccountName, bin(TimeGenerated, 1d)
| order by TimeGenerated desc

SQL threat protection: understanding alert context

Defender for SQL alerts require database-specific investigation skills. The most common alert — “Potential SQL injection” — requires you to assess whether the injection attempt was successful, which demands understanding of what the injected query actually does.

SQL injection alert anatomy: The alert includes the flagged query (or query pattern), the client IP, the application name, the database and table targeted, and the detection method (rule-based or ML anomaly). The query pattern is the key evidence — it tells you what the attacker was trying to do.

Common injection patterns and their objectives: UNION SELECT queries attempt to extract data from other tables by appending results to a legitimate query. ' OR 1=1 -- attempts to bypass authentication checks by making WHERE clauses always true. ; DROP TABLE attempts destructive operations. xp_cmdshell attempts to execute operating system commands through the database — this is the most dangerous because it can lead to full server compromise.

Assessing success: Check the database audit log for the same session. If the injected query returned data (rows affected > 0 for data extraction queries), the injection was successful. If the database returned an error (syntax error, permission denied), the injection failed. Also check the application’s HTTP response — a 200 OK response with data in the body suggests the application returned the extracted data to the attacker’s browser.

Defender for Key Vault and Defender for DNS

Two additional workload plans deserve mention for their unique detection capabilities.

Defender for Key Vault monitors access to Azure Key Vault — the service that stores cryptographic keys, certificates, and secrets. Alerts include: access from unusual IPs (possible credential compromise), high volume of secret reads (possible secret enumeration), and access from suspicious application registrations (possible OAuth application abuse). Key Vault alerts are particularly significant because Key Vault contains the “keys to the kingdom” — database connection strings, API keys, encryption keys, and certificates that protect other resources.

Defender for DNS analyses DNS query patterns from Azure resources. It detects: communication with known malicious domains (C2 traffic), DNS tunnelling (data exfiltration via DNS queries), and domain generation algorithm (DGA) patterns (malware using algorithmically generated domains to locate C2 servers). DNS analysis is valuable because DNS traffic is often overlooked in security monitoring — attackers use it precisely because it is rarely blocked or inspected.

SAS token security for storage accounts

Shared Access Signatures (SAS tokens) are scoped, time-limited access tokens for storage accounts. Unlike account keys (which grant full unrestricted access), SAS tokens can be scoped to specific containers, specific operations (read-only vs read-write), specific IP ranges, and specific time windows. They are more secure than keys but still carry risks.

SAS token risks: SAS tokens are bearer tokens — anyone who possesses the token has the permissions it grants, regardless of identity. If a SAS token is embedded in a URL that is shared publicly (a common pattern for file download links), anyone with the URL can access the data until the token expires. If a SAS token is stolen from a log file, email, or application configuration, the attacker has access until expiration.

Best practices for SOC awareness: When investigating a Defender for Storage alert, check whether the access used a SAS token (the authentication type field in the alert shows “SAS”). If so, determine which SAS token was used: was it a service SAS (scoped to one container), an account SAS (broader access), or a user delegation SAS (tied to an Entra ID identity and auditable through sign-in logs)? User delegation SAS tokens are the most secure because they are identity-based and auditable — prefer them over service or account SAS tokens.

SAS token revocation: Unlike account keys (which can be rotated to invalidate all access), individual SAS tokens cannot be revoked directly. To invalidate a compromised SAS token: if it is a service SAS or account SAS, rotate the storage account key that signed the token (this invalidates ALL tokens signed by that key). If it is a user delegation SAS, revoke the user’s delegation key. If a stored access policy was used to create the SAS, modify or delete the stored access policy to invalidate all SAS tokens generated from it.

App Service security: deployment slots and access restrictions

Defender for App Service monitors the production slot by default. If your application uses deployment slots (staging, testing), each slot has its own endpoint and can be accessed independently. Attackers sometimes target non-production slots because they may have weaker access controls — a staging slot with no IP restrictions is an open door to the same application code and potentially the same database connections as production.

Access restrictions should be configured on all slots, not just production. Navigate to App Service → Networking → Access restrictions and configure IP-based rules or virtual network integration to restrict access to known IPs and networks. In the Defender for Cloud recommendations, “App Service should not be accessible from the internet” may appear for slots that lack access restrictions.

Knowledge check