China-Linked Velvet Ant Backdoored Linux Authentication to Stay Hidden for Years

A China-nexus intrusion tracked by Sygnia as Velvet Ant shows how dangerous a compromise becomes when attackers stop hiding near the login process and start hiding inside it. In Operation Highland, Sygnia says the group spent years inside an internal network with no direct internet access, then maintained access by replacing trusted Linux authentication components with backdoored versions.

The affected platforms are not obscure. Sygnia’s report centers on Linux hosts using Linux-PAM, especially pam_unix.so, and modified OpenSSH binaries such as ssh, sshd, and scp. Those are the exact components administrators rely on to sign in, move files, troubleshoot outages, and recover systems. When they are altered, password resets and session termination become incomplete responses because the attacker may still control the code that receives the next password.

Sygnia’s investigators describe the case as a “near-decade of undetected presence,” with the earliest artifacts dating back to 2016. The target network had “no direct internet connectivity,” according to the firm, but the attackers still reached it by staging through internet-facing systems, tunneling through the IT environment, and using web infrastructure as a bridge into the isolated segment.

That is the hook for security teams: isolation helped, but it did not equal assurance. Network segmentation reduced direct exposure, yet the attackers built a path around it and then embedded persistence in software that defenders often assume is clean unless a package manager says otherwise.

What Happened

Sygnia says Velvet Ant followed a staged path. First, the group established access on internet-facing systems. The report describes use of a modified GS-Netcat binary, disguised under a system-like name, plus a SOCKS5 proxy used for tunneling and lateral movement. From there, the attackers abused Nginx and FastCGI behavior to create an execution path into the restricted environment. The setup allowed remote commands to be passed through ordinary-looking web requests without requiring direct internet connectivity to the critical segment.

The most serious part came later. Once inside, Velvet Ant modified the authentication layer itself. Sygnia found nine distinct backdoored pam_unix.so variants across compromised hosts. Some variants accepted a hardcoded password that bypassed normal authentication. Others captured legitimate usernames and passwords during real login attempts and stored them for later use. Several details, including different build paths and per-host compatibility work, suggest this was not a quick opportunistic modification.

OpenSSH was altered in similar fashion. Sygnia found modified ssh, sshd, and scp binaries that could capture credentials, log commands typed during sessions, and hide parts of the attacker’s own activity. One version included a custom flag that disabled malicious logging, which meant operators could use the compromised tooling while reducing their own forensic trail.

This turns the normal defender playbook inside out. If malware runs as a separate process, responders can kill the process, remove a service, delete a scheduled task, rotate credentials, and watch for re-entry. If sshd and PAM are modified, every new login may feed the attacker fresh credentials. Every command typed by an administrator may be recorded. Every emergency recovery step may be observed.

Why PAM and OpenSSH Matter

PAM, short for Pluggable Authentication Modules, is a framework that lets Linux services use a common authentication stack. A login prompt, SSH session, sudo, and other services can all call into PAM modules depending on the system’s configuration. The Linux-PAM project is explicit about the operational risk of this layer: a bad install can make a system stop working. That warning is meant for administrators compiling or installing PAM, but it also explains why attackers prize it. PAM sits where trust is decided.

OpenSSH is just as central. The OpenSSH project provides the standard remote login and secure file transfer tools used across Linux, BSD, macOS, network appliances, and many enterprise products. It encrypts sessions, supports several authentication methods, and includes both client-side and server-side components. If sshd is modified, the server can accept backdoor credentials or collect real ones. If the client is modified, outbound administrator sessions can be observed too.

That client-side angle is easy to miss. Many teams think of SSH risk as a server exposure problem: patch the daemon, restrict source IPs, disable passwords, enforce keys, review sshd_config. Operation Highland shows a broader problem. A compromised SSH client on an admin workstation or jump host can steal credentials for other systems as the administrator connects outward. A backdoored scp can alter file movement and weaken SELinux controls if run with enough privilege. Authentication tooling is both a door and a recorder.

Expert Context

Sygnia frames Operation Highland as part of a repeated Velvet Ant pattern: when defenders find one foothold, the actor moves into infrastructure that receives less scrutiny. In 2024, the firm reported Velvet Ant activity involving F5 BIG-IP appliances and later a Cisco Nexus switch campaign tied to CVE-2024-20399. The NVD entry for that flaw describes a Cisco NX-OS command injection issue requiring administrator credentials, with successful exploitation allowing root-level command execution on affected devices.

That distinction matters. CVE-2024-20399 was not a simple unauthenticated internet break-in. It was useful after privileged access already existed. The vulnerability helped turn a switch into a stronger persistence point. CISA added the issue to its Known Exploited Vulnerabilities catalog on July 2, 2024, with required action by July 23, 2024, according to the NVD record. Cisco’s advisory is linked from the same NVD page and remains the right starting point for affected Nexus environments.

The practical thread is consistent: edge appliances, switches, login modules, and remote access binaries often live below the level where daily detection work happens. Security operations teams may have mature endpoint telemetry on Windows laptops, cloud workload alerts, EDR on standard Linux servers, and SIEM rules for identity providers. They may have far less visibility into load balancers, old Linux hosts, jump servers, network devices, or isolated production segments.

That gap is exactly where long-running intrusion operators like to work. They do not need a noisy exploit every day if they can turn a trusted component into a credential tap or a hidden door.

Why Password Resets Are Not Enough

