Azure Arc - CraftedSignal Threat Feedhttps://feed.craftedsignal.io/products/azure-arc/Trending threats, MITRE ATT&CK coverage, and detection metadata. Fed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioWed, 31 Jan 2024 12:00:00 +0000Kubernetes Secret or ConfigMap Access via Azure Arc Proxyhttps://feed.craftedsignal.io/briefs/2024-01-31-azure-arc-proxy-secret-configmap-access/Wed, 31 Jan 2024 12:00:00 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2024-01-31-azure-arc-proxy-secret-configmap-access/Detection of unauthorized access to Kubernetes secrets or configmaps via the Azure Arc AAD proxy service account, indicating potential abuse of stolen service principal credentials to read, exfiltrate, or modify sensitive data.This detection rule identifies suspicious access patterns within Kubernetes clusters connected to Azure Arc. Specifically, it focuses on activity where secrets or configmaps are accessed, created, modified, or deleted, and the Kubernetes audit logs indicate the Azure Arc AAD proxy service account (system:serviceaccount:azure-arc:azure-arc-kube-aad-proxy-sa) as the user. The impersonatedUser field contains the actual caller identity, suggesting operations are being routed through the Azure ARM API, rather than directly via kubectl. While Azure Arc-managed workflows legitimately use this proxy, adversaries with compromised service principal credentials can exploit Arc Cluster Connect. This allows them to read, exfiltrate, or modify secrets and configmaps while masking their activity under the guise of the Arc proxy service account in K8s audit logs. The rule excludes known Arc namespaces and Helm release secrets to reduce false positives.

Attack Chain

  1. An attacker compromises an Azure AD service principal with permissions to interact with the Azure Arc-connected Kubernetes cluster.
  2. The attacker authenticates to Azure using the compromised service principal credentials.
  3. The attacker leverages the Azure ARM API to issue commands targeting the Kubernetes cluster, specifically secrets or configmaps. This might involve using LISTCLUSTERUSERCREDENTIAL to initiate an Arc proxy session.
  4. The Azure Arc Cluster Connect proxy receives the request and impersonates the requesting user.
  5. The proxy service account (system:serviceaccount:azure-arc:azure-arc-kube-aad-proxy-sa) in the Kubernetes cluster executes the requested operation (get, list, create, update, patch, or delete) against secrets or configmaps.
  6. Kubernetes audit logs record the activity, showing the Arc proxy service account as the user and the attacker's identity in the impersonatedUser field.
  7. The attacker potentially retrieves sensitive data from secrets (e.g., database credentials, API keys) or configmaps.
  8. The attacker exfiltrates the retrieved data or uses it to further compromise the Kubernetes cluster or connected resources.

Impact

Successful exploitation allows attackers to gain unauthorized access to sensitive information stored in Kubernetes secrets and configmaps. This can lead to data breaches, lateral movement within the cluster, and further compromise of the overall cloud environment. The impact depends on the data stored in the compromised secrets and configmaps, but it could include exposure of database credentials, API keys, or other sensitive configuration data. Compromised credentials can then be used to access other systems and resources, expanding the scope of the attack.

Recommendation

  • Deploy the Sigma rule Kubernetes Secret or ConfigMap Access via Azure Arc Proxy to your SIEM and tune for your environment.
  • Investigate any alerts generated by the Sigma rule by examining the kubernetes.audit.impersonatedUser.username field to identify the actual caller and correlating with Azure Activity Logs.
  • Regularly review and audit Azure AD service principals with permissions to access Azure Arc-connected Kubernetes clusters.
  • Monitor Azure Sign-In Logs for suspicious authentication activity related to service principals used for Azure Arc management.
  • Consider implementing stricter network segmentation to limit the blast radius of compromised service principals.
]]>mediumadvisorykubernetesazure-arccredential-accesscollectionUnusual Source IP for Azure Arc Cluster Credential Accesshttps://feed.craftedsignal.io/briefs/2024-01-azure-arc-credential-access/Wed, 03 Jan 2024 12:00:00 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2024-01-azure-arc-credential-access/Detects when a service principal or user performs an Azure Arc cluster credential listing operation from a source IP not previously associated with that identity, potentially indicating compromised credentials.This detection identifies anomalous access patterns to Azure Arc-connected Kubernetes clusters. Specifically, it monitors the listClusterUserCredential operation, which provides credentials for the Arc Cluster Connect proxy, enabling kubectl access through the Azure ARM API. An attacker leveraging stolen credentials, such as those belonging to a service principal, may attempt to list cluster credentials from an unfamiliar IP address. The detection leverages a 7-day history to establish baseline IP-to-identity mappings, reducing false positives from legitimate sources like CI/CD pipelines with rotating IPs. This activity is particularly relevant because successful credential access can lead to unauthorized cluster access and potential data exfiltration or resource compromise. The IBM X-Force has identified potential abuse of Azure Arc for hybrid escalation and persistence. The detection logic originates from Elastic's detection rules.

Attack Chain

  1. Attacker compromises a service principal or user account with privileges to manage Azure Arc-connected Kubernetes clusters.
  2. Attacker authenticates to Azure using the compromised credentials.
  3. Attacker invokes the MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/LISTCLUSTERUSERCREDENTIAL/ACTION operation via the Azure API from a new or unusual source IP address.
  4. The operation returns credentials for the Arc Cluster Connect proxy.
  5. Attacker uses the retrieved credentials to establish a proxy tunnel via az connectedk8s proxy.
  6. Attacker routes kubectl commands through the Azure ARM API, accessing the Kubernetes cluster without direct network connectivity.
  7. Attacker performs reconnaissance within the Kubernetes cluster, identifying valuable resources like secrets and configmaps.
  8. Attacker exfiltrates sensitive data or compromises the cluster's integrity.

Impact

A successful attack can lead to unauthorized access to Kubernetes clusters connected to Azure Arc. Compromised credentials can enable attackers to perform arbitrary actions within the cluster, potentially leading to data theft, service disruption, or the deployment of malicious workloads. The severity depends on the privileges associated with the compromised identity and the sensitivity of the data stored within the cluster. Lateral movement from compromised cloud resources to on-premise Kubernetes clusters is possible.

Recommendation

  • Deploy the Sigma rule "Azure Arc Cluster Credential Access from Unusual Source" to your SIEM and tune the history window for your environment.
  • Investigate any alerts generated by the Sigma rule by examining the caller identity (azure.activitylogs.identity.claims.appid), source IP (source.ip), and associated Azure Sign-In Logs.
  • If a compromise is suspected, revoke the service principal credentials and remove Arc RBAC role assignments as detailed in the investigation guide.
  • Monitor Azure Activity Logs for MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/LISTCLUSTERUSERCREDENTIAL/ACTION events, filtering for unexpected source IPs.
  • Review Kubernetes audit logs for suspicious activity following the listClusterUserCredential operation.
]]>mediumadvisoryazureazure-arccredential-access