1. Basic Information

2. Executive Summary

CWPdoor is a passive backdoor embedded in a modified Control Web Panel web-server binary, cwpsrv. The analyzed deployment script requires root privileges to replace the legitimate binary.

The implant accepts commands through HTTP headers containing a timestamp, AES-encrypted data, and an RSA signature. After validation, a separate helper process executes the command and the result is returned encrypted. The backdoor excludes its trigger requests from its own web-access logging.

This conceals a specific interaction channel. It does not establish that every host, network, or external log is erased.

3. Attack Flow

Deployment Through a Fake Update Script

  1. Environment Check: The root-run cwpsrv_update.sh script checks for a supported cwpsrv version and downloads a corresponding modified binary from 136.0.141[.]71.
  2. Replacement: It backs up the original, stops the service, replaces the binary, restarts the service, and checks process health.
  3. Success or Rollback: A failed health check leads to rollback. Successful replacement leads to deletion of temporary files and the backup.
  4. Common Cleanup and Reporting: Regardless of success or failure, the script restores relevant binary and parent-directory timestamps, removes the current shell-history entry associated with execution, and reports the result.

Deleting temporary files or a history entry is not equivalent to securely erasing every trace.

Passive Command Channel

  1. The attacker sends a request containing X-Ngx-Integrity-Time, X-Ngx-Integrity-Data, and X-Ngx-Integrity-Sig.
  2. The modified server validates the timestamp against a ±300-second window and verifies the RSA signature with an embedded public key.
  3. If validation succeeds, the command is decrypted and passed through the ngx_http_integrity_helper Unix domain socket to a helper child process.
  4. The command executes, and its output is AES-encrypted and returned in an HTTP 200 response.
  5. The trigger request is excluded from the server's access logging.

Requests that fail validation do not activate this command path.

Component Role and Privilege Boundary Communication Concealment and Limits
Modified cwpsrv Receives requests and validates trigger headers; actual runtime privileges matter Existing HTTP/HTTPS endpoint Excludes validated backdoor interactions from its access logs
Unix domain socket Local communication between processes ngx_http_integrity_helper Local IPC does not remove the externally reachable web trigger
Helper process Executes commands with its actual OS privileges Receives commands and participates in returning results A separate process is not necessarily a sandbox or time-limited environment
Deployment script Replaces the binary with root privileges Downloads the implant and reports status Restores timestamps and removes selected artifacts and history

4. Threat Actor Location and Execution Site

  • Deployment: The analyzed script requires root on the target host. The initial access route and method of obtaining that privilege were not disclosed.
  • Post-Deployment Access: The operator must reach the CWP web endpoint and supply a valid timestamp and signature.
  • Execution: Commands run on the compromised host through the implant and helper. Their effective privileges must be established from the host, separately from the script's root requirement.

Network reachability alone does not allow an arbitrary third party to issue accepted commands.

5. Victim and Administrator Visibility

  • Users and Webmasters: Ordinary control-panel functions may continue to work without obvious symptoms. The analysis does not prove an absence of every performance or interface anomaly.
  • Administrators: Trigger requests are omitted from the implant's own access logging, while selected timestamps are restored.
  • Other Evidence: Binary differences, running helpers, the Unix socket, service activity, deployment traffic, host auditing, and external network records may remain available.

A lack of access-log entries is not proof that no backdoor request occurred.

6. Success and Failure Conditions

Success Conditions

  • The deployment script can run with root privileges.
  • The installed version matches a supported sample, identified as 1.15.10 or 1.24.0.
  • The modified binary starts successfully.
  • A trigger request reaches it and passes both timestamp and RSA-signature validation.
  • The helper can execute the requested operation within its actual privileges.

Prevention, Detection, and Their Limits

Stage Required Condition Relevant Control Limit
Deployment Root-authorized replacement of the binary Protect the update and write paths; inspect integrity against trusted baselines FIM detects changes; detection alone does not block replacement or execution.
Implant startup Modified binary runs successfully Verify files and investigate helpers and sockets A file mismatch alone does not prove the binary is running.
Concealment Cleanup and timestamp restoration execute Preserve host audit records and compare content hashes Restored timestamps do not prove file integrity.
Passive trigger Reachable endpoint, valid time, and valid signature Restrict management access and inspect traffic where visible An allowed or compromised management source may still reach the endpoint.
Command execution Validated command reaches an operational helper Monitor execution and contain the host A received request alone is not execution evidence.

Conditions That Interrupt Execution

  • A protection or response action blocks binary replacement, startup, or subsequent execution.
  • Network restrictions prevent trigger requests from reaching the management endpoint.
  • Timestamp or signature validation fails.

Package verification is useful only where the binary is covered by trusted package metadata. Otherwise, compare with a trusted vendor baseline.

7. What Happens Upon Success

  • The backdoor can execute commands with the actual privileges of the relevant processes.
  • Follow-on access to hosted sites, databases, email, or credentials may be possible, depending on permissions and the host's configuration.
  • Suppressed trigger-request logging and restored timestamps can complicate investigation.

The deployment script's root requirement does not independently prove the privilege of every later command. The report does not establish theft of every tenant's data.

8. Observable Logs

