SSH Hijacking: How Attackers Ride Trusted Sessions Into Your Infrastructure

SSH was designed to be secure. And it is—until an attacker doesn't need to break the encryption. They just need to borrow your socket.

Secure Shell—SSH—is one of the most trusted tools in any sysadmin's or developer's toolkit. It encrypts traffic, authenticates via cryptographic keys, and has been the standard for remote administration since the late 1990s. But that trust is also what makes SSH hijacking so dangerous: an attacker who successfully pulls it off doesn't need to crack anything. They impersonate a session that is already authenticated, leveraging credentials and trust that were already established before they arrived.

SSH hijacking is not a single technique but a family of related attacks, each targeting a different design feature of the SSH protocol or its surrounding toolchain. The vectors exploited most often are SSH agent forwarding abuse, ControlMaster socket takeover, and direct manipulation of ~/.ssh/authorized_keys combined with privilege escalation. Understanding these vectors separately—and then together—is how you build a defense that holds.

What SSH Hijacking Actually Is

At its core, SSH hijacking refers to gaining unauthorized access to a remote system by piggybacking on an existing, authenticated SSH session or the authentication material that makes one possible. It is classified under lateral movement and credential access in the MITRE ATT&CK framework under the parent technique T1563 (Remote Service Session Hijacking), with the specific sub-technique T1563.001 (Remote Service Session Hijacking: SSH Hijacking) and T1098.004 (Account Manipulation: SSH Authorized Keys).

What separates SSH hijacking from a brute-force login or a key theft attack is that, in many hijacking scenarios, the attacker never interacts with the SSH daemon directly. They don't authenticate—they inherit authentication. The cryptographic layer is never bypassed; it is simply used by the attacker in the same way the legitimate user would use it.

Security researcher Rob Fuller (mubix) has characterized SSH agent forwarding as one of the more dangerous features present in many environments by default, arguing that a single compromised link in an agent forwarding chain can expose the full extent of an organization's SSH trust relationships. — Rob Fuller (mubix), "SSH Agent Hijacking," Room362.com

The attack typically begins with an initial foothold on a system—via phishing, a web shell, a misconfigured service, or any number of other entry points. What makes SSH hijacking the next step is what that compromised host has running on it at the time. If a privileged user has an active SSH session with agent forwarding enabled, or if a ControlMaster socket is sitting in a world-readable /tmp directory, the attacker has a path to move laterally without ever needing to steal or crack a single key.

Agent Forwarding: The Most Abused Feature in SSH

SSH agent forwarding, enabled via the -A flag or ForwardAgent yes in ~/.ssh/config, is a convenience feature that lets your SSH authentication agent—typically ssh-agent—follow you through hop-to-hop connections. When you SSH from your laptop to a jump host and then from the jump host to a production server, agent forwarding means you don't have to store your private key on the jump host. Instead, cryptographic operations are forwarded back to your local machine.

This is the intended behavior, and it's a reasonable design. The problem is what happens on the intermediate host. When agent forwarding is active, the SSH daemon on the jump host creates a Unix domain socket—typically something like /tmp/ssh-XXXXXXXXX/agent.XXXXX—and sets the environment variable SSH_AUTH_SOCK to point to it. Any process on that host with read/write access to that socket can use your agent to authenticate as you.

On a multi-user system, root can access any user's agent socket. But more importantly, any process running as the same UID as the SSH session owner can access it. This is why agent forwarding is particularly lethal in environments where users share jump hosts, or where automation pipelines run under shared service accounts with ForwardAgent yes baked into their SSH configs.

The attack itself is straightforward once access is established. On a compromised host, an attacker lists agent sockets, sets SSH_AUTH_SOCK to point at a target socket, and uses ssh-add -l to enumerate the loaded keys. From there, they can SSH to any host that trusts those keys—often including production servers, internal tooling, cloud provider API gateways, and deployment systems. MITRE ATT&CK tracks the resulting lateral movement as T1021.004 (Remote Services: SSH), which captures how adversaries leverage valid SSH credentials—whether obtained through theft or inherited through a hijacked agent—to log into remote machines as an authenticated user.

# Attacker already has shell on a compromised jump host
# Find active agent sockets
find /tmp -name 'agent.*' 2>/dev/null

# Hijack the forwarded agent
export SSH_AUTH_SOCK=/tmp/ssh-AbCdEfGhI/agent.12345

