Twistlock Runtime Defense uses machine learning to understand expected behavior from containers and hosts. This model is then used to alert on or block activity when something happens outside the model. In Twistlock 2.3, we are extending this capability to incorporate real-world research from Twistlock Labs, our talented team of security researchers, to identify combinations of individual audits that are correlated with attacks seen in the wild against Docker deployments.
Key attack categories
Twistlock Incident Explorer aggregates individual runtime audit alerts based on categories of attacks that Twistlock Labs identified affecting the container ecosystem. Here are some samples of the categories of detections:
- Port scanning
- Hijacked processes
- Data exfiltration
- Backdoor administrative accounts
- Backdoor SSH access
- Crypto miners
- Lateral movement
- Brute force attacks
Each of these attacks can, individually, be damaging; however, in practice, they would tend to be part of a larger campaign. For example, port scanning will give an attacker a better understanding of what services are exposed, providing opportunities for movement further into your infrastructure. Backdoor SSH access may be used to plant persistence mechanisms, giving the attacker ongoing access to this container, and then to access/copy sensitive data
Twistlock Labs continuously investigates threats against production container deployments; for example, the detection of Bitcoin and other cryptocurrency miners is a direct result of our research into real-world compromises of misconfigured registries.
An example attack scenario
Using hijacked processes detection as an example, let’s step through an example of when this would be triggered. In this scenario, we have a container running that includes a Struts 2 server that is vulnerable to CVE-2017-5638. This vulnerability allows an attacker to execute remote code on the Struts 2 server using a specially crafted upload.
In this case, our attacker has used this vulnerability to launch a reverse shell, which would allow the attacker to execute further commands. Twistlock identifies two separate but related events and aggregates them into a single incident as shown in the screenshot within Incident Explorer.
We can see both the file written by the upload (showcase_jsp.java) and the process execution (/bin/bash executed by Java, enabling the remote shell) as a single incident, identifying not just the specific violations of the model of known behavior for this container but also the larger context for these violations.
Security operations engineers and security incident responders are often faced with a large number of discrete alerts and must interpret them to determine whether a security incident has occurred and, if so, how severe the incident is. The answers to these questions determine whether a single event should be investigated further or treated as a false positive. In a complex, distributed environment, it may be difficult to determine if a single event, such as the filesystem write or the process launch seen above, are meaningful…but ignoring these alerts may result in a significant compromise going unnoticed.
By using our leading research into attacks against the container ecosystem to automatically identify common incidents in the graph of real-time telemetry in Docker deployments protected by Twistlock, we are enabling customers to respond quickly and confidently to threats that affect their services.
Follow @Twistlockteam on Twitter to get updates on what’s next with Twistlock and cloud native cybersecurity.
- Runtime Defense
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
Istio Visualization, Security, and Compliance Checks with TwistlockRead the Blog
Protecting Serverless Functions at Runtime: Serverless Defender v2Read the Blog
Cloud Platform Discovery: Identifying All Your Cloud Native ServicesRead the Blog
Using Twistlock to Secure Workloads on Pivotal Cloud FoundryRead the Blog
Twistlock, Azure Container Instances, and AKS virtual nodesRead the Blog