Why combine three unrelated resource types (IAM, EC2, CloudTrail) into one rule?

Because they share one underlying intent even though they touch different services: each removes a control that would otherwise detect, block, or produce evidence of an attacker's next move. Deleting an IAM security policy loosens access controls, opening a security group to 0.0.0.0/0 removes network containment, and deleting a CloudTrail trail destroys the audit log itself. An attacker doing post-compromise cleanup, or setting up for a second stage, often does more than one of these in the same session — which is exactly what the sample shows.

Why key on 0.0.0.0/0 specifically rather than any security group change?

Because most security group changes are routine and this one specific CIDR is the one that matters: it means the rule now permits traffic from every IP address on the internet, not a scoped range. AWS Config captures the full ipPermissions block in the configuration item, so the literal '0.0.0.0/0' is present whenever a rule is widened to unrestricted access — alerting on any SecurityGroup modification would bury this in routine rule tuning.

Why does deleting an IAM policy matter if the attached roles and users aren't touched?

Because the policy is very often the only thing doing the restricting. A policy named 'SecurityPolicy' attached to multiple roles as a baseline guardrail stops doing anything the instant it's deleted — every principal it was attached to silently inherits whatever permissions remain from their other policies, with no corresponding change to the role or user itself. That makes policy deletion a quieter and easier-to-miss privilege escalation than directly modifying a role's trust policy.

How does this differ from detecting the same actions in CloudTrail directly?

CloudTrail records the API call (DeleteTrail, DeletePolicy, AuthorizeSecurityGroupIngress) the moment it happens, which is faster but requires you to already trust CloudTrail is intact — exactly the control an attacker may have just destroyed. AWS Config's configuration-item history is a separate, resource-centric record of the resulting state change, so if an attacker disables or deletes the trail to cover their tracks, Config can still show the before/after resource state as a second, independent source of the same event.

CRITICAL AWS Config Defense Evasion / Security Control Tampering LTR-0020 ✓ validated

Detect Security Control Tampering in AWS Config — IAM Policy Deletion, Open Security Groups, CloudTrail Disablement

Published October 6, 2026

MITRE ATT&CK: T1562.001 T1562.007 T1562.008

Sigma Rule

title: AWS Config — IAM Policy Deletion, Open Security Group, or CloudTrail Deletion
id: 9ac4798c-466d-4f98-a64b-a3561f6eb903
status: experimental
description: >
  Detects three independent signals of security-control tampering in AWS Config's
  configuration-item history: deletion of an IAM policy, a security group modified
  to permit all traffic from anywhere (0.0.0.0/0), and deletion of a CloudTrail
  trail. Any one of these, seen together or alone, is the signature of an attacker
  (or a careless admin) removing the controls that would otherwise detect or block
  what happens next.
references:
  - https://attack.mitre.org/techniques/T1562/001/
  - https://attack.mitre.org/techniques/T1562/007/
  - https://attack.mitre.org/techniques/T1562/008/
author: LogTriage
date: 2026/10/06
logsource:
  product: aws
  service: config
detection:
  iam_policy_deleted:
    resourceType: 'AWS::IAM::Policy'
    configurationItemStatus: 'ResourceDeleted'
  security_group_opened:
    resourceType: 'AWS::EC2::SecurityGroup'
    cidrIp: '0.0.0.0/0'
  cloudtrail_deleted:
    resourceType: 'AWS::CloudTrail::Trail'
    configurationItemStatus: 'ResourceDeleted'
  condition: iam_policy_deleted or security_group_opened or cloudtrail_deleted
falsepositives:
  - Planned IAM policy consolidation (correlate with a change ticket)
  - Security group opened to 0.0.0.0/0 for a genuinely public-facing service
  - CloudTrail trail consolidation down to a single organization trail
level: critical
tags:
  - attack.defense_evasion
  - attack.t1562.001
  - attack.t1562.007
  - attack.t1562.008

What this rule detects

AWS Config’s configuration-item history doesn’t just say an API call happened — it shows the resource’s resulting state, which makes it a strong second source for a specific category of events: an attacker (or a careless administrator) tearing down the controls that would otherwise catch them. This rule fires on any of three independent signals:

IAM policy deletion — AWS::IAM::Policy with configurationItemStatus: ResourceDeleted.
Security group opened to the world — AWS::EC2::SecurityGroup with an ingress rule whose cidrIp is 0.0.0.0/0.
CloudTrail trail deletion — AWS::CloudTrail::Trail with configurationItemStatus: ResourceDeleted.