# Enumerate keys available through the hijacked agent
ssh-add -l

# Move laterally using the hijacked identity
ssh user@internal-prod-server

No privilege escalation required in many cases. If the attacker has already gained access as the same user who owns the agent socket—through a web shell, a deserialization exploit, or a misconfigured sudo rule—this is a completely unprivileged lateral movement technique.

ControlMaster and Socket Abuse

SSH's ControlMaster feature is a connection multiplexing mechanism. When enabled in ~/.ssh/config, the first SSH connection to a host creates a master socket. Subsequent connections to the same host reuse the existing authenticated connection without requiring new authentication. This speeds things up considerably for operations involving many rapid SSH connections, like Ansible runs or repeated scp calls.

# Typical ControlMaster configuration in ~/.ssh/config
Host *
    ControlMaster auto
    ControlPath ~/.ssh/sockets/%r@%h:%p
    ControlPersist 10m

The attack surface here is the ControlPath socket. If that socket is stored in a directory with weak permissions, or if ControlPersist is set to a long duration, an attacker with access to the filesystem can attach to the socket and piggyback on the existing connection.

Security researcher Rogan Dawes (SensePost) has described ControlMaster sockets as pre-authenticated tunnels left open on disk—when ControlPath resolves to a world-readable location, the socket functions as an open authenticated door for any attacker who gains access to the host. — Rogan Dawes, SensePost, on SSH multiplexing risks in red team operations

The ssh -S flag allows specifying a control socket path explicitly. An attacker who has found a valid ControlMaster socket can connect through it directly:

# Attacker connects through an existing ControlMaster socket
ssh -S /tmp/ssh-control-sockets/user@target:22 user@target

This works even if the attacker has no private key for the target host. The socket represents an already-authenticated session. The SSH client simply sends the new connection request through the existing tunnel, and the target host sees a legitimate connection from a trusted source.

ControlPersist makes this worse. When set to a duration like 10m or simply yes, the master connection stays alive even after the user closes their terminal. An attacker who arrives on a system minutes or hours after the original user has left can still find live sockets and use them. In environments with deployment automation that runs heavy SSH workloads, these persistent sockets may never expire at all.

Authorized Keys Manipulation: The Persistence Play

Agent forwarding and ControlMaster abuse are session-level attacks—they are alive only as long as a socket or active session exists. The ~/.ssh/authorized_keys attack is different in character. It's a persistence mechanism. An attacker who already has write access to a user's home directory, or who has escalated to root, can add their own public key to the authorized keys file and return at will—indefinitely, silently, without any need to catch an active session.

Before planting their own key, however, attackers frequently harvest existing private key material from the compromised host. MITRE ATT&CK tracks this under T1552.004 (Unsecured Credentials: Private Keys)—adversaries search for .pem, id_rsa, id_ed25519, and similar key files stored without passphrases. The presence of unprotected private keys on shared hosts or CI/CD runners is common, and those keys often grant access to the same infrastructure the attacker is already trying to reach through socket hijacking.

The mechanics are straightforward. The authorized_keys file contains one public key per line. An attacker appends theirs:

# Attacker with write access to a user's home directory
echo "ssh-ed25519 AAAAC3Nza... attacker@c2" >> ~/.ssh/authorized_keys

The SSH daemon reads this file at authentication time and will accept connections from whoever holds the corresponding private key. No password required, no MFA required unless SSH is configured to require a second factor unconditionally for all key-based logins (many environments are not). The attacker's key sits alongside legitimate keys and is essentially invisible unless someone is specifically auditing the file.

MITRE ATT&CK tracks this under T1098.004. What makes it particularly dangerous is its interaction with the rest of the kill chain: agent forwarding and ControlMaster abuse give an attacker immediate access for lateral movement; authorized_keys manipulation gives them a way back if the initial session is disrupted or the investigation starts.

Detection here is simpler than for socket abuse, but it requires that someone is actually watching. File integrity monitoring on ~/.ssh/authorized_keys across all user accounts, alerting on any modification, is one of the highest-value FIM rules an organization can implement. The signal is unambiguous: authorized_keys should not change outside of a provisioning workflow. Any modification outside that workflow warrants immediate investigation.

Real-World Usage by Threat Actors

SSH hijacking is not a theoretical attack confined to conference talks. It appears consistently in post-incident analyses of sophisticated intrusions, particularly in cases involving lateral movement through cloud and hybrid environments.

