Hackers Abuse Cloud Logging Services to Hide Attacks and Monitor Victim Environments

Attackers are increasingly targeting cloud logging services because these systems give defenders their main view into cloud activity. If threat actors can disable, redirect, encrypt, or poison those logs, security teams may lose the evidence they need to detect an intrusion.

According to Unit 42, attackers can abuse services such as AWS CloudTrail and Google Cloud Logging for two main goals: defense evasion and continuous visibility. In the first case, they try to blind defenders. In the second, they try to stream activity data to attacker-controlled infrastructure.

This is not a traditional vulnerability that cloud providers can fix with one patch. The risk comes from how powerful logging permissions can become when attackers compromise privileged accounts, service accounts, access keys, or IAM roles.

Cloud Logs Are Now a High-Value Target

Cloud logging platforms record activity across cloud environments, including management actions, identity changes, resource deployments, API calls, data access, and configuration changes. Security teams feed this data into SIEM, SOAR, CSPM, and incident response tools.

That makes logging systems one of the first places attackers may try to disrupt after gaining access. If logs stop flowing, get deleted, or get routed elsewhere, defenders may not see the next stage of the attack.

AWS says CloudTrail event history provides a searchable, downloadable, immutable record of the past 90 days of management events in an AWS Region. However, that protection is separate from custom trails, event data stores, and exported logs that organizations configure for long-term monitoring.

Attacker goal	Technique	Defender impact
Blind monitoring tools	Stop logging or disable sinks	New events stop reaching SIEM and alerting systems
Destroy evidence	Delete log storage destinations	Archived logs may disappear or become harder to recover
Break log routing	Delete trails or sinks	Security pipelines lose their source data
Make logs unreadable	Change encryption keys	Logs may exist but become inaccessible
Mislead responders	Modify stored log files	Forensic timelines may become unreliable

Attackers Can Stop Logs From Reaching Defenders

The simplest attack is to stop logging. In AWS, an attacker with cloudtrail:StopLogging permissions can stop a trail from writing new logs to its S3 bucket. In Google Cloud, an attacker with the right permissions can disable a logging sink so new logs no longer reach the intended destination.

Google Cloud’s Log Router uses sinks to decide where log entries go. By default, logs are routed to log buckets, but administrators can also create sinks to route logs to destinations such as Cloud Storage, BigQuery, or Pub/Sub.

These features are useful for centralization and analytics, but they also create a sensitive control point. A malicious change to a sink can stop logs from reaching the security team’s normal destination or send them somewhere else.

Deleting or Encrypting Logs Can Damage Forensics

Another technique is deleting the storage destination. In AWS, an attacker with enough S3 permissions can delete the bucket that receives CloudTrail logs. In Google Cloud, a user with logging.buckets.delete permissions can request deletion of a log bucket.

Google’s Cloud Logging buckets documentation explains that log buckets support configurable retention periods. If organizations do not protect those buckets with strict permissions and retention controls, attackers may try to shorten the available investigation window.

Encryption can also become an attack path. Unit 42 described a scenario in which attackers change the encryption key used for logs, then remove defender access to that key. The result is a logging pipeline where data may be present but unreadable.

• Limit who can stop CloudTrail trails or update Google Cloud logging sinks.
• Restrict who can delete S3 log buckets, Cloud Storage destinations, and Google Cloud log buckets.
• Monitor changes to KMS, CMEK, and log encryption settings.
• Alert when logs stop arriving from high-value accounts or projects.
• Keep a separate, protected copy of critical audit logs where possible.

Log Poisoning Can Mislead Incident Response Teams

Log poisoning is more subtle than simply turning logs off. Instead of stopping collection, attackers modify stored logs so investigators see an incomplete or false picture of what happened.

In AWS, CloudTrail log files delivered to S3 can be targeted if an attacker has object read and write permissions. In Google Cloud, a similar risk can appear when logs are routed to Cloud Storage and an attacker has enough object-level access.

AWS provides CloudTrail log file integrity validation to help detect whether CloudTrail log files changed after delivery. AWS says this feature is enabled by default for new trails created in the console, but administrators using APIs or the CLI should confirm that it is enabled.

