Attackers Hide Linux Malware in SSH-Named Files During Package Installs

Key Takeaways

• A sophisticated supply chain attack has compromised over 700 GitHub repositories, targeting developers using PHP and Node.js packages.
• The attackers inject malicious postinstall scripts into software packages, which silently download and execute a Linux binary disguised as a legitimate SSH process.
• The malware is hidden in /tmp/.sshd and launched in the background, making it difficult for developers to detect through standard installation logs or system monitoring.
• The campaign leverages a GitHub account named parikhrpreksha for payload delivery and affects both individual developer machines and CI/CD pipelines.
• While many affected packages have been removed from Packagist, developers must verify upstream repositories and implement proactive scanning measures.

Stealthy Supply Chain Attack Hits Over 700 GitHub Repositories

A novel supply chain attack campaign is actively compromising developer environments by embedding malicious postinstall hooks within popular PHP and Node.js software packages. Researchers at Socket.dev uncovered the widespread operation, which has already impacted more than 700 GitHub repositories.

The attack vector exploits a mechanism many developers might overlook: automated scripts that run immediately after a package installation. These stealthy scripts download a harmful Linux binary and camouflage it on the victim’s system, making it appear as a standard operating system process.

How the Campaign Operates

The attackers inject a malicious postinstall script into affected PHP and Node.js packages. When a developer installs one of these compromised packages, the script automatically executes without any visible warnings or prompts. This script then connects to an attacker-controlled GitHub account to retrieve a binary file.

The downloaded binary is saved to a temporary directory on the victim’s Linux system, specifically at /tmp/.sshd. This filename is a deliberate attempt to mimic the legitimate SSH daemon file, helping it blend in with standard system processes and avoid detection. Socket.dev researchers identified this campaign during an investigation into flagged Packagist packages, using their AI-powered scanner to detect suspicious install-time behaviors like binary downloads and silent execution.

Coordinated Delivery and Evasion

The investigation revealed a highly coordinated supply chain operation. A GitHub account named parikhrpreksha served as the central distribution point for the malicious payload. Across hundreds of repositories, the same postinstall command consistently appeared, all fetching the identical binary from the same GitHub Releases URL, indicating a single, organized campaign.

A key element of the attack’s stealth lies in its ability to suppress error messages during installation and run the downloaded binary silently in the background. This design ensures that developers reviewing typical installation logs would find nothing out of the ordinary. Furthermore, the payload’s disguise as an SSH process makes it challenging to identify among other system files.

Payload Hidden Behind an SSH-Like Filename

The attack’s core relies on a deceptively simple but effective disguise. The malicious script downloads a binary named fvbs.network from the attacker’s GitHub Releases page. It then writes this file to /tmp/.sshd on the compromised machine. The dot prefix in .sshd ensures the file is hidden from most standard directory listings, while the .sshd extension makes it resemble a trusted system service.

After being written, the binary is granted executable permissions using chmod +x and launched silently in the background, effectively severing its visible connection to the original installation process. The script utilizes curl with TLS verification disabled (curl -sk), which prevents it from validating the legitimacy of the remote source. By the time the installation command completes, the malicious payload is already running covertly on the developer’s system.

Socket’s investigation also confirmed that malicious commits were directly pushed into upstream GitHub repositories. These commits often targeted branch-tracking versions such as dev-main, dev-master, and dev. This means any Packagist package configured to point to these development branches would automatically pull in the compromised code with subsequent updates, making simple package version removal insufficient without addressing the upstream repository itself.

Malicious Hooks Spread Across Packagist and Node.js

The confirmed Packagist packages all contained identical postinstall hooks that directed to the same attacker-controlled GitHub account. In several Node.js repositories, the same payload delivery command was discovered within GitHub Actions workflow files. This dual-vector approach means the attack could compromise both individual developer workstations and automated CI/CD pipeline environments.

In one instance, the payload command was embedded within a workflow file using a dependency named dependency_cache_sync, expanding the attack surface beyond what traditional package scanning might detect. Socket reported all identified affected packages to Packagist, which promptly removed them. However, due to the nature of branch-tracking packages, developers must independently verify that their upstream repositories have been remediated.

What You Should Do

• Inspect composer.json files: For teams using Packagist packages with PHP or Laravel tooling, meticulously review composer.json files for any unexpected or suspicious postinstall entries.
• Monitor /tmp directory: Actively scan or monitor the /tmp directory for any newly created binaries, especially those with dot-prefixed names like .sshd, which could indicate hidden malicious activity.
• Audit GitHub Actions workflows: Review GitHub Actions workflow files for unfamiliar or suspicious steps, particularly those involving binary downloads or silent execution commands.
• Prefer fixed release tags: Where possible, configure package dependencies to track fixed release tags rather than development branches (e.g., dev-main, dev-master) to reduce exposure to rapidly changing, potentially compromised code.
• Implement runtime monitoring: Utilize runtime security tools that can detect unusual process execution, network connections, or file system modifications, even if initial installation appears benign.

Indicators of Compromise (IoCs):-

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.