PHP RAT in Your Composer Dependencies: The Fake Laravel Packagist Packages Hiding a Cross-Platform Backdoor

The Packages

Security researchers identified three malicious packages published by the Packagist user nhattuanbl:

• nhattuanbl/lara-helper — 37 downloads — contains the RAT payload in src/helper.php
• nhattuanbl/simple-queue — 29 downloads — malicious package loading lara-helper as a dependency
• nhattuanbl/lara-swagger — 49 downloads — visually clean code, but loads nhattuanbl/lara-helper as a Composer dependency, inheriting the payload

The same author published at least three other packages with clean, legitimate code prior to the malicious push. This is a credibility-building technique: establish a presence on the registry with functional tools before weaponising a dependency or publishing a trojanised package. Developers who searched for this author's packages and found real working code had no initial reason to treat new packages from the same namespace as suspicious.

The download counts are small — but Composer package installs propagate. A single compromised project pulled into CI/CD, a starter template, or a shared internal Laravel scaffolding means every application built on top of it is also compromised.

What the Payload Does

The RAT implementation lives in src/helper.php inside lara-helper. It's registered as a Laravel Service Provider, which means it runs at application boot — before any routes, middleware, or application code execute. From the first moment your Laravel application starts, the attacker has a foothold in the same PHP process.

C2 connection: The RAT connects to helper.leuleu[.]net on port 2096 via TCP using PHP's stream_socket_client(). The C2 hostname and path are encoded in the payload to slow static analysis. The connection is currently non-responsive — the C2 appears to be down as of March 4 — but the RAT retries every 15 seconds. Any change to the domain's DNS resolution or C2 infrastructure reactivates every installed instance.

Command capabilities:

• cmd — Execute arbitrary shell commands
• powershell — Execute PowerShell (Windows targets)
• run — Execute commands in background (non-blocking)
• screenshot — Capture screen (where supported)
• download / upload — File transfer to/from attacker
• stop — Terminate the RAT process
• heartbeat — 60-second ping to maintain C2 registration

Shell fallback chain: The RAT doesn't assume a specific execution function is available. It tries them in order: popen → proc_open → exec → shell_exec → system → passthru. PHP hardening configurations that disable individual functions (e.g., disabling exec and shell_exec in php.ini) are not sufficient mitigation — the RAT will fall back to whatever function remains available.

Obfuscation: Control flow is obfuscated. Domain names and API paths are encoded. Variable and function names are randomised. This isn't sophisticated anti-analysis — it's one step above plaintext, and clearly written for deployment speed rather than long-term evasion. Static analysis is slowed but not blocked.

Cross-platform: The RAT runs on Windows (using PowerShell for execution), macOS, and Linux — anywhere PHP runs. This is typical of PHP-based malware: the runtime handles the platform abstraction.

Why Running in the Same Process as Your App Matters

The Service Provider registration pattern is the critical design choice here. Laravel's service providers are the application bootstrap layer — they run before routing, before middleware, before anything your application logic does. A Service Provider registered in composer.json or config/app.php runs with every application invocation: every web request, every queue worker, every Artisan command.

This means the RAT process has full access to:

• The .env file — database credentials, API keys, mail server credentials, payment processor keys, OAuth secrets, encryption keys
• The application's database connection — direct access to all application data through the same credentials the app uses
• The application cache and session store — including any session data or temporary tokens in Redis/Memcached
• The filesystem — all files readable by the web server user, including application source code, uploaded files, and log data
• The network — the ability to make outbound connections to any host the server can reach

From an attacker's perspective, this is ideal placement. The RAT isn't running as a separate process that might get killed by process monitoring or trigger resource alerts. It's embedded in your application — and it has everything your application has.

The Composer Ecosystem Attack Surface

Packagist is the canonical registry for PHP Composer packages. Unlike npm (which has a formal security team) or PyPI (which has invested significantly in malware detection), Packagist historically operated closer to a "publish and trust the community" model. Recent investments have improved automated scanning, but the ecosystem remains high-trust — developers expect composer require vendor/package to give them working, safe code.

