Blinding the Watchmen: Abusing Cloud Logging Services for Defense Evasion and Visibility
Threat actors are increasingly targeting cloud logging services like AWS CloudTrail and Google Cloud Logging to evade detection and maintain persistence. By manipulating log routing, deleting storage destinations, or impairing encryption keys, attackers can blind security operations and operate undetected. Furthermore, attackers can redirect log flows to attacker-controlled infrastructure to gain continuous visibility into the victim's cloud environment.
Detection / HunterGoogle
What Happened
Attackers are tampering with cloud logging systems in Amazon Web Services (AWS) and Google Cloud to hide their tracks and spy on victim environments. By turning off logs, deleting log storage, or messing with encryption keys, hackers can make themselves invisible to security teams. They can also redirect these logs to their own systems to continuously monitor what the victim is doing. Organizations should tightly control who has permission to change logging settings and use built-in features that prevent logs from being altered or deleted.
Key Takeaways
- Attackers target cloud logging services (AWS CloudTrail, GCP Logging) to evade detection and establish continuous visibility into victim environments.
- Defense evasion techniques include stopping logging APIs, deleting storage buckets/routers, impairing encryption keys, and poisoning log files.
- Attackers can achieve continuous visibility by redirecting log sinks or creating new trails that point to attacker-controlled infrastructure.
- Impairing logging via attacker-controlled KMS keys allows adversaries to render logs unreadable without deleting the storage bucket, creating a stealthy visibility gap.
- Organizations must restrict IAM permissions for logging configuration and utilize immutable log storage features like GCP locked buckets and AWS log file integrity validation.
Affected Systems
- AWS CloudTrail
- Amazon S3
- AWS KMS
- Google Cloud Logging
- Google Cloud Storage
Attack Chain
Attackers first gain initial access and escalate privileges to obtain permissions over cloud logging services. They then execute defense evasion techniques such as invoking stop-logging APIs, deleting S3/Cloud Storage buckets, or replacing KMS keys to halt log delivery. Alternatively, they may use update-trail or logging.sinks.update to redirect log flows to attacker-controlled infrastructure. Finally, they leverage this continuous visibility or lack of defender visibility to map the environment, exfiltrate data, and maintain persistence undetected.
Detection Availability
- YARA Rules: No
- Sigma Rules: No
- Snort/Suricata Rules: No
- KQL Queries: No
- Splunk SPL Queries: No
- EQL Queries: No
- Other Detection Logic: No
- Platforms: Cortex XDR
The article mentions that Cortex XDR provides behavioral and static alerting for these techniques, but does not provide the actual query logic or rules.
Detection Engineering Assessment
EDR Visibility: None — The described attacks occur entirely within the cloud provider's control plane (AWS API, GCP API) and do not involve endpoint operating systems. Network Visibility: Low — Cloud API calls are encrypted via HTTPS; network sensors will only see traffic to AWS/GCP endpoints without payload visibility. Detection Difficulty: Moderate — Detecting these actions requires robust monitoring of the logging infrastructure itself. If the attacker successfully disables the logs, the very telemetry needed to detect them is cut off, making alerting on the initial modification critical.
Required Log Sources
- AWS CloudTrail
- Google Cloud Audit Logs
- AWS EventBridge
Hunting Hypotheses
| Hypothesis | Telemetry | ATT&CK Stage | FP Risk |
|---|---|---|---|
| An attacker may attempt to modify the KMS key associated with a CloudTrail or GCP Log Bucket to an external key, followed by revoking access. | AWS CloudTrail (UpdateTrail events) or GCP Audit Logs (logging.buckets.update) | Defense Evasion | Low |
| An attacker may redirect log sinks or trails to an unknown or external storage bucket. | AWS CloudTrail (UpdateTrail, CreateTrail) or GCP Audit Logs (logging.sinks.update, logging.sinks.create) | Collection/Exfiltration | Medium |
| An attacker may attempt to delete log storage destinations to destroy forensic evidence. | AWS CloudTrail (DeleteBucket on logging buckets) or GCP Audit Logs (logging.buckets.delete) | Defense Evasion | Low |
Control Gaps
- Lack of immutable log storage
- Overly permissive IAM roles for logging configuration
- Missing alerts on logging infrastructure changes
Key Behavioral Indicators
- API calls to stop-logging or logging.sinks.update with disabled=true
- Changes to KMS keys on logging buckets
- Creation of new log sinks/trails pointing to external accounts
False Positive Assessment
- Low
Recommendations
Immediate Mitigation
- Verify against your organization's incident response runbook and team escalation paths before acting.
- Review IAM permissions to ensure only highly privileged, authorized users can invoke update-trail, delete-trail, or modify GCP logging sinks.
- Audit current cloud logging configurations to verify that logs are being delivered to the expected, internal storage destinations.
Infrastructure Hardening
- Consider enabling AWS CloudTrail log file integrity validation to cryptographically verify logs have not been tampered with.
- Evaluate implementing GCP bucket locks for logging buckets to make retention policies permanent and irreversible.
- Configure S3 bucket policies to strictly prevent non-admin users from modifying configurations and ensure only the CloudTrail service can write objects.
User Protection
- Enforce MFA for all accounts with administrative access to cloud logging and storage resources.
- Implement least privilege access for cloud engineers, separating logging administration from general cloud administration where possible.
Security Awareness
- Train cloud operations and SOC teams on the importance of monitoring the health and configuration of the logging infrastructure itself.
MITRE ATT&CK Mapping
- T1562.008 - Impair Defenses: Disable or Modify Cloud Logs
- T1537 - Transfer Data to Cloud Account
- T1082 - System Information Discovery
Additional IOCs
- Command Lines:
- Purpose: Modify a Google Cloud logging bucket to use an external, attacker-controlled KMS key for defense evasion. | Tools:
gcloud| Stage: Defense Evasion |gcloud logging buckets update
- Purpose: Modify a Google Cloud logging bucket to use an external, attacker-controlled KMS key for defense evasion. | Tools:
