AWS CloudTrail records API activity across an AWS environment, helping security teams investigate identity misuse, unauthorised configuration changes, privilege escalation, and data access. However, attackers who obtain sufficient permissions may attempt to stop logging, delete trails, alter trail configurations, or interfere with the delivery of audit records.

Investigating these events requires more than identifying a logging-related API call. Analysts must determine what changed, which identity initiated the action, whether logging coverage was affected, what activity occurred during the exposure window, and whether independent evidence remains available.

This article explains how to investigate potential CloudTrail tampering, reconstruct activity from multiple AWS evidence sources, and improve the resilience of cloud audit logging.

1. Introduction: The Missing Audit Trail

A SOC analyst investigating suspicious activity in an AWS production account notices that CloudTrail delivery has stopped for one of the configured trails.

Shortly before the gap, the account recorded unusual IAM activity and access to sensitive resources. The trail's configuration has also changed, but the available records do not immediately establish whether the change was part of approved maintenance or an attempt to conceal activity.

The investigation now has two objectives: determine what happened to the logging configuration and reconstruct the potentially affected activity.

The analyst needs to establish:

• Which identity modified or stopped the trail?

• Was logging actually interrupted, or was only one delivery destination affected?

• Were events still captured by another trail or logging mechanism?

• Did suspicious activity occur during the suspected gap?

• Can the missing activity be reconstructed using independent evidence?

• Was the change authorised?

This scenario illustrates a fundamental cloud forensic principle: a gap in audit data is itself an investigative concern, but it does not automatically prove malicious tampering.

2. Understanding AWS CloudTrail

CloudTrail records supported AWS API activity and related event metadata. It is an essential source of evidence for investigating changes to AWS identities, permissions, infrastructure, and security configurations.

CloudTrail event categories include:

• Management events: Control-plane operations such as creating IAM users, modifying security groups, or changing trail configurations.

• Data events: Resource-level operations, such as certain Amazon S3 object actions and Lambda function invocations, when configured and supported.

• Insights events: Events generated by CloudTrail Insights when enabled and when qualifying unusual API activity is detected.

CloudTrail can deliver logs to Amazon S3, integrate with Amazon CloudWatch Logs, and provide events through other supported AWS monitoring mechanisms. The exact visibility depends on the configuration and services involved.

Why logging configuration matters

A CloudTrail trail can be configured with different event selectors, destinations, regions, and management options. A change may affect only part of the environment rather than stopping every form of logging.

For example:

• Stopping a trail can interrupt its normal collection and delivery.

• Deleting a trail can remove that trail's configuration.

• Updating event selectors can reduce which events the trail records.

• Changing an S3 destination or its access configuration can affect log delivery.

• Altering a CloudWatch Logs integration can disrupt a downstream monitoring pipeline.

Investigators must distinguish between event collection, log delivery, log retention, and SIEM ingestion. A missing SIEM event does not necessarily mean CloudTrail stopped recording it. The issue may instead involve delivery, permissions, processing, or ingestion.

3. Common CloudTrail Tampering Indicators

Investigators should look for unexpected changes to logging, audit destinations, and the permissions controlling those systems.

IndicatorWhy it mattersInvestigation focusStopLoggingMay stop recording through a specific trailActor, target trail, time, and whether the stop succeededDeleteTrailRemoves a trail configurationTrail identity, authorisation, and alternative logging sourcesUpdateTrailChanges trail configurationCompare configuration before and after the eventPutEventSelectorsChanges which events a trail recordsDetermine whether sensitive event coverage was reducedPutInsightSelectorsChanges CloudTrail Insights configurationEstablish whether an expected Insights configuration was alteredUnexpected S3 bucket policy changesMay affect access to or delivery of audit logsReview policy versions, principals, and delivery permissionsCloudWatch Logs integration changesMay affect downstream audit visibilityInspect trail configuration, delivery status, and subscription settingsMissing expected eventsMay indicate a logging or ingestion problemCheck collection, delivery, retention, and SIEM pipelinesUnusual IAM permission changesMay enable later audit manipulationCorrelate policy changes with logging-related API calls

