Notifications
Clear all
Topic starter
01/08/2026 10:50 pm
TL;DR: Attackers can impair AWS CloudTrail without using StopLogging or DeleteTrail by narrowing selectors, halting ingestion, disabling Insights, removing resource policies, and breaking federation, according to Abstract Security’s research. The lesson is that logging governance must treat configuration abuse as an active attack path, not a maintenance event.
NHIMG editorial — based on content published by Abstract Security: Security How Attackers Disable CloudTrail Without Calling StopLogging or DeleteTrail
Questions worth separating out
Q: What breaks when CloudTrail logging is altered instead of stopped?
A: Defenders may keep seeing a healthy trail while the attacker silently removes the events that matter most, such as management changes, data exfiltration signals, or anomaly detections.
Q: Why do cloud admin credentials create such a serious logging risk?
A: Because the same credentials that manage the environment often also control audit settings, federation, and event stores.
Q: What do security teams get wrong about CloudTrail tampering?
A: Many teams focus on obvious disablement actions and miss the quieter configuration changes that achieve the same result.
Practitioner guidance
- Harden CloudTrail mutation permissions Restrict access to PutEventSelectors, StopEventDataStoreIngestion, DisableFederation, DeleteEventDataStore, DeleteResourcePolicy, and DeregisterOrganizationDelegatedAdmin to a minimal security administration role with separate approval paths.
- Alert on selector scope reduction Detect when management events are disabled, read-write scope is narrowed to ReadOnly or None, or data resources are emptied in advanced selectors, because these are strong indicators of logging blind spots.
- Correlate logging-control sequences Build correlation rules that tie together UpdateEventDataStore with termination protection disabled, DisableFederation, and DeleteEventDataStore from the same principal or account in a short window.
What's in the full article
Abstract Security's full article covers the operational detail this post intentionally leaves for the source:
- API-by-API detection logic for PutEventSelectors, DeleteEventDataStore, StopEventDataStoreIngestion, and related CloudTrail tampering actions.
- The exact response fields and state changes analysts can use to confirm whether a control-plane change succeeded.
- Correlation patterns that link UpdateEventDataStore, DisableFederation, DeleteEventDataStore, and selector narrowing into one attack sequence.
- Practical alerting guidance for separating legitimate maintenance from audit-blinding activity.
👉 Read Abstract Security's analysis of how attackers blind AWS CloudTrail without StopLogging →
CloudTrail logging evasion: what IAM and SOC teams need to catch?
Explore further
01/08/2026 10:58 pm
Logging evasion is now an access-governance problem, not just a SIEM problem. If an attacker can modify selectors, ingestion, federation, or policies, then the issue sits inside the privilege model that granted those capabilities in the first place. That means CloudTrail protection depends on how tightly cloud-admin and security-admin rights are separated, reviewed, and constrained. Practitioners should treat audit-system mutation as a privileged workflow with explicit approvals and monitoring.
A question worth separating out:
Q: Who should be accountable for changes to audit logging controls?
A: Accountability should sit with the owners of privileged cloud administration, security operations, and IAM governance, not only the team running detections. If logging controls can be changed without clear ownership and approval, the organisation has a control failure as well as a detection gap.
👉 Read our full editorial: CloudTrail blinding without StopLogging shows a logging governance gap
