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.
Detection Query
sequence with maxspan=30m
[authentication where data_stream.dataset == "azure.signinlogs"
and azure.signinlogs.category == "ServicePrincipalSignInLogs"
and azure.signinlogs.properties.status.error_code == 0
] by azure.signinlogs.properties.app_id
[any where data_stream.dataset == "azure.activitylogs"
and azure.activitylogs.operation_name : "MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/LISTCLUSTERUSERCREDENTIAL/ACTION"
and event.outcome : ("Success", "success")
] by azure.activitylogs.identity.claims.appid
Author
Elastic
Created
2026/03/10
Data Sources
References
- https://learn.microsoft.com/en-us/azure/azure-arc/kubernetes/cluster-connect
- https://learn.microsoft.com/en-us/cli/azure/connectedk8s#az-connectedk8s-proxy
- https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-ins
- https://www.ibm.com/think/x-force/identifying-abusing-azure-arc-for-hybrid-escalation-persistence
- https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/
Tags
Raw Content
[metadata]
creation_date = "2026/03/10"
integration = ["azure"]
maturity = "production"
updated_date = "2026/04/10"
[rule]
author = ["Elastic"]
description = """
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.
"""
false_positives = [
"""
CI/CD pipelines that authenticate as a service principal and then access Arc clusters as part of deployment
workflows will trigger this rule. Identify and exclude known automation service principal app IDs.
""",
"""
Administrators using service principal credentials to manage Arc-connected clusters during maintenance windows may
trigger this rule. Correlate with change management records.
""",
]
from = "now-30m"
index = ["logs-azure.signinlogs-*", "logs-azure.activitylogs-*"]
interval = "15m"
language = "eql"
license = "Elastic License v2"
name = "Azure Service Principal Sign-In Followed by Arc Cluster Credential Access"
note = """## 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_id` from 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 = [
"https://learn.microsoft.com/en-us/azure/azure-arc/kubernetes/cluster-connect",
"https://learn.microsoft.com/en-us/cli/azure/connectedk8s#az-connectedk8s-proxy",
"https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-ins",
"https://www.ibm.com/think/x-force/identifying-abusing-azure-arc-for-hybrid-escalation-persistence",
"https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/",
]
risk_score = 47
rule_id = "dacfbecd-7927-46a7-a8ba-feb65a2e990d"
severity = "medium"
tags = [
"Domain: Cloud",
"Domain: Identity",
"Data Source: Azure",
"Data Source: Azure Arc",
"Data Source: Microsoft Entra ID",
"Data Source: Microsoft Entra ID Sign-In Logs",
"Use Case: Threat Detection",
"Tactic: Credential Access",
"Tactic: Initial Access",
"Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
sequence with maxspan=30m
[authentication where data_stream.dataset == "azure.signinlogs"
and azure.signinlogs.category == "ServicePrincipalSignInLogs"
and azure.signinlogs.properties.status.error_code == 0
] by azure.signinlogs.properties.app_id
[any where data_stream.dataset == "azure.activitylogs"
and azure.activitylogs.operation_name : "MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/LISTCLUSTERUSERCREDENTIAL/ACTION"
and event.outcome : ("Success", "success")
] by azure.activitylogs.identity.claims.appid
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1528"
name = "Steal Application Access Token"
reference = "https://attack.mitre.org/techniques/T1528/"
[[rule.threat.technique]]
id = "T1552"
name = "Unsecured Credentials"
reference = "https://attack.mitre.org/techniques/T1552/"
[[rule.threat.technique.subtechnique]]
id = "T1552.007"
name = "Container API"
reference = "https://attack.mitre.org/techniques/T1552/007/"
[rule.threat.tactic]
id = "TA0006"
name = "Credential Access"
reference = "https://attack.mitre.org/tactics/TA0006/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1078"
name = "Valid Accounts"
reference = "https://attack.mitre.org/techniques/T1078/"
[[rule.threat.technique.subtechnique]]
id = "T1078.004"
name = "Cloud Accounts"
reference = "https://attack.mitre.org/techniques/T1078/004/"
[rule.threat.tactic]
id = "TA0001"
name = "Initial Access"
reference = "https://attack.mitre.org/tactics/TA0001/"
[rule.investigation_fields]
field_names = [
"@timestamp",
"azure.signinlogs.properties.app_id",
"azure.signinlogs.properties.app_display_name",
"azure.signinlogs.properties.service_principal_name",
"azure.signinlogs.category",
"azure.activitylogs.operation_name",
"azure.activitylogs.identity.claims.appid",
"azure.resource.id",
"source.ip",
"source.geo.country_name",
"source.geo.city_name",
"source.as.organization.name",
]