Velvet Ant Hid Inside Linux Auth for Nearly a Decade by Backdooring PAM and OpenSSH
A China-nexus threat actor planted rogue authentication modules on victim networks and stayed undetected for close to ten years — by targeting the one layer most incident-response playbooks quietly trust.
A China-nexus intrusion group tracked as Velvet Ant buried backdoors directly inside Pluggable Authentication Modules (PAM) and OpenSSH binaries on a compromised network and maintained that access for nearly ten years. Researchers at Sygnia documented the campaign, revealing one of the longest-running silent footholds tied to a single threat actor in recent memory.
What Velvet Ant Actually Did
Forget the endpoints defenders spend most of their budget watching. Velvet Ant went deeper. The group targeted the Linux authentication stack — the software layer every other system on the network has to consult before granting a shell session to anyone.
PAM, the Pluggable Authentication Modules framework, is how Linux distributions tie together `sshd`, `sudo`, `su`, screen lockers, and console logins into a single, swappable auth backend. A rogue shared object dropped into `/lib/security/` and wired into `/etc/pam.d/sshd` is invisible to most endpoint detection tools. It processes every login. It sees every credential. And if the attacker hard-codes a magic password or a static key check inside that module, they have a parallel authentication path that bypasses logging entirely.
The OpenSSH angle follows the same logic one layer up. A modified `sshd` binary — or a patched library it links against — can silently accept an attacker's private key, skip audit hooks, or whitelist a specific source IP without generating a single suspicious log entry. Trojanized OpenSSH builds are not new. What is notable here is that Velvet Ant kept this working for roughly ten years.
Why the Persistence Lasted So Long
Dwell time at this scale does not happen by accident. Several structural weaknesses in standard enterprise hygiene made the foothold almost self-sustaining.
Golden images are the first problem. When an organization builds its "known-good" server image years after the initial compromise, and that image gets generated from already-infected source files, every new VM deployed from it carries the backdoor forward. Reboots change nothing. Rebuilding a host from the corporate baseline changes nothing.
Credential rotation — a control defenders often reach for after detecting suspicious access — is equally useless here. The backdoor does not rely on stolen credentials. It answers to its own key or password, one that exists entirely outside the organization's identity provider. Rotating Active Directory passwords, cycling SSH keys, even replacing service accounts: none of it touches the implant.
"Identity is infrastructure," Sygnia researchers noted in their analysis. The code that decides who gets in deserves the same supply-chain scrutiny organizations now apply to container base images and CI/CD pipelines.
The Verizon 2024 Data Breach Investigations Report found that system intrusion patterns — including those involving compromised or abused credentials and installed backdoors — accounted for 36% of all breaches analyzed that year. Velvet Ant is an extreme example of what happens when the credential-verification layer itself becomes the attacker's real estate.
The Detection Problem Nobody Talks About
Most incident-response runbooks treat PAM and `sshd` as part of the operating system. They are background. They are assumed. That assumption is exactly what Velvet Ant exploited.
Detection is unglamorous but achievable. Start with file integrity. Hash every `pam_*.so` object against the authoritative checksum published by the distro package maintainer for that exact version. Do the same for the `sshd` binary and every shared library it links. Any mismatch is a finding worth escalating immediately.
Next, watch the process tree. A legitimate `sshd` daemon spawns shells or SFTP subsystems. It does not exec arbitrary binaries or write to temp directories. Behavioral rules that alert on unusual `sshd` child processes are cheap to write and rarely fire on clean systems.
Finally, audit what PAM modules are loaded at runtime against the package manager's own manifest. Any module that does not appear in the manifest — or that lives outside the expected path — should be treated as hostile until proven otherwise.
Which Controls Failed
This campaign exposes a specific category of failure: insufficient integrity monitoring at the authentication layer. Most organizations run file-integrity monitoring tools that watch web roots, system binaries in `/usr/bin`, and configuration files. The PAM module directory and the `sshd` binary itself are frequently absent from those watchlists, or monitored only for existence rather than cryptographic integrity.
There is also a supply-chain hygiene gap. If golden images are built from source repositories that predate — or postdate an undetected — compromise, the image-baking process will faithfully reproduce the malicious artifact and distribute it at scale. Organizations that treat image hardening as a one-time task rather than a continuous verification process are particularly exposed.
Security awareness training typically focuses on phishing and social engineering, and rightly so. But the human failure here is upstream: the engineers and architects who designed the monitoring strategy never assigned an owner to the question "how do we know our auth binaries haven't been replaced?" That is a process and culture problem, not just a tooling gap. Teams that run regular security standards reviews tend to catch these ownership blind spots before an attacker does.
What Defenders Should Do Right Now
The immediate priority is verifying the integrity of authentication components across every Linux host in the environment. That means:
- Run `rpm -V openssh-server` on RPM-based systems or `debsums -c openssh-server` on Debian-based systems to compare installed files against package metadata.
- List every module in `/etc/pam.d/` and cross-reference loaded `.so` paths against package manager records.
- Audit `authorized_keys` files across all accounts, including service accounts and system users, and revoke any key that cannot be traced to a documented provisioning event.
- Review golden image build pipelines for any step that pulls pre-compiled binaries rather than building from verified source with reproducible build tooling.
Velvet Ant's ten-year run is a benchmark nobody wants to match. The group demonstrated that defenders who focus exclusively on endpoint telemetry and network traffic are leaving a category of persistence entirely unmonitored. Auth-layer integrity needs to be on every threat model.
How this could have been prevented
- Add PAM module directories and core auth binaries (sshd, sudo) to your file-integrity monitoring watchlist with cryptographic hash verification, not just timestamp checks.
- Establish a formal golden-image audit cycle: every base image should be validated against upstream package checksums before promotion to production, and that validation should be automated.
- Assign explicit ownership to auth-layer integrity in your threat model — if no team member can answer 'how do we know sshd hasn't been replaced,' that gap is an open door.
Train2Secure's security-awareness program helps technical and non-technical staff recognize the process failures — like unowned monitoring gaps — that let campaigns like Velvet Ant run undetected for years.
Start free — no card requiredSources & further reading
Frequently asked questions
What is a PAM backdoor and why is it so dangerous?
A PAM (Pluggable Authentication Modules) backdoor is a rogue shared library inserted into the Linux authentication stack. Because PAM processes every login event — SSH, sudo, console — a malicious module can silently accept a hardcoded attacker credential while passing normal logins through unchanged. It operates below most endpoint detection tools and generates no suspicious log entries.
Why didn't credential rotation stop Velvet Ant's access?
The backdoor did not depend on stolen user credentials. It accepted its own embedded key or password, entirely outside the organization's identity provider. Rotating passwords or SSH keys in Active Directory or LDAP has no effect on an implant that has its own parallel authentication path baked into the login binary.
How can organizations detect a trojanized OpenSSH binary or PAM module?
Use the package manager's built-in verification commands (rpm -V or debsums) to compare installed file hashes against official package metadata. Any PAM module loaded from a path not listed in the package manifest should be treated as suspicious. Behavioral monitoring for unusual sshd child processes also helps catch active exploitation.
How did a compromise go undetected for nearly ten years?
The implants lived in components that incident-response playbooks typically treat as trusted OS infrastructure. Golden server images rebuilt from already-compromised source files redistributed the backdoor automatically. Because the malicious code answered to its own credentials and skipped standard audit hooks, it produced no meaningful alerts in SIEM or EDR tooling tuned for higher-level indicators.
