You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
### AWS Config Resource Deletion
- added exclusions for services that perform Config modifications by design, reducing noise by 97% over the last 30 days.
- added success criteria to query as well
- increased severity to medium as this alert should be triaged
- updated description, false positive and investigation guide sections
- reduced execution window
- updated MITRE
- updated tags
- added highlighted fields
### AWS Configuration Recorder Stopped
no major query changes needed for this rule, performing as expected in telemetry with low volume as this is more rare activity.
- updated description, false positive and investigation guide sections
- reduced execution window
- updated MITRE
- updated tags
- added highlighted fields
Identifies attempts to delete an AWS Config Service resource. An adversary may tamper with Config services in order to
11
-
reduce visibility into the security posture of an account and / or its workload instances.
10
+
Identifies attempts to delete AWS Config resources. AWS Config provides continuous visibility into resource
11
+
configuration changes and compliance posture across an account. Deleting Config components can significantly reduce
12
+
security visibility and auditability. Adversaries may delete or disable Config resources to evade detection, hide prior
13
+
activity, or weaken governance controls before or after other malicious actions.
12
14
"""
13
15
false_positives = [
14
16
"""
15
-
Privileged IAM users with security responsibilities may be expected to make changes to the Config service in order
16
-
to align with local security policies and requirements. Automation, orchestration, and security tools may also make
17
-
changes to the Config service, where they are used to automate setup or configuration of AWS accounts. Other kinds
18
-
of user or service contexts do not commonly make changes to this service.
17
+
Deletion of AWS Config resources may occur during legitimate account restructuring, environment teardown, or changes
18
+
to compliance tooling. Centralized security teams or approved automation may also delete and recreate Config
19
+
components as part of controlled workflows. Confirm that the action aligns with approved change management and was
20
+
performed by an expected principal.
19
21
""",
20
22
]
21
-
from = "now-60m"
23
+
from = "now-6m"
22
24
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
23
-
interval = "10m"
24
25
language = "kuery"
25
26
license = "Elastic License v2"
26
27
name = "AWS Config Resource Deletion"
27
28
note = """## Triage and analysis
28
29
30
+
> **Disclaimer**:
31
+
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
32
+
29
33
### Investigating AWS Config Resource Deletion
30
34
31
-
AWS Config provides a detailed view of the configuration of AWS resources in your AWS account. This includes how the resources are related to one another and how they were configured in the past so that you can see how the configurations and relationships change over time.
35
+
AWS Config records configuration changes, relationships, and compliance status for AWS resources over time.
36
+
Deleting Config components such as recorders, delivery channels, rules, or conformance packs disrupts
37
+
security monitoring, compliance enforcement, and forensic visibility. This behavior is uncommon outside of
38
+
planned infrastructure changes and should be treated as high-risk when unexpected. This rule detects successful deletion of AWS Config resources.
39
+
40
+
### Possible investigation steps
41
+
42
+
**Identify the actor**
43
+
- Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine who initiated the deletion.
44
+
- Confirm whether this principal typically manages AWS Config or centralized security tooling.
45
+
- Check `user_agent.original` to determine whether the action was performed via console, CLI, SDK, or automation.
46
+
47
+
**Determine what was deleted**
48
+
- Inspect `event.action` and `aws.cloudtrail.request_parameters` to identify which Config component was removed
49
+
(e.g., configuration recorder, delivery channel, rule, aggregator, or conformance pack).
50
+
- Assess whether the deleted resource was account-scoped or organization-wide. Used for compliance reporting, guardrails, or security monitoring.
51
+
- Identify the affected regions and accounts using `cloud.region` and `cloud.account.id`.
52
+
53
+
**Reconstruct timing and intent**
54
+
- Use `@timestamp` to correlate the deletion with:
55
+
- IAM changes (role updates, policy modifications, STS activity).
56
+
- Other monitoring disruptions (CloudTrail, GuardDuty, Security Hub).
57
+
- Destructive or high-impact actions occurring shortly before or after.
58
+
- Compare the timing against approved maintenance windows or infrastructure changes.
59
+
60
+
**Correlate with broader activity**
61
+
- Pivot in CloudTrail on the same principal or access key to identify:
62
+
- Additional attempts to disable logging or security controls.
63
+
- Resource deletions or configuration weakening across services.
64
+
- Evaluate whether the deletion appears isolated or part of a broader evasion sequence.
65
+
66
+
**Validate intent with stakeholders**
67
+
- Confirm with security, cloud platform, or compliance teams whether the deletion was planned and approved.
68
+
- Verify whether replacement Config resources were created shortly after, or whether monitoring remains disabled.
32
69
33
-
This rule looks for the deletion of AWS Config resources using various API actions. Attackers can do this to cover their tracks and impact security monitoring that relies on these sources.
70
+
### False positive analysis
34
71
35
-
#### Possible investigation steps
72
+
- **Planned environment changes**
73
+
- Non-production account teardown, environment consolidation, or compliance tool migrations may involve
74
+
deletion of Config resources.
36
75
37
-
- Identify the user account that performed the action and whether it should perform this kind of action.
38
-
- Identify the AWS resource that was involved and its criticality, ownership, and role in the environment. Also investigate if the resource is security-related.
39
-
- Investigate other alerts associated with the user account during the past 48 hours.
40
-
- Contact the account and resource owners and confirm whether they are aware of this activity.
41
-
- Check if this operation was approved and performed according to the organization's change management policy.
42
-
- Considering the source IP address and geolocation of the user who issued the command:
43
-
- Do they look normal for the calling user?
44
-
- If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control?
45
-
- If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance?
46
-
- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.
76
+
- **Authorized security automation**
77
+
- Approved automation or security tooling may delete and recreate Config components during setup or remediation.
78
+
- Tune exceptions carefully using specific principals or automation roles rather than broad exclusions.
47
79
48
-
### False positive analysis
80
+
### Response and remediation
49
81
50
-
- If this rule is noisy in your environment due to expected activity, consider adding exceptions — preferably with a combination of user and IP address conditions.
82
+
- **Contain and restore visibility**
83
+
- If unauthorized, immediately re-enable AWS Config components, including recorders and delivery channels.
84
+
- Validate that historical configuration data and compliance reporting resume as expected.
51
85
52
-
### Response and remediation
86
+
- **Investigate scope and impact**
87
+
- Determine how long Config visibility was impaired and what activity may have occurred during that window.
88
+
- Review other monitoring gaps (e.g., CloudTrail or GuardDuty changes) for coordinated evasion.
89
+
90
+
- **Credential and access review**
91
+
- Rotate or disable credentials associated with the deleting principal if compromise is suspected.
92
+
- Review IAM permissions to ensure only a minimal, well-defined set of roles can manage AWS Config.
53
93
54
-
- Initiate the incident response process based on the outcome of the triage.
55
-
- Disable or limit the account during the investigation and response.
56
-
- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:
57
-
- Identify the account role in the cloud environment.
58
-
- Assess the criticality of affected services and servers.
59
-
- Work with your IT team to identify and minimize the impact on users.
60
-
- Identify if the attacker is moving laterally and compromising other accounts, servers, or services.
61
-
- Identify any regulatory or legal ramifications related to this activity.
62
-
- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions.
63
-
- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users.
64
-
- Consider enabling multi-factor authentication for users.
65
-
- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.
66
-
- Implement security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS.
67
-
- Take the actions needed to return affected systems, data, or services to their normal operational levels.
68
-
- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector.
69
-
- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
70
-
71
-
## Setup
72
-
73
-
The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
94
+
- **Hardening and prevention**
95
+
- Use SCPs or IAM conditions to restrict deletion of Config resources in production and security accounts.
96
+
- Implement AWS Config rules or Security Hub controls to alert when Config is disabled or degraded.
97
+
- Document and formalize change procedures for governance tooling.
98
+
99
+
### Additional information
100
+
- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)**
event.dataset:aws.cloudtrail and event.provider:config.amazonaws.com and
93
-
event.action:(DeleteConfigRule or DeleteOrganizationConfigRule or DeleteConfigurationAggregator or
123
+
event.dataset: aws.cloudtrail
124
+
and event.provider: config.amazonaws.com
125
+
and event.outcome: success
126
+
and event.action: (DeleteConfigRule or DeleteOrganizationConfigRule or DeleteConfigurationAggregator or
94
127
DeleteConfigurationRecorder or DeleteConformancePack or DeleteOrganizationConformancePack or
95
128
DeleteDeliveryChannel or DeleteRemediationConfiguration or DeleteRetentionConfiguration)
129
+
and not aws.cloudtrail.user_identity.invoked_by: (securityhub.amazonaws.com or fms.amazonaws.com or controltower.amazonaws.com or config-conforms.amazonaws.com)
0 commit comments