From Registries to Private Networks: Threat Scenarios Putting Organizations in Jeopardy

By Alfredo Oliveira and David Fiser

Key Takeaways

• We looked into how threat actors can find private keys or certificates and use them to further infiltrate an organization.
• We show how stolen certificates and private keys introduce specific challenges as they allow threat actors to impersonate users and enable the attacks to remain hidden longer.
• We highlight how certificates and private keys end up in built container images.
• We detail recommendations, mitigations, and common misconceptions companies must be aware of.

The alarm goes off within the lab. The company's XDR solution reports that an unrecognized device has joined a network. The administrator rushes to his computer screen and prints out the recent access log. The administrator identifies the use of a VPN to access the company’s private network using an employee’s private key and certificate. He calls the employee and asks about the purported use of an uncertified device to access the network.

However, the suspected person did not use any unknown device; the employee just pushed a container image into their private container registry.

At first, this might sound like an unlikely scenario. However, our findings involving 32 OpenVPN client configuration files inside container images show otherwise, proving the plausibility of the scenario as supported by our long-term research of exposed private container registries.

If left unattended, the consequences could include unrestricted server or private network access, leading to identity theft, supply chain infection, and customer data breaches, ultimately resulting to reputation damage.

We extracted 2,278 unique private keys, out of which 169 are SSH private keys. Eighty-eight of the most vulnerable private keys lack any password protection, exposing them to potential security threats. This critical oversight highlights the need for robust security measures to safeguard sensitive information.

Figure 1. SSH Private Keys (with and without password) among Unique Private Keys

The attack starts when threat actors gain access to the organization's private container registry. They download all images and find a VPN configuration, including server addresses, connection keys, and certificates without password protection. The attackers use them to connect to the organization's internal network.

Even worse, one image contains a script using password-less SSH keys with their IP addresses, allowing the attacker to further infiltrate the internal infrastructure.

Figure 2. How threat actors could gain access to the registry

One might think, "Isn't that just like exposing secrets?"

Sure, certificates and private keys technically fall under the secrets category. However, they carry a distinct set of risks. An SSH private key or OpenVPN key file in a publicly accessible container image might allow an attacker to pivot towards other systems, impersonate servers or users, intercept encrypted communications, or even escalate privileges in a broader environment.

Unlike general access tokens, compromised certificates and private keys can be particularly damaging because they enable attackers to masquerade as trusted entities. This is not just about losing credentials; it's about losing an identity the system or users implicitly trust.

This article will describe threat scenarios based on real-world cases we identified during our research, emphasizing the need to be vigilant about the impact exposures can bring to an organization.

Recap: The problems with exposed container registries

We described in our previous research how we found over 20,503 images spread across 197 unique image registries containing more than 9.36 TB of data.

A container registry is basically a warehouse for storing container images — each with its own code, dependencies, and configuration details. If that warehouse is unintentionally left open, malicious actors could penetrate and examine images.

To summarize, below are some of the main issues with exposed container registries.

Problem 1: Exposed registry or leaked registry credentials

With exposed registries, all images (including images under development, testing versions, or older backups) are accessible to threat actors. The images often contain sensitive information, such as credentials stored within configuration or built scripts. These provide access to internal systems.

As a registry could serve as the company knowledge base, leaving it exposed could lead to an avalanche of deeper security issues. Companies should ensure that their registries remain secure and properly configured.

Problem 2: Secret storage

The second problem is why and how the organization stores those secrets inside the container image. We dug deeper into the roots of the topic in our previous research on the threats hidden in the DevOps minefield.

There are two ways to tackle this problem. First, organizations must not store any secrets within the image; instead, reference them on runtime. Implementing secret scanning and protection mechanisms will also prevent attacks from succeeding.

Second, it should be automatically assumed that the secret will find a way to the image, code base, etc., no matter what. Setting a certain level of trust is also inevitable. Therefore, the secrets must be stored encrypted. The decryption is done on runtime, meaning the decryption key is not present in the image. Therefore, if the secret is leaked, it ends up as a worthless binary blob for the threat actors.

Why certificates and private keys introduce specific challenges

When it comes to secrets stored in images, we often associate them with API tokens, passwords, or authentication credentials for different platforms. But the certificates and private keys also deserve special attention due to their properties:

