Web Compromise · October 20, 2025

From Webshells to the Cloud

Contents

Campaign Identifier: Webshells-To-Cloud-Modular-Intrusion
Last Updated: October 20, 2025
Threat Level: HIGH

BLUF (Bottom Line Up Front)

Executive Summary

This campaign chains PHP backdoors, exploit kits, and cloud API abuse into a modular intrusion framework. Attackers compromise web servers via CloudPanel 0-day exploit kits, deploy RSA-encrypted webshells for exclusive persistent access, and exfiltrate data through Dropbox, Rclone, and AWS S3. A reused RSA public key, consistent cookie name (clp-fm), and predictable file paths form strong attribution fingerprints across both infrastructure servers.

Defenders should block known infrastructure (45[.]118[.]144[.]151:8081, 152[.]32[.]191[.]156:8081), scan web directories for PHP files containing __wakeup() with RSA key blocks, audit cloud API logs for unexpected outbound transfers, and hunt web logs for the clp-fm cookie and access to /file-manager/backend/makefile. Full technical findings begin at Technical Analysis.

Key Risk Factors

Risk Factor	Score	Business Impact
Web Server Compromise	9/10	Complete server control with data exfiltration and lateral movement capabilities
Cloud Infrastructure Abuse	8/10	Legitimate cloud services abused for C2, exfiltration, and attack infrastructure
Persistence Mechanisms	8/10	Multiple backdoors with RSA encryption ensuring exclusive attacker access
Attribution Fingerprints	7/10	Strong attribution evidence but may indicate shared tools across threat groups

Recommended Actions

Priority 1: Immediate Response

ISOLATE web servers with PHP backdoor infections from production networks
BLOCK known malicious infrastructure at the network perimeter (45[.]118[.]144[.]151:8081, 152[.]32[.]191[.]156:8081)
SCAN web server directories for PHP backdoors using provided IOCs
AUDIT cloud service access logs for unauthorized API usage and exfiltration indicators
COLLECT forensic evidence: web server logs, memory images, and network captures

Priority 2: Investigation

Reconstruct the exploitation timeline from web server logs
Correlate log entries against known malicious infrastructure indicators
Audit cloud accounts for unauthorized API access and anomalous data transfers
Recover and analyze PHP backdoors and exploit kit components
Hunt for lateral movement and additional compromised hosts

Priority 3: Remediation

Rebuild compromised web servers from verified clean images
Apply current patches to all web applications and frameworks
Deploy web application firewall rules targeting PHP backdoor patterns
Establish baseline monitoring for cloud service API usage

Technical Analysis

Infrastructure Overview

Infrastructure Component	Value	Role in Attack Chain
Primary C2 Server	45.118.144[.]151:8081	Initial webshell deployment and backdoor hosting
Exploitation Server	152.32.191[.]156:8081	Exploit kits, payload delivery, and automation
Content Delivery	juyu1[.]yifanyi.app	Malicious content distribution and SEO poisoning
Command Infrastructure	shellcp[.]info	Remote content injection and proxy services

Phase 1: Initial Discovery (45.118.144[.]151)

Analyst note: This phase covers the attacker’s first-stage implants: a backdoored PHP page that executes only attacker-signed payloads, a general-purpose command shell, and a traffic redirector. Understanding the RSA-keyed execution gate is key — it blocks any third party from reusing these backdoors against the same victims.

File: pg-politica-de-privacidade.php

Trojanized Privacy Policy page.
PHP class A with __wakeup() method.
Hardcoded RSA public key → only attacker‑encrypted payloads execute.
Trigger: $_POST['mxx'].
Obfuscation: dynamically builds function names (openssl_public_decrypt, base64_decode).
Executes decrypted payload via eval().
Camouflage: Legitimate Portuguese Privacy Policy appended.
Implication: Exclusive access backdoor; RSA key is a campaign fingerprint.
Hunting Highlights:
- PHP files with __wakeup() + unserialize() + eval()
- POST requests with parameter mxx
- Embedded RSA public key blocks in PHP code

File: upnimix.php

Full‑featured PHP webshell.
Capabilities: command execution, file upload/edit/delete/rename, directory listing.
Implication: Persistence and full remote control.
Hunting Highlights:
- PHP files with goto + exec/system/shell_exec/passthru
- POSTs with parameters like cmd, file_content, upload
- PHP spawning OS processes (/bin/sh, cmd.exe)

File: video.php

Remote content injector.
Behavior: proxies requests to shellcp[.]info/api.php.
Cloaks behavior for Googlebot (?googlebot).
Implication: SEO poisoning, phishing, or malware delivery.
Hunting Highlights:
- PHP files with file_get_contents("http://shellcp.info/...")
- Outbound HTTP requests to shellcp[.]info
- Cloaking logic tied to “oogle” in User‑Agent

Phase 2: Pivot & Exploitation (152.32.191[.]156)

Analyst note: This phase covers the exploit kits targeting CloudPanel — a web hosting control panel. The exploit chain forges an authentication cookie to bypass access controls, then creates and uploads a command shell. Attackers also create a persistent OS-level account as a fallback.

Exploit Kits

