Loading

AWS CloudWatch Alarm Deletion

Detects the deletion of one or more Amazon CloudWatch alarms using the "DeleteAlarms" API. CloudWatch alarms are critical for monitoring metrics and triggering alerts when thresholds are exceeded. An adversary may delete alarms to impair visibility, silence alerts, and evade detection following malicious activity. This behavior may occur during post-exploitation or cleanup phases to remove traces of compromise or disable automated responses.

Rule type: query
Rule indices:

  • filebeat-*
  • logs-aws.cloudtrail-*

Rule Severity: medium
Risk Score: 47
Runs every:
Searches indices from: now-6m
Maximum alerts per execution: ?
References:

Tags:

  • Domain: Cloud
  • Data Source: AWS
  • Data Source: Amazon Web Services
  • Data Source: Amazon CloudWatch
  • Resources: Investigation Guide
  • Tactic: Defense Evasion

Version: ?
Rule authors:

  • Elastic

Rule license: Elastic License v2

Disclaimer: 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, validate and adapt it to your operational context.

Amazon CloudWatch is a monitoring and observability service that collects monitoring and operational data in the form of logs, metrics, and events for resources and applications. This data can be used to detect anomalous behavior in your environments, set alarms, visualize logs and metrics side by side, take automated actions, troubleshoot issues, and discover insights to keep your applications running smoothly.

Amazon CloudWatch Alarms monitor key metrics and trigger automated alerts or remediation workflows. Deleting these alarms disables monitoring of associated metrics and can delay detection of performance degradation or security incidents. Attackers may delete alarms to evade detection, suppress alerts, or disable security automation that responds to anomalies or policy violations.

This rule detects successful calls to the DeleteAlarms API via CloudTrail. These events should be rare and always associated with a valid change-control request or automation pipeline.

  • Identify the actor

    • Review aws.cloudtrail.user_identity.arn and aws.cloudtrail.user_identity.access_key_id to determine who initiated the deletion.
    • Check whether this actor typically performs CloudWatch management or automation tasks.

  • Review request details

    • Inspect aws.cloudtrail.request_parameters or target.entity.id for the specific alarm names deleted.
    • Determine whether the alarms were security-related (e.g., CloudTrail log delivery, GuardDuty finding rate, or IAM API monitoring alarms).
    • Cross-reference deleted alarms with your organization's list of critical monitoring configurations.

  • Analyze source and context

    • Review source.ip and user_agent.original for anomalies such as external IPs, unusual user agents, or custom SDKs.
    • Determine whether the activity occurred during a known maintenance window or from a trusted automation host.
    • Examine cloud.region to identify whether alarms were deleted from unexpected regions.

  • Correlate with surrounding events

    • Review CloudTrail events for related activity around the same time, such as:
      • PutMetricAlarm, DisableAlarmActions, or DeleteLogGroup
      • Changes to CloudTrail, Config, or GuardDuty configurations
      • IAM policy or permission modifications that could facilitate evasion
    • Identify whether the same actor has previously modified logging or monitoring infrastructure.

  • Assess impact and scope

    • Determine which systems or detection workflows relied on the deleted alarms.
    • Review whether the deletion affected automated responses, notifications, or third-party integrations (e.g., SNS, Lambda, or PagerDuty).
  • Legitimate automation or redeployment
    • Infrastructure as Code (IaC) frameworks such as Terraform or CloudFormation may delete and recreate alarms during updates.
    • Validate automation account roles and ensure alarm deletions are immediately followed by re-creation actions.
  • Operational maintenance
    • Scheduled monitoring cleanup, regional deactivation, or test environment resets can trigger legitimate deletions.
    • Verify timing and user identity against approved change management records.
  • Organizational migrations
    • Security operations or DevOps teams may consolidate alarms during account merges or refactors.
    • Confirm intent with relevant teams and exclude authorized administrative accounts as necessary.

  • Containment

    • If the deletion was unauthorized, recreate the deleted alarms immediately using IaC templates or CloudFormation backups.
    • Re-enable any dependent automation or alerts that rely on those alarms.
    • Temporarily restrict CloudWatch modification privileges to designated IAM roles.

  • Investigation

    • Review related CloudTrail logs for preceding IAM changes, STS activity, or anomalous role assumptions that might indicate compromised credentials.
    • Investigate whether any alerts were suppressed or delayed prior to the deletion.

  • Recovery and hardening

    • Implement AWS Config rules to continuously monitor alarm existence and alert on DeleteAlarms API calls.
    • Restrict permissions to cloudwatch:DeleteAlarms and enforce MFA for users performing monitoring configuration changes.
    • Maintain IaC definitions for all critical alarms to support rapid restoration.
    • Audit IAM roles and automation accounts that manage CloudWatch configurations to ensure least privilege.
    • Integrate alarm configuration checks into your CI/CD validation workflows.
event.dataset: "aws.cloudtrail"
  and event.provider: "monitoring.amazonaws.com"
  and event.action: "DeleteAlarms"
  and event.outcome: "success"
  and source.ip: *
  and not user_agent.original : "AWS Internal"

Framework: MITRE ATT&CK