• Identity and trust - An SSL/TLS certificate or SSH key is more than just a secret; it is an identifier that a system or user is who they claim to be. If an attacker gets hold of these, they can impersonate servers or users. This leads to scenarios where organizations connect to an attacker-controlled resource but still see it as trustworthy because it presents a legitimate certificate or key.
• Long-lived and harder to rotate - API tokens and passwords can often be rotated quickly or automatically. On the other hand, certificates and private keys are part of a more formal issuance and trust chain. Revoking and reissuing them is a more complicated process, extending the exposure time.
• Stealth potential - Using compromised certificates or keys can allow attacks that remain hidden far longer because there is not always an immediate indicator that someone unauthorized is using them. A skilled attacker can mask malicious traffic as legitimate or create seemingly regular sessions that raise no red flags.
• Regulatory and compliance risks - In some industries, exposing specific certificates and keys is not just a security concern but can also lead to compliance violations. Companies operating in a field governed by strict data protection regulations might face penalties or legal complications in addition to the security fallout.

These are the reasons why leaving unprotected certificates and private keys in a container image is equal to giving away the keys to the kingdom. Unfortunately, these files can be forgotten during development, especially when packaging a service that needs to function locally. A similar situation could apply to quick VPN or SSH testing.

Real-world use: Image containing both OpenVPN and SSH keys

Through our research, we identified an image leaking OpenVPN certificates (and private keys) and SSH private keys, both essential elements of communications.

OpenVPN is a popular technology for setting up VPN tunnels. It relies on certificates and private keys to establish secure, encrypted connections. If attackers obtain these, they could set up a rogue VPN server that appears authentic, or they could connect to an organization’s legitimate VPN as an authorized user. This could allow them to sniff traffic, pivot into other corporate networks, exfiltrate sensitive information, or launch a supply chain attack.

Meanwhile, SSH is the cornerstone for secure remote administration of servers. Once an SSH private key is compromised, an attacker can often log into the servers or systems that trust the corresponding public key, bypassing password-based authentication entirely. Worse, many administrators reuse or replicate SSH keys across multiple environments, so the compromise of one key can cascade into a compromise of numerous servers and services.

Finding both in one image provides the opportunity for threat actors to launch a perfect storm of security incidents. This could start with gaining unauthorized VPN access, followed by pivoting the SSH credentials and taking over the internal servers and even the whole network.

The number of potential outcomes is staggering and could even rise exponentially with the reuse of the private keys or certificates.

Figure 3. OpenVPN Server shows SSH service on Shodan

Figure 4. OpenVPN service is running on the server using the default port and UDP protocol

Figure 5. The registry and images are no longer exposed

Figure 6. OpenVPN configuration file with certificate and key

Figure 7. The entry point of the container that, once the VPN is connected, uses an SSH key to create a tunnel

Figure 8. SSH private and public keys are also present inside the image

Figure 9. Content of the private key present inside the container image

How do certificates and private keys end up in built images?

Let's take a step back. How does it happen that an image ends up with such sensitive files inside? Here are some common scenarios.

First is the lack of separation between the build and production environment. Developers sometimes build container images in an environment where the host system stores environment variables or shares volumes containing sensitive keys. It is easy for an oversight in the Dockerfile to enable copying everything from a directory (including the private keys) into the image.

During our research, we found 1,653 unique Dockerfiles and 918 unique Docker Compose files. Those files were copied inside the image during the building process.

Figure 10. Examples of a leaked Dockerfile copying all folder current content into the image

Second is prioritizing convenience. Including SSH keys into the image sometimes allows quicker troubleshooting or replication of the production environment. It is often done when there’s not enough time and the environment setup is complicated. But this can have consequences for security.

Another scenario involves copy-paste configuration. In technologies like VPN, there are Dockerfiles with instructions such as "Put your config files here." By simply reusing the snippet, the docker engine copies the entire config directory upon build. The directory may include everything from the certificate to the private key and CA chain.

Last is overlooked clean-up. Even if someone briefly placed keys in the container for debugging, they might forget to remove them later. Or they might remove references to them in the Dockerfile but forget that the intermediate build layers are still part of the image history. If the registry stores not just the final image but also older layers, the keys remain discoverable.

Impact of exposed certificates and keys

The impact of exposed certificates and keys could range from disruptive to devastating. Upon leakage, threat actors can perform the following:

• VPN compromise - Exposed OpenVPN certificates and private keys let an attacker set up a rogue VPN or join an existing one. This opens up the company’s internal network to malicious traffic and data exfiltration.
• Unrestricted server access - If the SSH private key belongs to a privileged user, the attacker gains full administrative rights to the system. Once inside, they can move laterally, install backdoors, and cause persistent damage.
• Man-in-the-middle attacks - With a stolen SSL/TLS certificate and private key, an attacker can perform man-in-the-middle (MitM) attacks, especially if they intercept traffic or trick users into connecting through a malicious proxy.
• User impersonation - If the MitM attacks succeed, threat actors can collect the user credentials of the company's customers interacting with the system.
• Data theft - The obtained access allows threat actors to steal more sensitive customer and/or company data.
• Supply chain infection - Digital certificates are used for signing executables. When a build container becomes public, threat actors can infect the supply chain by adding malicious behavior to the binary executable. The binary is then signed with the leaked certificate. There is no visible change for the customer until the leaked certificate expires or is revoked.
  
  The general rule of thumb is: The more secrets are present in the container, the more successful the attack will be.
• Reputation damage - All of these could result in financial loss and reputation damage. Clients and partners could lose trust in the organization’s security practices. Even if the issue is remediated quickly, the damage to the company’s reputation could linger.

Figure 11. Leaked and unprotected SSH private keys

Misconceptions to watch out for

Regardless of the mitigation and security solutions companies have in place, it is essential not to be misled by any of these misconceptions:

Misconception 1: "My container is private. I am safe!"

Registries can be misconfigured in a split second. Users should be extra careful with self-hosted container registries, as their default settings do not require authentication. The moment it is inadvertently made public to everyone, threat actors could then obtain all the credentials. The notion of privacy goes straight out of the window.

Misconception 2: "I use docker ignore files. I am fine!"

Using .dockerignore helps reduce accidental copying of files, but it is not bulletproof. A single misstep in your Dockerfile or .dockerignore can defeat the purpose of the intended separation.

Misconception 3: "It is only a dev/test image."

Even if the environment is labeled as dev or test, the SSH keys or certificates might still be tied to a production system, or they might unlock other network resources. Attackers can glean valuable insights from dev images that help them breach production.

Misconception 4: "I will remove the file later."

Later means never. Intermediate image layers can contain the file history, so unless you handle multi-stage builds or remove layers properly, the data might still be discoverable in the image layer structure.

Risk mitigation and best practices

The key to preventing this nightmare scenarios is a combination of strict processes, code reviews, scanning solutions, and mindful development practices. The following are some recommendations:

Keep secrets out of images entirely

As a rule of thumb, any secret or credential, including certificates and private keys, should never be baked into a container image. Instead, consider using environment variables or secrets management solutions (like HashiCorp Vault, AWS Secrets Manager, or Docker/Kubernetes secrets) that inject credentials at runtime.

Suppose you have an SSL certificate named server.crt and its corresponding private key file server.key. You want to pass them into the container without hardcoding them in the Dockerfile or docker-compose.yml.

One option is to create secrets in your swarm:

$ docker secret create my_server_crt server.crt
$ docker secret create my_server_key server.key

Although Docker secrets are primarily used to create passwords, they also support keys and certificate files.

Implement image scanning

There are tools designed to scan container images for secrets, cryptographic keys, or even suspicious file names. Integrate these scanning steps into the CI/CD pipeline to catch exposed files before they ever land in a registry.

Proactive security solutions

The Trend Micro Artifact Scanner (TMAS) performs pre-runtime image, vulnerability, malware, and secret scans on certain artifacts.This enables you to identify and fix issues before they reach a production environment. TMAS is part of Trend Vision One™️the only AI-powered enterprise cybersecurity platform that centralizes cyber risk exposure management, security operations, and robust layered protection. This comprehensive approach helps you predict and prevent threats, accelerating proactive security outcomes across your entire digital estate. Backed by decades of cybersecurity leadership and Trend Cybertron, the industry's first proactive cybersecurity AI, it delivers proven results: a 92% reduction in ransomware risk and a 99% reduction in detection time. Security leaders can benchmark their posture and showcase continuous improvement to stakeholders. With Trend Vision One, you’re enabled to eliminate security blind spots, focus on what matters most, and elevate security into a strategic partner for innovation. 

Use multi-stage builds

Docker multi-stage builds allow keeping the final image clean. Choosing to copy only necessary artifacts into the production stage guarantees that development or debugging keys never make it into the final image.

Ensure that registries are private by default and enforce strict access control. Use strong authentication and role-based permissions to ensure that only trusted personnel and systems can pull or push images.

Encrypt secrets

Assume that no matter what we do, the secret will find a way to the image, code base, etc. At the end of the day, a certain level of trust has to be set, anyway. This requires ensuring the secrets are stored encrypted. The decryption is done on runtime, meaning the decryption key is not present in the image. As a result, the leaked secret ends up as a worthless binary blob for the threat actor.