{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/tags/azure-arc/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":true,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["azure","azure-arc","credential-access","initial-access"],"_cs_type":"threat","_cs_vendors":[],"content_html":"\u003cp\u003eThis detection identifies a specific attack sequence targeting Azure Arc-connected Kubernetes clusters. It focuses on the scenario where a service principal authenticates to Microsoft Entra ID and subsequently requests credentials for an Azure Arc-connected Kubernetes cluster. The \u003ccode\u003elistClusterUserCredential\u003c/code\u003e action is used to retrieve tokens that enable kubectl access through the Arc Cluster Connect proxy. This sequence is particularly concerning when the service principal authenticates externally and immediately accesses Arc cluster credentials, especially from unexpected locations or Autonomous System Numbers (ASNs). This behavior, observed in attacks like those described by IBM X-Force in 2025, can lead to attackers gaining unauthorized access to and control over Kubernetes clusters. Defenders should investigate such events, particularly when the sign-in originates from an unexpected location or ASN.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Compromise:\u003c/strong\u003e An attacker gains unauthorized access to a service principal\u0026rsquo;s credentials (e.g., through credential stuffing, phishing, or exposed secrets).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eService Principal Authentication:\u003c/strong\u003e The attacker uses the compromised service principal credentials to authenticate to Microsoft Entra ID (Azure AD) using the \u003ccode\u003eServicePrincipalSignInLogs\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCredential Listing Request:\u003c/strong\u003e Immediately following successful authentication, the attacker leverages the service principal to initiate a request to list the cluster user credentials for an Azure Arc-connected Kubernetes cluster, triggering the \u003ccode\u003eMICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/LISTCLUSTERUSERCREDENTIAL/ACTION\u003c/code\u003e in the Activity Logs.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCredential Retrieval:\u003c/strong\u003e The attacker retrieves the Arc cluster credentials.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eProxy Tunnel Establishment:\u003c/strong\u003e The attacker uses the retrieved credentials to establish a proxy tunnel into the Kubernetes cluster via the Arc Cluster Connect proxy.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eKubernetes Access:\u003c/strong\u003e With the tunnel established, the attacker can now execute kubectl commands, perform unauthorized actions within the cluster, such as creating, reading, updating, and deleting (CRUD) secrets and configmaps.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement \u0026amp; Privilege Escalation:\u003c/strong\u003e The attacker exploits vulnerabilities or misconfigurations within the Kubernetes cluster to move laterally to other resources, escalate privileges, and gain further control.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration or Ransomware Deployment:\u003c/strong\u003e The attacker exfiltrates sensitive data from the Kubernetes cluster or deploys ransomware to encrypt critical data, impacting business operations.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this attack chain can lead to complete compromise of Azure Arc-connected Kubernetes clusters. Attackers can gain unauthorized access to sensitive data, disrupt critical services, and potentially deploy ransomware. The IBM X-Force team has documented cases of attackers using similar techniques for hybrid escalation and persistence. This can impact organizations across all sectors utilizing Azure Arc for managing Kubernetes clusters, potentially affecting dozens or hundreds of clusters per victim organization.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rules to your SIEM and tune for your environment to detect the sequence of service principal sign-in followed by Arc cluster credential access.\u003c/li\u003e\n\u003cli\u003eReview Azure AD Audit Logs for recent changes to service principals, focusing on new credentials, federated identities, and owner changes, based on the investigation steps outlined in the rule\u0026rsquo;s note.\u003c/li\u003e\n\u003cli\u003eEnable conditional access policies to restrict service principal authentication by location to prevent logins from unexpected regions, as suggested in the rule\u0026rsquo;s note.\u003c/li\u003e\n\u003cli\u003eMonitor Azure Activity Logs for \u003ccode\u003eMICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/LISTCLUSTERUSERCREDENTIAL/ACTION\u003c/code\u003e events to identify potential unauthorized access attempts.\u003c/li\u003e\n\u003cli\u003eRotate service principal credentials regularly and revoke active sessions and tokens for the SP as outlined in the rule\u0026rsquo;s response and remediation steps.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-10T16:27:52Z","date_published":"2026-04-10T16:27:52Z","id":"/briefs/2024-11-24-azure-arc-credential-access/","summary":"Detects a service principal authenticating to Azure AD followed by listing credentials for an Azure Arc-connected Kubernetes cluster, indicating potential adversary activity with stolen service principal secrets to establish a proxy tunnel into Kubernetes clusters.","title":"Azure Service Principal Sign-In Followed by Arc Cluster Credential Access","url":"https://feed.craftedsignal.io/briefs/2024-11-24-azure-arc-credential-access/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["azure","azure-arc","credential-access","initial-access"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis detection rule identifies a specific attack chain targeting Azure Arc-connected Kubernetes clusters. The attack begins with a service principal authenticating to Microsoft Entra ID and immediately requesting credentials for an Azure Arc-connected Kubernetes cluster. This \u003ccode\u003elistClusterUserCredential\u003c/code\u003e action retrieves tokens enabling \u003ccode\u003ekubectl\u003c/code\u003e access via the Arc Cluster Connect proxy. This behavior is indicative of adversaries using stolen service principal secrets to gain unauthorized access and establish a proxy tunnel into Kubernetes environments. The rule prioritizes external service principal authentications (excluding managed identities) followed by Arc cluster credential access, particularly when sign-in origins are from unexpected locations or Autonomous System Numbers (ASNs). This activity was observed in attacks documented by IBM X-Force and Microsoft, as referenced below.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker compromises or obtains valid credentials for an Azure Service Principal.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to Microsoft Entra ID using the compromised service principal credentials, generating a ServicePrincipalSignInLogs event in Azure.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to list cluster user credentials for a connected Kubernetes cluster using the compromised service principal. This generates an Azure Activity Log event: \u003ccode\u003eMICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/LISTCLUSTERUSERCREDENTIAL/ACTION\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eIf successful, the \u003ccode\u003elistClusterUserCredential\u003c/code\u003e action provides the attacker with tokens to access the Kubernetes cluster through the Arc Cluster Connect proxy.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the acquired credentials to interact with the Kubernetes cluster via \u003ccode\u003ekubectl\u003c/code\u003e proxied through Azure Arc.\u003c/li\u003e\n\u003cli\u003eThe attacker performs reconnaissance within the Kubernetes cluster to identify valuable targets.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to create, read, update, or delete (CRUD) sensitive Kubernetes resources, such as secrets or configmaps.\u003c/li\u003e\n\u003cli\u003eThe attacker may attempt to escalate privileges within the cluster or pivot to other resources within the Azure environment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCompromise of service principal credentials and subsequent access to Azure Arc-connected Kubernetes clusters can lead to significant data breaches, service disruption, and unauthorized resource access. Successful exploitation allows attackers to gain control over Kubernetes clusters, potentially leading to lateral movement within the environment, exfiltration of sensitive data, and deployment of malicious workloads. The number of victims and specific sectors targeted vary based on the attacker\u0026rsquo;s objectives and the compromised environment.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect the described attack chain, tuning the \u003ccode\u003emaxspan\u003c/code\u003e value based on observed authentication patterns and network latency.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on unexpected sign-in locations or ASNs for the service principal (refer to the investigation fields in the rule definition).\u003c/li\u003e\n\u003cli\u003eImplement regular rotation of service principal credentials and enforce multi-factor authentication where possible (refer to Microsoft Entra ID documentation).\u003c/li\u003e\n\u003cli\u003eReview and restrict Azure role assignments for service principals on Arc-connected clusters to minimize potential impact from compromised credentials (refer to Azure RBAC documentation).\u003c/li\u003e\n\u003cli\u003eEnable logging for Azure sign-in logs and activity logs to ensure the data sources are available for the detection rule (refer to Azure Monitor documentation).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-03-17T15:06:47Z","date_published":"2026-03-17T15:06:47Z","id":"/briefs/2024-01-02-azure-arc-credential-access/","summary":"Detects a service principal authenticating to Microsoft Entra ID and then listing credentials for an Azure Arc-connected Kubernetes cluster within a short time window, indicating potential unauthorized access to Kubernetes clusters via stolen service principal secrets.","title":"Azure Service Principal Sign-In Followed by Arc Cluster Credential Access","url":"https://feed.craftedsignal.io/briefs/2024-01-02-azure-arc-credential-access/"}],"language":"en","title":"CraftedSignal Threat Feed — Azure-Arc","version":"https://jsonfeed.org/version/1.1"}