Blinding the Watchmen Abusing Cloud Logging Services for Def...

[carlospolop]

🤖 Automated Content Update

This PR was automatically generated by the HackTricks News Bot based on a technical blog post.

📝 Source Information

• Blog URL: https://unit42.paloaltonetworks.com/cloud-logging-defense-evasion
• Blog Title: Blinding the Watchmen: Abusing Cloud Logging Services for Defense Evasion and Visibility
• Suggested Section: Pentesting Cloud -> AWS Pentesting -> AWS - Post Exploitation -> AWS - CloudTrail / Security Logging Defense Evasion; and Pentesting Cloud -> GCP Pentesting -> GCP - Post Exploitation -> GCP - Logging Post Exploitation. Alternatively, add a cross-cloud page under Pentesting Cloud Methodology named Cloud Logging Defense Evasion and Log Exfiltration.

🎯 Content Summary

Unit 42 analyzes how attackers can abuse cloud logging infrastructure itself as an attack surface. The post is not about a CVE or memory corruption vulnerability; it is a set of cloud control-plane abuse techniques against AWS CloudTrail and Google Cloud Logging. The attacker model is an adversary who has already obtained IAM permissions that allow modification of trails, sinks, buckets, objects, or encryption keys. With those permissions, the attacker can blind monitoring, ...

🔧 Technical Details

Disable the log delivery control plane: If an attacker gains permissions to modify logging resources, they can blind detection without touching workloads. In AWS, cloudtrail:StopLogging allows stop-logging against a CloudTrail trail, preventing new events from being written to S3. In Google Cloud, logging.sinks.update allows setting a sink’s disabled field to true, stopping routed log export.

Destroy or disrupt the log storage backend: Cloud logs often depend on object storage. In AWS, deleting a CloudTrail S3 bucket requires s3:DeleteBucket and usually s3:DeleteObject to empty the bucket first. In Google Cloud, logging.buckets.delete places a log bucket into DELETE_REQUESTED state for seven days before deletion. Locked Google Cloud log buckets resist this because retention becomes permanent and the bucket cannot be deleted until all records age ou...

🤖 Agent Actions

I’m using the repository exploration workflow first to find the best existing cloud logging page and avoid duplicating techniques.
Done.

Updated:

• src/pentesting-cloud/pentesting-cloud-methodology.md

Added a new cross-cloud section:

• Cloud Logging Defense Evasion & Log Exfiltration

It covers:

• stopping log delivery
• deleting log routers/destinations
• KMS/CMEK sabotage
• historical log poisoning
• parallel attacker-controlled log exports
• redirecting existing logging pipelines
• concise AWS/GCP defensive details

Validation:

• Confirmed the new section is present
• Confirmed ## References is at the end of the file
• Reviewed the git diff

Note:

• mdbook build could not be executed because mdbook is not installed in this environment.

---

This PR was automatically created by the HackTricks Feed Bot. Please review the changes carefully before merging.

[carlospolop]

🔗 Additional Context

Original Blog Post: https://unit42.paloaltonetworks.com/cloud-logging-defense-evasion

Content Categories: Based on the analysis, this content was categorized under "Pentesting Cloud -> AWS Pentesting -> AWS - Post Exploitation -> AWS - CloudTrail / Security Logging Defense Evasion; and Pentesting Cloud -> GCP Pentesting -> GCP - Post Exploitation -> GCP - Logging Post Exploitation. Alternatively, add a cross-cloud page under Pentesting Cloud Methodology named Cloud Logging Defense Evasion and Log Exfiltration.".

Repository Maintenance:

• MD Files Formatting: 586 files processed

Review Notes:

• This content was automatically processed and may require human review for accuracy
• Check that the placement within the repository structure is appropriate
• Verify that all technical details are correct and up-to-date
• All .md files have been checked for proper formatting (headers, includes, etc.)

Bot Version: HackTricks News Bot v1.0