Deploy Container

Adversaries may deploy a container into an environment to facilitate execution or evade defenses. In some cases, adversaries may deploy a new container to execute processes associated with a particular image or deployment, such as processes to execute or download malware. In others, an adversary may deploy a new container configured without network rules, user limitations, etc. to bypass existing defenses within the environment, an adversary may attempt to deploy a privileged or vulnerable container into a specific node to Escape to Host and access other containers running on the node.

Containers can be deployed by various means, such as via Docker's create and start API or via a web application such as Kubernetes dashboard Kubeflow. In Kubernetes environments, containers may be deployed through workloads such as ReplicaSets or DeamonSets, which can allow containers to be deployed across multiple nodes. Adversaries may deploy containers based on retrieved or built malicious images from benign images that download and execute malicious payloads at runtime.

In this scenario will create an Ubuntu Docker then send this to the user and when the user install the Docker it will have access to the host files via a mount drive, this way we can execute commands form inside the docker and interact with the hosts files as well, this extra step of running everything from inside the Docker is assumed to avoid defenses since everything is coming from inside a container which the hosts processes or AV/EDR capabilities don't have access.

In this scenario we are simply setting up a container that will give us access to the hosts root directory, but we can also install a vulnerable Docker container to exploit an Escape to Host technique, will begin by pulling a docker image

Now we will save the Docker container into a TAR file, by making sure the REPOSITORY names match when saving

The newly created TAR file is what will we be sending to the user's workstation, this only works if the host has DOCKER as well, and once sent to the user it will need to load first

Once the images have been loaded, we can run and mount the file systems folders from the container and the host

With the successful mount we can verify this by placing a file on the Host then opening an interactive shell on the container and try to read the Host file

Notice on the screen above that we have access to the Host files via the DOCKER, now only your creativity and social engineering will help you in achieving these steps on the Ubuntu host, in the previous commands for mounting the drive we also opened a few ports on our container so it can communicate with the outside network, achieving this helps us gain a reverse shell on our attacking machine with any shell of your preference supported by Ubuntu

From the container

And from the attacker

In his scenario everything was set manually but we can have these reverse shells call us by using cron jobs in Linux which are similar to Scheduled Tasks in Windows that way the only step to work with is the setting up the Docker image on the user's workstation