Skip to content
T1686.001 Microsoft Sentinel · KQL

Detect Disable or Modify Cloud Firewall in Microsoft Sentinel

Adversaries may disable or modify a firewall within a cloud environment to bypass controls that limit access to cloud resources. Cloud environments typically utilize restrictive security groups and firewall rules that only allow network activity from trusted IP addresses via expected ports and protocols. An adversary with appropriate permissions may introduce new firewall rules or policies to allow access into a victim cloud environment. For example, adversaries may create new ingress rules in existing security groups or create new security groups entirely to allow any TCP/IP connectivity.

MITRE ATT&CK

Tactic
Defense Impairment
Technique
T1686 Disable or Modify System Firewall
Sub-technique
T1686.001 Cloud Firewall
Canonical reference
https://attack.mitre.org/techniques/T1686/001/

KQL Detection Query

Microsoft Sentinel (KQL)
kusto 
let CloudFirewallActions = dynamic(["AuthorizeSecurityGroupIngress", "AuthorizeSecurityGroupEgress", "RevokeSecurityGroupIngress", "RevokeSecurityGroupEgress", "CreateSecurityGroup", "DeleteSecurityGroup", "UpdateSecurityGroup", "microsoft.network/networksecuritygroups/write", "microsoft.network/networksecuritygroups/securityRules/write", "microsoft.network/networksecuritygroups/delete", "compute.firewalls.create", "compute.firewalls.delete", "compute.firewalls.update"]);
AuditLogs
| where TimeGenerated > ago(24h)
| where OperationName has_any (CloudFirewallActions)
| extend SourceIP = tostring(parse_json(tostring(InitiatedBy.user)).ipAddress)
| extend Actor = tostring(parse_json(tostring(InitiatedBy.user)).userPrincipalName)
| extend IsOpenToAll = Result has "0.0.0.0/0" or Result has "::/0"
| project TimeGenerated, OperationName, Actor, SourceIP, TargetResources, Result, IsOpenToAll
| sort by TimeGenerated desc
high severity medium confidence

Detects cloud firewall/security group modifications across AWS (CloudTrail), Azure (Activity Log NSG operations), and GCP (Audit Log firewall operations). Flags rules that open access to 0.0.0.0/0 (all IPs) as particularly suspicious. Uses AuditLogs table for multi-cloud coverage in Microsoft Sentinel.

Data Sources

Cloud Service: Cloud Service ModificationFirewall: Firewall Rule ModificationAWS CloudTrailAzure Activity LogGCP Audit Log

Required Tables

AuditLogs

False Positives & Tuning

  • Cloud infrastructure teams deploying new services with appropriate security group configurations
  • Infrastructure-as-Code pipelines (Terraform, CloudFormation, ARM templates) that manage security groups during deployment
  • Auto-scaling events that create temporary security groups for new instances

Other platforms for T1686.001

Splunk (SPL) Elastic Security (Elastic) IBM QRadar (QRadar) Sumo Logic CSE (Sumo) Google Chronicle (YARA-L) CrowdStrike LogScale (LogScale) All platforms (combined) →

Testing Methodology

Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1 AWS Security Group Ingress Rule Addition

    Expected signal: CloudTrail event: AuthorizeSecurityGroupIngress with requestParameters showing port 22 and 0.0.0.0/0 CIDR. GuardDuty finding: UnauthorizedAccess:EC2/TorIPCaller if from suspicious IP.

  2. Test 2 Azure NSG Rule Addition

    Expected signal: Azure Activity Log: Microsoft.Network/networkSecurityGroups/securityRules/write operation.

  3. Test 3 AWS GuardDuty IP Allowlisting via Pacu

    Expected signal: CloudTrail event: CreateIPSet for GuardDuty. This is a critical indicator of defense impairment in AWS.

Last updated: 2026-04-20 Research depth: deep
References (4)

Response Playbook

Triage

  1. Identify the cloud provider and the specific security group or firewall rule that was modified
  2. Check if the rule opens access from 0.0.0.0/0 — this is almost always suspicious in production environments
  3. Verify the actor identity — is this a known cloud admin or IaC service principal? Check for corresponding change tickets.
  4. Determine what ports/protocols were opened — common abuse targets RDP (3389), SSH (22), and database ports (3306, 5432)
  5. Check the source IP of the API call — does it match the actor's expected location?

Containment

  1. Immediately revert unauthorized security group changes using CLI or console
  2. If 0.0.0.0/0 ingress was added: remove the rule and check for any connections that may have been established
  3. If actor credentials are compromised: rotate the access keys/tokens and disable the user account
  4. Review VPC flow logs for any traffic that traversed the modified security group during the exposure window
  5. Enable GuardDuty (AWS) or Security Center (Azure) alerts for security group modifications

Evidence Collection

  1. AWS: CloudTrail events for AuthorizeSecurityGroupIngress with requestParameters showing CIDR ranges
  2. AWS: VPC Flow Logs for traffic during the exposure window
  3. Azure: Activity Log for NSG write operations with request body showing rule details
  4. Azure: NSG Flow Logs for traffic analysis
  5. GCP: Audit Log for compute.firewalls.create/update with firewall rule details
  6. All: Source IP and user agent of the API call that made the change

