Welcome to our fifth blog post on the Kubernetes threat vectors series.
We are covering different tactics on the Kubernetes attack matrix, published by Microsoft and originally based on the MITRE ATT&CK framework. In this blog post, we will review the Defense Evasion tactic, and cover its techniques.
What is Defense Evasion?
The defense evasion tactic consists of techniques that are used by attackers to avoid detection and stay under the radar by concealing any evidence of their presence.
Let’s review the different techniques:
- Clear container logsThis technique is essentially the act of deleting relevant logs from an application or an operating system, capturing traces of an attacker’s activity.
How to mitigate?
From a Kubernetes perspective, the best way to tackle this technique is to limit or deny completely the host mounts, thus minimizing container access to nodes. This method of mitigation is also used in previously covered tactics such as Persistence and Privilege Escalation.
Another essential way to mitigate this is by using a real-time, automated analysis tool for Kubernetes audit logs. Alcide kAudit does exactly that, by intelligently leveraging these audit logs in runtime. kAudit enables identifying security rules violations, abnormal administrative activity, and anomalous Kubernetes behavior.
- Delete Kubernetes eventsKubernetes events are objects that log any state changes like container creation or an image pull, as well as failures of resources. Deleting these events reduce the risk of detecting security-related activities performed by the attacker.
How to mitigate?
Same as the previous one, this technique should be mitigated by configuring continuous audit logging and preferably exporting it to an external SIEM tool and the likes of it.
Also similarly with previous techniques, an organization should use proper configurations for preventing hostPath mounts, blocking code execution, and limiting permissions for deletion of logs and events.
- Container name similarity
Attackers can leverage the creation of pods with a random suffix in their names.
This enables the attacker to name their backdoor pods as they were created by the existing controllers (Deployment or DaemonSet) and obfuscates the presence of unauthorized pods within a cluster. This can ultimately lead to gaining access to additional resources and executing malicious code.How to mitigate?
The prime area to focus on when mitigating this technique is Role-Based Access Control (RBAC) configurations. These controls should be limited while keeping the principle of least privilege, specifically for the creation of Kubernetes resources like pods.Kubernetes security platforms like Alcide offer aid in protecting against such threats, by providing continuous and progressive monitoring capabilities. These capabilities come in handy with identifying malicious and abnormal activities across all layers in an environment and recognizing illicit activity based on policy-based authorization. In addition, Alcide enables reducing risk and exposure by ensuring that Kubernetes cluster resources don’t have permissions to create or modify pods or containers using the Kubernetes API server.
- Connect from proxy serverProxy servers and anonymous networks such as TOR are often used by attackers to hide their origin IP and initiate communication channels with applications or directly to the API server.
How to mitigate?
The main area to focus on in this case is configurations and controls within the cloud provider. Network access should be restricted with regards to the Kubernetes API server and proper firewall rules should be implemented.
What We Think Is Missing
As we go and cover the different tactics and techniques in the Kubernetes attack matrix, we’re also providing our take on it, and what we think Microsoft has left out, specifically within the Kubernetes domain. In one of our previous blogs – Cloud Native Security for Kubernetes In Practice, we talked about cluster operations threats and risks, and how they are usually associated with either the supply chain (CI/CD pipeline) or the Runtime environment.
With that in mind, we took the liberty to add several noteworthy security elements, that were not found in Microsoft Azure’s original matrix:
Kubernetes relies heavily on DNS as its critical infrastructure for service discovery.
A common practice for establishing covert channels is to exploit inherent weaknesses in the DNS protocol messages exchange. For this reason, it’s important to monitor DNS activity within your Kubernetes cluster to detect and potentially prevent C2 channels from establishing covert channels. Read the full article on Dark Reading magazine – Microsoft’s Kubernetes Threat Matrix: Here’s What’s Missing.
Stay tuned for our next chapter, where we will review the sixth tactic – Credentials Access.
Want to give Alcide a try? Sign up for our 14-day trial to fully experience our platform.