Cloud Logging Blind Spots: How Attackers Erase Their Tracks in Multi-Tenant Environments
Unit 42 research demonstrates practical techniques for disabling or manipulating cloud logging services (AWS CloudTrail, Azure Monitor, GCP Cloud Logging) to evade detection. This represents a critical post-compromise capability that undermines forensic investigation and compliance monitoring.
Affected
Unit 42 has documented a significant class of attack techniques targeting the logging infrastructure itself rather than user workloads. The research focuses on how adversaries with cloud account access can selectively delete, disable, or redirect logs to prevent forensic reconstruction of their activities. This is not a vulnerability in the classical sense but rather an exploitation of overly permissive IAM policies and design assumptions that logging services are tamper-proof once enabled.
The technical approach involves leveraging legitimate cloud API calls to modify or delete log data. AWS CloudTrail can be disabled by principals with appropriate IAM permissions; Azure Monitor diagnostic settings can be altered or deleted; GCP Cloud Logging sinks can be reconfigured to send logs to attacker-controlled destinations or to reduce retention. The key insight is that in many organisations, the permissions needed to modify logging configuration are not sufficiently restricted or monitored, allowing a compromised application service account or developer credential to become a threat to the entire audit trail.
This attack pattern sits at a critical juncture in the kill chain: after initial access and privilege escalation, but before the most damaging lateral movement or data exfiltration. By erasing or redirecting logs early, attackers can operate with significantly reduced detection risk and complicate post-incident forensics. Compliance-mandated log retention and immutability controls often apply only to specific log types or regions, leaving gaps that skilled adversaries can exploit.
Defenders must implement compensating controls: restrict IAM permissions for log deletion and configuration changes to a minimal set of principals; enable immutable log storage (AWS S3 Object Lock, Azure Immutable Blob Storage); monitor changes to logging configuration itself as a high-fidelity detection signal; and maintain out-of-band log aggregation to a security information and event management (SIEM) system not governed by the same cloud account. The most effective mitigation is treating logging infrastructure as a separate security boundary with its own identity verification and approval workflows.
The broader implication is that cloud-native architectures have concentrated logging trust in the same platforms that host workloads. Unlike traditional on-premises environments where logs might be sent to a physically separate syslog server, cloud logging is tightly integrated and often under the same IAM model as application access. This research underscores that cloud security frameworks must treat the logging control plane as attack surface worthy of the same hardening applied to data access controls.
Sources