<?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 Kubernetes Services - CraftedSignal Threat Feed</title><link>https://feed.craftedsignal.io/products/azure-kubernetes-services/</link><description>Trending threats, MITRE ATT&amp;CK coverage, and detection metadata. Fed continuously.</description><generator>Hugo</generator><language>en</language><managingEditor>hello@craftedsignal.io</managingEditor><webMaster>hello@craftedsignal.io</webMaster><lastBuildDate>Tue, 02 Jan 2024 15:00:00 +0000</lastBuildDate><atom:link href="https://feed.craftedsignal.io/products/azure-kubernetes-services/feed.xml" rel="self" type="application/rss+xml"/><item><title>Azure Kubernetes Services (AKS) Kubernetes Rolebindings Created</title><link>https://feed.craftedsignal.io/briefs/2024-01-aks-rolebinding-created/</link><pubDate>Tue, 02 Jan 2024 15:00:00 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2024-01-aks-rolebinding-created/</guid><description>The creation of role binding or cluster role bindings in Azure Kubernetes Services (AKS) can indicate privilege escalation by an adversary creating a binding to the cluster-admin ClusterRole or other high-privilege roles.</description><content:encoded><![CDATA[<p>This detection rule identifies the creation of role binding or cluster role bindings in Azure Kubernetes Services (AKS) by monitoring Azure activity logs for successful creation events. These role bindings assign roles to Kubernetes subjects, like users, groups, or service accounts. An attacker who has permissions to create bindings and cluster-bindings can escalate privileges by creating a binding to the cluster-admin ClusterRole or other high privileges roles. This activity is logged within Azure and can be detected using the Azure Activity Logs. This activity can lead to complete control of the Kubernetes cluster and its resources if a cluster-admin role is bound to a malicious actor.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>The attacker gains initial access to an Azure account with sufficient permissions to interact with AKS and create role bindings.</li>
<li>The attacker enumerates available roles and cluster roles within the AKS cluster.</li>
<li>The attacker identifies high-privilege roles, such as <code>cluster-admin</code>, which would grant extensive control over the cluster.</li>
<li>The attacker creates a new RoleBinding or ClusterRoleBinding, associating the target user/group/service account with the high-privilege role. The Azure activity logs capture this event.</li>
<li>The attacker validates the successful creation of the role binding.</li>
<li>The attacker (or the user/group/service account targeted) leverages the newly granted privileges to perform unauthorized actions within the AKS cluster.</li>
<li>The attacker maintains persistence by using the Valid Account (T1078) to access the cluster.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>Successful exploitation leads to privilege escalation within the AKS cluster, allowing the attacker to perform actions beyond their intended authorization. This can lead to unauthorized access to sensitive data, modification or deletion of critical resources, and potential compromise of the entire Kubernetes environment. While specific victim counts aren't available, the impact is significant for organizations relying on AKS for containerized applications.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Deploy the Sigma rule <code>Detect AKS Role Binding Creation</code> to detect the creation of role bindings in your AKS environment by monitoring Azure Activity Logs.</li>
<li>Review and tighten Role-Based Access Control (RBAC) policies to ensure that only necessary permissions are granted (reference: description).</li>
<li>Investigate any detected role binding creations to validate their legitimacy and identify potential unauthorized privilege escalation attempts (reference: description).</li>
<li>Monitor <code>event.outcome</code> to ensure the operation was successful and not a failed attempt, which might indicate a misconfiguration or testing (reference: description).</li>
</ul>
]]></content:encoded><category domain="severity">low</category><category domain="type">advisory</category><category>cloud</category><category>azure</category><category>kubernetes</category><category>privilege-escalation</category></item><item><title>Azure Kubernetes Services (AKS) Kubernetes Pod Deletion</title><link>https://feed.craftedsignal.io/briefs/2024-01-aks-pod-deletion/</link><pubDate>Tue, 02 Jan 2024 12:00:00 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2024-01-aks-pod-deletion/</guid><description>The deletion of Azure Kubernetes Pods can indicate malicious activity aimed at disrupting the environment's normal behavior.</description><content:encoded><![CDATA[<p>This detection identifies the deletion of Azure Kubernetes Pods, which could indicate malicious activity. Adversaries might delete Kubernetes pods to disrupt services or evade detection. Successful pod deletion operations logged in Azure activity logs are monitored, alerting security teams to potential unauthorized actions impacting environment stability and security. The rule focuses on events logged with the operation name &quot;MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/PODS/DELETE&quot; and a successful outcome. Defenders should be aware of unexpected or unauthorized pod deletions, as these actions can lead to service disruptions and potential data loss. This activity affects Azure Kubernetes Services (AKS) environments.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>An attacker gains unauthorized access to the Azure environment, potentially through compromised credentials or exploiting a vulnerability.</li>
<li>The attacker authenticates to the Azure API and identifies the target Kubernetes cluster and namespace.</li>
<li>The attacker uses stolen credentials to make an authorized API call.</li>
<li>The attacker issues a DELETE request targeting specific pods within the Kubernetes cluster, using the &quot;MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/PODS/DELETE&quot; operation.</li>
<li>Azure processes the deletion request, and if authorized, removes the specified pods from the cluster.</li>
<li>The event is logged in Azure Activity Logs with an &quot;Success&quot; outcome.</li>
<li>Legitimate applications or services that rely on the deleted pods experience disruption or failure.</li>
<li>The attacker achieves their objective, which may include disrupting services, causing data loss, or hindering incident response efforts.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>Successful pod deletions can lead to service disruptions, application failures, and potential data loss within the Azure Kubernetes Services (AKS) environment. The severity depends on the criticality of the affected pods and the applications they support. A successful attack could impact the availability of customer-facing services, internal business processes, or critical infrastructure components. Undetected malicious pod deletions can also complicate incident response efforts and prolong the time it takes to restore normal operations.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Deploy the Sigma rule <code>Azure Kubernetes Pod Deletion</code> to your SIEM and tune for your environment to detect malicious or accidental pod deletions in your Azure environment.</li>
<li>Review Azure activity logs for events matching the <code>MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/PODS/DELETE</code> operation name to identify potential pod deletion incidents.</li>
<li>Implement stricter access controls and role-based access management to minimize the risk of unauthorized pod deletions.</li>
<li>Integrate monitoring and alerting with a SIEM system to detect and respond to unauthorized pod deletions promptly (refer to the setup instructions in the overview).</li>
</ul>
]]></content:encoded><category domain="severity">medium</category><category domain="type">advisory</category><category>azure</category><category>kubernetes</category><category>impact</category><category>cloud</category></item></channel></rss>