Multiple Cloud Secrets Accessed by Source Address
This rule detects authenticated sessions accessing secret stores across multiple environments from the same source address within a short period of time, including cloud providers (AWS, GCP, Azure) and Kubernetes clusters. Adversaries with access to compromised credentials or session tokens may attempt to retrieve secrets from services such as AWS Secrets Manager, Google Secret Manager, Azure Key Vault, or Kubernetes Secrets in rapid succession to expand their access or exfiltrate sensitive information.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2025/12/01"
3integration = ["aws", "gcp", "azure", "kubernetes"]
4maturity = "production"
5updated_date = "2026/09/18"
6
7[rule]
8author = ["Elastic"]
9description = """
10This rule detects authenticated sessions accessing secret stores across multiple environments from the same source
11address within a short period of time, including cloud providers (AWS, GCP, Azure) and Kubernetes clusters.
12Adversaries with access to compromised credentials or session tokens may attempt to retrieve secrets from services such
13as AWS Secrets Manager, Google Secret Manager, Azure Key Vault, or Kubernetes Secrets in rapid succession to expand
14their access or exfiltrate sensitive information.
15"""
16from = "now-9m"
17interval = "5m"
18language = "esql"
19license = "Elastic License v2"
20name = "Multiple Cloud Secrets Accessed by Source Address"
21note = """## Triage and analysis
22
23### Multiple Cloud Secrets Accessed by Source Address
24
25This alert identifies a single source IP address accessing secret-management APIs across **multiple cloud providers**
26(e.g., AWS Secrets Manager, Google Secret Manager, Azure Key Vault) within a short timeframe.
27This behavior is strongly associated with **credential theft, session hijacking, or token replay**, where an adversary
28uses stolen authenticated sessions to harvest secrets across cloud environments.
29
30Unexpected cross-cloud secret retrieval is uncommon and typically indicates automation misuse or malicious activity.
31
32### Possible investigation steps
33
34- Validate the principal
35 - Identify the user, service account, workload identity, or application making the requests.
36 - Confirm whether this identity is expected to operate across more than one cloud provider.
37- Review related activity
38 - Look for additional alerts involving the same identity, source IP, or token over the last 24–48 hours.
39 - Identify whether the source IP has been observed performing unusual authentication, privilege escalation,
40 or reconnaissance.
41- Check application or service context
42 - Determine whether any workload legitimately pulls secrets from multiple cloud providers.
43 - Review deployment pipelines or integration layers that might legitimately bridge AWS, Azure, and GCP.
44- Analyze user agent and invocation patterns
45 - Compare `user_agent.original` or equivalent fields against expected SDKs or automation tools.
46 - Suspicious indicators include CLI tools, unknown libraries, browser user agents, or custom scripts.
47- Inspect IP reputation and origin
48 - Determine whether the source IP corresponds to a managed workload (EC2, GCE, Azure VM) or an unexpected host.
49 - Validate that the associated instance or host is under your control and behaving normally.
50- Review IAM permissions and accessed secrets
51 - Check the policies attached to the identity.
52 - Verify whether the accessed secrets are sensitive, unused, or unrelated to the identity’s purpose.
53- Assess potential compromise scope
54 - If compromise is suspected, enumerate other assets accessed by the same identity in the last 24 hours.
55 - Look for lateral movement, privilege escalation, or abnormal API usage.
56- Review Kubernetes activity
57 - Identify the Kubernetes user, service account, or workload performing the secret access.
58 - Determine whether the access originated from a pod, node, or external client.
59 - Validate whether the identity is expected to access secrets in the affected namespaces.
60 - Investigate whether the activity corresponds to application behavior or manual/API access.
61
62### False positive analysis
63
64- Validate whether the source IP is associated with a legitimate multi-cloud orchestration tool, automation pipeline,
65 or shared CI/CD system.
66- Confirm that the identity is authorized to access secrets across multiple cloud services.
67- If activity is expected, consider adding exceptions that pair account identity, source IP, and expected user agent
68 to reduce noise.
69- Determine whether the source IP is associated with Kubernetes nodes, controllers, or internal workloads
70 that legitimately retrieve secrets alongside cloud provider integrations.
71
72### Response and remediation
73
74- Initiate incident response** if the activity is unauthorized or suspicious.
75- Restrict or disable** the affected credentials or service accounts.
76- Rotate all accessed secrets** and review other secrets the identity can access.
77- Analyze systems** that may have leaked credentials, such as compromised hosts or exposed tokens.
78- Harden identity security:
79 - Enforce MFA for users where applicable.
80 - Reduce permissions to least privilege.
81 - Review trust relationships, workload identities, and cross-cloud integrations.
82- Search for persistence mechanisms** such as newly created keys, roles, or service accounts.
83- If Kubernetes access is involved:
84 - Rotate Kubernetes secrets and service account tokens.
85 - Review RBAC permissions and restrict secret access to least privilege.
86 - Inspect affected pods or nodes for compromise.
87- Improve monitoring and audit visibility** by ensuring logging is enabled across all cloud environments.
88- Determine root cause** (phishing, malware, token replay, exposed credential, etc.) and close the vector to prevent recurrence.
89"""
90references = [
91 "https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html",
92 "https://docs.cloud.google.com/secret-manager/docs/samples/secretmanager-access-secret-version",
93 "https://learn.microsoft.com/en-us/azure/key-vault/secrets/about-secrets",
94 "https://www.wiz.io/blog/shai-hulud-2-0-ongoing-supply-chain-attack",
95]
96risk_score = 73
97rule_id = "472b4944-d810-43cf-83dc-7d080ae1b8dd"
98setup = """
99This multi-datasource rule relies on additional configurations from each hyperscaler.
100
101- GCP Audit: [Enable DATA_READ for the Secret Manager API service](https://docs.cloud.google.com/logging/docs/audit/configure-data-access)
102- Azure: [Enable Diagnostic Logging for the Key Vault Service](https://learn.microsoft.com/en-us/azure/key-vault/general/howto-logging?tabs=azure-cli)
103- AWS: Secrets Manager read access is automatically logged by CloudTrail.
104"""
105severity = "high"
106tags = [
107 "Domain: Cloud",
108 "Domain: IAM",
109 "Domain: Storage",
110 "Data Source: AWS",
111 "Data Source: Amazon Web Services",
112 "Data Source: AWS Secrets Manager",
113 "Data Source: Azure",
114 "Data Source: Azure Activity Logs",
115 "Data Source: GCP",
116 "Data Source: Google Cloud Platform",
117 "Data Source: Kubernetes",
118 "Tactic: Credential Access",
119 "Resources: Investigation Guide",
120 "Noise: Low",
121 "Performance: Fast",
122 "Profile: Recommended",
123 "Rule Type: ES|QL",
124 "Platform: AWS",
125 "Platform: Azure",
126 "Platform: Kubernetes",
127 "Platform: GCP",
128 "Domain: Containers",
129 "Domain: Identity",
130 "Service: AWS Secrets Manager",
131 "Data Source: Azure Platform Logs",
132 "Service: Azure Key Vault",
133 "Service: GCP Secret Manager",
134]
135timestamp_override = "event.ingested"
136type = "esql"
137
138query = '''
139FROM logs-azure.platformlogs-*, logs-aws.cloudtrail-*, logs-gcp.audit-*, logs-kubernetes.audit_logs-* METADATA _id, _version, _index
140| WHERE
141 (
142 /* AWS Secrets Manager */
143 (data_stream.dataset == "aws.cloudtrail" AND event.action == "GetSecretValue") OR
144
145 // Azure Key Vault (platform logs)
146 (data_stream.dataset == "azure.platformlogs" AND event.action IN ("SecretGet", "KeyGet")) or
147
148 /* Google Secret Manager */
149 (data_stream.dataset IN ("googlecloud.audit", "gcp.audit") AND
150 event.action IN ("google.cloud.secretmanager.v1.SecretManagerService.AccessSecretVersion", "google.cloud.secretmanager.v1.SecretManagerService.GetSecretRequest")) OR
151
152 /* Kubernetes Secrets */
153 (data_stream.dataset == "kubernetes.audit_logs" AND kubernetes.audit.objectRef.resource == "secrets" AND kubernetes.audit.verb IN ("get", "list"))
154
155 ) AND source.ip IS NOT NULL
156
157// Cloud vendor label based on dataset
158| EVAL Esql.cloud_vendor = CASE(
159 data_stream.dataset == "aws.cloudtrail", "aws",
160 data_stream.dataset == "azure.platformlogs", "azure",
161 data_stream.dataset IN ("googlecloud.audit","gcp.audit"), "gcp",
162 data_stream.dataset == "kubernetes.audit_logs", "k8s",
163 "unknown"
164 )
165// Vendor+tenant label, e.g. aws:123456789012, azure:tenant, gcp:project
166| EVAL Esql.tenant_label = CASE(
167 Esql.cloud_vendor == "aws", CONCAT("aws:", cloud.account.id),
168 Esql.cloud_vendor == "azure", CONCAT("azure:", cloud.account.id),
169 Esql.cloud_vendor == "gcp", CONCAT("gcp:", cloud.account.id),
170 Esql.cloud_vendor == "k8s", CONCAT("k8s:", orchestrator.cluster.name),
171 "unknown"
172 )
173| WHERE Esql.cloud_vendor != "unknown"
174| STATS
175 // Core counts
176 Esql.events_count = COUNT(*),
177 Esql.vendor_count_distinct = COUNT_DISTINCT(Esql.cloud_vendor),
178 // Action & data source context
179 Esql.event_action_values = VALUES(event.action),
180 Esql.data_source_values = VALUES(data_stream.dataset),
181 // Cloud vendor + tenant context
182 Esql.cloud_vendor_values = VALUES(Esql.cloud_vendor),
183 Esql.tenant_label_values = VALUES(Esql.tenant_label),
184 // Hyperscaler-specific IDs
185 Esql.aws_account_id_values = VALUES(CASE(Esql.cloud_vendor == "aws", cloud.account.id, "unknown")),
186 Esql.azure_tenant_id_values = VALUES(CASE(Esql.cloud_vendor == "azure", cloud.account.id, "unknown")),
187 Esql.gcp_project_id_values = VALUES(CASE(Esql.cloud_vendor == "gcp", cloud.account.id, "unknown")),
188 // Generic cloud metadata
189 Esql.cloud_region_values = VALUES(cloud.region),
190 Esql.k8s_namespace_values = VALUES(kubernetes.audit.objectRef.namespace),
191 // Namespace values
192 Esql.data_stream_namespace_values = VALUES(data_stream.namespace),
193 Esql_priv.user_name_values = VALUES(user.name)
194 BY source.ip
195// Require multi-vendor cred-access from same source IP
196| WHERE Esql.vendor_count_distinct >= 2
197| SORT Esql.events_count DESC
198| KEEP Esql.*, Esql_priv.*, source.ip
199'''
200
201
202
203[[rule.threat]]
204framework = "MITRE ATT&CK"
205[[rule.threat.technique]]
206id = "T1555"
207name = "Credentials from Password Stores"
208reference = "https://attack.mitre.org/techniques/T1555/"
209[[rule.threat.technique.subtechnique]]
210id = "T1555.006"
211name = "Cloud Secrets Management Stores"
212reference = "https://attack.mitre.org/techniques/T1555/006/"
213
214
215
216[rule.threat.tactic]
217id = "TA0006"
218name = "Credential Access"
219reference = "https://attack.mitre.org/tactics/TA0006/"
Triage and analysis
Multiple Cloud Secrets Accessed by Source Address
This alert identifies a single source IP address accessing secret-management APIs across multiple cloud providers (e.g., AWS Secrets Manager, Google Secret Manager, Azure Key Vault) within a short timeframe. This behavior is strongly associated with credential theft, session hijacking, or token replay, where an adversary uses stolen authenticated sessions to harvest secrets across cloud environments.
Unexpected cross-cloud secret retrieval is uncommon and typically indicates automation misuse or malicious activity.
Possible investigation steps
- Validate the principal
- Identify the user, service account, workload identity, or application making the requests.
- Confirm whether this identity is expected to operate across more than one cloud provider.
- Review related activity
- Look for additional alerts involving the same identity, source IP, or token over the last 24–48 hours.
- Identify whether the source IP has been observed performing unusual authentication, privilege escalation, or reconnaissance.
- Check application or service context
- Determine whether any workload legitimately pulls secrets from multiple cloud providers.
- Review deployment pipelines or integration layers that might legitimately bridge AWS, Azure, and GCP.
- Analyze user agent and invocation patterns
- Compare
user_agent.originalor equivalent fields against expected SDKs or automation tools. - Suspicious indicators include CLI tools, unknown libraries, browser user agents, or custom scripts.
- Compare
- Inspect IP reputation and origin
- Determine whether the source IP corresponds to a managed workload (EC2, GCE, Azure VM) or an unexpected host.
- Validate that the associated instance or host is under your control and behaving normally.
- Review IAM permissions and accessed secrets
- Check the policies attached to the identity.
- Verify whether the accessed secrets are sensitive, unused, or unrelated to the identity’s purpose.
- Assess potential compromise scope
- If compromise is suspected, enumerate other assets accessed by the same identity in the last 24 hours.
- Look for lateral movement, privilege escalation, or abnormal API usage.
- Review Kubernetes activity
- Identify the Kubernetes user, service account, or workload performing the secret access.
- Determine whether the access originated from a pod, node, or external client.
- Validate whether the identity is expected to access secrets in the affected namespaces.
- Investigate whether the activity corresponds to application behavior or manual/API access.
False positive analysis
- Validate whether the source IP is associated with a legitimate multi-cloud orchestration tool, automation pipeline, or shared CI/CD system.
- Confirm that the identity is authorized to access secrets across multiple cloud services.
- If activity is expected, consider adding exceptions that pair account identity, source IP, and expected user agent to reduce noise.
- Determine whether the source IP is associated with Kubernetes nodes, controllers, or internal workloads that legitimately retrieve secrets alongside cloud provider integrations.
Response and remediation
- Initiate incident response** if the activity is unauthorized or suspicious.
- Restrict or disable** the affected credentials or service accounts.
- Rotate all accessed secrets** and review other secrets the identity can access.
- Analyze systems** that may have leaked credentials, such as compromised hosts or exposed tokens.
- Harden identity security:
- Enforce MFA for users where applicable.
- Reduce permissions to least privilege.
- Review trust relationships, workload identities, and cross-cloud integrations.
- Search for persistence mechanisms** such as newly created keys, roles, or service accounts.
- If Kubernetes access is involved:
- Rotate Kubernetes secrets and service account tokens.
- Review RBAC permissions and restrict secret access to least privilege.
- Inspect affected pods or nodes for compromise.
- Improve monitoring and audit visibility** by ensuring logging is enabled across all cloud environments.
- Determine root cause** (phishing, malware, token replay, exposed credential, etc.) and close the vector to prevent recurrence.
References
Related rules
- Azure Key Vault Excessive Secret or Key Retrieved
- GKE Rapid Secret GET Activity Against Multiple Objects
- GKE Secret get or list with Suspicious User Agent
- GKE Secrets List from Unusual Source AS Organization
- AWS Bedrock AgentCore Runtime Prompt Containing Credentials