Skip to content
Reverse Engineering
Credential Accessbeginner

SSH Key Theft

Harvesting unencrypted private keys and agent-forwarding sockets from a compromised host to enable onward SSH access to every system that trusts them.

SSH is the default remote-access protocol across most Linux and cloud infrastructure, and its trust model is built entirely on possession of a private key rather than a password an operator types each time. That makes a private key sitting unencrypted in a user's home directory one of the highest-value, lowest-effort finds on a compromised host: it is a ready-made credential for every other system that trusts it, with no cracking required.

How it works

The harvest targets a small, predictable set of locations:

text
~/.ssh/id_rsa, ~/.ssh/id_ed25519, ...   ; private keys (some passphrase-free)
~/.ssh/known_hosts                       ; reveals what else to target
~/.ssh/config                            ; per-host aliases, jump-host chains
$SSH_AUTH_SOCK                           ; a live ssh-agent socket can be
                                          ; abused to sign with a loaded key
                                          ; without ever reading its bytes

A passphrase-protected key is far less immediately useful than an unencrypted one — it still requires an offline cracking stage — but an attacker with an interactive session can also simply wait for the legitimate user to unlock it once, then either read the decrypted key from an ssh-agent or reuse the agent's forwarding socket directly. This is a particularly common way commodity Linux malware (cryptojacking/worming botnets) spreads: harvest keys and known_hosts from every host it lands on, then try each key against every host it reveals.

Detection & analysis

  • Static — A sample enumerating ~/.ssh/ across multiple user home directories, or one that specifically greps for PRIVATE KEY headers across the filesystem, is a strong tell — legitimate software has no reason to do this.
  • Dynamic — File-access monitoring on ~/.ssh/* from an unexpected process; on Linux, auditd watch rules on the .ssh directory; on macOS, Endpoint Security file-open events for the same path. A burst of outbound SSH connection attempts to hosts newly appearing in a compromised account's known_hosts is a strong lateral-movement signal.
  • Response — Because a stolen key is valid on every host that trusts it, treat confirmed key theft as requiring key rotation and removal of the corresponding public key from every authorized_keys file it appears in — not just re-securing the originating host.
  • Tools — auditd/EndpointSecurity file monitoring, Sysmon on Windows-hosted OpenSSH clients, YARA rules for PRIVATE KEY / OPENSSH PRIVATE KEY string patterns during static triage of a sample's filesystem-scanning logic.
Votes

Comments(0)