MITRE ATT&CK documents real-world usage of SSH agent hijacking under T1563.001, noting that adversaries have used this technique to move from a compromised bastion host to internal infrastructure. The technique requires no additional tooling beyond standard Unix utilities, generates minimal anomalous traffic (the connections look identical to legitimate SSH usage), and leaves very limited forensic artifacts on intermediate hosts.

The 2020 SolarWinds supply chain compromise, while primarily known for its use of trojanized software updates and novel SAML token forgery techniques, also involved the abuse of trusted credentials and session material for lateral movement once initial access was established. Post-compromise analysis by FireEye (now Mandiant) described adversary behavior consistent with credential and session reuse patterns that include SSH session material. The full Mandiant report, published December 2020, documented the attackers' extensive use of existing authentication mechanisms rather than exploiting new vulnerabilities post-access. [1]

More directly, the SANS Internet Storm Center has logged repeated observations of post-compromise scripts that automatically scan for agent sockets and ControlMaster files as part of automated lateral movement toolkits. Security researcher Seth Art published a detailed analysis in 2018 documenting the specific steps red teams and threat actors use to enumerate and abuse SSH agent sockets on compromised Linux hosts. [2]

Red team practitioners who routinely audit enterprise Linux environments report finding at least one exploitable condition on nearly every engagement: a sudo misconfiguration, an exposed agent socket, or an accessible ControlMaster path. The pattern is consistent enough to be treated as a planning assumption rather than a best-case scenario. — Seth Art, "SSH Agent Hijacking," BishopFox.com, 2018

The Lazarus Group, North Korea's primary state-sponsored threat actor, has been documented using SSH-based lateral movement techniques in intrusions targeting financial institutions and cryptocurrency platforms. A 2023 joint advisory from CISA, NSA, and FBI (AA23-055A) specifically called out SSH key abuse in the context of North Korean threat actor TTPs, noting that adversaries regularly harvest SSH key material from compromised hosts for use in subsequent lateral movement. [3]

In cloud environments, the problem is compounded by the way many organizations deploy SSH. Bastion hosts with agent forwarding enabled connect to dozens or hundreds of internal instances. A single compromise of the bastion yields access to every host that trusts the forwarded agent's keys—effectively making agent forwarding abuse a one-step full-environment compromise in poorly segmented architectures.

How to Detect It

Detecting SSH hijacking is difficult precisely because the traffic it generates is indistinguishable from legitimate SSH traffic. The connections are authenticated, encrypted, and come from hosts that would normally be expected to connect. However, there are several signals that, when correlated, can reveal hijacking activity.

Agent Socket Activity

On Linux systems using auditd, process creation events that reference SSH_AUTH_SOCK in an unexpected context are worth flagging. Specifically, look for processes that set or read SSH_AUTH_SOCK outside of an expected user shell session. Auditd rules targeting execve calls involving ssh or ssh-add from unusual parent processes are a useful starting point.

# auditd rule to watch for ssh-add invocations
-a always,exit -F arch=b64 -S execve -F exe=/usr/bin/ssh-add -k ssh_agent_use

# Watch for SSH connections with unusual parent processes
-a always,exit -F arch=b64 -S execve -F exe=/usr/bin/ssh -k ssh_lateral

Anomalous SSH Connection Patterns

Legitimate SSH sessions from a given jump host to internal targets will typically follow predictable patterns: specific users, specific destination IPs, specific times of day. SIEM correlation rules that flag SSH connections from a bastion host at unusual hours, to unusual destinations, or under unusual user accounts are effective at surfacing hijacking activity—particularly when it follows shortly after an unexpected connection to the bastion itself.

Socket File Permissions and Locations

Security tooling that monitors /tmp for newly created Unix domain sockets, or that alerts on agent sockets with permissions broader than 700, can catch misconfigured ControlMaster paths before they are abused. Tools like auditd, osquery, and EDR platforms with file integrity monitoring capabilities can all be configured to flag these conditions.

# osquery query to find SSH control sockets
SELECT * FROM file
WHERE path LIKE '/tmp/%'
AND type = 'socket'
AND (permissions NOT LIKE '--------%' OR uid != (SELECT uid FROM users WHERE username = 'root' LIMIT 1));

SSH Daemon Logging

