Azure Service Principal Sign-In Followed by Arc Cluster Credential Access
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.
Query · eql
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
Investigation fields
Pivot points the source recommends for triage.
@timestampazure.signinlogs.properties.app_idazure.signinlogs.properties.app_display_nameazure.signinlogs.properties.service_principal_nameazure.signinlogs.categoryazure.activitylogs.operation_nameazure.activitylogs.identity.claims.appidazure.resource.idsource.ipsource.geo.country_namesource.geo.city_namesource.as.organization.name
Known 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.
Analyst notes
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.