Escalation Criteria

  • !Security group rule allowing 0.0.0.0/0 inbound on any port (completely open)
  • !Security group modification made from an unusual IP address or outside business hours
  • !Multiple security groups modified in rapid succession (automated attack)
  • !Security group change combined with new EC2 instance launch (potential cryptomining)
  • !GuardDuty finding for compromised credentials paired with security group changes

Investigation Guide

Forensic Artifacts

  • >AWS CloudTrail: AuthorizeSecurityGroupIngress, CreateSecurityGroup events with requestParameters
  • >AWS VPC Flow Logs: Traffic flowing through the modified security group
  • >Azure Activity Log: Microsoft.Network/networkSecurityGroups/write operations
  • >Azure NSG Flow Logs: Network traffic through modified NSGs
  • >GCP Audit Log: compute.firewalls.create, compute.firewalls.update events
  • >IAM: Last activity timestamp for the actor account

Tuning Guidance

IaC pipelines (Terraform, CloudFormation) are the primary source of false positives. Build an allowlist of CI/CD service principals and IAM roles used for infrastructure deployment. Focus high-severity alerts on rules opening 0.0.0.0/0 ingress. Consider separate detection logic for each cloud provider to leverage provider-specific fields for better accuracy.

Hunting Queries

Hunt for AWS security group rules that open ingress to all IPs (0.0.0.0/0). These rules should be extremely rare in production and may indicate compromised credentials or malicious automation.

Hunting — KQL
kql 
AWSCloudTrail
| where TimeGenerated > ago(7d)
| where EventName == "AuthorizeSecurityGroupIngress"
| where RequestParameters has "0.0.0.0/0"
| project TimeGenerated, UserIdentityArn, SourceIpAddress, RequestParameters
| sort by TimeGenerated desc
Hunting — SPL
spl 
index=aws sourcetype=aws:cloudtrail eventName=AuthorizeSecurityGroupIngress requestParameters.ipPermissions.items{}.ipRanges.items{}.cidrIp="0.0.0.0/0"
| table _time, userIdentity.arn, sourceIPAddress, requestParameters
| sort - _time

Atomic Red Team Tests

Test 1 AWS Security Group Ingress Rule Addition
linux

Adds an inbound rule to an AWS security group allowing SSH (port 22) from all IPs. This simulates an adversary opening access to cloud instances. Requires AWS CLI configured with appropriate credentials.

Command

bash 
aws ec2 authorize-security-group-ingress --group-id sg-xxxxxxxx --protocol tcp --port 22 --cidr 0.0.0.0/0 --region us-east-1

Cleanup

bash 
aws ec2 revoke-security-group-ingress --group-id sg-xxxxxxxx --protocol tcp --port 22 --cidr 0.0.0.0/0 --region us-east-1

Expected Telemetry

CloudTrail event: AuthorizeSecurityGroupIngress with requestParameters showing port 22 and 0.0.0.0/0 CIDR. GuardDuty finding: UnauthorizedAccess:EC2/TorIPCaller if from suspicious IP.

Expected Detection

KQL: IsOpenToAll=true. SPL: IsOpenToAll='Yes'.

Test 2 Azure NSG Rule Addition
linux

Adds an inbound allow rule to an Azure Network Security Group allowing all traffic from any source. Requires Azure CLI authenticated.

Command

bash 
az network nsg rule create --resource-group myRG --nsg-name myNSG --name df00tech-test --priority 100 --access Allow --direction Inbound --protocol '*' --source-address-prefixes '*' --destination-port-ranges '*'

Cleanup

bash 
az network nsg rule delete --resource-group myRG --nsg-name myNSG --name df00tech-test

Expected Telemetry

Azure Activity Log: Microsoft.Network/networkSecurityGroups/securityRules/write operation.

Expected Detection

SPL: CloudProvider='Azure', IsOpenToAll='Yes'.

Test 3 AWS GuardDuty IP Allowlisting via Pacu
linux

Simulates using the Pacu AWS exploitation framework to add an attacker IP to GuardDuty's trusted IP list, effectively allowlisting it from all security group monitoring.

Command

bash 
aws guardduty create-ip-set --detector-id abcdef1234567890 --name df00tech-test --format TXT --location s3://my-bucket/attacker-ips.txt --activate --region us-east-1

Cleanup

bash 
aws guardduty delete-ip-set --detector-id abcdef1234567890 --ip-set-id <returned-id> --region us-east-1

Expected Telemetry

CloudTrail event: CreateIPSet for GuardDuty. This is a critical indicator of defense impairment in AWS.

Expected Detection

Monitor for GuardDuty CreateIPSet and UpdateIPSet CloudTrail events.

Related Detections

Tactic Hub

TA0112 Defense Impairment ATT&CK Matrix

Parent Technique

T1686 Disable or Modify System Firewall

Related Sub-techniques

T1686.002 Disable or Modify Network Device Firewall T1686.003 Windows Host Firewall

Related Techniques

T1562 Impair Defenses T1078.004 Cloud Accounts T1580 Cloud Infrastructure Discovery

Same Tactic: Defense Impairment

Popular Detections