The specific technique used here — credibility building before weaponisation — is the same pattern seen in the npm supply chain attacks covered in the StegaBin campaign. The North Korea-linked npm packages studied in that campaign also established presence with functional code before deploying malicious payloads. This pattern defeats naive "only install packages from established authors" guidance. The attack surface isn't new-package-from-unknown-author — it's any package that hasn't been independently verified.

Laravel's Service Provider pattern is particularly attractive as an attack vector because:

• Providers run automatically — there's no explicit invocation for an attacker to trigger
• Developers routinely add provider registrations to config/app.php without examining what the provider does
• Providers are expected to do side-effectful things (register bindings, set up event listeners, establish connections) — so outbound network connections from boot aren't inherently anomalous

SecurityClaw's supply-chain-scanner skill is specifically designed to detect this class of threat. A supply chain audit that checks for encoded strings, unusual network socket calls, and backdoor command patterns in Service Provider code would flag the lara-helper payload before it reaches production.

Detection and Remediation

If you have any of these packages installed, treat your application as compromised. The C2 being currently non-responsive doesn't mean it was never responsive — and it can become responsive again at any time.

Immediate steps:

1. Remove the packages: composer remove nhattuanbl/lara-helper nhattuanbl/simple-queue nhattuanbl/lara-swagger and remove any Service Provider registrations from config/app.php
2. Rotate all credentials exposed in .env: Database passwords, API keys, OAuth secrets, mail credentials, encryption keys. Assume all values in .env were read and exfiltrated. This applies even if the C2 was non-responsive — the payload may have been storing data for later retrieval
3. Audit network egress logs for outbound connections to helper.leuleu[.]net or port 2096 from your application servers. Even a failed TCP connection attempt confirms the RAT executed
4. Audit your Composer dependency tree for other packages from the nhattuanbl namespace or packages that list nhattuanbl/lara-helper as a dependency
5. Check your database for any anomalous records, backdoor accounts, or data modifications in the window since the package was installed
6. Review application logs for unusual commands or file access patterns from the web server user

Ongoing supply chain hygiene:

• Lock dependency versions in composer.lock and commit the lockfile — don't allow composer update in production without a review step
• Use composer audit (available since Composer 2.4) to check for known-malicious packages in your dependency tree
• Review Service Providers registered by third-party packages before installation. A Service Provider that makes outbound network connections is a red flag unless documented and expected
• Consider Socket.dev or equivalent tools for automated malicious package detection in your CI pipeline
• Restrict PHP functions in production environments — even if not sufficient to prevent this RAT, disabling exec, shell_exec, system, and passthru in php.ini raises the attacker's bar for arbitrary command execution

For developers who want to understand the tooling for auditing dependency trees and detecting malicious code patterns, Black Hat Python 2nd Edition provides practical Python tooling for building custom security analysis scripts — including the kind of static analysis checks that would catch encoded socket calls in dependency code.

The Three-Package Approach: Dependency Chain as Attack Vector

The most interesting technical choice in this campaign is the use of lara-swagger — a package with apparently clean code — to pull in lara-helper as a Composer dependency. This creates a two-hop attack chain.

A developer who audits lara-swagger's code sees nothing suspicious. The malicious code is in a dependency they didn't explicitly choose to install and may not have read. Composer's dependency resolution installs it automatically.

This mirrors a well-documented npm attack pattern: publish a clean, useful package (e.g., a Swagger UI helper for Laravel), include a malicious package as a dependency, and let the dependency system do the installation. The developer is auditing the wrong package.

The implication for supply chain security is that auditing only directly declared dependencies is insufficient. You need to audit the full resolved dependency tree — including transitive dependencies. For a typical Laravel application this can be dozens of packages deep. Automated tooling for this audit is non-optional at any meaningful scale.

The Web Application Hacker's Handbook and broader web application security literature covers the trust assumptions that make supply chain attacks effective — understanding why developers trust package registries is the prerequisite for understanding how these campaigns exploit that trust.