These indicators are not conclusive on their own. For example, a legitimate cloud migration may involve UpdateTrail, while a permissions issue may prevent log delivery without an attacker deliberately disabling logging.

4. Investigating CloudTrail Tampering Step by Step

Step 1: Validate the Alert

Identify the alert source, AWS account, region, affected trail, and relevant time window.

Collect:

• Event timestamp.

• eventSource and eventName.

• AWS account and region.

• userIdentity.

• sourceIPAddress.

• userAgent.

• requestParameters.

• responseElements, where available.

• errorCode and errorMessage, where present.

• Event ID and request ID.

Confirm whether the operation succeeded. A denied StopLogging request is different from a successful logging interruption, although both may warrant investigation.

Also establish whether the alert concerns CloudTrail itself, S3 log delivery, CloudWatch Logs, or the SIEM ingestion pipeline.

Step 2: Identify the Actor

Determine which principal initiated the change.

The event may originate from an IAM user, assumed role, federated identity, automation pipeline, or AWS service. Examine the available principal and session information, including the role session issuer and source identity where configured.

Correlate the activity with:

• AWS IAM Identity Center or the relevant identity provider.

• MFA and sign-in records.

• Privileged access management records.

• CloudShell, CLI, SDK, or console activity where evidence is available.

• Endpoint and network telemetry.

• Change-management approvals and deployment logs.

Do not attribute an action solely to an IP address or user-agent string. These can be shared, proxied, or otherwise insufficient to identify the operator.

Step 3: Examine Logging Configuration Changes

Review the relevant CloudTrail management events, particularly:

• StopLogging

• StartLogging

• DeleteTrail

• CreateTrail

• UpdateTrail

• PutEventSelectors

• PutInsightSelectors

Establish the trail's configuration before and after the event, including its region coverage, management-event selectors, data-event selectors, destination, and CloudWatch Logs integration where applicable.

Determine whether the change reduced visibility, stopped recording, redirected delivery, or affected only a downstream monitoring component.

A configuration change is most concerning when it occurs shortly before other suspicious actions, lacks an approved change record, or affects the same account and resources involved in the investigation.

Step 4: Establish the Actual Logging Gap

Build a timeline of expected and observed events.

Compare:

1. The last known event before the suspected interruption.

2. The logging-related API operation.

3. The expected time of subsequent events.

4. The first observed event after logging resumed.

5. Delivery and ingestion timestamps, where available.

Check whether the trail was recording events but failing to deliver them, or whether the events were not captured by that trail at all.

Also consider regional scope, multi-Region trail configuration, event selectors, retention settings, and whether another independent trail or monitoring source continued to capture the activity.

A gap in a SIEM dashboard alone is insufficient to conclude that CloudTrail logging was disabled.

Step 5: Investigate Activity During the Gap

Once the likely exposure window is identified, search other available evidence sources for potentially suspicious activity.

Relevant sources include:

• CloudTrail logs from another trail or account.

• AWS Config history and configuration snapshots, where available.

• Amazon S3 access logs and relevant S3 data events.

• CloudWatch Logs and application logs.

• IAM Identity Center and identity-provider logs.

• VPC Flow Logs and DNS logs.

• GuardDuty findings.

• AWS Security Hub findings.

• Service-specific audit records.

• CI/CD pipeline and infrastructure-as-code logs.

These sources provide different kinds of evidence. For example, VPC Flow Logs can show network connections and traffic metadata, but they do not independently reconstruct every AWS API operation. AWS Config may preserve resource configuration history but does not replace CloudTrail's API-level audit records.

Correlate timestamps, identities, resource identifiers, and request metadata wherever possible.

Step 6: Determine Whether Other Security Controls Were Affected

Investigate whether the same principal modified related security controls.

Potential areas of interest include:

• IAM policies and role trust relationships.

• S3 bucket policies and public-access settings.

• CloudWatch Logs retention or delivery configuration.

• Security group and network access changes.

• GuardDuty or Security Hub configuration.

• AWS Config recording settings.

• KMS key policies and permissions.

• Log archive account access controls.

Do not assume all these changes occurred simply because CloudTrail was modified. Search for actual evidence and establish the relationship between each event and the suspected incident.

Step 7: Preserve Available Evidence

