Protecting Kubernetes Against MITRE ATT&CK: Defense Evasion

The fifth installment in our nine-part blog series – where we examine each of the nine MITRE ATT&CK tactics and techniques for Kubernetes – covers Defense Evasion, a grouping of techniques focused on concealing adversary actions intended to avoid detection. This includes tactics such as deleting evidence of an attacker’s presence or obfuscating how access to a resource was gained. You can find the first four articles in the series below:

• Part one - Initial Access
• Part two - Execution
• Part three - Persistence
• Part four - Privilege Escalation
• Part six - Credential Access
• Part seven - Discovery
• Part eight - Lateral Movement
• Part nine - Impact

StackRox helps mitigate these Defense Evasion threats by monitoring all pods, including those not created by using a Kubernetes controller, and identifying standalone pods directly in the StackRox user interface.

Technique 5.1: Clear container logs

Issue

With this technique, an attacker may delete logs from the container runtime or operating system that capture the attacker’s activity within containers.

Best Practice for Mitigation

Primary areas to configure security controls: Kubernetes, Cloud Provider, and Other - container runtime and operating system

Kubernetes

Within Kubernetes, organizations can mitigate this threat by minimizing container access to nodes by restricting host mounts (also see Techniques 3.2 “Writable hostPath mount” and 4.3 “hostPath mount” for reference).

Cloud Provider

Within the cloud provider environment, organizations should minimize access to cluster nodes to mitigate this threat.

Other - Container runtime and operating system

Organizations should continuously send collected logs from the container runtime and operating system to a secure, external logging service, security information and event management (SIEM) system, or persistent storage.

Technique 5.2: Delete Kubernetes events

Issue

Another technique an attacker may use to avoid detection is to delete Kubernetes audit logs, which provide a chronological record of security-relevant activities taken by users or system components within a Kubernetes cluster.

Best Practice for Mitigation

Primary areas to configure security controls: Kubernetes and Cloud Provider

Kubernetes

Organizations should configure Kubernetes audit logging to continuously send events to an external logging service outside clusters. Additionally, administrators should minimize container access to underlying nodes, especially in the Kubernetes control plane, by restricting host mounts (also see Techniques 3.2 “Writable hostPath mount” and 4.3 “hostPath mount” for reference).

Cloud Provider
If running clusters using a cloud provider-managed Kubernetes service, organizations should use activity logging feature available. Administrators should also further minimize user access to underlying nodes.

Technique 5.3: Pod / container name similarity

Issue

This threat arises from the possibility that pods created by controllers such as Deployments or DaemonSets may have a random suffix in their names. An attacker could use a random suffix to obfuscate the presence of an unauthorized pod within the cluster that could be used to execute malicious code or gain access to additional resources.

Best Practice for Mitigation

Primary area to configure security controls: Kubernetes

Administrators should mitigate the risk of this threat by following the principle of least privilege with regard to access control and limiting RBAC permissions on pod creation APIs.

How StackRox Helps

StackRox helps protect against this attack technique by monitoring all pods, including those not created by using a Kubernetes controller. StackRox also identifies standalone pods (those not created by a controller) in its platform.

Technique 5.4: Connect from Proxy server

Issue

To conceal their network origin, attackers may employ this technique by using proxy servers or anonymous networks to hide their IP address.

Best Practice for Mitigation

Primary area to configure security controls: Cloud Provider

Organizations can mitigate this threat by configuring controls within the cloud provider such as applying network access restrictions to the Kubernetes API server using managed Kubernetes service controls, if applicable, or cloud network firewall rules. Note that these practices can also mitigate Kubernetes API server vulnerabilities or misconfigurations such as CVE-2018-1002105.