OpenSSH's LogLevel VERBOSE setting causes sshd to log the public key fingerprint used for each authentication. In an agent-forwarding hijacking scenario, the same key fingerprint will appear in authentication logs from two different source addresses in close temporal proximity. This is a strong indicator of session hijacking and is easy to detect with log correlation.

What to Actually Do When You Catch It

The detection section describes signals. This section covers what happens after those signals fire. SSH hijacking is a lateral movement technique, which means by the time you detect it, an attacker already has a foothold and has been moving. The response workflow has to account for that.

Immediate Containment

The first priority is stopping the bleeding without destroying forensic evidence. Kill active SSH sessions from the compromised host using pkill -u [username] sshd if you need to terminate sessions for a specific user, or isolate the host at the network layer (security group changes, firewall rule drops) if the scope is wider. Do not simply reboot—this destroys in-memory artifacts and clears /tmp, which may contain agent sockets you want to document first.

# List active SSH sessions before killing them
who
ss -tnp | grep sshd

# Find and document agent sockets before containment
find /tmp -name 'agent.*' -o -name 'ssh-*' 2>/dev/null | xargs ls -la

# Check authorized_keys on all accounts before containment
for user in $(cut -d: -f1 /etc/passwd); do
    keyfile="/home/$user/.ssh/authorized_keys"
    [ -f "$keyfile" ] && echo "=== $user ===" && cat "$keyfile"
done

Scope the Blast Radius

Determine which keys were accessible through hijacked sockets. ssh-add -l run against captured socket paths tells you what identities were exposed. Cross-reference those key fingerprints against your SSH CA records or known authorized_keys entries to understand which hosts could have been reached. In environments without a central SSH CA or key inventory, this step is painful—which is itself a finding.

Rotate Everything the Attacker Could Have Used

Any key fingerprint that was accessible via a hijacked agent socket during the window of compromise should be treated as exposed. Rotate those keys, revoke old authorized_keys entries across all hosts, and reissue certificates if you're using certificate-based authentication. For authorized_keys manipulation specifically, audit every account on every host that the attacker could have reached—not just the initial compromise host—and remove any keys that are not in your provisioning baseline.

Preserve Logs Before They Rotate

SSH daemon logs, auditd logs, and shell history from the affected hosts are time-sensitive. Export them to a write-once location (S3 with object lock, a SIEM, or an isolated log aggregator) before they roll. If the attacker had shell access, also check whether ~/.bash_history or equivalent was cleared—a blank history file on a recently active account is itself an indicator.

Hardening SSH Against Hijacking

The defensive posture against SSH hijacking starts with honest configuration hygiene. Many of the conditions that enable these attacks are default settings or convenience features that were added without adversarial scenarios in mind.

Disable Agent Forwarding by Default

The OpenSSH server-side directive AllowAgentForwarding no in /etc/ssh/sshd_config disables agent forwarding at the daemon level regardless of what the client requests. This should be the default on any host that is not explicitly a jump host. For jump hosts that require forwarding, restrict which users are permitted to use it with Match blocks.

# /etc/ssh/sshd_config - disable agent forwarding globally
AllowAgentForwarding no

# Re-enable only for specific groups with a Match block
Match Group jumpadmins
    AllowAgentForwarding yes

Lock Down ControlMaster Socket Paths

If ControlMaster is in use, the ControlPath directive should resolve to a directory under the user's home directory with permissions 700, not under /tmp. Setting a short ControlPersist timeout (60 seconds is reasonable for interactive use; automation should use ControlPersist no) minimizes the window during which an abandoned socket can be exploited.

# Safer ControlMaster configuration
Host *
    ControlMaster auto
    ControlPath ~/.ssh/sockets/%r@%h:%p
    ControlPersist 60s

Ensure ~/.ssh/sockets/ exists with permissions 700. The SSH client will create it if it doesn't exist, but it will use whatever permissions the umask dictates—which may be more permissive than desired on shared systems.

Use Certificate-Based Authentication with Short-Lived Certs

SSH certificates issued by an internal certificate authority, with short validity windows (minutes to hours rather than days), dramatically reduce the value of harvested session material. OpenSSH has supported certificate-based authentication since version 5.4 (2010), yet adoption in enterprise environments remains low. Tools like HashiCorp Vault's SSH Secrets Engine, Cloudflare's SSHCA tooling, and Netflix's BLESS all implement short-lived SSH certificate issuance at scale. [4]