Scripts: 测试.py, exploit.py, exploit2.py.
Helper: Crypto.php (forged clp-fm cookie).
Exploit chain: forge cookie → access /file-manager/ → create file → upload shell → set permissions → verify at /htdocs/app/files/public/shell.php.
Variants: batch exploitation, version‑specific (CloudPanel 0day Version : 2.0.0 >= 2.3.0).
Persistence variant: creates user zeroday / password Etharus@1337.

Webshells

One‑liner (?cmd= → system execution, fallback to phpinfo()).
shell.php uploaded with 0777 permissions.

Hunting Highlights

Web logs with cookie header clp-fm.
Access to /file-manager/backend/makefile or /phpmyadmin/js/.
New privileged accounts (zeroday).
File creation in /htdocs/app/files/public/.
Requests with ?cmd= in query strings.

Phase 3: Exfiltration & Cloud Abuse

Analyst note: This phase covers the attacker’s use of legitimate cloud storage APIs to move stolen data off the victim server. Because outbound traffic reaches real cloud provider endpoints (Dropbox, AWS), standard perimeter blocks are ineffective — detection depends on behavioral anomalies in the traffic volume and destination.

Modules

Dropbox: Client.php, AccessCodeValidator.php → API abuse for stealthy uploads.
Rclone: Rclone.php, TarCreator.php → bulk data theft, retries, throttling.
AWS: Ami.php, Instance.php, Regions.php → S3 exfiltration, destructive actions possible.

Hunting Highlights

Outbound traffic to api.dropboxapi.com.
Rclone process execution (rclone, rclone.exe).
Unexpected S3 PutObject/DeleteObject events in CloudTrail.
Large outbound transfers to cloud storage from servers without backup roles.

Phase 4: Infrastructure Automation

Analyst note: This phase covers the attacker’s toolkit for scaling compromised infrastructure — installing new web applications, standing up reverse proxies, and automating domain provisioning. This automation capability indicates the operator treats compromised servers as reusable attack nodes, not one-time footholds.

Site Builder Framework (Site/ directory)

Installers: WordPressInstaller.php, PhpSite.php, NodejsSite.php, PythonSite.php.
Reverse Proxy: ReverseProxySite.php → traffic redirection.
Domain Automation: DomainName.php.
Scaling: VarnishCache/Creator.php.

Hunting Highlights

Automated WordPress installs from non‑admin sources.
Sudden creation of reverse proxy configs in Nginx/Apache.
Varnish cache deployments on non‑web infra.
Suspicious PHP files named WordPressInstaller.php, ReverseProxySite.php.

Attack Chain Analysis

Campaign Structure Summary

Attack Phase	Primary Techniques	Infrastructure Used	Business Impact
Initial Access	CloudPanel 0-day exploit kits, PHP backdoors	45.118.144[.]151:8081	CRITICAL - Server compromise
Persistence	Webshells, backdoor accounts, RSA-encrypted payloads	Multiple compromised servers	HIGH - Long-term access
Exfiltration	Dropbox API abuse, Rclone, AWS S3 exploitation	Legitimate cloud services	HIGH - Data theft
Infrastructure Scaling	Automated site builder framework, reverse proxies	Compromised web infrastructure	MEDIUM - Attack expansion

Attribution Fingerprints

Fingerprint Type	Value	Confidence Level
RSA Public Key	Reused across multiple IPs and backdoors	CONFIRMED
Cookie Names	clp-fm (consistent across exploit kits)	CONFIRMED
File Paths	/htdocs/app/files/public/shell.php	CONFIRMED
Account Patterns	zeroday/Etharus@1337 (consistent credentials)	MODERATE

Operational Impact Assessment

Impact Scenarios

Impact Category	Severity Level	Recovery Time
Data Compromise	HIGH	extended period
System Compromise	HIGH	several weeks
Cloud Service Abuse	MEDIUM	several weeks
Operational Disruption	HIGH	several weeks

Operational Impact Timeline

Immediate Response: Web server isolation, service disruption, emergency response
Investigation Phase: System rebuilding, security hardening, enhanced monitoring
Recovery Phase: Process improvements, cloud security implementation
Long-term Phase: Security architecture review, compliance activities

Frequently Asked Questions

Technical Questions

Q: What makes the RSA encryption backdoor particularly dangerous?
A: It ensures exclusive attacker access — only payloads encrypted with the corresponding private key will execute, preventing other actors or security tools from reusing the backdoor.

Q: How does cloud service abuse work in this campaign?
A: Attackers abuse legitimate cloud APIs (Dropbox, AWS S3) for data exfiltration and infrastructure, making detection difficult because traffic reaches real cloud provider endpoints.

Q: What are the key hunting indicators for this campaign?
A: PHP files with __wakeup() methods, POST requests with mxx parameter, embedded RSA keys, and access to /file-manager/ endpoints with forged cookies.

Business Questions

Q: What are the regulatory implications of cloud service abuse?
A: Unauthorized cloud access can trigger data breach notification obligations and potential liability for customer data exposure, depending on applicable regulations.

Q: Should compromised web servers be rebuilt or patched?
A: Rebuilding from a verified clean image is the safer path given the depth of backdoor access and the possibility of additional hidden compromise mechanisms.

Q: How can similar cloud abuse be prevented?
A: Cloud access monitoring, API security controls, regular access reviews, and least-privilege enforcement on cloud service accounts each reduce the attack surface for this technique.