The instinct after credential theft is to rotate passwords and invalidate sessions. In this case, that sequence can fail if performed too early. If the attacker has modified pam_unix.so or sshd, the new password may be captured the next time a user logs in. If the attacker added keys to authorized_keys, password rotation may not affect SSH key-based access. If the attacker altered client binaries, administrator activity during cleanup can leak new secrets and internal paths.

The safer order is verification, containment, restoration, then rotation. First, identify which hosts have modified authentication components. Second, preserve evidence and avoid using potentially compromised remote access paths for sensitive recovery work. Third, restore known-good packages or binaries matched to the exact OS and distribution version. Fourth, validate that login, sudo, SSH, and emergency access still work. Only after persistence is removed should teams rotate credentials at scale.

This is where remediation becomes delicate. Replacing a web shell is usually simple compared with replacing PAM or SSH. A wrong pam_unix.so, mismatched OpenSSH binary, missing dependency, bad SELinux context, or incorrect package version can lock administrators out. Sygnia’s report says remediation required lab testing, host profiling, rollback planning, and validation after each replacement. That is the right model for any environment where authentication code may have been tampered with.

What Defenders Should Check

Start with file integrity, not just alerts. Compare pam_unix.so, ssh, sshd, scp, sftp, and ssh-keygen against known-good versions from trusted package repositories or golden images. On Debian and Ubuntu systems, commands such as debsums can help validate package-managed files. On RPM-based distributions, rpm -Va can identify changes to files installed by packages. Treat results carefully, because legitimate configuration changes and local builds can produce noise, but authentication binary drift deserves immediate review.

Monitor PAM paths and SSH paths explicitly. High-value locations include /lib/security/, /lib64/security/, /usr/lib/security/, /etc/pam.d/, /usr/bin/ssh, /usr/sbin/sshd, /usr/bin/scp, /usr/bin/sftp, /etc/ssh/sshd_config, root and service-account authorized_keys files, systemd unit directories, SysVinit scripts, and privileged loader paths. File integrity monitoring should alert on content changes, ownership changes, permission changes, unexpected extended attributes, and timestamp anomalies.

Hunt for credential dump locations and suspicious hidden directories. Sygnia reported paths such as /usr/sbin/.ssh.log, /usr/share/man9/ph/, /usr/share/man9/ph/.ph.man, /var/lib/sam/, and /usr/lib/eth-scsi/ in the investigated environment. Do not treat those as universal indicators. Treat them as examples of attacker tradecraft: hiding logs under system-looking directories, using dotfiles, encrypting collected credentials, and manipulating timestamps to blend with older system files.

Review authorized_keys at scale. Attackers often combine advanced persistence with simple persistence because simple methods survive mistakes. Inventory privileged accounts, service accounts, local administrators, and stale user homes. Remove keys that do not map to a current owner and approval record. Where possible, move administration through controlled bastion hosts and short-lived certificates rather than long-lived unmanaged keys.

Check network paths that should not exist. In Operation Highland, the isolated network was reachable through a chain of compromised systems. Look for unexpected SOCKS proxies, unusual Nginx proxy rules, FastCGI execution paths, reverse shell behavior, and outbound connections from systems that normally should not initiate them. For appliance-heavy environments, inspect F5, Cisco Nexus, and other network infrastructure with the same seriousness applied to servers.

Practical Hardening Steps

Treat authentication components as security controls. PAM modules and OpenSSH binaries should be part of your critical file monitoring baseline. For regulated or critical environments, keep offline copies of known-good binaries and package metadata for each supported OS version. If isolated systems cannot fetch packages from the internet during recovery, responders need trusted media, tested scripts, and documented dependency sets ready before an incident.

Reduce direct administrative exposure. Disable direct root SSH login, require named accounts, enforce least-privilege sudo, and route privileged sessions through hardened jump hosts with session recording. Where feasible, put MFA before access reaches critical Linux systems, such as at VPN, bastion, privileged access management, or identity-aware proxy layers. Host-level MFA is useful, but if PAM is compromised, upstream controls become more valuable.

Separate recovery credentials from daily credentials. Break-glass access should be tightly controlled, monitored, and tested, but not used for routine administration. Store emergency procedures offline. Make sure teams know how to access consoles, hypervisor controls, out-of-band management, or cloud serial consoles if SSH becomes untrustworthy.

Improve Linux telemetry in restricted segments. Isolated networks still need logs. If EDR cannot run everywhere, use compensating controls: auditd rules for authentication file changes, package verification jobs, centralized syslog through approved collectors, command/session monitoring on jump hosts, and periodic offline scans. A segment with no internet should not become a segment with no evidence.

Patch related infrastructure, but do not confuse patching with eradication. For Cisco Nexus environments, review the CVE-2024-20399 advisory path and confirm fixed NX-OS versions or vendor mitigations. For OpenSSH and PAM, maintain current supported packages from your distribution vendor. In Operation Highland, however, the central issue was post-compromise tampering. A normal package update may replace malicious files, but responders still need to find how the attacker got in, where credentials were captured, which accounts were used, and what other persistence remains.

The Bigger Lesson

Operation Highland is a reminder that trusted infrastructure needs proof of trust. Linux authentication modules, SSH clients, SSH daemons, jump hosts, network switches, load balancers, and isolated web bridges are not passive plumbing. They are control points, and control points are attractive targets.

For defenders, the practical takeaway is direct: build integrity checks around the login layer, keep known-good recovery paths ready, and rotate credentials only after the compromised trust path has been removed. A patient attacker can survive ordinary cleanup when the cleanup runs through the very software they backdoored.