<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Azure-Arc — CraftedSignal Threat Feed</title><link>https://feed.craftedsignal.io/tags/azure-arc/</link><description>Trending threats, MITRE ATT&amp;CK coverage, and detection metadata — refreshed continuously.</description><generator>Hugo</generator><language>en</language><managingEditor>hello@craftedsignal.io</managingEditor><webMaster>hello@craftedsignal.io</webMaster><lastBuildDate>Fri, 10 Apr 2026 16:27:52 +0000</lastBuildDate><atom:link href="https://feed.craftedsignal.io/tags/azure-arc/feed.xml" rel="self" type="application/rss+xml"/><item><title>Azure Service Principal Sign-In Followed by Arc Cluster Credential Access</title><link>https://feed.craftedsignal.io/briefs/2024-11-24-azure-arc-credential-access/</link><pubDate>Fri, 10 Apr 2026 16:27:52 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2024-11-24-azure-arc-credential-access/</guid><description>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.</description><content:encoded><![CDATA[<p>This 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 <code>listClusterUserCredential</code> 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.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li><strong>Initial Compromise:</strong> An attacker gains unauthorized access to a service principal&rsquo;s credentials (e.g., through credential stuffing, phishing, or exposed secrets).</li>
<li><strong>Service Principal Authentication:</strong> The attacker uses the compromised service principal credentials to authenticate to Microsoft Entra ID (Azure AD) using the <code>ServicePrincipalSignInLogs</code>.</li>
<li><strong>Credential Listing Request:</strong> 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 <code>MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/LISTCLUSTERUSERCREDENTIAL/ACTION</code> in the Activity Logs.</li>
<li><strong>Credential Retrieval:</strong> The attacker retrieves the Arc cluster credentials.</li>
<li><strong>Proxy Tunnel Establishment:</strong> The attacker uses the retrieved credentials to establish a proxy tunnel into the Kubernetes cluster via the Arc Cluster Connect proxy.</li>
<li><strong>Kubernetes Access:</strong> 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.</li>
<li><strong>Lateral Movement &amp; Privilege Escalation:</strong> The attacker exploits vulnerabilities or misconfigurations within the Kubernetes cluster to move laterally to other resources, escalate privileges, and gain further control.</li>
<li><strong>Data Exfiltration or Ransomware Deployment:</strong> The attacker exfiltrates sensitive data from the Kubernetes cluster or deploys ransomware to encrypt critical data, impacting business operations.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>Successful 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.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Deploy 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.</li>
<li>Review 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&rsquo;s note.</li>
<li>Enable conditional access policies to restrict service principal authentication by location to prevent logins from unexpected regions, as suggested in the rule&rsquo;s note.</li>
<li>Monitor Azure Activity Logs for <code>MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/LISTCLUSTERUSERCREDENTIAL/ACTION</code> events to identify potential unauthorized access attempts.</li>
<li>Rotate service principal credentials regularly and revoke active sessions and tokens for the SP as outlined in the rule&rsquo;s response and remediation steps.</li>
</ul>
]]></content:encoded><category domain="severity">medium</category><category domain="type">threat</category><category>azure</category><category>azure-arc</category><category>credential-access</category><category>initial-access</category></item><item><title>Azure Service Principal Sign-In Followed by Arc Cluster Credential Access</title><link>https://feed.craftedsignal.io/briefs/2024-01-02-azure-arc-credential-access/</link><pubDate>Tue, 17 Mar 2026 15:06:47 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2024-01-02-azure-arc-credential-access/</guid><description>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.</description><content:encoded><![CDATA[<p>This 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 <code>listClusterUserCredential</code> action retrieves tokens enabling <code>kubectl</code> 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.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>The attacker compromises or obtains valid credentials for an Azure Service Principal.</li>
<li>The attacker authenticates to Microsoft Entra ID using the compromised service principal credentials, generating a ServicePrincipalSignInLogs event in Azure.</li>
<li>The attacker attempts to list cluster user credentials for a connected Kubernetes cluster using the compromised service principal. This generates an Azure Activity Log event: <code>MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/LISTCLUSTERUSERCREDENTIAL/ACTION</code>.</li>
<li>If successful, the <code>listClusterUserCredential</code> action provides the attacker with tokens to access the Kubernetes cluster through the Arc Cluster Connect proxy.</li>
<li>The attacker uses the acquired credentials to interact with the Kubernetes cluster via <code>kubectl</code> proxied through Azure Arc.</li>
<li>The attacker performs reconnaissance within the Kubernetes cluster to identify valuable targets.</li>
<li>The attacker attempts to create, read, update, or delete (CRUD) sensitive Kubernetes resources, such as secrets or configmaps.</li>
<li>The attacker may attempt to escalate privileges within the cluster or pivot to other resources within the Azure environment.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>Compromise 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&rsquo;s objectives and the compromised environment.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Deploy the provided Sigma rule to your SIEM to detect the described attack chain, tuning the <code>maxspan</code> value based on observed authentication patterns and network latency.</li>
<li>Investigate 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).</li>
<li>Implement regular rotation of service principal credentials and enforce multi-factor authentication where possible (refer to Microsoft Entra ID documentation).</li>
<li>Review and restrict Azure role assignments for service principals on Arc-connected clusters to minimize potential impact from compromised credentials (refer to Azure RBAC documentation).</li>
<li>Enable 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).</li>
</ul>
]]></content:encoded><category domain="severity">medium</category><category domain="type">advisory</category><category>azure</category><category>azure-arc</category><category>credential-access</category><category>initial-access</category></item></channel></rss>