AWS CloudTrail Management Events Disabled via PutEventSelectors

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

AWS CloudTrail Management Events Disabled via PutEventSelectors

edit

Detects CloudTrail PutEventSelectors calls where the legacy event selectors explicitly set includeManagementEvents to false, disabling capture of all management API calls for that trail. Unlike StopLogging or DeleteTrail — which leave an obvious trace of the trail being stopped or removed entirely — this technique leaves the trail appearing active and healthy in the console while silently blinding defenders to subsequent IAM changes, credential operations, and resource abuse. This technique is documented in Stratus Red Team as aws.defense-evasion.cloudtrail-event-selectors and is a known pre-exfiltration step.

Rule type: query

Rule indices:

  • logs-aws.cloudtrail-*

Severity: medium

Risk score: 47

Runs every: 5m

Searches indices from: now-6m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

  • Domain: Cloud
  • Data Source: AWS
  • Data Source: Amazon Web Services
  • Data Source: AWS CloudTrail
  • Use Case: Log Auditing
  • Tactic: Defense Evasion
  • Resources: Investigation Guide

Version: 1

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating AWS CloudTrail Management Events Disabled via PutEventSelectors

PutEventSelectors controls which CloudTrail events a trail captures. This rule fires when the new event selectors explicitly set includeManagementEvents to false — disabling capture of all management API calls for that trail while leaving it appearing active in the console. This is a surgical evasion technique that does not trigger the existing StopLogging or DeleteTrail alerts, and can persist silently for days before detection.

Possible investigation steps

  • Confirm the intent: aws.cloudtrail.request_parameters contains the full JSON of the new event selectors. The rule has already matched includeManagementEvents: false. Confirm whether ALL selectors have management events disabled or only some, and whether ExcludeManagementEventSources further filters specific services.
  • Check for other narrowing: Also inspect ReadWriteType and DataResources in the same event — switching to ReadOnly or removing data event entries compounds the coverage gap.
  • Verify the caller: aws.cloudtrail.user_identity.arn — IaC automation (Terraform, CloudFormation, CDK) uses AssumedRole/ASIA* credentials and legitimately sets management event selectors to true during trail creation. An AKIA* key or Root identity making this change outside of a deployment pipeline is high-confidence adversarial.
  • Check trail scope: Was this a multi-region trail or organization-wide trail? Changes to broad-scope trails have the largest visibility impact.
  • Correlate activity: Look for high-impact API calls in the 30–60 minutes following this event — particularly IAM changes, credential operations, or S3/KMS data access — that would now be invisible to the trail.
  • Prior access: Check for GetTrailStatus, GetEventSelectors, or DescribeTrails calls from the same identity before this event, indicating reconnaissance of the trail configuration.

Response and remediation

  • Immediately call PutEventSelectors to restore includeManagementEvents: true on all selectors.
  • Confirm that GetTrailStatus shows IsLogging: true.
  • Review all API activity from the time the selectors were modified until detection using alternative sources (CloudWatch, other regional trails) for the gap window.
  • Restrict cloudtrail:PutEventSelectors to break-glass roles and enforce via SCP.

Rule query

edit
data_stream.dataset: "aws.cloudtrail"
    and event.provider: "cloudtrail.amazonaws.com"
    and event.action: "PutEventSelectors"
    and event.outcome: "success"
    and aws.cloudtrail.request_parameters: *includeManagementEvents*false*

Framework: MITRE ATT&CKTM