Hackers Abuse AWS CloudTrail and Google Cloud

Overview

Cloud logging services — the very tools meant to protect cloud environments — are now being weaponized by attackers. Researchers from Unit 42 have documented how threat actors are abusing AWS CloudTrail and Google Cloud Logging to evade detection and exfiltrate logs, turning visibility systems into blind spots for security teams.

The New Target: Cloud Logging Infrastructure

As organizations shift to cloud computing, services like CloudTrail and Cloud Logging record every API call, resource change, and user action — forming the core of cloud auditing and incident response.

But that same visibility makes them a high‑value target. An attacker who can tamper with logs can move undetected, erase evidence, or even spy on the victim’s environment in real time.

Platform	Logging Service	Purpose
AWS	CloudTrail	Tracks API calls and resource changes
Google Cloud	Cloud Logging	Records user actions and system events

Two Attack Models Identified

Unit 42 researchers outlined two distinct attack patterns:

1. Defense Evasion — Attackers disable, corrupt, or delete logs to hide their tracks.
2. Continuous Visibility — Attackers redirect logs to their own infrastructure to monitor victim activity over time.

When logs are missing or altered, tools like SIEM, SOAR, and CSPM go blind — leaving attackers free to escalate privileges and exfiltrate data without detection.

Defense Evasion Techniques

Attackers use multiple methods to silence or poison cloud logs:

Technique	AWS Method	Google Cloud Equivalent
Stop Logging	stop‑logging API call halts writes to S3 bucket	Disable sink to stop log delivery
Delete Storage	s3:DeleteBucket and DeleteObject permissions	Delete log bucket (DELETE_REQUESTED state for 7 days)
KMS Key Swap	Replace encryption key with attacker‑controlled KMS key	Revoke access to key → “Bucket access denied” error
Log Poisoning	Edit and re‑upload log files to erase evidence	Modify entries to invalidate audit trail

Each method either stops logging entirely or renders logs unreadable — effectively blinding security operations.

Attackers Reroute Logs for Real‑Time Spy Access

Sophisticated actors don’t just destroy logs — they redirect them to their own storage.

• AWS: Using create‑trail or update‑trail APIs with a custom bucket name.
• Google Cloud: Using logging.sinks.create or logging.sinks.update APIs to reroute entries.

From that moment, attackers receive a live feed of the victim’s cloud activity — IAM changes, data access, and resource modifications — all without the victim knowing.

Mitigation and Best Practices

To defend against cloud logging abuse:

• Restrict API Permissions — Limit update‑trail and logging.sinks.update to highly privileged users.
• Lock Bucket Policies — Ensure only CloudTrail can write to S3 buckets.
• Enable Immutable Logs — Use AWS’s 90‑day immutable event history and Google’s Required log bucket.
• Activate Integrity Validation — Cryptographically verify log files to detect tampering.
• Monitor KMS Key Changes — Alert on unauthorized key swaps or revocations.

These controls ensure that even if attackers gain access, they cannot silence or redirect logs without triggering alerts.

Expert in the Cloud Insight

This research highlights a critical truth: visibility is security. When attackers target logging systems, they attack the eyes of defense. Cloud teams must treat log integrity as a core security asset — not just an audit tool.

For enterprises running multi‑cloud environments, the path forward is clear: centralize log validation, enforce immutable storage, and monitor for API abuse in real time.