For every AWS account there is an immutable 90 day CloudTrail Event History of all management events.
Cloud logging services are both the single best source of truth about activity inside cloud environments and, Unit 42 warns, a high-value target for attackers who want to hide. Palo Alto Networks’ Unit 42 outlines a set of practical techniques adversaries can use to stop, corrupt, or steal cloud logs — and shows how those moves create persistent blind spots or, in some cases, continuous visibility into victims' estates. The firm focuses on two widely used services: AWS CloudTrail and Google Cloud Logging, and maps specific APIs, permissions, and failures that defenders should watch.
How attackers manipulate AWS CloudTrail and S3
Unit 42 details several concrete attack flows against CloudTrail and the S3 buckets that receive its logs. An attacker with cloudtrail:StopLogging permissions can invoke the stop-logging API for a trail, immediately halting new log delivery. If the attacker instead has s3:DeleteBucket and s3:DeleteObject permissions, they can delete the bucket (after emptying it), cutting off log storage. Attackers can also change the encryption key used by a trail: creating an external KMS key, updating the trail’s KMS setting to that key with update-trail, then removing CloudTrail’s access to the key; CloudTrail will report a configuration error and stop writing logs because it cannot encrypt them. Unit 42 also describes log poisoning: with s3:GetObject and s3:PutObject permissions an attacker can download, modify, and re-upload CloudTrail JSON files, breaking chain of custody and misleading analysts. Finally, adversaries can create or update trails (create-trail, update-trail) to direct logs to attacker-controlled S3 buckets, enabling continuous, passive discovery of the victim environment. Where EventBridge and CloudTrail Event History are configured, some creation events may be visible; not all organizations have those defenses enabled.
How attackers exploit Google Cloud sinks, buckets, and CMEK
Unit 42 lays out parallel techniques for Google Cloud. Logs are routed by sinks into log buckets or other destinations; an attacker with logging.sinks.update can set a sink’s disabled field to true, stopping exports. With logging.buckets.delete permissions a log bucket can be moved to a DELETE_REQUESTED state — Google Cloud retains that state for seven days before final deletion — unless the bucket has been locked with an irreversible retention policy. Customer-managed encryption keys (CMEK) are another lever: an attacker can point a log bucket to an external CMEK (using gcloud logging buckets update ...) and then remove decrypt permissions from the external key, rendering logs unreadable and preventing rekeying without decrypt access. Like AWS, Google Cloud storage objects can be downloaded and overwritten with storage.objects.get and storage.objects.create, enabling log poisoning. Sinks can also be created or updated to divert logs to attacker resources, giving real-time visibility into activity.
Five core techniques adversaries use against cloud logging
- Stop logging: API calls (cloudtrail:StopLogging; setting a sink disabled) that halt exports.
- Delete the log storage destination: deleting S3 buckets or Google log buckets (DELETE_REQUESTED state).
- Delete the log router: removing an AWS trail or Google sink so new logs are not routed.
- Impair logging via encryption keys: swapping in attacker-controlled KMS/CMEK and then revoking access so logs cannot be written or read.
- Log poisoning: downloading, altering, and re-uploading stored JSON log objects to corrupt the audit trail.
Unit 42 emphasizes that disrupting log data undermines SIEMs, SOAR platforms, and CSPM tools that depend on that telemetry — giving attackers the ability to evade detection, exfiltrate in real time, or frustrate forensic investigations.
Mitigations, native protections, and response options
The report recommends restricting access to logging resources to highly privileged users and hardening the destinations and keys that logging services rely on. For AWS, Unit 42 advises limiting update-trail and stop-logging invocations to privileged identities, configuring S3 bucket policies to prevent non-admin configuration changes, and ensuring only the CloudTrail service can write to bucket objects. AWS also offers CloudTrail log file integrity validation to detect post-delivery modifications (enabled by default when Trails are created in the Console). On Google Cloud, defenders should restrict logging.sinks.update, protect destination resources, and consider locking log buckets with an immutable retention policy; the platform’s built-in _Required and _Default log buckets also provide an immutable record for certain audit logs. Palo Alto Networks points to Cortex Cloud runtime security operations as a product that can collect and analyze cloud audit logs to detect many of the techniques described and lists a set of Cortex alerts (Table 2) tied to these behaviors.
What this means for security teams, cloud architects, and procurement leaders
- Security teams: instrument detection for specific API events called out by Unit 42 (stop-logging, create/update-trail, delete-bucket, logging.sinks.update) and enable CloudTrail EventBridge and log integrity features where possible.
- Cloud architects: enforce least privilege on logging service APIs, lock or protect log buckets and CMEKs, and ensure only the logging service account can write to logging destinations.
- Procurement leaders: require vendors and third-party integrations to respect native logging protections and verify that third-party access cannot alter logging configuration or destinations.
Unit 42 shared these findings with the Cyber Threat Alliance so protections can be broadly deployed. If you believe you are compromised, the team recommends contacting Unit 42 Incident Response; Unit 42 provides regional contact numbers including North America toll-free +1 (866) 486-4842 and other international lines listed in the report.
The integrity of the logging pipeline is not an optional convenience; Unit 42’s analysis shows it is a frontline control. When attackers aim directly at trails, sinks, buckets, and keys, defenders must treat those resources as crown jewels — restrict access, enforce write-only service permissions, and instrument alerts for the precise API calls that signal tampering.
https://unit42.paloaltonetworks.com/cloud-logging-defense-evasion/
