MITRE ATT&CK Framework: Discerning a Threat Actor’s Mindset
Imagine a military battalion trying to invade its enemy’s territory. What would a soldier do once they’ve infiltrated the opposition? They would take cover and wait for the right opportunity to attack. Similarly, in cybercrime, an attacker will take time to make sure they evade any type of defense that has been put in place. Defense evasion is the fifth stage in the MITRE ATT&CK framework. In this article, I will explore this fifth stage, along with stages six through nine, and offer some suggestions on how to mitigate related attack techniques.
Delivery and Exploitation Tactics
Many security solutions offer a wide range of features to detect and track malicious behavior in containers. Defense evasion techniques are meant to obfuscate these tools so that everything the bad actor is doing seems legitimate.
One example of defense evasion includes building the container image directly on the host instead of pulling from public or private registries. There are also evasion techniques that are harder to identify, such as those based on reverse forensics. Attackers use these techniques to delete all logs and events related to their malicious activities so that the administrator of a security, security information and event management (SIEM), or observability, tool has no idea that an unauthorized event or process has occurred.
To protect against defense evasion, you’ll need a container security solution that detects malware during runtime and provides threat detection and blocking capabilities. Two examples of this would be runtime threat defense to protect against malware and honeypots to capture malicious actors and activity.
If, after employing defensive evasion techniques, an attacker has not been successful in obtaining sensitive data, they are probably looking at accounts, passwords and other credentials that will let them access the data they’re looking for.
There are multiple ways an attacker can get the credentials they need, such as social engineering, spear phishing, brute force and network sniffing. In a Kubernetes-based environment, access tokens for APIs are required to authorize API communication (OAuth 2.0) that happens between the Kubernetes API server and the container processes. If these tokens are compromised, any attacker can run Kubernetes commands as an authorized user.
This is a critical stage for both the attacker and the organization (defender). Once an adversary gets enough information from this stage about all the resources, such as pods, nodes, images, etc., they’ll have an approximate blueprint of the entire application. This information can be used to plan how to move from workload to workload until their desired outcome is reached. Most threat actors and teams spend a considerable amount of time in this phase.
To thwart an attacker, you’ll need a solution with zero trust workload access that delivers the following mitigation strategies for the discovery phase of an attack:
- DNS policies and workload access controls to limit access to resources.
- Identity-based microsegmentation to reduce the attack surface and prevent sensitive workloads from being discovered.
Installation and Spread Tactics
There is a downside to the array of benefits that come with using public cloud services, as well as the way cloud native applications are architected: lateral communication. Traditionally, we would see traffic entering and leaving a network perimeter more than traffic that does not hit the perimeter firewall (east-west traffic). With modern cloud native applications, the numbers have flipped.
We tend to see a high volume of traffic between services and within pods in a Kubernetes-based microservice application. Although the MITRE framework has included “lateral movement” as a tactic, it has not addressed the data plane or user traffic that flows laterally.
Lateral movement is a critical aspect when it comes to container security as it can be a way to evade traditional security tools that are not designed to be deployed in a Kubernetes-based application.
This is where zero trust workload security principles come into play: You’ll want to use least-privilege access for user traffic. Applying DNS policies to workloads could help ensure that granular access such as pod-to-pod communication is controlled and filtered based on a workload’s function.
Command and Control Tactics
The ultimate goal of any adversary or bad actor could be one or a combination of the following:
- Stealing sensitive data
- Holding stolen data for ransom (ransomware)
- Stealing compute resources to mine cryptocurrency (cryptojacking)
- State-sponsored cyber terrorism to bring down public infrastructure
Organizations are most worried about losing critical data — both internal and customer information — through command-and-control activity. Any security system, no matter how good it is at detecting vulnerabilities or threat activity, must be able to block the transfer of sensitive data from inside the organization to an external actor.
In a containerized environment, this means applying the principle of least privilege for workloads when they communicate with other workloads within a cluster, with external applications and workloads outside the cluster, and with end users.
You can protect workloads from being severely affected by an attack by using a suite of zero trust security policies, microsegmentation to limit an attack’s blast radius, a global default-deny policy, and alerting for anomaly detection.
This article explored the mindset and strategies used by cybercriminals to breach an organization. Container security solutions should be one step ahead of the criminals by investing in a tailor-made security approach for containers and Kubernetes. The ideal solution for DevOps and platform teams will be Kubernetes native and employ a solid defense-in-depth strategy.
Calico Cloud provides zero-trust-based security for containers during build, deployment and runtime. Try Calico Cloud for free with a 14-day trial.