Preserve the relevant audit records, configuration details, and supporting telemetry before they expire or are overwritten.

Record:

• The original event data and source.

• Acquisition time and time zone.

• Relevant account, region, and resource identifiers.

• Trail and destination configuration.

• File hashes for collected evidence, where appropriate.

• Collection methods and tool versions.

• Any gaps or limitations in the evidence.

If the incident is ongoing, containment may need to happen immediately. Document any response action that changes the system or could affect evidence.

5. CloudTrail Lake Investigation Query

CloudTrail Lake can help analysts search retained CloudTrail events, subject to the event data store's coverage, retention, and configuration.

The following illustrative query searches for several logging-related management events. Replace YOUR_EVENT_DATA_STORE_ID with the appropriate event data store identifier.

SELECT eventTime, eventSource, eventName, awsRegion, sourceIPAddress, userAgent, userIdentity, requestParameters, responseElements, errorCode, errorMessage, eventID FROM YOUR_EVENT_DATA_STORE_ID WHERE eventSource = 'cloudtrail.amazonaws.com' AND eventName IN ( 'StopLogging', 'StartLogging', 'DeleteTrail', 'CreateTrail', 'UpdateTrail', 'PutEventSelectors', 'PutInsightSelectors' ) ORDER BY eventTime DESC;

This query identifies relevant event types. It does not determine whether the action was malicious or whether a logging gap actually occurred.

Confirm the supported SQL syntax and available fields for your CloudTrail Lake event data store. Query results will only include events that were captured and retained in that data store.

Correlating the actor's subsequent activity

After identifying a suspicious change, search the relevant time window for API calls by the same principal or related role session.

Prioritise activity involving:

• IAM permission changes.

• Access to sensitive S3 objects.

• Secrets Manager or Systems Manager Parameter Store access.

• Changes to security groups or compute resources.

• Creation of credentials or new roles.

• Additional logging or monitoring changes.

Use principal identifiers and session information where available. Matching only the IP address or user-agent string can produce false associations.

6. Reconstructing a Hypothetical Tampering Incident

Consider this hypothetical timeline:

Time (UTC)EvidenceAssessment14:02An assumed role performs an unusual IAM policy changePossible privilege expansion; validate policy impact14:05StopLogging succeeds for a configured trailConfirms that logging was stopped for that trail14:08A sensitive S3 access operation appears in a separate retained sourceSupports investigation of potentially unauthorised data access14:13StartLogging is recordedIndicates that logging was restarted14:16The original SIEM pipeline begins receiving new eventsEstablishes a return of ingestion, not necessarily complete recovery of missing records

The evidence would support a logging interruption and suspicious surrounding activity. It would not automatically establish that the actor intended to conceal a data theft incident.

Investigators should establish whether the same principal was responsible for the policy change and logging interruption, whether the S3 access was authorised, and whether the alternative source reliably captured the relevant operation.

The final assessment should distinguish the confirmed logging change, the observed resource access, and any inference about intent.

7. Detection Engineering: Identifying Potential Log Tampering

Detection 1: Successful Logging Interruption

Alert when StopLogging succeeds on a production or security-critical trail, unless the action is part of a recognised and approved workflow.

Increase investigative priority when the actor is unfamiliar, the change occurs outside an approved maintenance window, or other high-risk events follow.

Detection 2: Trail Deletion or Coverage Reduction

Monitor DeleteTrail, UpdateTrail, and PutEventSelectors for unexpected changes to trail coverage or destination configuration.

Compare the resulting configuration against a known-good baseline. An API call alone is insufficient; the detection should evaluate what changed and which accounts, regions, or event categories were affected.

Detection 3: Logging Change Followed by Sensitive Activity

Conceptual detection logic:

IF a logging configuration change succeeds AND the change reduces expected audit coverage AND the same identity or related session performs sensitive operations: correlate the events preserve available evidence raise a high-priority investigation

The correlation window should reflect the environment's normal activity, event-delivery delays, and the logging configuration involved.

Detection 4: Unexpected Logging Configuration Changes

Periodically compare deployed CloudTrail configurations against an approved baseline. Detect missing trails, unexpected selector changes, altered destinations, and disabled integrations.

