A supply chain attack targeting the PHP developer community has surfaced through Packagist, the official package repository for PHP and Laravel projects.

Threat actor nhattuanbl published several packages that disguised a fully functional remote access trojan (RAT) inside what looked like standard Laravel utility libraries, giving attackers silent and persistent control over any system that installed them.

The attack relied on a straightforward but effective strategy: blend in. 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, nhattuanbl/lara-helper and nhattuanbl/simple-queue, carried an identical malicious payload buried inside a file named src/helper.php.

A third package, nhattuanbl/lara-swagger, contained no malicious code on its own but silently pulled in lara-helper as a hard Composer dependency, making it a clean-looking carrier for a dirty payload.

Socket.dev analysts identified this remote access trojan distributed across the malicious Packagist packages, noting that once installed, the payload connects to a command-and-control (C2) server at helper[.]leuleu[.]net on port 2096, transmits a full system profile, and waits for operator commands, giving the attacker complete remote control over the compromised host.

The researchers submitted takedown requests to the Packagist team, though the packages remained live at the time of publication.

The impact of this campaign is wide-reaching. Any Laravel application that installed these packages has a persistent RAT running in the same process as the web app, 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 that does not discriminate based on the developer’s operating system.

lara-swagger's composer.json explicitly requires nhattuanbl - lara-helper at dev-master (Source - Socket.dev) — lara-swagger’s composer.json explicitly requires nhattuanbl – lara-helper at dev-master (Source – Socket.dev)

What makes this attack particularly concerning is that even if the C2 server goes offline, the threat does not disappear.

The RAT retries its connection every 15 seconds indefinitely, meaning the attacker could simply redirect it to a new host at any time without modifying the payload itself.

The RAT-bearing packages, once loaded, operate silently in the background from the moment the application starts.

Inside the Infection Mechanism

The infection chain is built for stealth at every stage. The malicious file helper.php is 27,340 bytes and delivered as a single continuous line after the opening tag, making it hard to read at a glance.





The payload uses three distinct obfuscation layers: control flow is shattered into hundreds of randomized goto jumps with meaningless labels like tc0pE and IlaiV; every string literal, including domain names, command names, and file paths, is encoded using hexadecimal or octal escape sequences so nothing readable appears in plaintext; and all variable and function names are randomly generated strings like $riz07 and BsYhQ().



Mitre attack techniques (Source – Socket.Dev)



Activation works differently depending on which infected package a developer installs. In lara-helper, the package registers a Laravel service provider through Composer’s auto-discovery mechanism, and helper.php is loaded on every single application boot. 



In simple-queue, the malicious include sits at the file scope level, meaning the payload fires the moment PHP’s autoloader resolves the class, even through a type-hint or a simple class_exists() check. 



Once triggered, the RAT spawns a detached background process of itself, passing a helper argument, while the parent process returns to normal execution so the application never shows any visible signs of infection. 



A lock file prevents duplicate instances and expires every 15 minutes. All traffic between the RAT and its C2 server is encrypted using AES-128-CTR, with a hardcoded 16-byte key (esCAmxUoJkIjTV0n) embedded in the payload. 



The C2 accepts JSON commands that instruct the RAT to run shell or PowerShell commands, capture screenshots, upload or download files, and return full system reconnaissance data including hostname, OS version, user permissions, and a machine unique ID.



Any team that installed nhattuanbl/lara-helper, nhattuanbl/simple-queue, or nhattuanbl/lara-swagger should treat the affected host as fully compromised. 



All secrets accessible from the application environment, including database passwords, API keys, and .env values, must be rotated immediately. 



The packages and the helper.php file should be removed, any files with chmod 0777 permissions should be audited, and the lock file at {sys_get_temp_dir}/wvIjjnDMRaomchPprDBzzVSpzh61RCar.lock should be deleted. 



Teams should also review outbound traffic to helper[.]leuleu[.]net:2096, audit transitive dependencies, and avoid using dev-master constraints in production environments since they bypass version pinning entirely.



Follow us on Google News, LinkedIn, and X to Get More Instant Updates, Set CSN as a Preferred Source in Google.
The post Malicious Packages Disguised as Laravel Utilities Deploy PHP RAT and Enables Remote Access appeared first on Cyber Security News.