Infrastructure security practitioner Mike Julian has argued that switching from long-lived static keys to short-lived certificates backed by a proper CA represents the single highest-impact improvement available to most organizations—because it transforms stolen key material and hijacked agents from persistent threats into time-bounded ones. — Mike Julian, "Practical SSH Hardening for Production Environments," 2023

Does MFA Actually Help Here?

This question deserves a direct answer, because a lot of organizations implement SSH MFA and then consider the problem solved. It is not solved. Pluggable Authentication Modules can enforce a second factor at session establishment—pam_google_authenticator and similar modules integrate with OpenSSH via ChallengeResponseAuthentication yes and AuthenticationMethods publickey,keyboard-interactive. This raises the bar for the initial compromise that enables hijacking, which matters.

But MFA does not prevent agent forwarding abuse or ControlMaster socket takeover once a session is authenticated. The hijacker is not re-authenticating through the SSH daemon. They are talking directly to the agent socket or the ControlMaster socket, both of which have no concept of a second factor—authentication already happened, from their perspective. MFA protects the front door. It does nothing about the window the last person left open.

Network Segmentation and SSH Proxy Controls

Restricting SSH access so that only designated bastion hosts can initiate connections to internal targets—enforced at the network layer, not just by policy—limits the blast radius of a successful hijack. Even if an attacker pivots through a bastion via agent hijacking, they cannot reach targets that are not accessible from that bastion. Combining this with host-based firewalls (nftables, iptables) that whitelist only specific source IPs for SSH access creates meaningful friction.

Privileged Access Workstations and Zero-Trust SSH

Modern zero-trust SSH platforms—including Teleport, StrongDM, and similar tools—replace direct SSH access with brokered sessions that are recorded, audited, and bound to short-lived certificates. These architectures eliminate the persistent socket and long-lived key material problems at the architectural level rather than relying on configuration hardening of individual hosts.

SSH Certificate Authority with Enforcement at the Host Level

Simply issuing short-lived certificates is not sufficient if hosts still accept static keys as a fallback. The architectural fix requires configuring sshd_config on every internal host to set AuthorizedKeysFile none and rely exclusively on a TrustedUserCAKeys directive pointing to your internal CA's public key. This eliminates the authorized_keys persistence vector entirely—an attacker who compromises a host and attempts to plant a key in ~/.ssh/authorized_keys will find that sshd ignores the file. The CA becomes the sole gate. Combined with certificate validity windows of four to eight hours and principal constraints that bind a certificate to a specific username, this approach means hijacked session material expires on a predictable schedule regardless of how it was obtained.

# sshd_config - CA-only enforcement, no static key fallback
TrustedUserCAKeys /etc/ssh/trusted_user_ca.pub
AuthorizedKeysFile none

# Optionally restrict which principals are allowed to log in
AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u

Restrict What a Forwarded Agent Can Sign

OpenSSH 8.9 and later supports ssh-agent key constraints that limit which hosts a loaded key can be used to authenticate against. Rather than a blanket disable of agent forwarding, administrators can load keys into the agent with destination restrictions that prevent the agent from signing authentication challenges for hosts outside a defined allowlist. The constraint travels with the key in the agent, not with the socket. This means even if an attacker hijacks the socket and attempts to use a loaded key to reach a host that is not on the destination list, the agent refuses to sign the challenge.

# Load a key with destination restrictions (OpenSSH 8.9+)
ssh-add -h user@jumphost -h user@prod-server ~/.ssh/id_ed25519

# The key can only be used to authenticate to jumphost and prod-server
# Any attempt to use it against other targets will fail

Audit Socket Exposure with Continuous Runtime Visibility

Static configuration hardening only addresses known misconfigurations at a point in time. Operators and CI systems regularly introduce ad-hoc ssh -A invocations, Ansible playbooks with ssh_args: -o ForwardAgent=yes, and Terraform remote-exec provisioners that ignore the sshd_config defaults. A persistent runtime audit layer—using osquery with scheduled queries, Falco rules watching for SSH_AUTH_SOCK being set in unexpected process lineages, or EDR telemetry that tracks Unix domain socket creation under /tmp—catches the drift that configuration management misses. The signal to build toward: any process that accesses an agent socket whose parent process chain does not include a known-good SSH daemon invocation warrants immediate alert and automated session termination.

