GCP - Logging Enum
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
This service allows users to store, search, analyze, monitor, and alert on log data and events from GCP.
Cloud Logging is fully integrated with other GCP services, providing a centralized repository for logs from all your GCP resources. It automatically collects logs from various GCP services like App Engine, Compute Engine, and Cloud Functions. You can also use Cloud Logging for applications running on-premises or in other clouds by using the Cloud Logging agent or API.
Key Features:
Log Data Centralization: Aggregate log data from various sources, offering a holistic view of your applications and infrastructure.
Real-time Log Management: Stream logs in real time for immediate analysis and response.
Powerful Data Analysis: Use advanced filtering and search capabilities to sift through large volumes of log data quickly.
Integration with BigQuery: Export logs to BigQuery for detailed analysis and querying.
Log-based Metrics: Create custom metrics from your log data for monitoring and alerting.
Basically the sinks and log based metrics will device where a log should be stored.
Cloud Logging is highly configurable to suit diverse operational needs:
Log Buckets (Logs storage in the web): Define buckets in Cloud Logging to manage log retention, providing control over how long your log entries are retained.
By default the buckets _Default
and _Required
are created (one is logging what the other isn’t).
_Required is:
Retention period of the data is configured per bucket and must be at least 1 day. However the retention period of _Required is 400 days and cannot be modified.
Note that Log Buckets are not visible in Cloud Storage.
Log Sinks (Log router in the web): Create sinks to export log entries to various destinations such as Pub/Sub, BigQuery, or Cloud Storage based on a filter.
By default sinks for the buckets _Default
and _Required
are created:
Exclusion Filters: It's possible to set up exclusions to prevent specific log entries from being ingested, saving costs, and reducing unnecessary noise.
Log-based Metrics: Configure custom metrics based on the content of logs, allowing for alerting and monitoring based on log data.
Log views: Log views give advanced and granular control over who has access to the logs within your log buckets.
Cloud Logging automatically creates the _AllLogs
view for every bucket, which shows all logs. Cloud Logging also creates a view for the _Default
bucket called _Default
. The _Default
view for the _Default
bucket shows all logs except Data Access audit logs. The _AllLogs
and _Default
views are not editable.
It's possible to allow a principal only to use a specific Log view with an IAM policy like:
By default Admin Write operations (also called Admin Activity audit logs) are the ones logged (write metadata or configuration information) and can't be disabled.
Then, the user can enable Data Access audit logs, these are Admin Read, Data Write and Data Write.
You can find more info about each type of log in the docs: https://cloud.google.com/iam/docs/audit-logging
However, note that this means that by default GetIamPolicy
actions and other read actions are not being logged. So, by default an attacker trying to enumerate the environment won't be caught if the sysadmin didn't configure to generate more logs.
To enable more logs in the console the sysadmin needs to go to https://console.cloud.google.com/iam-admin/audit and enable them. There are 2 different options:
Default Configuration: It's possible to create a default configuration and log all the Admin Read and/or Data Read and/or Data Write logs and even add exempted principals:
Select the services: Or just select the services you would like to generate logs and the type of logs and the excepted principal for that specific service.
Also note that by default only those logs are being generated because generating more logs will increase the costs.
The gcloud
command-line tool is an integral part of the GCP ecosystem, allowing you to manage your resources and services. Here's how you can use gcloud
to manage your logging configurations and access logs.
Example to check the logs of cloudresourcemanager
(the one used to BF permissions): https://console.cloud.google.com/logs/query;query=protoPayload.serviceName%3D%22cloudresourcemanager.googleapis.com%22;summaryFields=:false:32:beginning;cursorTimestamp=2024-01-20T00:07:14.482809Z;startTime=2024-01-01T11:12:26.062Z;endTime=2024-02-02T17:12:26.062Z?authuser=2&project=digital-bonfire-410512
There aren't logs of testIamPermissions
:
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)