Ongoing vulnerability scanning is a key feature for Twistlock. We know that we won’t accidentally deploy a build with a known exploit or a dependency on a compromised library. The Twistlock intelligence streams are constantly being updated and we know that our containers are safe from known exploits.
But what about the zero days? What about the brand new malware or the vulnerability that hasn’t been disclosed yet? Enter Twistlock Runtime.
I wanted to see what real world attacks and malware in the wild look like on a system protected by Twistlock Runtime. Containers protected by twistlock are constantly monitored for activity across a variety of channels: restricted filesystem access, suspicious process activity, abnormal system calls, and high risk network connections. Monitoring those channels isn’t a new concept or one that is specific to containers but separating the legitimate calls from the malicious ones has always been a challenge. How should we tell them apart? This is especially challenging when the monitoring is at the OS level and includes a variety of activity: OS background processes, monitoring and deployment daemons, and the actual application or service that is being hosted.
The abstraction level used by containers makes it much easier to separate the legitimate OS level activity from the malicious activity. The Dockerfile and run time arguments for a container can tell us a lot about how it is going to be used. A container based on MySql and linked to a backend container? We can already make assumptions on filesystem and network access and we know that general OS, deployment, and monitoring activity will all happen outside of the container context.
This makes zero configuration runtime monitoring feasible. Let’s put it to the test.
Twistlock Runtime In The Wild – Mirai
The first malware I was curious about was Mirai. This is malware that targets IoT devices and was a big part of the the largest DDoS attack on record a few weeks ago. Mirai and its various derivatives target devices running BusyBox and gain access with telnet dictionary attack. In other words, it logs into devices running embedded linux with default factory-settings credentials.
So my honeypot would consist of: a container running BusyBox with one of the targeted credentials. On the same host, alongside the target container, I installed a default, zero configuration installation of Twistlock. It’s important to note that this is an out-of-box configuration of Twistlock, we didn’t tweak it at all for this scenario. Twistlock performs automated learning of how a containerized application should behave. Because containers are immutable and single-purpose (if you structure the container as a minimalistic application), we can do effective and automatic learning of what the application’s behavior model should be.
Let’s see what a vanilla installation of Twistlock can pick up with this setup.
It is also important to note that out of the box Twistlock will alert about suspicious activity but won’t block it. This will let me examine what Twistlock picks up but for the purpose of this experiment I will be letting the suspicious activity run, be it running the malware process or generating the DDoS traffic.
The trap was set, here is what came up.
We are seeing two types of alerts from the filesystem monitoring: files in /dev/ changing, and a file created that is identified as container malware from the live Twistlock Intelligence Stream. Both of these alerts are generated when the Mirai downloader downloads the malware binary into /dev/dvrHelper.
It is important to note that this would be suspicious even without the intelligence stream with the malicious signature. A typical BusyBox installation shouldn’t be modifying files in /dev/ and Twistlock alerts us when that happens.
The processes monitoring in Twistlock Runtime is catching the suspicious attempts at launching the container malware process. Twistlock knows which files were in the container when it was launched and will alert when a new unfamiliar process starts running. We would also see the alerts if the process was part of the container but with different contents. Running modified binaries that changed since the container malware was launched is definitely an anomaly.
And last but not least – our container is now generating traffic as part of a DDoS botnet. The live intelligence stream is aware of compromised IPs and can flag the suspicious traffic.
Runtime monitoring of OS level activity and host level traffic isn’t new, but having a container to contextualize that activity makes it easier to detect when something is wrong — even without explicitly configuring anything. Twistlock Runtime uses a combination of up to date intelligence streams for known attacks and malware but also has very powerful heuristics for container malware that is still in the wild and hasn’t been caught and identified yet. The properties that make containers appealing to develop with also make them easier to defend in ways that have been very manual or very prone to false positives in more traditional environments.
If you are interested in finding out more about Twistlock technology or seeing how Twistlock can block threats like Mirai in action, request a free trial of our product here.
Follow us on Twitter
Keep up to date with the latest news from TwistlockLabs and TwistlockTeam.
Your Firewall’s Role in Cloud-Native Security
We live in the cloud-native era. That means the firewall strategy that...
Compliance, Microservices and Your Application
Compliance in modern applications that leverage containers, serverless...
6 Tips for Secure Data Management for Containers
One of the main reasons why containers have become so popular is that ...
OpenShift Internal Registry: Populating Registry Scans with Twistlock
Twistlock uses the Docker v2 Registry catalog API call to inventory im...
Better Together: Protecting Docker Registries with Twistlock and JFrog Artifactory
In a containerized devops lifecycle, a registry such as JFrog Artifact...