Any one of these on its own is worth investigating; seeing more than one in the same session is a strong indicator of deliberate defense evasion rather than routine maintenance.

Detection logic

Each selection is a narrow, high-confidence conjunction rather than “any change to this resource type”:

iam_policy_deleted requires both the resource type and the ResourceDeleted status — a policy being read or attached doesn’t fire this, only its removal.
security_group_opened keys on the literal 0.0.0.0/0 inside the security group’s captured ipPermissions, not just any modification — the overwhelming majority of security group edits are routine, and this is the one CIDR value that specifically means “reachable from anywhere.”
cloudtrail_deleted mirrors the IAM selection: resource type plus ResourceDeleted. There is no legitimate reason to delete an active management trail outside of a deliberate, documented consolidation.

There is no count threshold on any of the three — each is rare and significant enough that a single occurrence justifies an alert.

Validated against a real sample

Validated against aws_config_changes.json (shipped with LogTriage), three configuration items captured one minute apart in the same account:

AWS::IAM::Policy SecurityPolicy — configurationItemStatus: ResourceDeleted
AWS::EC2::SecurityGroup prod-sg modified to an ingress rule of ipProtocol: -1 (all protocols) from cidrIp: 0.0.0.0/0
AWS::CloudTrail::Trail mgmt-trail — configurationItemStatus: ResourceDeleted

Read in sequence, that’s a security baseline policy deleted, the production security group opened to all traffic from anywhere, and the management trail removed — in that order, within two minutes. The rule fires on all three selections. It stays silent on the matching benign log, where the only two configuration items are a running EC2 instance (OK) and a newly discovered S3 bucket with public access blocking explicitly enabled — no deletions, no 0.0.0.0/0, and no AWS::IAM::Policy or AWS::CloudTrail::Trail resource types anywhere in the file.

False positives

The quiet, legitimate version of each selection is traceable to a change ticket: IAM policy deletion during a planned consolidation (paired with a near-simultaneous replacement policy creation), a security group opened to 0.0.0.0/0 for a resource that’s genuinely meant to be public (an internet-facing load balancer’s HTTPS listener), or a CloudTrail trail retired as part of consolidating down to a single organization-wide trail. In all three cases, the identifying feature of a false positive is that the actor and timing match a documented change — an attacker’s version of these events arrives without one.

Frequently Asked Questions

Why combine three unrelated resource types (IAM, EC2, CloudTrail) into one rule?: Because they share one underlying intent even though they touch different services: each removes a control that would otherwise detect, block, or produce evidence of an attacker's next move. Deleting an IAM security policy loosens access controls, opening a security group to 0.0.0.0/0 removes network containment, and deleting a CloudTrail trail destroys the audit log itself. An attacker doing post-compromise cleanup, or setting up for a second stage, often does more than one of these in the same session — which is exactly what the sample shows.
Why key on 0.0.0.0/0 specifically rather than any security group change?: Because most security group changes are routine and this one specific CIDR is the one that matters: it means the rule now permits traffic from every IP address on the internet, not a scoped range. AWS Config captures the full ipPermissions block in the configuration item, so the literal '0.0.0.0/0' is present whenever a rule is widened to unrestricted access — alerting on any SecurityGroup modification would bury this in routine rule tuning.
Why does deleting an IAM policy matter if the attached roles and users aren't touched?: Because the policy is very often the only thing doing the restricting. A policy named 'SecurityPolicy' attached to multiple roles as a baseline guardrail stops doing anything the instant it's deleted — every principal it was attached to silently inherits whatever permissions remain from their other policies, with no corresponding change to the role or user itself. That makes policy deletion a quieter and easier-to-miss privilege escalation than directly modifying a role's trust policy.
How does this differ from detecting the same actions in CloudTrail directly?: CloudTrail records the API call (DeleteTrail, DeletePolicy, AuthorizeSecurityGroupIngress) the moment it happens, which is faster but requires you to already trust CloudTrail is intact — exactly the control an attacker may have just destroyed. AWS Config's configuration-item history is a separate, resource-centric record of the resulting state change, so if an attacker disables or deletes the trail to cover their tracks, Config can still show the before/after resource state as a second, independent source of the same event.

Related Resources

See this detection run on a real report

Try the live demo with a pre-loaded malicious log set — no signup required — or upload your own log file and get a full AI-reviewed threat report in minutes.

Try Live Demo → Analyze Your Own Logs