Malicious PHP Packages Target Laravel Devs with Cross-Platform RATs

Supply chain attacks are no longer just an npm problem. Security researchers in 2025 identified three malicious Packagist packages—lara-helper, simple-queue, and lara-swagger—deliberately crafted to impersonate legitimate Laravel ecosystem tools. These packages deploy fully functional Remote Access Trojans (RATs) across Windows, macOS, and Linux, silently activating the moment a developer boots their application. With Laravel powering millions of production applications worldwide, this campaign represents a high-impact threat to PHP development teams everywhere.

The attacker behind this campaign, publishing under the alias nhattuanbl, used a calculated trust-building strategy before introducing malicious payloads. If your team relies on Composer for dependency management without rigorous vetting, your production environment—including .env secrets and database credentials—may already be at risk. This post breaks down exactly how this attack works, what makes it so effective, and the concrete steps you must take to protect your PHP projects.

How the Attack Was Constructed: The Credibility Trap

Understanding this campaign requires examining the attacker's methodology, which mirrors tactics seen in high-profile npm supply chain incidents. The approach was deliberate, patient, and technically sophisticated.

Clean Packages First, Malicious Ones Later

The attacker did not publish malicious code immediately. Instead, nhattuanbl first released functional, benign versions of each package to establish a credibility baseline on Packagist. Early adopters or automated dependency scanners running at that moment would have seen nothing suspicious. Only after building a minimal foothold of trust did the attacker push tainted versions containing the RAT payload.

This "poisoned update" pattern is increasingly common in supply chain attacks (CISA Supply Chain Advisory, 2024). It exploits the implicit trust developers place in packages they—or their colleagues—previously reviewed as safe.

Dependency Chaining as a Delivery Mechanism

Rather than embedding malicious code directly in the top-level package, the attacker used dependency chaining: the tainted packages declared dependencies on one another, ensuring the payload propagated through Composer's resolution graph. A developer installing lara-swagger for API documentation could unknowingly pull in lara-helper, which carried the core malicious logic.

This technique complicates detection because:

Static analysis of the primary package may appear clean
Transitive dependencies receive far less scrutiny during code review
Composer lock files may cache previously-verified versions, masking updates

Table: Attack Delivery Comparison — Direct vs. Chained Dependency

Technique	Detectability	Developer Awareness	Blast Radius
Direct malicious package	Moderate	Higher	Single install
Dependency chaining	Low	Very low	All dependents
Poisoned update	Low	Low	Existing installs
Typosquatting	Moderate	Low	New installs only

Anatomy of the Payload: Inside src/helper.php

The core malicious logic lives in src/helper.php, and its construction reveals a developer with meaningful obfuscation experience. This is not a script-kiddie payload—it is an engineered evasion tool.

Control Flow Obfuscation and Encoding

The payload uses several interleaved techniques to resist static and dynamic analysis:

Encoded domain strings: The C2 address helper.leuleu[.]net:2096 is not stored in plaintext but assembled at runtime from encoded fragments
Randomized variable names: Each execution cycle uses dynamically generated variable identifiers, breaking signature-based YARA rules
Control flow flattening: Conditional logic is restructured into non-linear execution paths that confuse decompilers and manual reviewers

Important: Obfuscation of this caliber suggests the attacker anticipated automated scanning. Standard Composer audit tools and many SAST solutions will not flag this payload without heuristic or behavioral analysis.

Function Probing for Maximum Compatibility

One of the most technically interesting aspects of this RAT is its resilience strategy. Before executing shell commands, the payload queries PHP's disable_functions configuration to determine which execution primitives are available. It then falls back across a chain of alternatives in order:

popen
proc_open
exec
shell_exec
system
passthru

This exhaustive fallback ensures the RAT operates even in hardened PHP environments where administrators have disabled common execution functions. Most shared hosting environments and some production hardening guides disable only a subset of these—the attacker accounts for every gap.

Table: PHP Execution Functions Targeted by the RAT

