AWS CloudTrail Management Events Disabled via PutEventSelectors
Description
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.
Query · kuery
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*
Investigation fields
Pivot points the source recommends for triage.
@timestampuser.nameuser_agent.originalsource.ipaws.cloudtrail.user_identity.arnaws.cloudtrail.user_identity.typeaws.cloudtrail.user_identity.access_key_idevent.actionevent.providerevent.outcomecloud.account.idcloud.regionaws.cloudtrail.request_parameters
Known false positives
- IaC pipelines setting event selectors during trail creation always set includeManagementEvents to true — the rule will not fire on those calls. The remaining FP vector is an administrator intentionally restricting a trail to data-events-only for cost reasons. Validate the caller, change management ticket, and confirm this is not a multi-region or organization-wide trail where the coverage impact would be severe.
Analyst notes
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_parameterscontains the full JSON of the new event selectors. The rule has already matchedincludeManagementEvents: false. Confirm whether ALL selectors have management events disabled or only some, and whetherExcludeManagementEventSourcesfurther filters specific services. -
Check for other narrowing: Also inspect
ReadWriteTypeandDataResourcesin the same event — switching toReadOnlyor 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 totrueduring 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, orDescribeTrailscalls from the same identity before this event, indicating reconnaissance of the trail configuration.
Response and remediation
- Immediately call
PutEventSelectorsto restoreincludeManagementEvents: trueon all selectors. - Confirm that
GetTrailStatusshowsIsLogging: 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:PutEventSelectorsto break-glass roles and enforce via SCP.