# Falco rule: alert on unexpected SSH_AUTH_SOCK access
- rule: Unexpected SSH Agent Socket Access
  desc: A process read SSH_AUTH_SOCK outside an expected shell context
  condition: >
    spawned_process and
    proc.env contains "SSH_AUTH_SOCK" and
    not proc.name in (ssh, ssh-add, scp, rsync, ansible) and
    not proc.pname in (sshd, bash, zsh)
  output: "Unexpected SSH agent socket access (user=%user.name proc=%proc.name parent=%proc.pname)"
  priority: WARNING

Namespace and UID Isolation for Service Accounts

Agent forwarding abuse requires the attacker's process to share a UID with the session owner—or be root. Service accounts used by CI/CD pipelines and automation tooling should therefore run under dedicated UIDs with no other processes sharing that UID on the same host. On Linux, this can be enforced with user namespaces that give the service a private UID mapping, preventing any process outside the namespace from accessing its agent socket even with root on the host. For container-based CI runners, ensuring runners execute in isolated user namespaces and never mount the host's /tmp filesystem eliminates the socket enumeration path entirely. This is a structural control—it makes the attack geometrically harder rather than just harder to notice.

Bastion Host Replacement with Session-Brokered Access

The most durable fix for the bastion host problem is to retire the bastion model entirely for privileged access. Session brokering tools—Teleport, StrongDM, AWS Systems Manager Session Manager, Google Cloud IAP TCP forwarding—interpose a control plane between the operator and the target host. The operator never holds a private key that grants direct SSH access. Instead, they authenticate to the broker, which issues a short-lived credential scoped to the specific session and target. Agent forwarding is irrelevant because there is no SSH agent forwarding in the architecture. The broker records the session, enforces RBAC, and revokes access centrally. This is not a configuration hardening of SSH—it is a replacement of the threat surface.

Key Takeaways

1. Agent forwarding is not safe by default on shared hosts: Any process running as the same UID as a session with agent forwarding can use the forwarded agent to authenticate as that user to any host the user's key trusts. Disable it globally and re-enable only where explicitly needed.
2. ControlMaster sockets are pre-authenticated handles: A socket in a world-readable or group-readable location is an open door. Lock ControlPath to a user-owned directory with mode 700, and set a short ControlPersist timeout.
3. Authorized_keys manipulation is the persistence layer: Agent and socket abuse give an attacker immediate access. An unauthorized key in authorized_keys gives them permanent access. File integrity monitoring on authorized_keys files, with alerting on any change outside provisioning workflows, is one of the highest-signal FIM rules you can implement.
4. MFA helps with initial access. It does not help here: SSH MFA protects the moment of authentication. It has no effect on agent socket abuse or ControlMaster takeover, both of which operate after authentication has already occurred. MFA is a layer, not a solution to this class of attack.
5. The traffic looks legitimate because it is legitimate: Detection cannot rely on anomalous packet contents. Effective detection uses process-level telemetry, log correlation (same key fingerprint, different sources), and behavioral baselines for SSH connection patterns.
6. Short-lived certificates are the architectural fix: Moving from long-lived static keys to certificate-based authentication with short validity windows eliminates the persistent value of hijacked agent material. This is the direction the industry is moving, and for good reason.
7. Post-compromise speed matters: SSH hijacking is a lateral movement technique that requires an existing foothold. The faster an organization detects and contains the initial compromise, the less opportunity an attacker has to pivot via agent or socket abuse. Detection and response time is a defensive multiplier here.

SSH hijacking sits in an uncomfortable place in the threat landscape: it is genuinely difficult to detect, requires no specialized tooling, produces no exploits that endpoint defenses would flag, and succeeds in the kinds of environments—shared jump hosts, CI/CD pipelines, cloud bastion architectures—that are common in mature organizations. The three techniques covered here—agent forwarding abuse, ControlMaster socket takeover, and authorized_keys manipulation—are frequently used together in the same intrusion: the first two for lateral movement during the active session, the third for persistence afterward. The defense is not a single fix but a configuration posture: minimize forwarding, lock socket paths, shorten credential lifetimes, audit authorized_keys continuously, and build detection that looks at behavior rather than content. And have an incident response workflow ready—because knowing what you're looking at is only useful if you know what to do about it. The attackers are counting on the assumption that you haven't done all of that yet.