Kubernetes Secret or ConfigMap Access via Azure Arc Proxy
Detects when secrets or configmaps are accessed, created, modified, or deleted in a Kubernetes cluster by the Azure Arc
AAD proxy service account. When operations are routed through the Azure Arc Cluster Connect proxy, the Kubernetes audit
log records the acting user as system:serviceaccount:azure-arc:azure-arc-kube-aad-proxy-sa with the actual caller
identity in the impersonatedUser field. This pattern indicates that someone is accessing the cluster through the Azure
ARM API rather than directly via kubectl against the API server. While legitimate for Arc-managed workflows, adversaries
with stolen service principal credentials can abuse Arc Cluster Connect to read, exfiltrate, or modify secrets and
configmaps while appearing as the Arc proxy service account in K8s audit logs.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2026/03/10"
3integration = ["kubernetes"]
4maturity = "production"
5updated_date = "2026/03/24"
6
7[rule]
8author = ["Elastic"]
9description = """
10Detects when secrets or configmaps are accessed, created, modified, or deleted in a Kubernetes cluster by the Azure Arc
11AAD proxy service account. When operations are routed through the Azure Arc Cluster Connect proxy, the Kubernetes audit
12log records the acting user as `system:serviceaccount:azure-arc:azure-arc-kube-aad-proxy-sa` with the actual caller
13identity in the `impersonatedUser` field. This pattern indicates that someone is accessing the cluster through the Azure
14ARM API rather than directly via kubectl against the API server. While legitimate for Arc-managed workflows, adversaries
15with stolen service principal credentials can abuse Arc Cluster Connect to read, exfiltrate, or modify secrets and
16configmaps while appearing as the Arc proxy service account in K8s audit logs.
17"""
18false_positives = [
19 """
20 Azure Arc system components may create or update secrets and configmaps in the azure-arc and azure-arc-release
21 namespaces during normal cluster management. Filter by namespace to exclude these.
22 """,
23 """
24 Helm operations managed through Arc may create release secrets (prefixed with sh.helm.release.v1). These are normal
25 Arc lifecycle operations.
26 """,
27]
28from = "now-5d"
29interval = "9m"
30language = "esql"
31license = "Elastic License v2"
32name = "Kubernetes Secret or ConfigMap Access via Azure Arc Proxy"
33note = """## Triage and analysis
34
35### Investigating Kubernetes Secret or ConfigMap Access via Azure Arc Proxy
36
37When Kubernetes operations are performed through Azure Arc Cluster Connect, the K8s audit log shows the Arc AAD proxy
38service account as the authenticated user, with the actual Azure AD identity in the `impersonatedUser` field. This
39rule detects non-system secret and configmap access — including reads, writes, and deletions — routed through this
40proxy path. Read operations (`get`, `list`) are particularly important to detect as they represent the most common
41adversary action: exfiltrating secrets without leaving obvious modification traces.
42
43### Possible investigation steps
44
45- Check the `kubernetes.audit.impersonatedUser.username` field — this contains the Azure AD object ID of the actual
46 caller. Cross-reference with Azure AD to identify the service principal or user.
47- Review the `kubernetes.audit.impersonatedUser.extra.oid` field for the Azure AD object ID.
48- Examine the namespace — operations in `default` or application namespaces are more suspicious than `azure-arc` or
49 `kube-system`.
50- Check the `kubernetes.audit.objectRef.name` — look for suspicious secret/configmap names that don't match known
51 application resources.
52- Correlate with Azure Activity Logs for the same time window to find the `LISTCLUSTERUSERCREDENTIAL` operation that
53 initiated the Arc proxy session.
54- Review Azure Sign-In Logs for the impersonated identity's authentication source IP and geolocation.
55
56### Response and remediation
57
58- If the impersonated identity is not recognized, revoke its Azure AD credentials immediately.
59- Remove the ClusterRoleBinding or RoleBinding that grants the identity access to secrets/configmaps.
60- Rotate any Kubernetes secrets that may have been read or exfiltrated.
61- Review the Arc connection and consider disconnecting it if compromised.
62"""
63references = [
64 "https://learn.microsoft.com/en-us/azure/azure-arc/kubernetes/cluster-connect",
65 "https://microsoft.github.io/Threat-Matrix-for-Kubernetes/",
66 "https://www.ibm.com/think/x-force/identifying-abusing-azure-arc-for-hybrid-escalation-persistence",
67 "https://cloud.google.com/blog/topics/threat-intelligence/escalating-privileges-azure-kubernetes-services",
68 "https://www.wiz.io/blog/lateral-movement-risks-in-the-cloud-and-how-to-prevent-them-part-3-from-compromis",
69]
70risk_score = 47
71rule_id = "220d92c6-479d-4a49-9cc0-3a29756dad0c"
72severity = "medium"
73tags = [
74 "Data Source: Kubernetes",
75 "Domain: Kubernetes",
76 "Domain: Cloud",
77 "Use Case: Threat Detection",
78 "Tactic: Credential Access",
79 "Tactic: Collection",
80 "Resources: Investigation Guide",
81]
82timestamp_override = "event.ingested"
83type = "esql"
84
85query = '''
86FROM logs-kubernetes.audit_logs-* metadata _id, _version, _index
87| WHERE STARTS_WITH(kubernetes.audit.user.username, "system:serviceaccount:azure-arc:")
88 AND kubernetes.audit.objectRef.resource IN ("secrets", "configmaps")
89 AND kubernetes.audit.verb IN ("get", "list", "create", "update", "patch", "delete")
90 AND kubernetes.audit.objectRef.namespace NOT IN ("azure-arc", "azure-arc-release", "kube-system")
91 AND NOT STARTS_WITH(kubernetes.audit.objectRef.name, "sh.helm.release.v1")
92
93| STATS
94 Esql.verb_values = VALUES(kubernetes.audit.verb),
95 Esql.resource_type_values = VALUES(kubernetes.audit.objectRef.resource),
96 Esql.resource_name_values = VALUES(kubernetes.audit.objectRef.name),
97 Esql.namespace_values = VALUES(kubernetes.audit.objectRef.namespace),
98 Esql.acting_user_values = VALUES(kubernetes.audit.user.username),
99 Esql.user_agent_values = VALUES(kubernetes.audit.userAgent),
100 Esql.source_ips_values = VALUES(kubernetes.audit.sourceIPs),
101 Esql.response_code_values = VALUES(kubernetes.audit.responseStatus.code),
102 Esql.timestamp_first_seen = MIN(@timestamp),
103 Esql.timestamp_last_seen = MAX(@timestamp),
104 Esql.event_count = COUNT(*)
105 BY kubernetes.audit.impersonatedUser.username
106
107| WHERE Esql.timestamp_first_seen >= NOW() - 9 minutes
108| KEEP *
109'''
110
111
112[[rule.threat]]
113framework = "MITRE ATT&CK"
114
115[[rule.threat.technique]]
116id = "T1552"
117name = "Unsecured Credentials"
118reference = "https://attack.mitre.org/techniques/T1552/"
119
120[[rule.threat.technique.subtechnique]]
121id = "T1552.007"
122name = "Container API"
123reference = "https://attack.mitre.org/techniques/T1552/007/"
124
125[rule.threat.tactic]
126id = "TA0006"
127name = "Credential Access"
128reference = "https://attack.mitre.org/tactics/TA0006/"
129
130[[rule.threat]]
131framework = "MITRE ATT&CK"
132
133[[rule.threat.technique]]
134id = "T1213"
135name = "Data from Information Repositories"
136reference = "https://attack.mitre.org/techniques/T1213/"
137
138[[rule.threat.technique]]
139id = "T1530"
140name = "Data from Cloud Storage"
141reference = "https://attack.mitre.org/techniques/T1530/"
142
143[rule.threat.tactic]
144id = "TA0009"
145name = "Collection"
146reference = "https://attack.mitre.org/tactics/TA0009/"
147
148[[rule.threat]]
149framework = "MITRE ATT&CK"
150
151[[rule.threat.technique]]
152id = "T1565"
153name = "Data Manipulation"
154reference = "https://attack.mitre.org/techniques/T1565/"
155
156[[rule.threat.technique.subtechnique]]
157id = "T1565.001"
158name = "Stored Data Manipulation"
159reference = "https://attack.mitre.org/techniques/T1565/001/"
160
161[rule.threat.tactic]
162id = "TA0040"
163name = "Impact"
164reference = "https://attack.mitre.org/tactics/TA0040/"
Triage and analysis
Investigating Kubernetes Secret or ConfigMap Access via Azure Arc Proxy
When Kubernetes operations are performed through Azure Arc Cluster Connect, the K8s audit log shows the Arc AAD proxy
service account as the authenticated user, with the actual Azure AD identity in the impersonatedUser field. This
rule detects non-system secret and configmap access — including reads, writes, and deletions — routed through this
proxy path. Read operations (get, list) are particularly important to detect as they represent the most common
adversary action: exfiltrating secrets without leaving obvious modification traces.
Possible investigation steps
- Check the
kubernetes.audit.impersonatedUser.usernamefield — this contains the Azure AD object ID of the actual caller. Cross-reference with Azure AD to identify the service principal or user. - Review the
kubernetes.audit.impersonatedUser.extra.oidfield for the Azure AD object ID. - Examine the namespace — operations in
defaultor application namespaces are more suspicious thanazure-arcorkube-system. - Check the
kubernetes.audit.objectRef.name— look for suspicious secret/configmap names that don't match known application resources. - Correlate with Azure Activity Logs for the same time window to find the
LISTCLUSTERUSERCREDENTIALoperation that initiated the Arc proxy session. - Review Azure Sign-In Logs for the impersonated identity's authentication source IP and geolocation.
Response and remediation
- If the impersonated identity is not recognized, revoke its Azure AD credentials immediately.
- Remove the ClusterRoleBinding or RoleBinding that grants the identity access to secrets/configmaps.
- Rotate any Kubernetes secrets that may have been read or exfiltrated.
- Review the Arc connection and consider disconnecting it if compromised.
References
Related rules
- Kubernetes Potential Endpoint Permission Enumeration Attempt by Anonymous User Detected
- Kubernetes Service Account Secret Access
- Sensitive File Compression Detected via Defend for Containers
- Sensitive Files Compression
- Sensitive Files Compression Inside A Container