|
Since its release in 2015, the MITRE ATT&CK Framework has taken the cybersecurity industry by storm. Its ability to categorize threat actor behavior has made it easier to talk about what security analysts are seeing and to evaluate cybersecurity defenses. Its focus on documented, rather than theoretical, attacks has worked to maintain its strong footing in the practical applications of the framework and enhanced its usefulness for cybersecurity analysts.
MITRE announced the Cloud Framework in 2019. With 40 techniques and 44 sub-techniques (in January 2021), it is far smaller than the Enterprise Framework. Cloud technology is newer than classic enterprise data center technology, so there is a smaller time horizon from which to pull documented attacks. There are also fewer public cloud targets than enterprise data center targets. With the notable exception of the Capital One breach, public cloud providers have been reticent to publish detailed information about attacks. These factors result in a much smaller set of documented cloud attacks from which to pull attacker behaviors. Even without many attacks being publicly documented, we can infer likely attacker behavior based on the documentation that does exist and supplementing it by:
- Enumerating recent K8s and OpenShift CVEs
- Enumerating MITRE ATT&CK techniques for the Linux operating system
- Using the existing MITRE ATT&CK techniques for cloud workloads
Why bother? With the resulting expanded dictionary of cloud attacker behaviors, cloud infrastructure can be closely evaluated for its defensive posture and gaps can be identified. Without this fuller view of likely (rather than proven) cloud attacker behaviors, gaps in the security coverage may arise.
Methodology for Creating the Expanded Cloud Attack Framework
For each data source enumerated above, each potential technique was split into a set of detectable symptoms to provide an equal level of abstraction. This avoids the problem of some techniques encompassing many different behaviors. When the symptoms are in place, telemetry systems that produce the information used to detect the symptoms are enumerated. This methodology is shown in Figure 1.
The resulting expanded Cloud attack matrix is shown below in Figure 2. An interactive version is online at IBM Cloud Use-cases for closer inspection.
Let's take a closer look at a few of the new techniques to get a feel for what this expanded set of techniques looks like.
Initial Access -> User Impersonation at the Application Layer
"Attacker may perform application-level actions in the name of another user. This could be as a result of obtaining credentials or insufficient verification on login phase. This kind of activity is hard to detect, especially when the attacker has similar geolocation, browser, and other environmental identifiers."
An attacker using this technique may seek to exploit CVE-2014-0188 ("The OpenShift-origin-broker in Red Hat OpenShift Enterprise 2.0.5, 1.2.7, and earlier does not properly handle authentication requests from the remote-user auth plugin, which allows remote attackers to bypass authentication and impersonate arbitrary users via the X-Remote-User header in a request to a passthrough trigger.") or CVE-2018-1002105 ("In all Kubernetes versions prior to v1.10.11, v1.11.5, and v1.12.3, incorrect handling of error responses to proxied upgrade requests in the kube-apiserver allowed specially crafted requests to establish a connection through the Kubernetes API server to backend servers, then send arbitrary requests over the same connection directly to the backend, authenticated with the Kubernetes API server's TLS credentials used to establish the backend connection."). As the description states, it is difficult to detect this technique, but it may be detectable using machine learning mechanisms on worker node telemetry.
 ![]() |
Defense Evasion/Privilege Escalation -> Overwrite Container's Folder with Mount
"The container's original content (possibly sensitive folders such as /proc) can be overwritten using a mount."
An attacker using this technique may seek to exploit CVE-2015-3631 ("Docker Engine before 1.6.1 allows local users to set arbitrary Linux Security Modules (LSM) and docker -t policies via an image that allows volumes to override files in /proc."). This technique can be detected using rules on worker node logs.
Defense Evasion/Privilege Escalation -> Process Accessing Foreign Memory Region
"Processes may try to access memory region owned by a different process to inject code or get access to sensitive data."
An attacker using this technique may seek to exploit Spectre or Meltdown vulnerabilities or one of the many subsequent similar vulnerabilities.
Applying the Expanded Cloud Attack Framework
With the Expanded Cloud Attack Matrix in hand, it is now possible to determine whether the data to detect these techniques is available within the cloud infrastructure. As with the MITRE ATT&CK Evaluations, it is also possible to test sources of cloud telemetry to see how well they do at providing the data needed to detect these attacks.
A telemetry taxonomy arises from a survey of the cloud attack techniques. Each of the data categories below is needed to detect one or more of the cloud attack techniques.
File
Host Audit
- Background Tasks
- Environment
- File System
- Kernel
- Physical Resources
- Shell
- System Calls
- Users
Process
Kubernetes / OpenShift
- Application
- Cluster
- Container
- Image
- Pod
- Set / Deployment
- User
Network
- Application Layer
- Connection
- DPI
- Netflow
Other
Insights
After describing all of these potential attacks on cloud infrastructure, what have we learned about defending the cloud. There are several insights which can be drawn from this perspective on cloud attacks. Firstly, most of the techniques can be detected using File and Process telemetry. Many of the attacks can be prevented via simple rules and/or allow/deny listing techniques. The techniques that require machine learning for detection are primarily in the field of network anomalies or anomalous process/container behavior. And finally, we learned that to detect some of the attacks, K8s masternode monitoring is required.
Where can I find more on this topic?
IBM Research has written up a detailed report that goes into much more depth on this topic. Request a copy from an IBM team member: Bar Haim (barha@il.ibm.com), Yuval Lapidot (yuval.lapidot@ibm.com), or Anton Puzanov (antonp@il.ibm.com).
|