Analysing Docker Images in the Cado Platform

Normally when we talk about analysing Docker, we mean live containers. The Cado platform enables analysts to perform deep dive investigations of docker and container environments by either acquiring the contents inside a container (eg. EKS or ECS on Fargate), or the disk of the underlying host system (e.g. EKS on EC2).

In this blog, we’ve analysed the actual image on Dockerhub from which the docker container is launched.

The Test Data

Below we’ve analysed two docker images:

1. The container “tempsbro” that was featured in a report by Palo Alto titled “Finding Malicious Cryptojacking Images in Docker Hub”.
2. A Docker container running the vulnerable OpenSSL v3.0.0

Whilst there are tools to download Docker Images directly from Docker Hub, we’ve directly exported it to a .tar file with the commands:

• docker pull tempsbro/tempsbro
• docker save tempsbro -o tempsbro.tar

If you’d like to see what these images look like, we’ve uploaded them to a repository on Github.

Processing Data in the Cado Platform

Docker Images are tar files that contain a number of sub-files which include more tar archives and json format manifest files. In order to ensure the sub-files are extracted correctly by the Cado platform, we need to set the Processing Depth to “Full”:

Tempsbro - A Docker Image containing Xmrig

We then uploaded the Docker images to S3 storage and imported them into Cado. After processing is completed, we immediately see alarms. Alarms are malicious activity that was automatically flagged by the Cado platform – these serve as a great pivot point to kick off the investigation:

By browsing the disk, we can see the docker image structure of a tar file containing many sub-files (layer.tar):

We can also see the raw xmrig binary that is packed into the container:

OpenSSL v3.0.0 Container

As a topical example, we’ve included a YARA rule below which should detect Linux versions of the OpenSSL library recently deemed vulnerable. You can also grab the Yara rule from our Github repository. First lets add it to Cado Response under Settings > Detections:

Then we imported an image pushed to Dockerhub a year ago called salrashid123/openssl which we can see includes the vulnerable version 3.0.0 of openssl:

Note that we’re analysing a Docker container here, but as the Cado platform can perform snapshot scanning, you can also use Yara rules as an agentless way of scanning systems such as EC2 to find systems running vulnerable versions of OpenSSL.

Below we can see the Yara rule identifying the binary in the image at the location /usr/local/bin/openssl:

And that’s it! If you’d like to have a go at analysing Docker images yourself, we have a Free Trial and Community Edition available. We’ve also published a free playbook called “The Ultimate Guide to Docker & Kubernetes Forensics”.

Appendix

import "elf"

import "pe"
rule Vulnerable_Win_OpenSSL {
 meta:
 description = "Detects vulnerable version of OpenSSL Windows binary (3.0.0 and up to 3.0.6)"
 author = "mmuir@cadosecurity.com"
 date = "2022-10-31"
 reference = "https://www.zdnet.com/article/openssl-warns-of-critical-security-vulnerability-with-upcoming-patch/"
 license = "Apache License 2.0"
 strings:
 $ver = { 4F 70 65 6E 53 53 4C 20 33 2E 30 2E (30|31|32|33|34|35|36) }
 $str1 = "SSLv3"
 condition:
 $ver and
 (all of ($str*)) and
 pe.imports("bcrypt.dll") and
 pe.imports("WS2_32.dll") and
 filesize < 5MB
 }
rule Vulnerable_Linux_OpenSSL {
 meta:
 description = "Detects vulnerable version of OpenSSL Linux binary (3.0.0 and up to 3.0.6)"
 author = "mmuir@cadosecurity.com"
 date = "2022-10-31"
 reference = "https://www.zdnet.com/article/openssl-warns-of-critical-security-vulnerability-with-upcoming-patch/"
 license = "Apache License 2.0"
 strings:
 $ver = { 4F 70 65 6E 53 53 4C 20 33 2E 30 2E (30|31|32|33|34|35|36) }
 $str1 = "SSLv3"
 condition:
 $ver and
 (all of ($str*)) and
 elf.type == elf.ET_DYN and
 filesize < 30MB
 }