Which SIEM platforms have a T1686.001 detection rule?

df00tech provides T1686.001 (Disable or Modify Cloud Firewall) detection queries for 7 SIEM platforms: Microsoft Sentinel / Defender, Splunk, Elastic Security (EQL), IBM QRadar (AQL), Sumo Logic CSE, Google Chronicle / SecOps, CrowdStrike LogScale (CQL).

What data sources are required to detect Disable or Modify Cloud Firewall (T1686.001)?

Detecting Disable or Modify Cloud Firewall requires the following data sources: Cloud Service: Cloud Service Modification, Firewall: Firewall Rule Modification, AWS CloudTrail, Azure Activity Log, GCP Audit Log.

What severity and confidence is the T1686.001 detection?

The T1686.001 detection is rated high severity with medium confidence.

What are common false positives for T1686.001?

Common false positives for T1686.001 include: 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.

T1686.001 Google Chronicle · YARA-L

Detect Disable or Modify Cloud Firewall in Google Chronicle

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/

YARA-L Detection Query

Google Chronicle (YARA-L)

yaral

rule mitre_t1562_007_cloud_firewall_modification {
  meta:
    author = "Argus Detection Engineering"
    description = "Detects modification, creation, or deletion of cloud firewall rules across AWS, Azure, and GCP that may indicate an adversary bypassing network access controls."
    mitre_attack_tactic = "Defense Evasion"
    mitre_attack_technique = "T1562.007"
    severity = "HIGH"
    priority = "HIGH"

  events:
    $e.metadata.event_type = "USER_RESOURCE_UPDATE_CONTENT"
    (
      (
        $e.metadata.vendor_name = "AMAZON"
        AND (
          $e.metadata.product_event_type = "AuthorizeSecurityGroupIngress"
          OR $e.metadata.product_event_type = "AuthorizeSecurityGroupEgress"
          OR $e.metadata.product_event_type = "RevokeSecurityGroupIngress"
          OR $e.metadata.product_event_type = "RevokeSecurityGroupEgress"
          OR $e.metadata.product_event_type = "CreateSecurityGroup"
          OR $e.metadata.product_event_type = "DeleteSecurityGroup"
        )
      )
      OR (
        $e.metadata.vendor_name = "MICROSOFT"
        AND re.regex($e.target.resource.name, `(?i)networkSecurityGroups`)
      )
      OR (
        $e.metadata.vendor_name = "GOOGLE"
        AND re.regex($e.target.resource.name, `(?i)compute\.firewalls`)
      )
    )

  condition:
    $e
}

high severity medium confidence

Chronicle YARA-L 2.0 rule detecting cloud firewall configuration changes across AWS, Azure, and GCP using Unified Data Model fields. Triggers on security group ingress/egress authorization changes, NSG write operations, and GCP compute firewall modifications. Correlates actor identity via principal.user fields for analyst triage.

Data Sources

AWS CloudTrail (Chronicle AWS log ingestion)Azure Activity Logs (Chronicle Azure integration)GCP Cloud Audit Logs (Chronicle GCP integration)

Required Tables

UDM events with metadata.vendor_name IN (AMAZON, MICROSOFT, GOOGLE)

False Positives & Tuning

Cloud-native network automation tools that programmatically manage firewall rules as part of service mesh or zero-trust network architecture implementations
Disaster recovery drills that simulate environment reconstruction including firewall rule provisioning from infrastructure templates
Managed Kubernetes services (EKS, AKS, GKE) that automatically create and modify security groups and firewall rules when deploying load balancers or NodePort services

Other platforms for T1686.001

Microsoft Sentinel (KQL) Splunk (SPL) Elastic Security (Elastic) IBM QRadar (QRadar) Sumo Logic CSE (Sumo) 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.

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.
Test 2 Azure NSG Rule Addition

Expected signal: Azure Activity Log: Microsoft.Network/networkSecurityGroups/securityRules/write operation.
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

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

Containment

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

Evidence Collection

AWS: CloudTrail events for AuthorizeSecurityGroupIngress with requestParameters showing CIDR ranges
AWS: VPC Flow Logs for traffic during the exposure window
Azure: Activity Log for NSG write operations with request body showing rule details
Azure: NSG Flow Logs for traffic analysis
GCP: Audit Log for compute.firewalls.create/update with firewall rule details
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

Detect Disable or Modify Cloud Firewall in Google Chronicle

MITRE ATT&CK

YARA-L Detection Query

Data Sources

Required Tables

False Positives & Tuning

Other platforms for T1686.001

Testing Methodology

Response Playbook

Triage

Containment

Evidence Collection

Escalation Criteria

Investigation Guide

Forensic Artifacts

Tuning Guidance

Hunting Queries

Atomic Red Team Tests

Command

Cleanup

Expected Telemetry

Expected Detection

Command

Cleanup

Expected Telemetry

Expected Detection

Command

Cleanup

Expected Telemetry

Expected Detection

Related Detections

Tactic Hub

Parent Technique

Related Sub-techniques

Related Techniques

Same Tactic: Defense Impairment

Popular Detections

MITRE ATT&CK

YARA-L Detection Query

Data Sources

Required Tables

False Positives & Tuning

Other platforms for T1686.001

Testing Methodology

Response Playbook

Triage

Containment

Evidence Collection

Escalation Criteria

Investigation Guide

Forensic Artifacts

Tuning Guidance

Hunting Queries

Atomic Red Team Tests

Command

Cleanup

Expected Telemetry

Expected Detection

Command

Cleanup

Expected Telemetry

Expected Detection

Command

Cleanup

Expected Telemetry

Expected Detection

Related Detections

Tactic Hub

Parent Technique

Related Sub-techniques

Related Techniques

Same Tactic: Defense Impairment

Popular Detections

Get new detections in your inbox