Cloud logging control	What defenders should monitor
AWS CloudTrail trails	StopLogging, DeleteTrail, UpdateTrail, and destination bucket changes
AWS S3 log buckets	DeleteBucket, DeleteObject, PutObject, bucket policy changes, and object overwrite activity
AWS KMS keys	Key policy changes, disabled keys, scheduled key deletion, and unexpected external key use
Google Cloud sinks	Sink creation, deletion, disabled sinks, destination changes, and filter changes
Google Cloud log buckets	Deletion requests, retention changes, CMEK changes, and unexpected access failures

Attackers Can Use Logs for Continuous Visibility

Not every attack against logging is designed to erase evidence. Some attackers may use logging systems to quietly watch the victim’s cloud environment in real time.

Unit 42 said an attacker can create a new log routing resource or redirect an existing one to an attacker-controlled destination. That could give the attacker visibility into new VM deployments, IAM changes, data access events, and other cloud activity without running noisy discovery commands.

Google’s Cloud Logging routing model allows sinks to send log entries to supported destinations. This is valuable for central monitoring, but it also means sink changes should trigger high-priority security alerts.

1. An attacker gains access to a privileged cloud identity.
2. The attacker reviews available logging permissions.
3. The attacker creates a new trail, sink, or routing rule.
4. Logs begin flowing to an attacker-controlled destination.
5. The attacker watches IAM changes, deployments, and access events.
6. The attacker uses that visibility to plan lateral movement or privilege escalation.

Cloud Provider Safeguards Help, but They Are Not Enough

Cloud providers include useful protections, but organizations still need to configure and monitor them carefully. AWS keeps a 90-day CloudTrail event history for management events, but AWS notes that event history does not replace trails or event data stores for ongoing records.

Google Cloud also provides system-created log buckets and configurable log storage. The log buckets documentation says administrators can set retention from 1 day to 3,650 days for supported buckets, which gives teams flexibility but also makes permission control important.

For encryption, Google Cloud supports customer-managed encryption keys for stored logs. The CMEK documentation explains how log buckets can use customer-managed keys, but those keys must be protected because attackers may try to abuse key changes or key access removal.

How Organizations Can Protect Cloud Logging

Organizations should treat logging pipelines as critical security infrastructure. The accounts and roles that can change logging, routing, storage, retention, and encryption should be more tightly controlled than ordinary administrator permissions.

Security teams should also monitor for logging-control changes from a separate account, project, or security boundary. If attackers compromise the main environment, they should not be able to erase or redirect the only copy of the evidence.

The Unit 42 research recommends understanding how attackers misuse logging services so organizations can detect abuse. The practical response is to reduce logging permissions, protect log destinations, validate log integrity, and alert on changes to routing or encryption.

• Use least privilege for CloudTrail, logging sinks, log buckets, S3 buckets, KMS keys, and CMEK settings.
• Create alerts for StopLogging, DeleteTrail, UpdateTrail, DeleteBucket, DeleteSink, UpdateSink, and logging bucket deletion events.
• Require change control for log routing, retention, and encryption updates.
• Enable CloudTrail log file integrity validation where CloudTrail logs are delivered to S3.
• Use separate security accounts or projects for centralized logging.
• Block broad write access to stored log objects.
• Monitor for new log destinations outside approved accounts, projects, or organizations.
• Test whether your SIEM detects logging shutdown, log redirection, and encryption-key failures.

Cloud Logs Need the Same Protection as Production Data

Cloud logs are not just operational records. They are evidence, detection data, and a map of the cloud environment. Attackers who control them can hide activity, destroy timelines, or watch defenders and administrators work.

The risk is growing because modern cloud environments depend on automated routing, storage, encryption, and third-party integrations. Each of those layers can become a target if permissions are too broad.

Defenders should review cloud logging controls before an incident, not after. AWS log file validation, Google Cloud CMEK controls, centralized log storage, and real-time alerts can reduce the chance that attackers blind the security team when visibility matters most.

FAQ