The following distinguish sample-derived indicators from possible local investigation sources.

  • Email: No specific email indicator was identified.
  • Proxy / SWG / DNS: Deployment downloads and status-reporting traffic involving 136.0.141[.]71.
  • Endpoint / EDR: Changes to /usr/local/cwpsrv/bin/cwpsrv, service stops and restarts, helpers, shell execution, timestamp changes, and available history-related evidence.
  • Identity / IdP: Investigate earlier SSH and control-panel authentication records. The initial intrusion method is unknown; do not assume brute force or credential stuffing occurred.
  • SaaS / Cloud: Review hosting-platform actions and credential use if host compromise could have exposed them. These are investigation targets, not reported outcomes.
  • Network: Trigger headers where HTTP content is visible. TLS termination inside the compromised server can limit external inspection.

Do not infer a specific timestamp-changing syscall unless host evidence identifies it.

9. Determining Attack Success

  • Public Assessment: XLab assessed an archive submitted to VirusTotal as evidence that real victims existed. This is the source's sample-based assessment, distinct from published per-host execution telemetry.
  • Implant Running — Local Assessment: Establish that the modified binary is running and correlate it with the helper or socket. A suspicious file on disk alone does not establish active execution.
  • Command Execution — Local Assessment: Correlate a validated request with helper execution, returned output, or a resulting artifact.
  • Follow-On Compromise — Local Assessment: Verify subsequent access, modification, or theft separately.

The presence of trigger headers alone is insufficient because signature or timestamp checks may fail.

10. Investigation Playbook

  • Trigger: A suspicious helper or socket, modified cwpsrv binary, unexpected shell execution, or traffic to the reported deployment address.
  • Initial Checks: Record version, hashes, file source, running processes, service relationships, sockets, timestamps, and download destinations.
  • Evidence Preservation: Preserve available audit records, process accounting, shell history, root sessions, and recoverable deployment artifacts.
  • Identity and Cloud Review: Examine control-panel accounts, SSH keys, and any potentially exposed cloud credentials or metadata access.
  • Follow-On Investigation: Check hosted files, database exports, email configuration, credential access, and additional implants.
  • Containment: Isolate an affected host and plan recovery from trusted images or clean backups. Investigate the full privileged compromise rather than only replacing cwpsrv.
  • Credential Response: Rotate potentially exposed control-panel, SSH, cloud, and application credentials through the incident-response process.
  • Classification: Separate exposed CWP services, binary replacement, active implant execution, accepted commands, and downstream compromise.

11. Defense and Detection Ideas

These are defensive proposals based on the analyzed samples.

  • Single-Event Detection: Investigate the ngx_http_integrity_helper socket and unexpected helpers or shells associated with cwpsrv.
  • Correlation: Link downloads, service changes, binary replacement, timestamp restoration, and restart activity.
  • Hunting: Search relevant binaries for X-Ngx-Integrity, compare hashes with trusted files, and review traffic to 136.0.141[.]71.
  • Logging Limits: Use host and external telemetry alongside web logs because the implant suppresses its own trigger-request records.
  • Priority Controls: Protect and verify update sources, restrict management access, monitor binary integrity, and prepare a trusted-host rebuild process.

A detection alert is a reason to investigate and respond, not proof that the implant was prevented from executing.

12. Facts / Inference / Hypothesis

Facts

  • XLab captured cwpsrv_update.sh on June 29, 2026 and analyzed samples targeting two cwpsrv versions.
  • The script rolls back on failure and deletes temporary files and backups on success. Timestamp restoration and status reporting occur regardless of the outcome.
  • The analyzed command channel validates the timestamp and RSA signature before execution and suppresses access logging for the backdoor request.
  • A September 30 VirusTotal submission from Brazil contained CWPdoor and libkeyutils.so.1.5.2, identified as Ebury. Common authorship or operation was not established.

Inference

  • Because web-access logging and timestamps are manipulated, investigators should combine content integrity, running processes, sockets, and external communications.
  • A provider's compromised control panel could expose dependent customers, but that possibility does not establish compromise of every hosted service.

Hypothesis

No additional hypotheses. Unconfirmed matters are listed under "Open Questions and Further Investigation".

13. MITRE ATT&CK Mapping

ID Technique Confidence Basis
T1505.003 Server Software Component: Web Shell high The analyzed web-server implant provides an HTTP-triggered command interface. The mapping is based on functionality, not merely the presence of a backdoor.
T1059.004 Command and Scripting Interpreter: Unix Shell high The helper executes received shell commands through /bin/sh.
T1070.006 Indicator Removal: Timestomp high The deployment script restores timestamps on the binary and parent directory.
T1070.003 Indicator Removal: Clear Command History high The script removes the current shell-history entry associated with execution.

14. Open Questions and Further Investigation

  • The initial intrusion route and how the root-run script was introduced remain unknown.
  • Approximately 340,000 internet-exposed CWP instances represent potential exposure, not confirmed infections.
  • The relationship between Ebury and CWPdoor remains unconfirmed.
  • Runtime privileges and executed commands on a particular host require local evidence.

15. Impact on SOCs and Organizations

Organizations may depend on CWP through a hosting provider even if they do not operate it directly. A compromised management plane can create risk for hosted websites, databases, and email.

This is a provider-dependency risk, not proof that the legitimate CWP distribution channel was compromised. Review providers' host monitoring, binary-integrity controls, and incident-response arrangements. Do not rely solely on cwpsrv access logs to assess the backdoor's activity.

16. Summary by Role

  • SOC: Investigate helpers, sockets, binary differences, X-Ngx-Integrity strings, and reported deployment traffic, then correlate them with execution evidence.
  • Administrators: Restrict management access and investigate the full privileged compromise. Recover from trusted systems and rotate exposed credentials rather than only restoring one binary.
  • Users: Follow the hosting provider's incident guidance and change affected application or email credentials from a trusted environment after containment.