Azure Service Principal Sign-In Followed by Arc Cluster Credential Access
editAzure Service Principal Sign-In Followed by Arc Cluster Credential Access
editDetects 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.
Rule type: eql
Rule indices:
- logs-azure.signinlogs-*
- logs-azure.activitylogs-*
Severity: medium
Risk score: 47
Runs every: 15m
Searches indices from: now-30m (Date Math format, see also Additional look-back time)
Maximum alerts per execution: 100
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:
- 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
Version: 1
Rule authors:
- Elastic
Rule license: Elastic License v2
Investigation guide
editTriage 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.
Rule query
editsequence with maxspan=30m
[authentication where event.dataset == "azure.signinlogs"
and azure.signinlogs.category == "ServicePrincipalSignInLogs"
and azure.signinlogs.properties.status.error_code == 0
] by azure.signinlogs.properties.app_id
[any where event.dataset == "azure.activitylogs"
and azure.activitylogs.operation_name : "MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/LISTCLUSTERUSERCREDENTIAL/ACTION"
and event.outcome : ("Success", "success")
] by azure.activitylogs.identity.claims.appid
Framework: MITRE ATT&CKTM
-
Tactic:
- Name: Credential Access
- ID: TA0006
- Reference URL: https://attack.mitre.org/tactics/TA0006/
-
Technique:
- Name: Unsecured Credentials
- ID: T1552
- Reference URL: https://attack.mitre.org/techniques/T1552/
-
Sub-technique:
- Name: Container API
- ID: T1552.007
- Reference URL: https://attack.mitre.org/techniques/T1552/007/
-
Tactic:
- Name: Initial Access
- ID: TA0001
- Reference URL: https://attack.mitre.org/tactics/TA0001/
-
Technique:
- Name: Valid Accounts
- ID: T1078
- Reference URL: https://attack.mitre.org/techniques/T1078/
-
Sub-technique:
- Name: Cloud Accounts
- ID: T1078.004
- Reference URL: https://attack.mitre.org/techniques/T1078/004/