PT0-002 Practice Question: During a penetration test, a tester gains shell…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Use docker to mount the entire host filesystem and modify the root password.

  Why this is correct

  Running 'docker run -v /:/mnt -it ubuntu bash' mounts the host root filesystem. From inside the container, the attacker can chroot to /mnt and modify /etc/shadow or add an SSH authorized key, gaining full root access.

• ✗

  Use docker to run a container with network host mode to access internal services.

  Why it's wrong here

  Running a container with `--network host` attaches its network stack directly to the host, enabling the attacker to listen on or connect to services bound to the host's interfaces, such as internal APIs or databases. However, this only grants network visibility and reachability; it does not bypass the container's user namespace, capset, or mount namespace restrictions. Host-level privilege escalation would still require a separate kernel exploit, misconfigured Docker capabilities, or an exposed host file system. Thus, while useful for reconnaissance or lateral movement, this technique alone cannot modify host files like `/etc/shadow`, so it is not the correct path to root.

• ✗

  Use docker to pull a malicious image from the internet to compromise other containers.

  Why it's wrong here

  Pulling a malicious image from a public registry and running it creates a new container that runs under the same Docker daemon, but that container is still isolated by namespaces and capabilities just like the original one. The act of pulling an image does not inherently grant the attacker anything on the host—it merely adds another sandboxed execution environment. Even if the malicious image contains an exploit or backdoor, it would only affect other containers sharing the same host if a separate vulnerability is exploited, and it certainly does not provide direct write access to the host's root file system. Therefore, this option targets the container ecosystem rather than escaping it to compromise the host, making it an ineffective privilege escalation technique.

• ✗

  Use docker to create a new user with root privileges inside a container.

  Why it's wrong here

  Creating a user with UID 0 inside a container only establishes root authority within that container's user namespace; by default, Docker maps the container's root user to a non-privileged UID on the host (e.g., UID 1000) unless user namespace remapping is disabled or the container runs in privileged mode. Even if the user has full root powers inside the container, those powers are confined by the container's capabilities (e.g., `cap_sys_admin` is dropped) and seccomp/AppArmor profiles, preventing direct manipulation of host processes or files. Without mounting the host file system or using the `--privileged` flag, the root user inside the container cannot alter `/etc/shadow` on the host or inject SSH keys into the host's `/root/.ssh`. This technique confuses container-internal privilege with host-level privilege, which is exactly why it fails to escalate the attacker's control.

Go deeper

Related to this question