Azure Arc Cluster Credential Access by Identity from Unusual Source
Detects when a service principal or user performs an Azure Arc cluster credential listing operation from a source IP not
previously associated with that identity. The listClusterUserCredential action retrieves credentials for the Arc
Cluster Connect proxy, enabling kubectl access through the Azure ARM API. An adversary using stolen service principal
credentials will typically call this operation from infrastructure not previously seen for that SP. By tracking the
combination of caller identity and source IP, this rule avoids false positives from backend services and CI/CD pipelines
that rotate IPs but maintain consistent identity-to-IP patterns over time.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2026/03/10"
3integration = ["azure"]
4maturity = "production"
5updated_date = "2026/03/10"
6
7[rule]
8author = ["Elastic"]
9description = """
10Detects when a service principal or user performs an Azure Arc cluster credential listing operation from a source IP not
11previously associated with that identity. The `listClusterUserCredential` action retrieves credentials for the Arc
12Cluster Connect proxy, enabling kubectl access through the Azure ARM API. An adversary using stolen service principal
13credentials will typically call this operation from infrastructure not previously seen for that SP. By tracking the
14combination of caller identity and source IP, this rule avoids false positives from backend services and CI/CD pipelines
15that rotate IPs but maintain consistent identity-to-IP patterns over time.
16"""
17false_positives = [
18 """
19 A service principal used by a CI/CD pipeline may trigger this rule when the pipeline runs from a new IP range for
20 the first time (e.g., migrating to a new runner pool). The 7-day history window will learn the new IPs after the
21 first occurrence.
22 """,
23 """
24 Administrators accessing Arc clusters from a new VPN endpoint or travel location. Validate the caller identity
25 matches an expected user and correlate with known travel or access patterns.
26 """,
27]
28from = "now-9m"
29index = ["logs-azure.activitylogs-*"]
30language = "kuery"
31license = "Elastic License v2"
32name = "Azure Arc Cluster Credential Access by Identity from Unusual Source"
33note = """## Triage and analysis
34
35### Investigating Azure Arc Cluster Credential Access by Identity from Unusual Source
36
37The `listClusterUserCredential` operation on an Azure Arc-connected cluster returns credentials that allow the caller
38to establish a proxy tunnel via `az connectedk8s proxy`. This proxy routes kubectl commands through the Azure ARM API,
39enabling Kubernetes access without direct network connectivity to the cluster API server.
40
41### Possible investigation steps
42
43- Identify the caller service principal using `azure.activitylogs.identity.claims.appid` and cross-reference with
44 Azure AD to determine if this is a known application.
45- Check the source IP and geolocation — is this from a country or ASN where your organization operates?
46- Correlate with Azure Sign-In Logs around the same time to see the full authentication chain (SP login followed by
47 credential listing).
48- Verify the Azure role used — the `Azure Arc Enabled Kubernetes Cluster User Role` is required for this operation.
49 Was this role recently assigned?
50- Check if subsequent Arc-proxied operations (secret/configmap CRUD) occurred after the credential access.
51- Review the service principal creation date in Azure AD — recently created SPs are more suspicious.
52
53### Response and remediation
54
55- If the source IP is from an unexpected country or the service principal is not recognized, treat as potential
56 credential compromise.
57- Revoke the service principal credentials and remove Arc RBAC role assignments.
58- Review Kubernetes audit logs for any operations performed through the Arc proxy after credential access.
59- Rotate any Kubernetes secrets that may have been accessed.
60"""
61references = [
62 "https://learn.microsoft.com/en-us/azure/azure-arc/kubernetes/cluster-connect",
63 "https://learn.microsoft.com/en-us/cli/azure/connectedk8s#az-connectedk8s-proxy",
64 "https://www.ibm.com/think/x-force/identifying-abusing-azure-arc-for-hybrid-escalation-persistence",
65 "https://nvd.nist.gov/vuln/detail/cve-2022-37968",
66]
67risk_score = 47
68rule_id = "022c37cd-5a4f-422b-8227-b136b7a23180"
69severity = "medium"
70tags = [
71 "Domain: Cloud",
72 "Data Source: Azure",
73 "Data Source: Azure Arc",
74 "Data Source: Azure Activity Logs",
75 "Use Case: Threat Detection",
76 "Tactic: Initial Access",
77 "Tactic: Credential Access",
78 "Resources: Investigation Guide",
79]
80timestamp_override = "event.ingested"
81type = "new_terms"
82
83query = '''
84event.dataset: "azure.activitylogs"
85 and azure.activitylogs.operation_name: "MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/LISTCLUSTERUSERCREDENTIAL/ACTION"
86 and event.outcome: (Success or success)
87'''
88
89
90[[rule.threat]]
91framework = "MITRE ATT&CK"
92[[rule.threat.technique]]
93id = "T1078"
94name = "Valid Accounts"
95reference = "https://attack.mitre.org/techniques/T1078/"
96[[rule.threat.technique.subtechnique]]
97id = "T1078.004"
98name = "Cloud Accounts"
99reference = "https://attack.mitre.org/techniques/T1078/004/"
100
101
102
103[rule.threat.tactic]
104id = "TA0001"
105name = "Initial Access"
106reference = "https://attack.mitre.org/tactics/TA0001/"
107[[rule.threat]]
108framework = "MITRE ATT&CK"
109[[rule.threat.technique]]
110id = "T1552"
111name = "Unsecured Credentials"
112reference = "https://attack.mitre.org/techniques/T1552/"
113[[rule.threat.technique.subtechnique]]
114id = "T1552.007"
115name = "Container API"
116reference = "https://attack.mitre.org/techniques/T1552/007/"
117
118
119
120[rule.threat.tactic]
121id = "TA0006"
122name = "Credential Access"
123reference = "https://attack.mitre.org/tactics/TA0006/"
124
125[rule.investigation_fields]
126field_names = [
127 "@timestamp",
128 "azure.activitylogs.operation_name",
129 "azure.activitylogs.identity.claims.appid",
130 "azure.activitylogs.identity.authorization.evidence.role",
131 "azure.activitylogs.identity.authorization.evidence.principalType",
132 "azure.resource.id",
133 "source.ip",
134 "source.geo.country_name",
135 "source.geo.city_name",
136 "source.as.organization.name",
137]
138
139[rule.new_terms]
140field = "new_terms_fields"
141value = ["azure.activitylogs.identity.claims.appid", "source.ip"]
142[[rule.new_terms.history_window_start]]
143field = "history_window_start"
144value = "now-7d"
Triage and analysis
Investigating Azure Arc Cluster Credential Access by Identity from Unusual Source
The listClusterUserCredential operation on an Azure Arc-connected cluster returns credentials that allow the caller
to establish a proxy tunnel via az connectedk8s proxy. This proxy routes kubectl commands through the Azure ARM API,
enabling Kubernetes access without direct network connectivity to the cluster API server.
Possible investigation steps
- Identify the caller service principal using
azure.activitylogs.identity.claims.appidand cross-reference with Azure AD to determine if this is a known application. - Check the source IP and geolocation — is this from a country or ASN where your organization operates?
- Correlate with Azure Sign-In Logs around the same time to see the full authentication chain (SP login followed by credential listing).
- Verify the Azure role used — the
Azure Arc Enabled Kubernetes Cluster User Roleis required for this operation. Was this role recently assigned? - Check if subsequent Arc-proxied operations (secret/configmap CRUD) occurred after the credential access.
- Review the service principal creation date in Azure AD — recently created SPs are more suspicious.
Response and remediation
- If the source IP is from an unexpected country or the service principal is not recognized, treat as potential credential compromise.
- Revoke the service principal credentials and remove Arc RBAC role assignments.
- Review Kubernetes audit logs for any operations performed through the Arc proxy after credential access.
- Rotate any Kubernetes secrets that may have been accessed.
References
Related rules
- Azure Service Principal Sign-In Followed by Arc Cluster Credential Access
- Entra ID OAuth Authorization Code Grant for Unusual User, App, and Resource
- Azure Storage Account Keys Accessed by Privileged User
- Azure Service Principal Authentication from Multiple Countries
- Multiple Cloud Secrets Accessed by Source Address