How Public Docker Images Are Fueling a Global Proxy Network

TLDR: Researchers at DEF CON 2025 demonstrated how developers accidentally leak private Git repositories and sensitive credentials into public Docker images, creating a massive, searchable attack surface. By scanning Docker Hub for these misconfigurations, threat actors are building operational relay networks to proxy malicious traffic and bypass IP-based security controls. This research proves that a single COPY . . command in a Dockerfile can lead to full infrastructure compromise, and it serves as a wake-up call for anyone managing CI/CD pipelines.

Developers often treat Docker images as black boxes, assuming that once a container is built, the source code and environment variables are safely tucked away. That assumption is fundamentally flawed. When you run COPY . . in your Dockerfile without a properly configured .dockerignore file, you are not just copying your application code. You are copying the entire .git directory, your .env files, and any local configuration files sitting in your working directory.

This is not a theoretical risk. The research presented at DEF CON 2025 highlights a massive, automated effort by threat actors to scrape these public images for secrets. By using tools like TruffleHog, these actors are pulling down thousands of containers, extracting credentials, and using them to build an operational relay network. This network is then used to proxy malicious traffic, allowing attackers to bypass IP-based geolocation blocks and hide their origin.

The Mechanics of the Leak

The core of this issue lies in how Git metadata and environment files are handled during the build process. If a developer has a .git folder in their project root, COPY . . pulls that entire history into the image. An attacker who pulls your public image can simply run git log or git checkout to inspect the entire commit history, often finding hardcoded API keys, SSH private keys, or database credentials that were "deleted" in a previous commit but still exist in the Git object database.

Beyond Git, the inclusion of .env files is a common failure point. These files are rarely intended for production, yet they frequently end up in the final image layer. Once an image is pushed to a public registry like Docker Hub, these secrets are effectively public.

Consider this simple, dangerous Dockerfile pattern:

FROM ubuntu:22.04
WORKDIR /app
COPY . .
RUN pip install -r requirements.txt
CMD ["python", "app.py"]

If your local directory contains a .env file or a .git folder, they are now part of your image. An attacker can use the Docker Engine API to inspect the image layers and extract these files with minimal effort.

From Credential Exposure to Infrastructure Control

The most alarming part of this research is how these leaked credentials are used to build a persistent, multi-layered relay network. The researchers found that attackers are not just using these keys to access third-party services like AWS or GitHub; they are using them to spin up their own infrastructure.

By leveraging leaked CI/CD tokens, attackers can inject their own malicious steps into a target's build pipeline. This allows them to execute code as root within the build environment, exfiltrate more secrets, or even modify the application code before it is deployed. The researchers demonstrated a specific exploit where they could gain unauthorized access to private repositories by abusing these CI/CD tokens, effectively turning the victim's own automation against them.

The relay network itself is sophisticated. It uses NPS for node-to-node communication and FRP for network tunneling. By modifying the FRP fingerprint, attackers can make their traffic look like legitimate application traffic, making it incredibly difficult for standard network monitoring tools to flag the activity.

Testing for This in the Wild

For a pentester, this is a goldmine. During an engagement, you should always check the public container registries associated with your target. If you find a public image, pull it and inspect the layers. Use a tool like dive to visualize the image contents and look for sensitive files.

If you find a .git folder, use git checkout to restore the state of the repository at different commits. You will be surprised at how often you find credentials that were supposedly removed. If you find a .env file, you have likely found the keys to the kingdom, including database connection strings and cloud provider access keys.

Defensive Hardening

The fix is straightforward but requires discipline. First, ensure that every project has a robust .dockerignore file. At a minimum, it should include:

.git
.env
*.pem
*.key
__pycache__

Second, move away from hardcoded credentials entirely. Use secret management services like HashiCorp Vault or the native secret management features provided by your cloud provider. If you are using GitHub Actions or GitLab CI, ensure that your CI/CD tokens are scoped with the principle of least privilege. Do not give your build pipeline write access to your entire repository if it only needs to push a container image.

Security in the cloud is not just about firewalls and IAM policies. It is about the integrity of your build artifacts. If your Docker images are leaking your secrets, your entire security architecture is built on a foundation of sand. Stop pushing your local environment to the public, and start treating your container build process with the same scrutiny you apply to your production code.