Function	Common Hardening Status	RAT Fallback Priority
`popen`	Sometimes disabled	1st
`proc_open`	Sometimes disabled	2nd
`exec`	Often disabled	3rd
`shell_exec`	Often disabled	4th
`system`	Often disabled	5th
`passthru`	Rarely disabled	6th

RAT Capabilities: What an Attacker Can Do Post-Compromise

Once active, this RAT connects outbound to helper.leuleu[.]net on TCP port 2096, transmits system information, and enters a persistent command loop. The C2 server is currently offline, but the packages remain downloadable on Packagist—meaning any future infrastructure reactivation could immediately weaponize existing installations.

Command Set and Operational Scope

The RAT implements a command handler supporting the following operations:

ping / info: Confirm host connectivity and harvest system metadata (OS, hostname, PHP version, user context)
cmd: Execute arbitrary shell commands via the probed execution function
powershell: Windows-specific PowerShell execution for deeper system access
run: Launch processes in the background, enabling persistence mechanisms or lateral movement
screenshot: Capture screen state using PHP's imagegrabscreen function—particularly damaging on developer workstations
download / upload: Bidirectional file transfer with automatic chmod 777 applied to uploaded files

Persistence Through Laravel's Boot Cycle

What makes this RAT particularly dangerous in a Laravel context is when it activates. The payload registers itself via a service provider or Composer's autoload mechanism, meaning it executes every time the Laravel application boots—not just on first install. This gives it:

Web server process permissions (often elevated in misconfigured deployments)
Direct access to .env files containing database credentials, API keys, and encryption secrets
Persistent re-execution even after the initial infection vector is forgotten
A 15-second C2 retry loop ensuring reconnection whenever infrastructure comes back online

Pro Tip: Audit your config/app.php providers array and bootstrap/app.php immediately if any of these packages are present. Service providers registered by compromised packages will survive routine composer update cycles if not explicitly removed.

Detection, Response, and Threat Hunting

Speed matters in supply chain incidents. The following guidance applies whether you are triaging an active infection or hardening proactively.

Indicators of Compromise (IOCs)

Use these artifacts to hunt across your environment:

Network: Outbound TCP connections to port 2096, particularly from PHP-FPM or web server processes
DNS: Queries to helper.leuleu[.]net (defanged: helper[.]leuleu[.]net)
Filesystem: Presence of lara-helper, simple-queue, or lara-swagger in composer.json or vendor/ directories
Process: Anomalous child processes spawned by php-fpm, apache2, or nginx worker processes
File permissions: Unexpectedly world-writable files (chmod 777) in web-accessible directories

Immediate Remediation Steps

If any of the three packages are present in your environment, execute the following in order:

Isolate the affected application from production traffic immediately
Remove the packages: composer remove [package-name]
Rotate all secrets in .env—database passwords, API keys, APP_KEY, OAuth tokens
Audit outbound connections from the host for the past 30 days using network logs
Review all files modified since the package was first installed
Rebuild the application from a known-clean state rather than patching in place
Report the packages to Packagist's security team for removal

Table: Incident Response Priority Matrix

Action	Priority	Time Target	Owner
Isolate application	Critical	Immediate	Ops / SRE
Remove malicious packages	Critical	< 1 hour	Dev / DevSecOps
Rotate all credentials	Critical	< 2 hours	Dev / Security
Audit network logs	High	< 4 hours	Security
Rebuild from clean state	High	< 24 hours	Dev / Ops
File incident report	Medium	< 48 hours	Security / Legal

Strengthening Your PHP Supply Chain Security Posture

This incident is a forcing function for PHP teams that have not yet formalized their dependency security practices. The NIST Secure Software Development Framework (SSDF) and CIS Controls v8 both address supply chain risk—but implementation in PHP ecosystems often lags behind JavaScript and Python communities.

Dependency Vetting and SBOM Practices

A Software Bill of Materials (SBOM) is no longer optional for production PHP applications. Generate and maintain SBOMs using tools compatible with CycloneDX or SPDX formats. For every new dependency:

