SSH is built to avoid typing passwords again and again. The agent holds your unlocked key so every new connection is instant. That convenience is also a target. SSH Hijacking (T1563.001) is a Lateral Movement technique for Linux and macOS, and a subtechnique of Remote Service Session Hijacking.
How attackers use it
MITRE explains that SSH is the standard means of remote access on Linux and macOS. It builds an encrypted tunnel, and authentication commonly uses a password, a certificate, or an asymmetric key pair.
To move laterally from a compromised host, adversaries can use the trust relationships created through public key authentication in active SSH sessions, by hijacking an existing connection to another system. MITRE says this can happen through compromising the SSH agent itself, or through access to the agent's socket. With root access, MITRE says hijacking SSH sessions is likely trivial.
This differs from use of SSH as a Remote Service, because it takes over an existing session rather than creating a new one with Valid Accounts. So there may be no new login to see.
How an agent socket becomes a risk
When you connect with an agent, a socket file is created, and an environment variable named SSH_AUTH_SOCK points to it. Any process that can read that socket can ask the agent to authenticate. The owner's file permissions protect it, and root can bypass them.
Agent forwarding extends the problem. It makes the socket reachable on the remote machine you logged into, so an administrator or attacker with root on that machine can use your keys. This is why MITRE's first recommendation on this technique is to disable agent forwarding where it is not needed.
How to detect it
MITRE's analytics, for Linux and macOS:
- Reuse of SSH agent sockets across multiple users or processes.
- Unusual access to agent sockets in /tmp or /private/tmp, and to the user's ~/.ssh directory.
- Process access to another user's SSH_AUTH_SOCK.
- Lateral SSH activity with no corresponding login events, correlated with unusual network flows to internal systems.
Auditing access to socket files, with auditd on Linux, is a good place to start. You are looking for a process owned by one user touching another user's socket.
Making agent forwarding the exception
Agent forwarding is useful but it expands who can use your keys. If you need to reach a server through a jump host, there are safer patterns. The SSH client supports a ProxyJump option, written as ssh -J jumphost target, which passes the connection through the jump host without exposing your agent there. That is a widely documented alternative, and it is worth standardizing in your team's SSH configuration.
Where an agent is needed, limit its reach:
- Add keys with a lifetime, so they drop out of the agent automatically. The
ssh-add -toption sets that lifetime. - Use keys protected by a passphrase, as MITRE advises.
- Use separate keys for separate purposes, so a hijacked session reaches less.
Responding to suspected hijacking
If you think an agent or a session was abused:
- Identify which user's session and which hosts it could reach, using the authorized keys files on those hosts to see where the key was trusted.
- End the agent and any suspicious sessions. Unload the keys.
- Rotate the key pair, remove the old public key from every authorized keys file, and distribute the new one.
- Review those target hosts for activity that has no matching login event, which is the signature MITRE describes.
- Close the path that gave the adversary access to the socket, such as a root compromise or an over-permissive forwarding setting.
Remember the point from MITRE: with root, hijacking is likely trivial. If root was compromised on the host where the agent lived, assume the keys were usable.
How to reduce the risk
MITRE lists four mitigations.
- Restrict file and directory permissions. Set proper file permissions, and harden the system to prevent root privilege escalation, since root makes hijacking trivial.
- Disable or remove feature or program. Disable agent forwarding on systems that do not explicitly need it.
- Password policies. Protect SSH key pairs with strong passphrases, and avoid key stores such as ssh-agent unless they are properly protected.
- Privileged account management. Do not allow SSH access as root or other privileged accounts.
Check your own environment
These checks read state only.
# Linux or macOS: which keys does my agent currently hold?
ssh-add -l
# Linux or macOS: where is my agent socket?
echo $SSH_AUTH_SOCK
# Linux: list agent sockets in /tmp and their owners
ls -l /tmp/ssh-*
# Linux (as root): what is the effective agent forwarding setting for the SSH server?
sshd -T | grep -i allowagentforwarding
Then ask:
- Is agent forwarding enabled on servers that are only ever jump targets?
- Do your SSH keys have passphrases, and do you know which hosts trust each key?
- Does anyone log in as root over SSH?
Private keys also leak through code and configuration. The demo below shows how secret scanning finds credentials that were never meant to be shared.
Click through it at your own pace, or open it full screen.
Common mistakes
- Enabling agent forwarding globally in the client configuration for convenience, so every connection exposes the agent.
- Relying on file permissions alone for sockets on hosts where many people have root.
- Rotating the key but leaving the old public key in authorized keys files, which keeps the old trust path open.
Quick check
What two routes does MITRE name for hijacking an SSH session?
Compromising the SSH agent itself, or gaining access to the agent's socket.
Why is root access so important to this technique?
File permissions protect the agent socket from other users, but root can bypass them. MITRE says hijacking is likely trivial for an adversary with root.
