Velvet Ant’s Operation Highland: How a China-Nexus Actor Infiltrated an Internal Network Undetected

When Sygnia’s IR team began reconstructing the intrusion that would become known as Operation Highland, the earliest forensic artifacts dated back to 2016. What they uncovered was not a recent breach but a near-decade of undetected presence inside an internal network – a network the attacker had no direct path into, and reached anyway. 

Velvet Ant is a China-nexus threat actor Sygnia has tracked across multiple investigations. This is not an isolated campaign. In earlier research, we documented the group abusing F5 BIG-IP appliances and legacy Windows infrastructure to maintain long-term persistence. More recently, we reported on their exploitation of CVE-2024-20399, a zero-day in Cisco NX-OS, to deploy a hybrid backdoor (VELVETSHELL) directly on Cisco Nexus switches, and published a detailed advisory with detection and prevention guidance. The pattern across all these investigations is consistent: Velvet Ant escalates when detected, pivots to less-monitored infrastructure, and rebuilds persistence from a new vantage point. 

Operation Highland is distinct in one critical respect: the target network had no direct internet connectivity. Instead, the attacker engineered a deliberate multi-stage access chain to reach it.  

This post traces the full attack path from initial internet-facing compromise to deep persistence inside a segregated critical infrastructure network. 

Key findings from this investigation

• Forensic artifacts place Velvet Ant’s earliest activity in this environment at 2016 – nearly a decade of undetected presence inside an internal network
• The target network had no direct internet connectivity – the attacker staged through internet-facing systems and traversed the IT network to reach it 
• PAM modules and OpenSSH binaries were replaced with backdoored versions across multiple hosts – the attacker controlled the full authentication stack 
• Nine distinct pam_unix.so variants were identified, each built in a separate compile environment – the level of effort required to produce and maintain these variants points to a well-resourced, deliberate operation 
• The modified SSH binaries included a custom flag to disable their own credential logging – the attacker actively managed their forensic footprint during live operations, a hallmark of high OpSec discipline
• Remediation was unusually high-risk because the attacker had tampered with components critical to remote access and system administration

Attack Overview: How Velvet Ant Moved from Internet-Facing Systems to Critical Infrastructure

Velvet Ant’s path into the environment followed three distinct stages: 1. Establishing persistent access on internet-facing systems, 2. Pivoting through the IT network toward the critical infrastructure segment, and 3. Subverting the authentication stack to embed long-term persistence across compromised hosts. The sections below trace each stage in detail.

Why the Authentication Layer Was the Highest-Value Target

The attack did not stop at maintaining access; it extended into controlling how authentication works across the environment. Both PAM and OpenSSH were modified, giving the attacker visibility into credentials as they were used and the ability to bypass normal authentication flows entirely. Administrative activity became fully observable: every login; every command executed across compromised hosts. Access was no longer tied to a specific foothold but embedded into the authentication process itself. The compromise of the authentication process enabled persistence that survived password changes and session terminations, reducing the effectiveness of conventional containment measures.

Stage 1: Establishing Access on Internet-Facing Systems

GS-Netcat for Covert Command Execution

GS-Netcat, part of the Global Socket Toolkit, is a publicly available networking tool that functions as an encrypted and stealthy reverse shell. It enables secure, bidirectional communication between a client and a remote server via a brokered connection through the Global Socket Relay Network (GSRN), allowing users to tunnel traffic or execute commands remotely while evading detection.

Velvet Ant deployed a modified version of GS-Netcat on internet-facing servers to establish a reverse shell connection to a remote C2 server. The binary was named auditdb and placed in /usr/sbin/ to blend in with legitimate system utilities. The remote server’s domain was hardcoded into the binary, following the format %.gs.thc[.]org, where % represents a single character between a-z, a subdomain of thc.org (The Hacker’s Choice), the organization behind GS-Netcat, and likely part of the GSRN relay infrastructure. To evade detection, the binary overwrites its own argv[0] parameter with [khubd], disguising its presence in process listings by masquerading as a legitimate kernel thread.

To maintain persistence, the threat actor employed different methods based on the server’s operating system:

• On newer servers running systemd, a malicious unit file was placed in /lib/systemd/system/, disguised as a Chrome service, ensuring the malware executed at boot.
• On older servers using SysVinit, a malicious execution line was appended to existing startup scripts in /etc/init.d/, configuring it to run automatically during system initialization.

These mechanisms ensured the backdoor remained active across reboots while blending into legitimate system processes.

SOCKS5 Proxy for Tunneling and Lateral Movement

Alongside GS-Netcat, Velvet Ant deployed a network tunneling tool to facilitate lateral movement. Written in Perl, it functions as a SOCKS5 proxy server, relaying network traffic between clients and remote hosts. The script listens for incoming connections on a specified port (which varies across samples), enabling the threat actor to route traffic covertly through compromised hosts.

The script runs as a background daemon by forking itself, allowing the parent process to terminate while ensuring continuous execution independently of user sessions. Analysis identified it as a custom implementation of the publicly available ssspl project by GitHub, modified to align with the threat actor’s objectives.

To evade detection, Velvet Ant manipulated the argv[0] parameter, disguising the process name as smbd -D to blend in with legitimate system processes. Each sample used a unique filename, process name, and listening port, making identification and correlation across compromised systems significantly harder.

Stage 2: Moving Through the IT Network Toward Critical Infrastructure

Nginx and FastCGI Abuse as an Execution Path

Velvet Ant exploited an internet-facing Nginx server as an additional entry vector. They modified its configuration to proxy any incoming request to a specific URL through to the same URL on a backend server. The backend server was also compromised, with its Nginx configuration modified to forward requests to a FastCGI process (fcgiwrap, based on the public fcgiwrap repository), listening on a separate port.

This FastCGI wrapper acted as an execution bridge: it processed requests to the specified URL, executed the binary named uptime, and returned its output to the threat actor via Nginx. The uptime binary was a custom-built tool designed to establish an SSH connection to a server in the critical infrastructure network, based on HTTP POST parameters sent in the request. Once connected, it executed a script on the target device, enabling the threat actor to retrieve confidential information from the organization’s systems.

By chaining these modifications, Velvet Ant established a remote-execution path into the segregated environment via simple HTTP requests, with no direct connection to the critical infrastructure network ever required.

Stage 3: Manipulating authentication for stealth and persistence

Why SSH and PAM became central attack surfaces

OpenSSH provides secure, encrypted communication channels between clients and servers. Its core components include:

• ssh – main client for remote connections
• scp – secure file copy
• sftp – secure file transfer
• ssh-keygen – used to generate, manage, and convert SSH key pairs
• sshd – server daemon that listens for and manages incoming SSH sessions

SSH supports several authentication methods:

• Host-based authentication – relies on trusted client machines configured via /etc/hosts.equiv or /etc/shosts.equiv, and host keys in ~/.ssh/known_hosts, to grant password-free access
• scp – secure file copy
• sftp – secure file transfer
• ssh-keygen – used to generate, manage, and convert SSH key pairs
• sshd – server daemon that listens for and manages incoming SSH sessions

It is this last method, and the PAM subsystem underpinning it, that Velvet Ant targeted. PAM sits below the application layer – a compromised PAM module affects every service that relies on it, transparently and without generating anomalous log entries.

Backdoored pam_unix.so for Bypass and Credential Capture

During the investigation, nine files of a backdoored pam_unix.so were identified. Velvet Ant replaced the legitimate PAM module with maliciously modified versions across compromised hosts.

The targeted function, pam_sm_authenticate, is responsible for user authentication in PAM modules. Normally, it retrieves the username and password, verifies credentials, and returns success or failure. In the modified versions, this function was patched to either accept a hardcoded backdoor password, harvest credentials from legitimate authentication attempts, or both.

The malicious files contained an embedded RPATH (runtime library search path), likely left over from development or testing. RPATH defines the directories where the runtime linker searches for dependent shared libraries. Notably, each variant was linked to a different build environment, indicating the files were compiled in separate, unique setups: consistent with a structured, per-target build pipeline.

Among the nine identified files, two primary variants were identified:

1. Authentication Bypass (backdoor only):

