Cloud Logging Impairment: Post-Compromise Evasion and Log Exfiltration via AWS CloudTrail and GCP Logging APIs

Cloud logging infrastructure, including AWS CloudTrail, GCP Cloud Logging, and their equivalents, has emerged as a high-value target for adversaries who have already established a foothold in a cloud environment. Unit 42 research from Palo Alto Networks catalogues seven distinct post-compromise techniques that either blind defenders by destroying or degrading log visibility, or establish persistent attacker visibility by silently diverting log streams to attacker-controlled storage. Because cloud security operations centers depend on management-plane audit logs as the primary evidence source for detecting lateral movement, privilege escalation, and persistence, successful impairment can allow prolonged undetected access while ongoing operations continue unobserved. The techniques apply across any threat actor class that has obtained sufficient IAM or cloud administrator credentials, including ransomware operators, espionage groups, and financially motivated actors targeting resource-rich environments.

Attackers with cloud management-plane access can pursue five distinct defensive impairment paths. The highest-likelihood technique is simply calling the StopLogging API (AWS) or disabling the logging sink (GCP), which immediately halts log delivery; the 90-day CloudTrail Event History buffer provides a partial backstop, but it covers only management-plane events and cannot be disabled, making it a gap rather than a full control. Storage deletion goes further, by removing the S3 bucket or GCP log bucket destroys existing evidence and prevents future delivery simultaneously. Trail or sink configuration deletion achieves the same result by severing the routing infrastructure without touching the destination, making recovery dependent on recreating the configuration from scratch. A more covert technique involves rotating the KMS key associated with CloudTrail to one controlled by the attacker and then revoking the decryption permission, rendering accumulated log files unreadable without producing any "logging disabled" telemetry. Finally, log poisoning is done by downloading stored log JSON from S3 or Cloud Storage, modifying specific entries to remove or alter API calls, and re-uploading it. Thus, allowing retroactive alteration of the forensic record to obscure specific principals or operations from incident investigations.

Two additional techniques serve offensive intelligence gathering rather than evidence destruction. An attacker can create a new log routing configuration that delivers logs to an attacker-controlled storage bucket in a separate account, mirroring the victim's management-plane activity in real time without alerting the organization's security team. Alternatively, existing routing configurations can be modified in-place to redirect log delivery from the authorised destination to an external account, achieving the same outcome while leaving the appearance of an active and healthy logging pipeline intact. Both redirection techniques provide the attacker with ongoing visibility into defensive actions, incident response activities, and newly deployed resources, enabling adaptive evasion throughout a prolonged campaign. Unit 42 assesses redirection as high-likelihood given the low operational overhead involved; the required permissions are frequently granted to developer and DevOps identities whose access is not subject to the same scrutiny applied to dedicated security roles, making them viable without administrator-level compromise.