Configuration monitoring is valuable because it can identify drift even when a particular API event is unavailable to the primary SIEM.

Detection 5: Unexpected Log Delivery Failures

Monitor delivery status, expected log-arrival patterns, and ingestion pipeline health.

Distinguish between a stopped trail, a destination permission problem, an S3 delivery issue, a CloudWatch Logs integration failure, and a SIEM processing delay. Each requires a different response.

8. MITRE ATT&CK Mapping

The following techniques may be relevant when the evidence supports them. Confirm the current technique descriptions in the ATT&CK knowledge base before publication or operational use.

TechniqueATT&CK IDRelevanceImpair DefensesT1562Security controls or monitoring capabilities are impairedDisable or Modify Cloud LogsT1562.008Cloud logging is disabled or altered to reduce visibilityIndicator RemovalT1070Evidence supports attempts to remove or manipulate traces of activityCloud Service DiscoveryT1526The actor performs cloud service discovery, where observedValid AccountsT1078A legitimate account is used for unauthorised activity

Do not assign every technique merely because StopLogging or DeleteTrail appears in CloudTrail. The mapping should describe observed behaviour, and intent should be assessed separately from the API operation itself.

Reference: https://attack.mitre.org/

9. Containment and Recovery

When unauthorised CloudTrail tampering is suspected, coordinate incident response with the AWS account owner and cloud security team.

Potential actions include:

1. Restore the required trail configuration and event selectors.

2. Confirm that logging is active in the intended accounts and regions.

3. Validate that logs are reaching the correct destinations and SIEM.

4. Restrict or revoke the permissions that enabled the change.

5. Investigate whether the actor's credentials or role sessions are compromised.

6. Preserve evidence from alternative logging and monitoring sources.

7. Review other security-control changes made by the same principal.

8. Verify that the log archive and its access controls remain intact.

For high-assurance environments, protect the central log archive using a separate security account, tightly scoped permissions, and controls that limit modification and deletion. Consider supported organisation-level CloudTrail configurations and additional integrity or retention protections appropriate to the environment.

Restoring logging does not recreate events that were never captured. Recovery must therefore include validating current coverage and documenting any irrecoverable gaps.

10. Preventing CloudTrail Log Tampering

Centralise logging. Send relevant audit records to a dedicated security or log-archive account where practical, with carefully restricted write and administrative access.

Apply least privilege. Restrict permissions that allow principals to stop, delete, or modify trails. Administrative permissions should be granted only when required and controlled through approved processes.

Use organisation-level controls. Consider AWS Organizations and organisation trails to improve consistency across accounts, with appropriate governance and monitoring.

Protect the archive. Use suitable S3 bucket policies, restricted administrative access, and supported retention or immutability controls. S3 Object Lock can provide additional protection when configured appropriately, but it does not automatically prevent every form of logging disruption.

Monitor configuration drift. Detect changes to trails, selectors, destinations, logging integrations, and retention settings.

Separate duties. Avoid giving ordinary workload administrators unrestricted control over the audit infrastructure used to monitor them.

Monitor delivery health. Alert on missing expected events and failed delivery, and test the entire path from AWS logging through to SIEM ingestion.

Preserve independent evidence. Maintain complementary logs and monitoring sources so that a failure in one component does not eliminate all investigative visibility.

Conclusion

CloudTrail log tampering can significantly complicate an AWS security investigation by interrupting audit coverage, changing which events are recorded, or disrupting the delivery of records to monitoring systems.

A reliable investigation establishes exactly what changed, identifies the responsible principal, determines the scope and duration of the visibility gap, and correlates alternative evidence to reconstruct potentially affected activity.

For SOC analysts, the most important distinction is between a suspicious logging change and a proven attempt to conceal malicious activity. The former is an observable event; the latter requires contextual evidence.

Organisations can reduce this risk by restricting control over audit infrastructure, centralising logs, monitoring configuration changes, validating delivery health, and preserving independent evidence sources.

Further Reading

• AWS CloudTrail User Guide

• AWS CloudTrail Security Best Practices

• AWS CloudTrail Log File Integrity Validation

• AWS Organizations — Creating an Organization Trail

• MITRE ATT&CK