• The pam_sm_authenticate function was modified to accept a hardcoded backdoor password
• When this password was entered, the normal verification process was bypassed entirely, granting the threat actor unauthorized access
• To evade detection, the malicious library immediately overwrote the backdoor password string in memory with NULL values after authentication was bypassed
• RPATH format: /home/kevin/Desktop/Linux-PAM-{PAM version}/libpam/.libs:/lib64

2. Authentication Bypass and Credential Harvesting:

• Allowed authentication bypass when the backdoor password Pamauth@123456 was entered, stored within the binary in encrypted format
• If the password provided by a user did not match the expected value, the malicious library recorded both the username and password in a hidden file at /usr/sbin/.ssh.log
• In some cases, recorded passwords were deduplicated to reduce redundancy
• RPATH format: /c/src/Linux-PAM-{PAM version}/libpam/.libs (most cases)

Modified OpenSSH Binaries for Credential Theft and Keylogging

During Sygnia’s investigation, modified OpenSSH suites were identified across the compromised environment, highlighting the threat actor’s extensive control over the network. These compromised versions appeared in both older and newer variants, with malicious modifications targeting the ssh, sshd, and, in some cases, scp binaries.

Velvet Ant embedded malicious capabilities into these modified binaries to enable persistence, credential theft, and network reconnaissance. The suites were compiled per OS version to ensure compatibility with targeted environments, while some versions were designed to work across all operating systems.

In the newer variant, four files were modified: ssh, sshd, ssh-keygen, and scp. However, only three (ssh, sshd, and scp) contained additional malicious capabilities:

• Credential Dumping: The modified ssh and sshd binaries captured and stored authentication credentials for both remote SSH connections and local logins. These stolen credentials were encrypted and saved to /usr/share/man9/ph/.ph.man. Each entry contained the following flags:
  – Connection direction: O (outgoing) / I (incoming)
  – Authentication type: B (Kerberos authentication), C (PAM authentication), X (SSH2 authentication), etc.
  – Success status: Y (successful) / N (unsuccessful)

• Keylogging: The malicious ssh and sshd binaries were modified to log every command typed in the shell, storing them in encrypted format. The sshd binary records commands to a file under /usr/share/man9/ph/, using filenames that begin with s followed by the MD5 hash of the connected user and the TTY. Each log file starts with the username, TTY, timestamp, and IP address of the session. The modified ssh binary logs commands to the same folder, but uses filenames starting with c followed by the MD5 hash of the UID and the SSH_TTY environment variable, with each log beginning with the IP address and username used in the connection.

• Disable Malicious Logging (-d flag): The modified ssh binary included a custom -d flag, allowing the threat actor to disable their own credential logging and keylogging. When used, it prevents passwords from being recorded in /usr/share/man9/ph/.ph.man and blocks session keylogging in /usr/share/man9/ph/. This enabled the threat actor to operate through the compromised binary without leaving behind any recorded evidence of their own activity.
• Timestomping: All files created in /usr/share/man9/ph/, including the directory itself, were timestomped with the creation time of /etc/shells/ to evade detection.
• SELinux Disabling: The malicious scp binary could disable SELinux when executed as root, since only the root user can modify SELinux settings. Since SELinux enforces mandatory access controls (MAC) to limit unauthorized actions, disabling it allows malware to operate without security restrictions, enabling scp to access and transfer files on infected systems without being constrained by SELinux policies.

• Process Hiding (! flag): A custom ! flag was added to the scp binary, which, when used, disguises the process name as [kauditd] -sh, mimicking the legitimate Linux auditing daemon. This allowed the malware to blend in with system processes, avoiding detection.

An older variant of the modified OpenSSH suite was also identified, less advanced than the newer version described above. In this variant, only two files were modified: ssh and sshd. The key differences in capabilities between the two versions were:

• Backdoor Authentication: Rather than relying on a single static password, the malicious sshd binary implemented a more sophisticated backdoor mechanism. Entered passwords were intercepted, hashed, and compared against a hardcoded encrypted global MD5 hash, granting access on a match. Beyond this, the malware maintained seven separate MD5 hashes, each assigned to a specific day of the week, rotating the comparison target based on the current

