Can Native Cloud Security Tools Defend Your Kubernetes Environment?

Cymulate Threat Research Uncovers Low Detection Rates for Native Cloud Security Controls

The use of Kubernetes as the container orchestration system for deploying critical applications and workloads in cloud containers has gained mainstream adoption, with Kubernetes standing alone as the de facto standard across enterprises. 

But this adoption has also captured the interest of threat actors who are turning to the cloud as the next frontier to conduct their illicit activity. And, as more and more critical business applications and workloads migrate to the cloud, the volume of these attacks will continue to rise from threat actors across the globe.

Kubernetes Security Validation: Cymulate Puts Cloud Security Tools to the Test for Azure, AWS, and GCP

The popularity of Kubernetes and the increased use of K8 clusters has prompted the Cymulate Threat Research Group to conduct a comprehensive security validation test of the native cloud security tools that are made available by the three leading cloud infrastructure service providers: Microsoft Azure, Amazon AWS, and the Google Cloud Platform (or GCP). 

The goal of this research project was to validate that the standard cloud native security tools can detect the type of malicious activity that the threat intel community sees when a K8 cluster is under attack. The native cloud security tools that were validated for this research project included standard deployments (no customization) of:

• Azure Cloud Defender

• AWS GuardDuty

• Google Command Center 

The Cymulate research team established a Kubernetes K8 cluster in each of the cloud providers (Azure, AWS, GCP) which included their native cloud security tools listed above. 

Next, they created assessment templates within the Cymulate platform for each environment (Kubernetes – Azure, Kubernetes – AWS, Kubernetes – GCP) and developed a comprehensive suite of 29 test scenarios (or testing protocols) used to validate that these security tools (or controls) can defend a Kubernetes environment.  

The test scenarios represent the type of threat activity commonly used by threat actors to gain access to a cloud-hosted Kubernetes cluster and manipulate and move around containers, performing privileged actions within the cluster as part of their malicious actions. 

The tests used are aligned to the initial 7 phases of the MITRE ATT&CK® Matrix for Enterprise, including: initial access, execution, persistence, privilege escalation, defense evasion, credential access, and discovery. 

We stopped the assessment at the discovery phase, because once a threat actor reaches this point in the kill-chain (discovery), they can easily proceed with lateral movement, collection, exfiltration, and final impact on a Kubernetes environment. 

Native Cloud Security Tools – Low Detection Rates

After the execution of the Kubernetes assessments in our lab environment, the Cymulate research team analyzed the results across all three cloud service providers security tools and discovered some interesting, and even concerning results. 

On average, more than half (57%) of the simulation attack scenarios carried out by Cymulate, were Not Detected by the native security tools across all cloud providers combined. 

With detection rates ranging from 66% detections for Azure Cloud Defender, 38% for AWS GuardDuty, and 24% for GCP Command Center, we realized that anyone who is relying on the standard native cloud security tools above as their sole defense mechanism for their Kubernetes environment, is leaving themselves exposed to the risk of a cloud data breach. 

And while some tools performed better than others, there is work to be done to better protect business critical applications and workloads running in a K8 cluster.  

In addition to the detection rates, the research team also looked at the prevention rates with comparable results. The team decided to report on the detection rate given the stealth nature of threat actors conducting this type of malicious activity. Threat actors are looking to establish persistence, escalate privileges and evade defense mechanisms as they move about the nodes in the cluster undetected. It is critical for security operations teams to be alerted to this type of activity through detections so they can investigate potential threat activity. 

Even if the security tools prevented the action, without detections we would not even know that malicious actions are taking place. The absence of detection does not imply the absence of an attack and leads to a false sense of security. 

Countless Kubernetes Clusters Could Be at Risk

For any organization relying solely on a standard deployment of either Azure Cloud Defender or AWS GuardDuty or GCP Command Center, your K8 clusters could be at risk. Threat actors have been known to establish persistence and remain undetected in Kubernetes environment for weeks and months on end, evading detection and moving through your cluster to exfiltrate your data, consume your cloud resources, or disrupt your critical applications and workloads. 

Many cloud data breaches and disruptions are the result of common misconfigurations and over-provisioning of access rights. We have seen recent examples of Kubernetes attacks including:

1. An RBAC (role-based access control) Backdoor attack that took advantage of a misconfigured K8 API server that allowed unauthenticated requests from anonymous users to gain information about the K8 cluster.

2. The SCARLETEEL attacks which exploited a vulnerable public-facing service within the K8 cluster to establish persistence, exfiltrate data, and steal credentials once inside the pod.

3. DERO and MONERO crypto miner attacks that took advantage of K8 clusters with anonymous access enabled, to elevate privileges and deploy crypto mining operations that consume extensive cloud resources. 

Cymulate Recommendations to Better Protect Kubernetes Clusters

We believe that having your K8 clusters KO’d by a threat actor is NOT OK. Here are our recommendations to help you better protect your Kubernetes environment:

• Employ a multi-layered security approach including network segmentation, role-based access controls, and runtime security with more advanced monitoring tools and techniques to identify unusual patterns, signaling potential cloud breaches.

• Manage permissions using principle of least privilege to prevent unauthorized access to containers in a K8 cluster.

• Configure additional detection rules in native cloud security tools for undetected activity discovered through testing.

• Consider additional third-party tools for more advanced monitoring and detection of misconfigurations and privileged actions.

• Simulate Kubernetes-based attacks to validate detection gaps in your Kubernetes environment.

• Execute frequent automated testing and validation of K8 clusters to identify any drift over time away from an acceptable level of risk based on the criticality of the applications and workloads running in the Kubernetes environment.

For users of the Cymulate platform with a Kubernetes environment, we recommend running weekly validation tests against Kubernetes clusters. This permits your organization to safely simulate threat activity and observe the results; and this confirms where your controls are acting as expected and where changes are required to defend your Kubernetes environment.

Key Takeaways

Given the widespread adoption of Kubernetes as the de facto standard for container orchestration, and the growing number of threat actors looking to exploit cloud environments, we must increase our efforts to secure K8 clusters from being KO’d by a threat actor.

The detailed findings in our Kubernetes Research Report highlight the need for additional rules and tools if we are to stand a chance of defending business critical applications and workloads running in a Kubernetes environment.

While the major cloud providers offer robust and evolving security solutions, the fast-paced and intricate world of Kubernetes requires a more flexible and dedicated approach. The result of our research creates a call to action from organizations, cloud providers, and the security community at large to become more resilient when using Kubernetes.