AWS security service disabled
An AWS security or logging service was torn down — a GuardDuty detector, a WAF web ACL or IP set, a CloudWatch log group or stream, a Config rule, or an…
What it detects
An AWS security or logging service was torn down — a GuardDuty detector, a WAF web ACL or IP set, a CloudWatch log group or stream, a Config rule, or an S3 lifecycle policy set to expire objects.
These are the controls that would have recorded what happens next, so deleting them is preparation rather than an end in itself. The lifecycle case is the quiet one: instead of deleting a log bucket, which is conspicuous, an attacker attaches a lifecycle rule that expires its objects in a day or two and lets AWS do the destruction on a schedule.
MITRE ATT&CK mapping
False positives and triage
Infrastructure-as-code teardowns delete these resources legitimately and in bulk — a whole environment being destroyed will trip this repeatedly, and the caller will be a deployment role. Lifecycle policies are also ordinary cost management on non-log buckets. The signal is a delete by a human IAM user rather than a deployment principal, a delete not paired with a matching create elsewhere in the same change, a lifecycle policy applied to a bucket that receives CloudTrail or access logs, or a short expiry (a day or two) on any bucket holding evidence.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 75%. Source: rules/cloud/aws_security_service_disabled.yaml, licensed under the Apache License 2.0.
id: cloud.aws.security_service_disabled
version: 1.0.0
status: stable
severity: high
confidence: 0.75
platforms: [application]
mitre_techniques: [T1562.008, T1562.001]
description: |
An AWS security or logging service was torn down — a GuardDuty detector, a WAF
web ACL or IP set, a CloudWatch log group or stream, a Config rule, or an S3
lifecycle policy set to expire objects.
These are the controls that would have recorded what happens next, so deleting
them is preparation rather than an end in itself. The lifecycle case is the quiet
one: instead of deleting a log bucket, which is conspicuous, an attacker attaches
a lifecycle rule that expires its objects in a day or two and lets AWS do the
destruction on a schedule.
match:
provider: AWS
event_action_any:
- DeleteDetector
- DeleteMembers
- DisassociateMembers
- StopMonitoringMembers
- DeleteWebACL
- DeleteIPSet
- DeleteRule
- DeleteRuleGroup
- DeleteLogGroup
- DeleteLogStream
- DeleteConfigRule
- DeleteConfigurationRecorder
- DeleteDeliveryChannel
- StopConfigurationRecorder
- PutBucketLifecycle
- PutBucketLifecycleConfiguration
correlation_keys: [user_name]
false_positive_guidance: |
Infrastructure-as-code teardowns delete these resources legitimately and in bulk —
a whole environment being destroyed will trip this repeatedly, and the caller will
be a deployment role. Lifecycle policies are also ordinary cost management on
non-log buckets. The signal is a delete by a human IAM user rather than a
deployment principal, a delete not paired with a matching create elsewhere in the
same change, a lifecycle policy applied to a bucket that receives CloudTrail or
access logs, or a short expiry (a day or two) on any bucket holding evidence.
Related detections
Run this rule on your own logs — offline
KIROSEC runs this rule and the rest of the library over Windows, Linux, macOS and cloud audit logs on the analyst's own machine. Every alert links to the events that raised it, and nothing leaves the device.