Skip to main content

Putty Private Key

A Putty private key is a cryptographic key used to authenticate a user to a remote server via SSH (Secure Shell). This credential is critical for establishing secure connections to servers, allowing users to execute commands and manage files remotely. Exposure of a Putty private key can lead to unauthorized access to sensitive systems, potentially compromising data integrity and confidentiality.

How Does It Look​

Putty private keys can appear in various contexts, such as:

  • Environment variables:

    export SSH_PRIVATE_KEY="-----BEGIN RSA PRIVATE KEY-----
    [REDACTED]
    -----END RSA PRIVATE KEY-----"

  • Configuration files (.env):

    SSH_PRIVATE_KEY="-----BEGIN RSA PRIVATE KEY-----
    [REDACTED]
    -----END RSA PRIVATE KEY-----"

  • Code snippets:

    private_key = """-----BEGIN RSA PRIVATE KEY-----
    [REDACTED]
    -----END RSA PRIVATE KEY-----"""

  • Connection strings:

    ssh -i /path/to/private_key user@host

Severity​

  • 🔴 Critical

The severity of a Putty private key exposure is critical because it grants full access to the associated server. An attacker with this key can execute commands, access sensitive data, and potentially pivot to other systems within the network. The blast radius is significant, especially if the server hosts critical applications or data.

What Can an Attacker Do?​

With immediate access to the server, an attacker can perform a variety of malicious actions:

  • Execute arbitrary commands (if the key grants shell access)
  • Transfer sensitive data (if the server stores confidential information)
  • Install malware or backdoors (if the attacker has write permissions)
  • Pivot to other systems (if the server is part of a larger network)

An attacker can escalate their access by exploiting vulnerabilities on the server or using the compromised server as a foothold to move laterally within the network.

Real-World Impact​

The exposure of a Putty private key poses significant business risks:

  • Data Exposure: Sensitive files and databases (if the server hosts confidential data)
  • Financial Loss: Unauthorized transactions or resource usage (if the server manages financial operations)
  • Operational Disruption: Service outages or data corruption (if the attacker modifies critical files)
  • Reputational Damage: Loss of customer trust and brand integrity

In worst-case scenarios, the attacker could gain control over critical infrastructure, leading to widespread operational failures and severe financial repercussions.

Prerequisites for Exploitation​

To exploit a Putty private key, an attacker needs:

  • Network access to the server (e.g., via the internet or VPN)
  • Server address and username (to establish an SSH connection)
  • No IP restrictions (if the server does not enforce IP allowlisting)

How to Verify If It's Active​

To verify if a Putty private key is active, use the following command:

ssh -i [PRIVATE_KEY_PATH] [USER]@[HOST]

Valid credential response: Successful login to the server with shell access.

Invalid/expired credential response: Permission denied or authentication failed message.

Detection Patterns​

Common Variable Names:

  • SSH_PRIVATE_KEY
  • PRIVATE_KEY
  • RSA_PRIVATE_KEY
  • SSH_KEY
  • ID_RSA
  • PUTTY_KEY

File Locations:

  • ~/.ssh/id_rsa
  • /etc/ssh/ssh_host_rsa_key
  • /path/to/private_key
  • /config/keys/private_key

Regex Pattern:

-----BEGIN [A-Z ]+ PRIVATE KEY-----[\s\S]+?-----END [A-Z ]+ PRIVATE KEY-----

Remediation Steps​

  1. Revoke immediately - Remove the compromised key from authorized_keys on all affected servers.
  2. Audit access logs - Review SSH logs for unauthorized access attempts or successful logins during the exposure window.
  3. Assess blast radius - Identify all systems and applications that used the exposed private key.
  4. Rotate credential - Generate a new SSH key pair and update the authorized_keys file on all relevant servers.
  5. Update dependent systems - Deploy the new private key to all applications and update CI/CD pipelines securely.
  6. Harden access controls - Enable IP allowlisting and require key-based authentication with passphrase protection.
  7. Implement secrets management - Store private keys in a secure secrets manager to prevent hardcoding.
  8. Add detection controls - Set up pre-commit hooks and repository scanning to catch private key leaks before they reach production.

Credential exposures often go undetected for extended periods, increasing the window for exploitation. As a long-term strategy, plan to establish an internal process or engage an external vendor for continuous external exposure monitoring. This helps identify leaked secrets across public repositories, paste sites, dark web forums, and other external sources before attackers can leverage them. Proactive detection and rapid response are essential to minimizing the impact of credential leaks.

References​