Detection rules › Panther

Azure Excessive Network Security Group Read

Severity
medium
Log types
Azure.MonitorActivity
Tags
AZT101, Discovery, Reconnaissance, Network Service Discovery, Active Scanning, Vulnerability Scanning
Reference
https://microsoft.github.io/Azure-Threat-Research-Matrix/Reconnaissance/AZT101/AZT101/
Source
github.com/panther-labs/panther-analysis

Detects excessive read operations on Azure Network Security Groups. Adversaries may repeatedly read Network Security Group configurations to map network ports and firewall rules as part of reconnaissance activities. This pattern can indicate an attacker attempting to understand network security controls before launching lateral movement or exfiltration attacks. The threshold-based detection triggers when the same resource is read excessively within a time window.

MITRE ATT&CK coverage

Rule body yaml

AnalysisType: rule
Filename: azure_network_port_mapping.py
RuleID: "Azure.MonitorActivity.Network.PortMapping"
DisplayName: "Azure Excessive Network Security Group Read"
Enabled: true
LogTypes:
  - Azure.MonitorActivity
Severity: Medium
Threshold: 50
Description: >
  Detects excessive read operations on Azure Network Security Groups. Adversaries may repeatedly
  read Network Security Group configurations to map network ports and firewall rules as part of
  reconnaissance activities. This pattern can indicate an attacker attempting to understand network
  security controls before launching lateral movement or exfiltration attacks. The threshold-based
  detection triggers when the same resource is read excessively within a time window.
Reports:
  MITRE ATT&CK:
    - TA0007:T1046 # Discovery: Network Service Discovery
    - TA0043:T1595.002 # Reconnaissance: Active Scanning - Vulnerability Scanning
Tags:
  - AZT101
  - Discovery
  - Reconnaissance
  - Network Service Discovery
  - Active Scanning
  - Vulnerability Scanning
Runbook: |
  1. Query Azure Monitor Activity logs for all Network Security Group read operations by the callerIpAddress in the 24 hours before and after the alert
  2. Check if the same caller has performed other reconnaissance activities (reading route tables, virtual networks, or other network configurations)
  3. Review the callerIpAddress and caller identity to determine if this is legitimate administrative activity or unauthorized access
  4. Verify if the threshold (50 reads) aligns with normal operational patterns for your environment
Reference: https://microsoft.github.io/Azure-Threat-Research-Matrix/Reconnaissance/AZT101/AZT101/
SummaryAttributes:
  - resourceId
  - location
  - callerIpAddress
  - correlationId
Tests:
  - Name: Network Security Group Read Success
    ExpectedResult: true
    Log:
      {
        "time": "2025-12-22T10:30:00.0000000Z",
        "resourceId": "/subscriptions/12345678-1234-1234-1234-123456789abc/resourceGroups/network-rg/providers/Microsoft.Network/networkSecurityGroups/nsg-prod",
        "operationName": "MICROSOFT.NETWORK/NETWORKSECURITYGROUP/READ",
        "operationVersion": "2021-05-01",
        "category": "Administrative",
        "resultType": "Success",
        "resultSignature": "200",
        "callerIpAddress": "1.1.1.1",
        "correlationId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
        "level": "Informational",
        "location": "eastus",
        "tenantId": "87654321-4321-4321-4321-111111111111"
      }
  - Name: Network Security Group Read Case Insensitive
    ExpectedResult: true
    Log:
      {
        "time": "2025-12-22T11:15:00.0000000Z",
        "resourceId": "/subscriptions/11111111-1111-1111-1111-111111111111/resourceGroups/network-rg/providers/Microsoft.Network/networkSecurityGroups/nsg-dev",
        "operationName": "microsoft.network/networksecuritygroup/read",
        "category": "Administrative",
        "resultType": "Succeeded",
        "callerIpAddress": "2.2.2.2",
        "correlationId": "b2c3d4e5-f6a7-8901-bcde-f23456789012",
        "level": "Information",
        "location": "westeurope",
        "tenantId": "22222222-2222-2222-2222-222222222222"
      }
  - Name: Different Operation
    ExpectedResult: false
    Log:
      {
        "time": "2025-12-22T14:00:00.0000000Z",
        "resourceId": "/subscriptions/55555555-5555-5555-5555-555555555555/resourceGroups/network-rg/providers/Microsoft.Network/virtualNetworks/myvnet",
        "operationName": "MICROSOFT.NETWORK/VIRTUALNETWORKS/READ",
        "category": "Administrative",
        "resultType": "Success",
        "callerIpAddress": "5.5.5.5",
        "correlationId": "e5f6a7b8-c9d0-1234-ef01-567890123456",
        "tenantId": "55555555-5555-5555-5555-555555555555"
      }

Detection logic

Condition

operationName eq "MICROSOFT.NETWORK/NETWORKSECURITYGROUP/READ"
resultType in ["Success", "Succeeded"]

Indicators

Each row is a field, operator, and value that the rule matches. The corpus column counts how many other rules in the catalog look for the same combination: high numbers point to widely-used, community-vetted indicators. Blank or 1 shows that the indicator is specific to this rule.

FieldKindValues
operationNameeq
  • MICROSOFT.NETWORK/NETWORKSECURITYGROUP/READ
resultTypein
  • Succeeded
  • Success

Output fields

Fields the rule emits when it matches. Chronicle authors list these in the outcome block; they appear on the detection and $risk_score drives alerting. Sentinel / Defender XDR rules build them up through project / summarize / extend stages. Sentinel maps these into alert fields via entityMappings and customDetails; Defender XDR custom detections surface them as alert fields directly.

Field
resourceId