Cross-Environment Secret Harvesting via Cloud APIs
Adversaries are utilizing compromised credentials and stolen session tokens to perform rapid, automated secret harvesting across AWS, GCP, Azure, and Kubernetes environments from singular source IP addresses.
Adversaries are increasingly employing cross-cloud secret harvesting techniques to maximize the impact of compromised identity tokens. By leveraging stolen session data, attackers target secret management services including AWS Secrets Manager, Google Secret Manager, Azure Key Vault, and Kubernetes Secrets. This activity is characterized by rapid, programmatic access to these APIs across multiple cloud provider boundaries from a single source IP address, often within a very short timeframe.
This pattern is highly anomalous and strongly indicates credential theft, session hijacking, or automated token replay attacks. Security teams should be particularly concerned when a single principal or IP address exhibits behavior that bridges distinct cloud platforms, as this suggests a sophisticated effort to gain broad, persistent access or to exfiltrate sensitive environment variables, connection strings, and administrative credentials required for lateral movement. The detection of this behavior is critical for identifying potential supply chain compromises or full-scale cloud environment takeovers.
Attack Chain
- Initial access is gained through phishing, malware, or session token theft to acquire valid cloud or Kubernetes identity credentials.
- The attacker initializes an automated script or tool configured to interface with multiple cloud provider SDKs using the stolen credentials.
- The attacker systematically queries the AWS Secrets Manager API (GetSecretValue) for high-value secrets.
- The same source IP immediately pivots to query Google Secret Manager (AccessSecretVersion).
- Simultaneously, the attacker hits the Azure Key Vault API (SecretGet/KeyGet) to harvest additional platform-specific credentials.
- The attacker targets the Kubernetes API server within the environment to list and retrieve internal cluster secrets (verb: list/get).
- All stolen secrets are exfiltrated to an attacker-controlled listener or stored locally for subsequent lateral movement.
- The final objective is achieved by using the aggregated secrets to expand access across the entire multi-cloud estate.
Impact
Successful exploitation allows attackers to bypass perimeter security, gain persistent access to sensitive databases and infrastructure, and potentially compromise the entire cloud-native supply chain. This results in wide-scale data exfiltration, the loss of administrative control over cloud resources, and the compromise of downstream systems that rely on the stored secrets.
Recommendation
- Enable and aggregate logs for AWS CloudTrail, Azure Key Vault Diagnostic Logging, and Google Cloud Data Access (DATA_READ for Secret Manager) to ensure visibility into secret retrieval attempts.
- Implement automated alerting for cross-provider secret access as defined in the provided ESQL detection logic.
- Audit identity and access management policies to enforce least privilege, ensuring that service accounts and workload identities are strictly scoped to their required cloud environments.
- Deploy MFA for all cloud console and API access where possible to mitigate the impact of stolen session tokens.
- Review Kubernetes RBAC roles and cluster namespaces to restrict access to sensitive secret objects to authorized pods only.
Immediate actions
Enable required audit logging for Secret Manager APIs across AWS, Azure, and GCP.
Threat Hunt
Search for single source IPs accessing secrets in more than one cloud provider within a 5-minute window.
Data: AWS CloudTrail, Azure Platform Logs, GCP Audit Logs, Kubernetes Audit Logs