• Credential Dumping: Functionally identical to the newer variant, but credentials were written to /usr/lib/eth-scsi/libethscsi.so rather than the newer version’s storage path.
• Keylogging: Only ssh was modified for keylogging in this variant, using the same encrypted format as the newer version. The key difference lies in the naming convention: rather than MD5-based filenames, logs were written to /var/lib/sam/ with filenames in the format sam_{timestamp}, directly reflecting the time of the remote connection. This less sophisticated approach made the logs easier to track chronologically and allowed Sygnia to identify the earliest recorded keylogging activity in the environment, dating back to 2016.
• Disable Malicious Logging (-d flag): Identical capability to the newer variant – the modified ssh binary supported the same -d flag to suppress credential and session logging during the attacker’s own operations.
• Timestomping: Less thorough than the newer version – only the directories /var/lib/sam/ and /usr/lib/eth-scsi/ were timestomped, using the creation time of /bin/ls. Unlike the newer variant, file timestamps within those directories were left unchanged, making this version comparatively easier to detect through filesystem timeline analysis.

Authorized_keys Abuse for Durable Access

Alongside the PAM and OpenSSH modifications, Velvet Ant appended their own public keys to the authorized_keys files on compromised servers. This provided persistent, password-less access using the corresponding private key – a simpler but durable third persistence layer that operated independently of the backdoored binaries.

Eradication When the Login Stack Becomes the Backdoor

This was not a standard persistence cleanup. When the attacker controls authentication, you cannot “delete first and validate later”. You must restore trust without cutting off your own access or worse, disrupting the business.

Velvet Ant did not rely only on common persistence mechanisms such as services, cron jobs, users or other mechanisms that responders can usually remediate with limited operational impact. It compromised the authentication layer itself, and this changes everything.

The attacker’s persistence was embedded in the same components administrators rely on to access and manage production systems:

• pam_unix.so modules.
• OpenSSH binaries such as ssh, sshd and scp.
• SSH key abuse through authorized_keys.

The main remediation objective was therefore not simply to remove malware. It was to eradicate persistence without breaking the authentication itself or disrupting critical, zero-downtime production infrastructure.

From an eradication perspective, replacing a malicious service is one thing, while replacing PAM modules and OpenSSH binaries is another. A wrong package, incompatible binary or a missing dependency can completely lock administrators out of a host. In critical infrastructure, that can turn remediation into a production outage.

Internet access was also a challenge as most systems had no internet access at all, which meant no direct package pull from trusted repositories and no live dependency resolution. Also, the server estate included multiple Linux distributions and versions, each with its own binaries, libraries, PAM implementation, OpenSSH build, and kernel-level expectations. This means a remediation package that was safe for one host could be dangerous on another.

To reduce the risk of business disruption, remediation had to be engineered carefully. A lab was established to test the replacement process before production execution. Serialization and encoding were used to package and move eradication and recovery logic into the restricted network in a controlled, verifiable, and repeatable way, dropping the relevant binaries which were downloaded in a safe, controlled environment. Each host was profiled, matched to the correct replacement components, remediated, and immediately validated for SSH and authentication health to ensure business continuity.

Most importantly, failure scenarios were reviewed in advance. Rollback options were prepared as part of the effort and access validation was treated as part of remediation and not as a post-cleanup task.

Mitigations and Hardening Recommendations

To reduce the risk of authentication-layer persistence, treat PAM, OpenSSH, LSASS, and privileged access paths as critical security controls.

Deploy an EDR on all supported systems to maintain endpoint visibility and detection coverage. In isolated environments, ensure telemetry can still be collected through approved relays, collectors, or controlled offline exports to the SIEM. Where EDR cannot be deployed, enforce compensating controls such as:

• Strict application allowlisting.
• Enhanced audit logging.
• Command/session monitoring.
• Restricted administrative paths.
• High confidence alerts for authentication or system file modifications.

Harden privileged access to reduce the risk of unauthorized file changes and implement the following controls:

• Rotate credentials only after persistence is removed. Otherwise, new credentials may be harvested through the same compromised pam_unix.so, ssh, or sshd path.
• Remove stale local administrators to reduce potential attack surfaces.
• Vault privileged credentials.
• Disable direct root SSH login, require named accounts with tightly scoped ‘sudo’ permissions, and route administration through hardened jump servers or privileged access solutions.
• Where applicable, enforce MFA before access reaches critical hosts, not only inside the host-level flow.

