Denial Of Service on Azure

Denial of Service (DoS) attacks on Azure APIs exploit the platform's distributed nature and resource management systems. Azure's serverless architecture, while scalable, introduces specific vulnerabilities that attackers can target.

Azure Function Consumption Plan DoS is particularly problematic because Azure Functions scale automatically based on request volume. An attacker can trigger rapid scaling by sending concurrent requests to a function endpoint, causing Azure to provision multiple instances. Each instance has a cold start penalty, and the cumulative effect can exhaust the function's execution time limits (typically 10 minutes for Consumption Plan).

const http = require('http');
const hostname = process.env.WEBSITE_HOSTNAME || 'localhost';
const port = process.env.PORT || 7071;

const server = http.createServer((req, res) => {
  // No rate limiting - vulnerable to DoS
  res.statusCode = 200;
  res.setHeader('Content-Type', 'application/json');
  res.end(JSON.stringify({ message: 'Hello Azure' }));
});

server.listen(port, hostname, () => {
  console.log(`Server running at http://${hostname}:${port}/`);
});

Azure App Service DoS through request queuing is another common pattern. When an App Service instance receives more requests than it can process simultaneously, requests queue up in the platform's internal request queue. Azure's default request queue limit is 5,000 requests. Once this limit is reached, Azure returns HTTP 502 errors to clients, but the application continues processing queued requests, potentially leading to resource exhaustion.

Azure Cosmos DB throttling-based DoS occurs when applications make excessive requests to Cosmos DB. Cosmos DB implements request unit (RU) limits per container. Attackers can trigger RU exhaustion by making repeated requests to expensive operations like complex queries or stored procedures. When RUs are exhausted, Cosmos DB returns HTTP 429 Too Many Requests, but the application may retry automatically, creating a feedback loop that amplifies the attack.

// Vulnerable Cosmos DB query - no pagination or rate limiting
async function getAllUsers(container) {
  const query = 'SELECT * FROM c';
  const { resources: items } = await container.items.query(query).fetchAll();
  return items;
}

Azure Service Bus message storm attacks exploit the dead-letter queue mechanism. Attackers can flood Service Bus with malformed messages that fail processing and move to the dead-letter queue. If the application has auto-processing enabled for dead-letter messages, this creates a processing loop that consumes CPU resources.

Detecting DoS vulnerabilities in Azure requires understanding the platform's monitoring and logging capabilities. Azure Monitor provides Application Insights integration that can reveal DoS patterns through request volume analysis and dependency tracking.

Azure Application Insights dependency tracking shows Cosmos DB request failures and retry patterns. The following query identifies potential DoS indicators:

// Kusto query to detect Cosmos DB throttling
let threshold = 100; // requests per minute
let timeWindow = ago(5m);
let cosmosDBRequests = dependencies
| where timestamp > timeWindow
| where target contains 'documents.azure.com'
| where success == false
| where name contains '429';
cosmosDBRequests
| summarize count() by bin(timestamp, 1m)
| where count_ > threshold
| project timestamp, count_

Azure Function execution metrics reveal DoS through cold start frequency and concurrent execution counts. The Azure portal shows function execution metrics including:

• Function execution count and duration
• Cold start count and percentage
• Concurrent executions
• Throttled executions
• Errors by type

Azure App Service HTTP logs contain request queue depth information. When requests exceed the platform's processing capacity, the logs show increased response times and HTTP 502 errors. The following Azure CLI command retrieves recent App Service logs:

az webapp log tail --resource-group myResourceGroup --name myAppService

middleBrick's Azure-specific scanning identifies DoS vulnerabilities by testing API endpoints without requiring credentials. The scanner tests for:

• Missing rate limiting on Azure Function endpoints
• Unprotected Cosmos DB operations
• Service Bus message processing loops
• App Service request queue exhaustion

The CLI command for scanning Azure APIs:

npx middlebrick scan https://myazurefunction.azurewebsites.net/api/myfunction

middleBrick's black-box approach tests the unauthenticated attack surface, identifying DoS vulnerabilities that traditional authenticated testing might miss. The scanner provides severity ratings and remediation guidance specific to Azure's platform constraints.

Azure provides native features for DoS mitigation that integrate with the platform's resource management. Azure API Management acts as a security layer for Azure Functions and App Services, providing rate limiting and DDoS protection.

// Azure Function with rate limiting using API Management
// Rate limiting configured in Azure Portal > API Management > APIs > Rate limits
// Example: 100 requests per minute per IP

Azure Cosmos DB request unit optimization prevents DoS through RU budgeting. Applications should implement query pagination and caching to reduce RU consumption. The following pattern uses continuation tokens for efficient pagination:

async function getUsersPaged(container, pageSize = 100) {
  const query = 'SELECT * FROM c';
  const querySpec = {
    query: query,
    parameters: []
  };
  
  let continuationToken = undefined;
  let hasMore = true;
  const allResults = [];
  
  while (hasMore) {
    const { resources, hasMoreResults, continuation } = await container.items.query(
      querySpec,
      { continuationToken }
    ).fetchAll();
    
    allResults.push(...resources);
    continuationToken = continuation;
    hasMore = hasMoreResults;
  }
  
  return allResults;
}

Azure Service Bus dead-letter queue protection prevents message storm attacks. Configure Service Bus to disable auto-processing of dead-letter messages and implement manual inspection:

// Service Bus with dead-letter protection
const { ServiceBusClient } = require('@azure/service-bus');

async function processMessage(message) {
  try {
    // Process message
    await message.complete();
  } catch (error) {
    // Don't auto-deadletter - inspect first
    console.error('Message processing failed:', error);
    // Implement custom dead-letter logic with limits
    await message.abandon();
  }
}

Azure Front Door provides DDoS protection and global request routing. Configure Front Door to route requests to Azure Functions with built-in rate limiting:

// ARM template snippet for Azure Front Door with rate limiting
{
  "type": "Microsoft.Network/frontDoors",
  "apiVersion": "2020-11-01",
  "properties": {
    "routingRules": [
      {
        "name": "FunctionRouting",
        "properties": {
          "frontendEndpoints": ["/subscriptions/.../frontendEndpoints/myEndpoint"],
          "acceptedProtocols": ["Https"],
          "patternsToMatch": ["/*"],
          "frontendPorts": ["/subscriptions/.../frontendPorts/myPort"],
          "backendPool": {
            "backendPoolName": "FunctionBackendPool"
          }
        }
      }
    ],
    "backendPools": [
      {
        "name": "FunctionBackendPool",
        "properties": {
          "backends": [
            {
              "address": "myazurefunction.azurewebsites.net",
              "httpPort": 80,
              "httpsPort": 443
            }
          ]
        }
      }
    ]
  }
}

Azure Application Gateway Web Application Firewall (WAF) provides layer 7 DDoS protection with rate limiting rules. Configure WAF policies to protect Azure App Services:

// ARM template for WAF policy with rate limiting
{
  "type": "Microsoft.Network/ApplicationGatewayWebApplicationFirewallPolicies",
  "apiVersion": "2020-11-01",
  "properties": {
    "customRules": [
      {
        "name": "RateLimitRule",
        "priority": 1,
        "ruleType": "RateLimitRule",
        "rateLimitThreshold": 100,
        "timeWindow": "PT1M",
        "matchConditions": [
          {
            "matchVariables": [
              {
                "variableName": "RemoteAddr"
              }
            ],
            "operator": "IPMatch",
            "negationConditon": false,
            "matchValue": ["*"]
          }
        ],
        "action": "Block"
      }
    ]
  }
}