Verify publisher identity and publishing history on Packagist
Review the full dependency tree, not just direct dependencies
Check GitHub commit history for the package—sudden ownership transfers are a red flag
Confirm the package has a credible issue tracker, recent activity, and community engagement

Automated Scanning in CI/CD Pipelines

Integrate the following controls into every pull request and deployment pipeline:

composer audit: Flags packages with known CVEs against the PHP Security Advisories Database
SAST tools with PHP support: Behavioral analysis catches obfuscated payloads that signature scanners miss
Dependency pinning: Lock composer.lock into version control and require explicit review for any hash changes
Runtime application self-protection (RASP): Detects anomalous PHP execution patterns at runtime, including unexpected outbound socket connections

Compliance frameworks including SOC 2 Type II, PCI DSS v4.0, and ISO 27001:2022 all include supply chain risk management controls. If your organization operates under any of these standards, this class of attack is directly in scope for your auditors.

Key Takeaways

Remove immediately: If lara-helper, simple-queue, or lara-swagger appear anywhere in your codebase, treat it as an active incident and rotate all secrets
Hunt TCP port 2096: Outbound connections from PHP processes to this port are a high-confidence indicator of compromise
Vet transitive dependencies: The attack chains through dependencies—your direct composer.json entries are not the full picture
Disable unused PHP execution functions: Restricting exec, shell_exec, proc_open, and peers in php.ini limits RAT functionality even post-compromise
Implement SBOMs and composer audit in CI/CD: Automated scanning in the pipeline is the most scalable defense against this attack class
Treat service providers as a trust boundary: Any third-party package that registers a Laravel service provider executes on every application boot with full application context

Conclusion

The lara-helper, simple-queue, and lara-swagger campaign demonstrates that supply chain attackers are expanding beyond the npm ecosystem into PHP with sophisticated, operationally capable tooling. The combination of trust-building through clean releases, dependency chaining, deep obfuscation, and Laravel-native persistence makes this a high-impact threat for any team running PHP in production.

The attacker's current C2 infrastructure is offline—but the packages remain available for download, and the malware's 15-second retry loop means any infrastructure reactivation poses an immediate risk to existing installations. Do not wait for a confirmed compromise to act. Audit your dependencies today, implement automated scanning, and establish the SBOM practices that will make your supply chain resilient against the next campaign. The PHP community is now firmly in the crosshairs of supply chain attackers, and the organizations that survive will be those that treat dependency security as a first-class engineering concern.

Frequently Asked Questions

Q: How do I know if my Laravel application is already infected with this RAT? A: Search your composer.json and vendor/ directory for lara-helper, simple-queue, or lara-swagger. Additionally, review outbound network logs for TCP connections to port 2096 or DNS queries to helper.leuleu[.]net. Any PHP child processes spawned unexpectedly by your web server are also a strong indicator.

Q: The C2 server is currently offline—does that mean I'm safe if I have these packages installed? A: No. The malware includes a persistent 15-second retry loop that will reconnect the moment the attacker's infrastructure comes back online. An offline C2 means the attacker cannot currently issue commands, but your application is still running compromised code and your credentials may already have been exfiltrated during any prior active period.

Q: Does composer audit detect these malicious packages? A: Not currently. composer audit checks against the PHP Security Advisories Database, which requires a CVE or formal advisory to be filed. These packages may not yet be in that database. Behavioral SAST tools and manual review of transitive dependencies provide better coverage for novel supply chain threats like this one.

Q: What PHP hardening steps reduce the impact of a RAT like this? A: Disable unused execution functions in php.ini via the disable_functions directive—targeting exec, shell_exec, proc_open, popen, system, and passthru. Run PHP-FPM workers under a dedicated low-privilege user, restrict outbound network access from web processes using firewall rules, and ensure web-accessible directories are not world-writable.

Q: Is this attack limited to Laravel, or are other PHP frameworks at risk? A: The packages are named to impersonate Laravel tools, making Laravel developers the primary target. However, the core RAT payload in src/helper.php is framework-agnostic. Any PHP application that installs these packages via Composer is at risk, regardless of whether it uses Laravel, Symfony, or plain PHP.