Hackers Abuse AWS/Google Cloud Logging to CloudTrail Evade

Cloud environments represent an increasingly critical attack surface in modern cybersecurity. As organizations continue their rapid migration to cloud infrastructure, the logging and monitoring services designed to track activity within these environments have become a prime objective for threat actors.

Logging services, which record every action taken within a cloud account, are now being weaponized against the very teams that depend on them.

When these records are tampered with or rerouted, security teams lose their clearest window into what is happening inside their own infrastructure.

AWS CloudTrail and Google Cloud Logging are two of the most widely used services of this kind. Both are designed to give organizations a full picture of activity across their cloud environments, recording API calls, resource changes, and user actions in real time.

But that same depth of visibility makes them a high-value target. An attacker who can interfere with these logs can move undetected, erase evidence of their activity, or quietly watch everything the victim does without being noticed.

Researchers from Unit 42 identified and documented these attack methods in a report shared with Cyber Security News (CSN), breaking down how attackers target cloud logging in two distinct ways.

The first is defense evasion, where attackers disable or corrupt logs to avoid detection. The second is continuous visibility, where attackers redirect logs to their own infrastructure to silently monitor a victim’s cloud environment over time.

The scale of damage is significant. Tools like SIEM platforms, SOAR systems, and cloud security posture management products all depend on clean, uninterrupted log data to function.

If those logs are missing, altered, or rerouted, those tools go blind. An attacker operating in that silence can take their time, escalate privileges, and access sensitive data while facing almost no resistance from security teams.

Hackers Abuse AWS CloudTrail and Google Cloud Logging

Defense evasion through cloud logging takes several forms. The most direct method is stopping the logging process entirely.

In AWS, an attacker with the right permissions can call the stop-logging API on a specific trail, halting all log writes to the connected S3 bucket immediately.

In Google Cloud, the equivalent is disabling a sink, which stops log entries from reaching their destination.

Beyond stopping logs, attackers can delete the storage bucket entirely. In AWS, this requires s3:DeleteBucket and s3:DeleteObject permissions. In Google Cloud, a deleted log bucket enters a DELETE_REQUESTED state for seven days before permanent removal.

A subtler approach involves swapping the encryption key protecting logs with an attacker-controlled KMS key, then revoking access to it, making logs impossible to write or read.

The fifth method is log poisoning, where an attacker edits a log file to remove evidence of their activity and re-uploads it, invalidating the audit trail.

Attackers Reroute Logs for Real-Time Spy Access

Once inside a victim environment, sophisticated attackers do not just destroy logs. They redirect them by creating a new routing resource or modifying an existing one, they send all activity logs to storage they control.

In AWS, this is done using the create-trail or update-trail API with a custom bucket name. In Google Cloud, the logging.sinks.create or logging.sinks.update API achieves the same result.

From that point, the attacker receives a live feed of everything happening in the victim’s account, from IAM changes to sensitive data access, all without the victim knowing.

To reduce exposure, AWS users should restrict the update-trail API to highly privileged users and lock S3 bucket policies so only CloudTrail can write to them.

AWS also maintains a 90-day immutable event history that cannot be altered. In Google Cloud, teams should restrict logging.sinks.update permissions tightly.

The built-in _Required log bucket provides an immutable record that cannot be modified or deleted. Enabling CloudTrail log file integrity validation is also critical, as it uses cryptographic checks to detect whether log files were changed after delivery.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.