Attackers Abuse AWS CloudTrail, Google Cloud Logging to Evade Detection
Key Takeaways Threat actors are actively manipulating or exfiltrating cloud logging data from AWS CloudTrail and Google Cloud Logging to evade detection. These attack methods target the very systems...
Key Takeaways
- Threat actors are actively manipulating or exfiltrating cloud logging data from AWS CloudTrail and Google Cloud Logging to evade detection.
- These attack methods target the very systems designed for security visibility, effectively blinding organizations to malicious activity.
- Attackers employ tactics like stopping logs, deleting storage, manipulating encryption keys, poisoning log files, and rerouting logs to external infrastructure.
- The compromise of logging services can severely impact SIEM, SOAR, and CSPM tools, allowing attackers to escalate privileges and access sensitive data undetected.
- Mitigation strategies involve strict permission controls, leveraging immutable log features, and enabling integrity validation for cloud logs.
As enterprises increasingly migrate their operations to cloud environments, the security of these infrastructures has become paramount. A critical component of cloud security involves robust logging and monitoring services, which are now being actively targeted and weaponized by threat actors to obscure their activities and maintain persistent access.
Table Of Content
Logging services, which meticulously record every action within a cloud account, are no longer just a defensive tool. They have become a key objective for adversaries. When these vital records are compromised, either through tampering or redirection, security teams lose their primary means of understanding and responding to incidents within their cloud infrastructure.
AWS CloudTrail and Google Cloud Logging stand out as two of the most widely adopted services in this domain. Both platforms are engineered to provide organizations with a comprehensive overview of cloud activity, meticulously tracking API calls, resource alterations, and user actions in real time. However, this extensive visibility also renders them highly attractive targets for attackers.
An adversary who successfully interferes with these logging mechanisms can operate stealthily, erase any trace of their presence, or covertly monitor a victim’s activities without triggering alerts. This allows for prolonged dwell times and more extensive damage.
Researchers from Unit 42 have meticulously documented these sophisticated attack techniques in a report shared with Cyber Security News (CSN). Their findings detail two primary categories of attacks against cloud logging: defense evasion and continuous visibility.
Defense evasion involves methods where attackers disable or corrupt logs to avoid detection. Continuous visibility, conversely, focuses on redirecting logs to attacker-controlled infrastructure, enabling silent, long-term surveillance of a victim’s cloud environment.
The implications of such compromises are far-reaching. Security tools like Security Information and Event Management (SIEM) platforms, Security Orchestration, Automation, and Response (SOAR) systems, and Cloud Security Posture Management (CSPM) products all rely heavily on accurate and uninterrupted log data. If this data is missing, altered, or rerouted, these critical tools become effectively blind. Operating within this “blind spot,” attackers can methodically escalate privileges, access sensitive data, and exfiltrate information, often facing minimal resistance from unsuspecting security teams.
Hackers Abuse AWS CloudTrail and Google Cloud Logging
Defense evasion, specifically targeting cloud logging, manifests in several ways. The most straightforward approach involves completely halting the logging process.
Stopping and Deleting Logs
- AWS CloudTrail: An attacker with appropriate permissions can execute the
stop-loggingAPI call on a specific trail, instantly ceasing all log writes to the associated S3 bucket. - Google Cloud Logging: The equivalent action involves disabling a log sink, which prevents log entries from reaching their designated storage.

Beyond simply stopping logs, attackers may also opt to delete the entire storage bucket. In AWS, this requires s3:DeleteBucket and s3:DeleteObject permissions. Google Cloud offers a brief reprieve, as a deleted log bucket enters a DELETE_REQUESTED state for seven days before permanent removal, potentially allowing for recovery if detected promptly.
Encryption Key Manipulation and Log Poisoning
A more subtle tactic involves replacing the encryption key used to protect logs with an attacker-controlled AWS Key Management Service (KMS) key. Subsequently, access to this new key is revoked, rendering the logs unreadable and unwriteable. This effectively corrupts the log data without outright deletion.

Another sophisticated method is log poisoning. Here, an attacker modifies an existing log file to remove evidence of their malicious actions, then re-uploads the doctored file. This invalidates the integrity of the audit trail, making it extremely difficult for security teams to piece together the sequence of events.
Attackers Reroute Logs for Real-Time Spy Access
Advanced attackers often move beyond mere defense evasion, seeking to establish continuous surveillance within a compromised environment. They achieve this by rerouting log data to their own infrastructure.
This is accomplished by either creating a new log routing resource or modifying an existing one, directing all activity logs to storage under their control.
- AWS CloudTrail: Attackers utilize the
create-trailorupdate-trailAPI calls, specifying a custom S3 bucket name that they control. - Google Cloud Logging: The equivalent actions involve using the
logging.sinks.createorlogging.sinks.updateAPI to redirect log streams.
Once established, this redirection provides the attacker with a live, continuous feed of every event occurring within the victim’s cloud account. This includes sensitive information such as IAM changes, resource modifications, and access to critical data, all while remaining completely undetected by the victim organization.
What You Should Do
- Implement Strict Permission Controls: Limit permissions for APIs like AWS
update-trailand Google Cloudlogging.sinks.updateto only the most privileged and necessary users. Regularly audit these permissions. - Secure S3 Bucket Policies: For AWS CloudTrail, configure S3 bucket policies to ensure that only CloudTrail can write to them, preventing unauthorized modifications or deletions.
- Leverage Immutable Logs: Utilize AWS’s 90-day immutable event history and Google Cloud’s built-in
_Requiredlog bucket, which provides an immutable record that cannot be modified or deleted. Ensure these features are properly configured and monitored. - Enable Log File Integrity Validation: Activate CloudTrail log file integrity validation. This feature uses cryptographic hashes to detect any alterations to log files after they have been delivered.
- Monitor for Anomalous Activity: Implement robust monitoring for any changes to logging configurations, such as disabled trails/sinks, modified encryption keys, or log rerouting attempts. Look for unusual API calls related to logging services.
- Regularly Back Up Logs: Beyond cloud-native logging, consider independent, off-site backups of critical log data to ensure a redundant, untampered record exists.
Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.



No Comment! Be the first one.