Defenders should look for a single identity or source IP performing ListSecrets across 10 or more distinct project IDs in a short lookback interval. This behavior is rarely seen from human users and is typically reserved for automated CSPM tooling, security scanners, or inventory jobs. Distinguishing malicious enumeration from authorized automation requires correlating the identity, source IP, and user-agent string against known enterprise tooling and change management records.

Impact

Successful reconnaissance via Secret Manager enumeration facilitates targeted attacks against production workloads. If an adversary discovers secrets in specific projects, they may attempt to access sensitive configuration data, database credentials, or API keys, leading to potential data exfiltration or environment-wide compromise. The broad scope of this discovery technique allows attackers to map an entire cloud footprint efficiently.

Recommendation

• Enable DATA_READ audit logging for the Google Cloud Secret Manager API to ensure ListSecrets events are captured in the environment's audit logs.
• Deploy detection logic to alert on any principal performing ListSecrets across 10 or more distinct GCP projects within a 5-minute interval.
• Establish an allowlist of authorized security scanners, CSPM services, and CI/CD service accounts to reduce noise in the alerting pipeline.
• Audit IAM policies to enforce the principle of least privilege, ensuring human users and service accounts possess only the permissions required for their specific projects rather than broad, cross-project listing capabilities.
• Investigate event.outcome fields to identify failed permission probing, which often precedes successful enumeration.