Attackers Can Abuse AWS CloudTrail and Google Cloud Logging to Hide Activity and Steal Logs

Researchers warn that attackers can abuse AWS CloudTrail and Google Cloud Logging to evade detection, poison forensic records, and redirect cloud logs to attacker-controlled storage.

The techniques were detailed in a new Unit 42 report, which explains how cloud logging services have become high-value targets because they record API calls, configuration changes, identity activity, and access to sensitive resources.

The risk is serious because SIEM, SOAR, CSPM, and cloud detection tools depend on reliable logs. If attackers stop, corrupt, delete, encrypt, or reroute those logs, defenders can lose visibility at the exact moment they need it most.

Cloud Logs Are Now a Target, Not Just a Record

Cloud logging services give security teams a record of activity across cloud environments. AWS CloudTrail records AWS account activity, while Google Cloud Logging routes and stores logs from Google Cloud resources.

Google says Cloud Audit Logs help answer who did what, where, and when across Google Cloud resources. That same visibility makes cloud logs valuable to attackers who want to understand the victim’s environment without running noisy discovery commands.

Unit 42 divides the abuse into two broad categories: defense evasion and continuous visibility. Defense evasion blinds defenders, while continuous visibility lets attackers quietly receive a live feed of cloud activity.

Attack goal	Technique	Main impact
Defense evasion	Stop logging	Creates an immediate monitoring gap
Defense evasion	Delete storage destination	Destroys log archives and forensic evidence
Defense evasion	Delete log router	Breaks the pipeline that delivers logs
Defense evasion	Change encryption keys	Makes logs unreadable or prevents delivery
Defense evasion	Log poisoning	Corrupts the audit trail
Continuous visibility	Create or modify routing resources	Sends victim logs to attacker-controlled destinations

Stopping Logs Can Blind Security Tools

The most direct method is to stop log delivery. In AWS, an attacker with cloudtrail:StopLogging permission can stop a trail from writing new logs to the configured S3 bucket.

In Google Cloud, an attacker with logging.sinks.update permission can disable a sink. Once disabled, new log entries no longer reach that sink’s destination.

This matters because many alerting systems depend on those pipelines. A stopped trail or disabled sink can reduce detection coverage while an attacker escalates privileges, searches for sensitive data, or changes cloud resources.

Attackers Can Delete or Break Log Storage

Attackers can also target the storage destination. In AWS, deleting the S3 bucket used by CloudTrail can prevent new log delivery and remove archived records if the attacker has enough S3 permissions.

Google Cloud handles log bucket deletion differently. Its log bucket documentation says a deleted log bucket enters a DELETE_REQUESTED state for seven days, and Logging continues to route logs to the bucket during that period unless related sinks are changed.

Bucket locking gives defenders another layer of protection. Google’s log bucket locking feature locks the retention policy and prevents bucket deletion until stored entries satisfy the retention period.

Encryption Changes Can Make Logs Unreadable

Unit 42 also describes an attacker-controlled encryption key scenario. In AWS, an attacker could update a trail to use a KMS key they control and then remove CloudTrail’s access to that key.

AWS documents how CloudTrail can use customer-managed KMS keys in its CloudTrail encryption guidance. That same configuration area becomes risky if too many identities can change trail encryption settings.

Google Cloud has a similar customer-managed encryption key risk for log buckets configured with CMEK. If an attacker can point a bucket to an external key and later revoke access, defenders can lose the ability to read or recover the affected logs.

Log Poisoning Corrupts Investigations

Log poisoning takes a different approach. Instead of stopping logging, attackers modify stored log files to remove evidence or insert misleading records.

In AWS, CloudTrail logs are delivered as objects to S3. An attacker with read and write access to those objects could download a log file, remove selected events, and upload the altered file back to the bucket.

AWS offers CloudTrail log file integrity validation to detect whether delivered log files were modified, deleted, or unchanged. The feature uses hashing and digital signatures to help verify the chain of custody for CloudTrail logs.

Log Redirection Can Give Attackers Real-Time Visibility

Attackers do not always need to destroy logs. A more patient attacker can route logs to their own environment and quietly monitor the victim’s cloud activity.

In AWS, this can involve creating a new trail or updating an existing trail to point to an attacker-controlled S3 bucket. In Google Cloud, an attacker can create or update a sink so log entries flow to a destination they control.

The Unit 42 analysis says this gives attackers continuous visibility into activity such as new VM deployments, IAM policy changes, and access to sensitive data. That visibility can help them map the environment and plan later moves with less noise.

AWS and Google Cloud Have Built-In Safeguards

Cloud providers include some protections, but defenders still need to configure permissions and storage carefully. Unit 42 notes that AWS has an immutable 90-day CloudTrail Event History for management events, although data and network events do not appear there.

Google says audit log entries written by Cloud Audit Logs are immutable. Admin Activity audit logs and System Event audit logs are always written, while most Data Access audit logs must be explicitly enabled.

AWS also recommends using log file integrity validation when organizations need to prove that CloudTrail files have not changed after delivery. In environments that use KMS, teams should also review the CloudTrail KMS documentation and restrict who can update encryption settings.

How Defenders Can Reduce the Risk

The main defensive step is to treat logging resources as privileged security infrastructure. CloudTrail trails, Google Cloud sinks, logging buckets, S3 buckets, KMS keys, and routing policies should not be editable by ordinary cloud users.

Security teams should also monitor changes to logging configuration as high-value events. A new sink, a changed destination, a stopped trail, or a modified KMS key can indicate early-stage cloud compromise.

Organizations that export logs to external storage or third-party platforms should verify that those destinations have retention controls, restricted write permissions, and tamper-evident validation where available.

• Limit cloudtrail:StopLogging, update-trail, create-trail, and delete-trail to highly privileged roles.
• Restrict logging.sinks.create, logging.sinks.update, and logging.sinks.delete in Google Cloud.
• Ensure only the logging service can write to designated log storage buckets.
• Enable and routinely test CloudTrail integrity validation.
• Use bucket retention and bucket lock controls for long-term log storage.
• Alert on new log destinations, disabled sinks, stopped trails, and KMS key changes.
• Separate log administration from general cloud administration where possible.

Cloud Log Abuse Can Delay Incident Response

For attackers, cloud log abuse creates two advantages. It can hide active operations from security tooling, and it can give them a passive intelligence feed from the victim’s own environment.

For defenders, the lesson is clear. Logging must receive the same protection as production workloads, identity systems, and secrets. If attackers can control the logs, they can often control what the security team sees.

Cloud teams should review logging permissions, destination policies, retention settings, and monitoring rules now, especially in environments where multiple teams or third-party tools can modify log routing.

FAQ