Man In The Middle on Azure

Man In The Middle (MITM) attacks in Azure environments exploit the trust relationships between Azure services, managed identities, and external endpoints. Unlike traditional MITM scenarios, Azure-specific attacks often leverage the platform's service-to-service communication patterns and managed identity systems.

The most common Azure MITM vector targets Service-to-Service communication. When Azure services communicate using managed identities, attackers can intercept these calls by compromising the identity provider or exploiting misconfigured service endpoints. For example, an attacker who gains access to an Azure AD application registration can generate tokens that appear legitimate to Azure services.

const { DefaultAzureCredential } = require('@azure/identity');
const { KeyVaultClient } = require('@azure/keyvault-keys');

// Vulnerable pattern - no endpoint validation
const credential = new DefaultAzureCredential();
const client = new KeyVaultClient('https://target.vault.azure.net', credential);

// Attacker-controlled endpoint
const maliciousClient = new KeyVaultClient('https://attacker-controlled.vault.azure.net', credential);

Another Azure-specific MITM scenario involves Managed Identity token theft. Azure services use managed identities to authenticate without storing credentials. If an attacker compromises the service's network boundaries, they can intercept token requests and replay them to access other Azure resources.

// Azure Managed Identity token acquisition
const identityClient = new DefaultAzureCredential();
const token = await identityClient.getToken('https://management.azure.com/.default');

// If intercepted, this token grants full management API access
const headers = {
  Authorization: `Bearer ${token.token}`
};

Azure Storage MITM attacks exploit the service's public endpoint accessibility. Attackers can intercept storage account communications when services use HTTP instead of HTTPS, or when custom DNS configurations redirect traffic to malicious endpoints.

// Vulnerable - HTTP storage endpoint
const blobServiceClient = new BlobServiceClient(
  'http://mystorageaccount.blob.core.windows.net'
);

// Secure pattern - HTTPS with validation
const secureClient = new BlobServiceClient(
  'https://mystorageaccount.blob.core.windows.net',
  new DefaultAzureCredential(),
  { 
    retryOptions: { maxRetries: 3 },
    keepAliveOptions: { enable: true }
  }
);

Detecting MITM vulnerabilities in Azure requires examining both configuration and runtime behavior. middleBrick's Azure-specific scanning identifies these issues through black-box testing of Azure service endpoints.

middleBrick tests Azure service endpoints by attempting to establish connections without proper certificate validation. The scanner identifies services that accept self-signed certificates or have misconfigured TLS settings. For Azure Storage accounts, middleBrick attempts HTTP connections to storage endpoints and verifies if HTTPS is enforced.

// middleBrick detection output example
{
  "endpoint": "https://mystorageaccount.blob.core.windows.net",
  "test": "TLS Enforcement",
  "result": "FAIL",
  "severity": "HIGH",
  "remediation": "Enable HTTPS-only access in Azure Storage account settings"
}

The scanner also tests Azure Key Vault endpoints for token replay vulnerabilities by examining how services handle authentication tokens. middleBrick attempts to use captured tokens across different Azure regions and services to identify overly permissive token scopes.

For managed identity endpoints, middleBrick tests the Azure Instance Metadata Service (IMDS) endpoint at 169.254.169.254. The scanner verifies that only authorized services can access tokens and that tokens have appropriate expiration times.

// middleBrick IMDS security test
{
  "endpoint": "http://169.254.169.254/metadata/identity/oauth2/token",
  "test": "IMDS Access Control",
  "result": "PASS",
  "details": "Token access restricted to authorized source IPs"
}

middleBrick's OpenAPI analysis extends to Azure ARM (Azure Resource Manager) API specifications. The scanner cross-references your ARM template definitions with runtime API behavior, identifying endpoints that accept unvalidated requests or have overly broad permissions.

Azure provides several native features to prevent MITM attacks. The primary defense is Azure Private Link, which creates private endpoints for Azure services that are inaccessible from the public internet.

// Azure CLI - Create private endpoint for Key Vault
az network private-endpoint create \
  --resource-group myResourceGroup \
  --name myKeyVaultEndpoint \
  --vnet-name myVirtualNetwork \
  --subnet mySubnet \
  --private-connection-resource-id /subscriptions/.../resourceGroups/.../providers/Microsoft.KeyVault/vaults/myKeyVault \
  --group-id vault \
  --connection-name myConnection

// Verify private endpoint configuration
az network private-endpoint show \
  --resource-group myResourceGroup \
  --name myKeyVaultEndpoint \
  --query 'provisioningState'

For service-to-service communication, Azure Service Endpoints provide network isolation by extending your virtual network's address space to Azure services. This prevents traffic from being routed through untrusted networks.

// ARM template - Service Endpoint configuration
{
  "type": "Microsoft.Network/virtualNetworks/subnets",
  "apiVersion": "2021-05-01",
  "properties": {
    "serviceEndpoints": [
      {
        "service": "Microsoft.KeyVault",
        "locations": ["East US"]
      }
    ]
  }
}

Azure AD Conditional Access policies can prevent token theft by restricting where and how managed identities can be used. These policies verify device compliance, location, and application context before issuing tokens.

// Azure CLI - Conditional Access policy
az identity federated-credential create \
  --name myPolicy \
  --identity-name myManagedIdentity \
  --resource-group myResourceGroup \
  --issuer 'https://sts.windows.net/.../' \
  --subject 'app://my-aad-app-id' \
  --audiences 'api://AzureADTokenExchange'

Application code should use Azure's built-in validation mechanisms. The @azure/identity library automatically validates service endpoints and uses secure communication channels by default.

import { DefaultAzureCredential } from '@azure/identity';
import { KeyVaultClient } from '@azure/keyvault-keys';

// Secure pattern - DefaultAzureCredential handles validation
const credential = new DefaultAzureCredential({
  managedIdentityClientId: process.env.MANAGED_IDENTITY_CLIENT_ID
});

const client = new KeyVaultClient('https://myvault.vault.azure.net', credential);

// The credential automatically:
// - Validates TLS certificates
// - Uses private endpoints when configured
// - Enforces HTTPS-only communication
// - Validates token scopes and expiration

For Azure Storage, enable HTTPS-only access and configure firewall rules to restrict access to specific IP ranges or virtual networks.

// Azure CLI - Configure storage security
az storage account update \
  --resource-group myResourceGroup \
  --name myStorageAccount \
  --https-only true \
  --default-action Deny

az storage account network-rule add \
  --resource-group myResourceGroup \
  --account-name myStorageAccount \
  --vnet-name myVirtualNetwork \
  --subnet mySubnet