PROBABLYPWNED
MalwareMarch 5, 20263 min read

Malicious Laravel Packages on Packagist Deploy Cross-Platform RAT

Supply chain attack targets PHP developers via fake Laravel utilities containing encrypted RAT payload. The malware gains full access to database credentials and API keys.

James Rivera

A supply chain attack targeting the PHP developer community surfaced through Packagist, the official package repository for PHP and Laravel projects, with threat actor "nhattuanbl" publishing several packages that disguise a fully functional remote access trojan inside what looked like standard Laravel utility libraries.

The malicious packages—nhattuanbl/lara-helper and nhattuanbl/simple-queue—contain identical RAT payloads buried inside a file named src/helper.php. A third package, nhattuanbl/lara-swagger, serves as a dependency that silently installs the malicious code when developers pull it into their projects.

How the Attack Works

The threat actor published six packages under the same author name between June and December 2024, despite the Packagist account itself dating back to December 2015. Three of those packages were completely clean and served as credibility builders, while two carried the malicious payload.

Any Laravel application that installed these packages now has a persistent RAT running in the same process as the web application, with access to the same environment variables, database credentials, and API keys stored in .env files. The payload works on Windows, macOS, and Linux, making it a cross-platform threat.

All traffic between the RAT and its command-and-control server is encrypted using AES-128-CTR with a hardcoded 16-byte key embedded in the payload. The RAT retries its connection every 15 seconds indefinitely, meaning the attacker could redirect it to a new host at any time without modifying the payload itself.

Developer Impact

The supply chain nature of this attack makes it particularly dangerous. Developers who installed these packages—or any package that depends on them—unknowingly introduced persistent backdoor access into their applications and development environments.

This attack mirrors the tactics seen in the StegaBin North Korea NPM campaign that targeted JavaScript developers through malicious NPM packages. Package repository attacks have become a favored vector for threat actors because they exploit the implicit trust developers place in dependency ecosystems.

Unlike browser-based malware that targets end users, supply chain attacks on developer tools can compromise entire organizations. A single infected developer machine can lead to compromised CI/CD pipelines, production database access, and customer data exposure.

Why This Matters

The PHP ecosystem processes millions of Composer/Packagist package installations daily. While major packages receive scrutiny, the long tail of utility libraries often flies under the radar. This attack demonstrates how threat actors can establish seemingly legitimate accounts years before executing attacks, building credibility through clean packages before introducing malware.

The Lazarus GraphAlgo supply chain operation showed how nation-state actors use similar techniques to target specific industries. Whether this attack is opportunistic or targeted remains unclear, but the potential for data theft is significant given the access the RAT provides to production credentials.

Organizations relying on PHP applications should review their Composer dependencies and look for any packages from the nhattuanbl author. If found, assume the development environment and any deployed applications are compromised.

Recommended Actions

  1. Audit dependencies immediately - Run composer show nhattuanbl/* to check for any affected packages
  2. Rotate credentials - If compromised packages were installed, rotate all API keys, database passwords, and secrets stored in .env files
  3. Review CI/CD access - Check for unauthorized commits or pipeline modifications
  4. Network monitoring - Look for outbound connections to unknown endpoints from application servers
  5. Lock file verification - Ensure composer.lock files haven't been tampered with

The packages have been reported to Packagist maintainers. Organizations using dependency scanning tools should update their rulesets to flag these specific packages.

Related Articles