Consider deploying File Integrity Monitoring as an additional detection layer on critical production systems and forward alerts to the SIEM. Prioritize paths tied directly to the TTPs observed in this campaign:

• Linux PAM modules, especially pam_unix.so.
• Linux PAM configuration under /etc/pam.d/.
• OpenSSH binaries including ssh, sshd, scp, sftp, and ssh-keygen.
• SSH configuration files, including sshd_config.
• Privileged ‘authorized_keys’ files.
• Systemd unit files, SysVinit scripts, and startup paths.
• Linux loader and privilege paths such as /etc/sudoers

Apply the same principle to Windows authentication infrastructure. Skeleton Key-style attacks abuse the authentication process itself. On Domain Controllers and critical Windows servers, monitor LSASS access, unexpected LSASS module loads, and changes to LSA-related components such as Authentication Packages.

Prepare for an offline recovery. Critical and isolated networks need a strict backup and snapshot cadence, including offline or immutable copies where possible. Backups must also be tested. A backup that cannot be restored quickly is not a recovery capability. For zero-downtime environments, consider preparing golden recovery hosts with validated OS builds, known-good binaries including pre-tested recovery scripts. This strengthens both backup and DR readiness when production systems cannot safely pull packages from the internet.

Finally, any eradication that touches PAM, OpenSSH, or Windows authentication components must include rollback and emergency access plans. One incorrect replacement can turn containment into self-inflicted downtime.

The Role of Proactive Threat Hunting in Stealth Intrusions

Operation Highland is a case study in why signature-based detection and alert-driven security operations fall short against a patient, capable threat actor. There was no novel exploit to catch; no clearly malicious binary dropping into a monitored directory. Velvet Ant operates through pam_unix.so, sshd, and ssh – components that exist on virtually every Linux host in the environment, that behave normally for legitimate users, and that generate no anomalous log entries when backdoored. The attacker’s presence was, by design, indistinguishable from legitimate administrative activity.

This is precisely the scenario that proactive threat hunting services exist to address. When there is no alert to triage, detection depends on the ability to interrogate the environment directly by asking questions the SIEM was never configured to answer:

• Has this system component been modified from its expected state?
• Is this behavior consistent with how the system is normally used?
• Are trust boundaries being used in ways they shouldn’t be?

Proactive threat hunting shifts the analytical frame from “what is known to be malicious” to “what is inconsistent, unexpected, or unjustified in this environment.” That distinction matters enormously in segmented or high-sensitivity networks, where the assumption of isolation can create a false sense of security. Isolation changes how an attacker establishes access – it does not prevent compromise, and it does not make persistence easier to find. If anything, it reduces the volume of telemetry available, making hypothesis-driven inspection of internal systems more important, not less.

The keylog artifact dating back over five years illustrates the scale of what’s possible when a threat actor of this sophistication operates undetected – and why continuous, hypothesis-driven inspection of authentication infrastructure is non-negotiable in high-sensitivity environments.

Conclusion

Across Sygnia’s investigations, Velvet Ant has followed a consistent pattern: each time the group’s foothold is threatened, it moves deeper. Legacy Windows servers gave way to F5 appliances, then Cisco NX-OS, and now the authentication stack itself. Operation Highland marks the point where the attacker no longer needed to exploit individual services – they controlled the mechanism that authenticates access to all of them.

Linux PAM and OpenSSH reside inside the login process itself, and the question is not whether the attacker has access, but how many access paths exist, and whether eradication has found all of them. Removing one persistence layer while others remain intact buys the attacker time to reestablish.

That makes remediation fundamentally different from just deleting a binary, removing a cron job, or disabling a rogue service. The recovery team must remove the attacker’s persistence while preserving the organization’s ability to authenticate, administer, and stabilize high valued, critical 0-downtime production systems.

If you suspect your environment may be affected or want to assess your exposure to this class of attack, contact Sygnia at [email protected] or call our 24-hour hotline at +1-877-686-8680.

Download the full Indicators of Compromise list