Azure Service Principal Sign-In Followed by Arc Cluster Credential Access
Detects when a service principal authenticates to Microsoft Entra ID and then lists credentials for an Azure
Arc-connected Kubernetes cluster within a short time window. The listClusterUserCredential action retrieves tokens
that enable kubectl access through the Arc Cluster Connect proxy. This sequence (service principal sign-in followed by
Arc credential retrieval), represents the exact attack chain used by adversaries with stolen service principal secrets
to establish a proxy tunnel into Kubernetes clusters. Service principals that authenticate externally (as opposed to
managed identities) and immediately access Arc cluster credentials warrant investigation, particularly when the sign-in
originates from an unexpected location or ASN.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2026/03/10"
3integration = ["azure"]
4maturity = "production"
5updated_date = "2026/04/10"
6
7[rule]
8author = ["Elastic"]
9description = """
10Detects when a service principal authenticates to Microsoft Entra ID and then lists credentials for an Azure
11Arc-connected Kubernetes cluster within a short time window. The `listClusterUserCredential` action retrieves tokens
12that enable kubectl access through the Arc Cluster Connect proxy. This sequence (service principal sign-in followed by
13Arc credential retrieval), represents the exact attack chain used by adversaries with stolen service principal secrets
14to establish a proxy tunnel into Kubernetes clusters. Service principals that authenticate externally (as opposed to
15managed identities) and immediately access Arc cluster credentials warrant investigation, particularly when the sign-in
16originates from an unexpected location or ASN.
17"""
18false_positives = [
19 """
20 CI/CD pipelines that authenticate as a service principal and then access Arc clusters as part of deployment
21 workflows will trigger this rule. Identify and exclude known automation service principal app IDs.
22 """,
23 """
24 Administrators using service principal credentials to manage Arc-connected clusters during maintenance windows may
25 trigger this rule. Correlate with change management records.
26 """,
27]
28from = "now-30m"
29index = ["logs-azure.signinlogs-*", "logs-azure.activitylogs-*"]
30interval = "15m"
31language = "eql"
32license = "Elastic License v2"
33name = "Azure Service Principal Sign-In Followed by Arc Cluster Credential Access"
34note = """## Triage and analysis
35
36### Investigating Azure Service Principal Sign-In Followed by Arc Cluster Credential Access
37
38This rule detects the complete attack entry point for Arc-proxied Kubernetes attacks: a service principal authenticates
39to Azure AD, then immediately retrieves Arc cluster credentials. This is the prerequisite sequence before any
40Kubernetes-level activity can occur through the Arc proxy.
41
42### Possible investigation steps
43
44- Identify the service principal using the `app_id` from the sign-in event and resolve it in Azure AD — is this a
45 known application?
46- Check the sign-in source IP and geolocation — does it match expected infrastructure locations for this SP?
47- Review when the SP credentials were last rotated — stale credentials are more likely compromised.
48- Check the ASN of the sign-in source — is it from a known cloud provider, corporate network, or unexpected consumer ISP?
49- Examine Azure Activity Logs after the credential listing for any Arc-proxied operations (secret/configmap CRUD).
50- Correlate with Kubernetes audit logs for operations by the Arc proxy service account
51 (`system:serviceaccount:azure-arc:azure-arc-kube-aad-proxy-sa`) in the same time window.
52- Review Azure AD Audit Logs for recent changes to this SP (new credentials, federated identities, owner changes).
53
54### Response and remediation
55
56- Immediately rotate the service principal credentials (secrets and certificates).
57- Revoke active sessions and tokens for the SP.
58- Review and remove any unauthorized Azure role assignments on Arc-connected clusters.
59- Check Kubernetes audit logs for any operations performed through the Arc proxy after credential access.
60- Rotate any Kubernetes secrets that may have been accessed through the proxy tunnel.
61- Enable conditional access policies to restrict service principal authentication by location if supported.
62"""
63references = [
64 "https://learn.microsoft.com/en-us/azure/azure-arc/kubernetes/cluster-connect",
65 "https://learn.microsoft.com/en-us/cli/azure/connectedk8s#az-connectedk8s-proxy",
66 "https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-ins",
67 "https://www.ibm.com/think/x-force/identifying-abusing-azure-arc-for-hybrid-escalation-persistence",
68 "https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/",
69]
70risk_score = 47
71rule_id = "dacfbecd-7927-46a7-a8ba-feb65a2e990d"
72severity = "medium"
73tags = [
74 "Domain: Cloud",
75 "Domain: Identity",
76 "Data Source: Azure",
77 "Data Source: Azure Arc",
78 "Data Source: Microsoft Entra ID",
79 "Data Source: Microsoft Entra ID Sign-In Logs",
80 "Use Case: Threat Detection",
81 "Tactic: Credential Access",
82 "Tactic: Initial Access",
83 "Resources: Investigation Guide",
84]
85timestamp_override = "event.ingested"
86type = "eql"
87
88query = '''
89sequence with maxspan=30m
90[authentication where data_stream.dataset == "azure.signinlogs"
91 and azure.signinlogs.category == "ServicePrincipalSignInLogs"
92 and azure.signinlogs.properties.status.error_code == 0
93] by azure.signinlogs.properties.app_id
94[any where data_stream.dataset == "azure.activitylogs"
95 and azure.activitylogs.operation_name : "MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/LISTCLUSTERUSERCREDENTIAL/ACTION"
96 and event.outcome : ("Success", "success")
97] by azure.activitylogs.identity.claims.appid
98'''
99
100
101[[rule.threat]]
102framework = "MITRE ATT&CK"
103
104[[rule.threat.technique]]
105id = "T1528"
106name = "Steal Application Access Token"
107reference = "https://attack.mitre.org/techniques/T1528/"
108
109[[rule.threat.technique]]
110id = "T1552"
111name = "Unsecured Credentials"
112reference = "https://attack.mitre.org/techniques/T1552/"
113
114[[rule.threat.technique.subtechnique]]
115id = "T1552.007"
116name = "Container API"
117reference = "https://attack.mitre.org/techniques/T1552/007/"
118
119[rule.threat.tactic]
120id = "TA0006"
121name = "Credential Access"
122reference = "https://attack.mitre.org/tactics/TA0006/"
123
124[[rule.threat]]
125framework = "MITRE ATT&CK"
126
127[[rule.threat.technique]]
128id = "T1078"
129name = "Valid Accounts"
130reference = "https://attack.mitre.org/techniques/T1078/"
131
132[[rule.threat.technique.subtechnique]]
133id = "T1078.004"
134name = "Cloud Accounts"
135reference = "https://attack.mitre.org/techniques/T1078/004/"
136
137[rule.threat.tactic]
138id = "TA0001"
139name = "Initial Access"
140reference = "https://attack.mitre.org/tactics/TA0001/"
141[rule.investigation_fields]
142field_names = [
143 "@timestamp",
144 "azure.signinlogs.properties.app_id",
145 "azure.signinlogs.properties.app_display_name",
146 "azure.signinlogs.properties.service_principal_name",
147 "azure.signinlogs.category",
148 "azure.activitylogs.operation_name",
149 "azure.activitylogs.identity.claims.appid",
150 "azure.resource.id",
151 "source.ip",
152 "source.geo.country_name",
153 "source.geo.city_name",
154 "source.as.organization.name",
155]
Triage and analysis
Investigating Azure Service Principal Sign-In Followed by Arc Cluster Credential Access
This rule detects the complete attack entry point for Arc-proxied Kubernetes attacks: a service principal authenticates to Azure AD, then immediately retrieves Arc cluster credentials. This is the prerequisite sequence before any Kubernetes-level activity can occur through the Arc proxy.
Possible investigation steps
- Identify the service principal using the
app_idfrom the sign-in event and resolve it in Azure AD — is this a known application? - Check the sign-in source IP and geolocation — does it match expected infrastructure locations for this SP?
- Review when the SP credentials were last rotated — stale credentials are more likely compromised.
- Check the ASN of the sign-in source — is it from a known cloud provider, corporate network, or unexpected consumer ISP?
- Examine Azure Activity Logs after the credential listing for any Arc-proxied operations (secret/configmap CRUD).
- Correlate with Kubernetes audit logs for operations by the Arc proxy service account
(
system:serviceaccount:azure-arc:azure-arc-kube-aad-proxy-sa) in the same time window. - Review Azure AD Audit Logs for recent changes to this SP (new credentials, federated identities, owner changes).
Response and remediation
- Immediately rotate the service principal credentials (secrets and certificates).
- Revoke active sessions and tokens for the SP.
- Review and remove any unauthorized Azure role assignments on Arc-connected clusters.
- Check Kubernetes audit logs for any operations performed through the Arc proxy after credential access.
- Rotate any Kubernetes secrets that may have been accessed through the proxy tunnel.
- Enable conditional access policies to restrict service principal authentication by location if supported.
References
Related rules
- Entra ID OAuth Authorization Code Grant for Unusual User, App, and Resource
- Entra ID OAuth PRT Issuance to Non-Managed Device Detected
- Entra ID OAuth User Impersonation to Microsoft Graph
- Entra ID OAuth user_impersonation Scope for Unusual User and Client
- Entra ID Service Principal with Unusual Source ASN