Linux Hidden Persistence: Velvet Ant modifies PAM and OpenSSH to capture credentials

A China-related actor known as Velvet Ant has led persistence to a new level: instead of hiding in new software or own tools, it has modified the programs themselves that decide who enters Linux systems. According to public analysis and the group's trajectory, the opponent came to replace critical components of the authentication system - PAM and OpenSSH- with malicious versions that recorded credentials and commands, or that accepted hidden passwords; stealth work that can go through legitimate administration for years.

The technique is doubly dangerous: first because it attacks the most reliable point of the host - the one that validates identities - and second because the goal was, in many cases, isolated networks without direct Internet access. To get there the attackers used systems exposed as bridge and disguised tools that retransmitted orders to the "air-gapped" segment. This patient and modular approach is similar to the previous campaigns of the same actor, who have used infrastructure devices such as F5 BIG-IP o Cisco NX-OS switches as internal command and control platforms.

The operational implications are clear: standard containment procedures, such as closing sessions or forcing password change, can be ineffective if the piece that validates these credentials turns out to be compromised. Reset keys without first checking and cleaning the authentication chain leaves an open door for new credentials to be captured and exfiltered.

From a defensive point of view, the first lesson is to move surveillance to where it is traditionally not looked at. File integrity monitoring for login binaries (e.g. / usr / sbin / sshd and PAM modules in / lib / security or / lib64 / security according to distribution) should be on the priority list. In addition to real-time alerts, it is appropriate to implement active hunting: compare executable hashes with copies known and signed by the supplier, and verify the integrity of the package using the package manager's own tools (rpm -V, debsums or other alternatives according to the disk).

Remediation actions require caution. Do not replace or restart blind a production authentication binary; an incorrect copy can block administrators and complicate recovery. The reasonable flow is to isolate the equipment, start from a rescue medium (live CD / USB) to obtain a trusted environment, verify and replace the binaries with signed or built artifacts in a secure CI environment, and only then rotate credentials and keys. Testing any replacement in reproducible laboratories before applying in production reduces the risk of fatal errors.

The complementary hygiene that reduces the abuse window includes minimizing services and accounts with administrative privileges, forcing multifactor authentication for critical access and preferring key-based authentication and hardware-protected agents where possible. It is also necessary to audit and block unusual transmission channels: to review exposed web servers that can act as a bridge and to monitor unexpected outgoing connections from network applications and balancing.

In the specific case of the vulnerabilities previously used by this actor, the equipment must ensure that the patches and mitigations recommended by manufacturers and safety authorities are applied. The organizations can consult official notices and guides to confirm the exposure of their infrastructure; public resources such as CISA or reports of firms responding to incidents such as Sygnia offer useful technical context and mitigation steps. To better understand the attacked components and how to protect them, it is also necessary to review the original sources of the software as OpenSSH and Linux-PAM.

Finally, the strategic lesson is that the default confidence in infrastructure must be replaced by continuous verification. Components that historically were considered stable and "always correct" - swimmers, switches, and especially the login itself - are now objectives of persistence. Effective defence requires the integration of integrity controls into day-to-day monitoring, recovery policies that provide for confidence-building, and threat-hunting exercises that check critical device changes before assuming that a re-establishment of credentials closes the incident.