Red Team

CWPdoor: trojanised Control Web Panel server hides signed backdoor

XLab finds CWPdoor, a backdoor rebuilt into Control Web Panel’s cwpsrv that obeys only signed requests and hides them from logs. How to hunt for it.

Illustration of a Linux server with a hidden backdoor, headlined Backdoor hides inside Control Web Panel server

Researchers have found a backdoor compiled directly into the web server that powers Control Web Panel, a free hosting control panel common on budget Linux servers. It sleeps until it receives a cryptographically signed request, then executes commands without leaving a line in the access log.

What happened

On 5 November 2026 XLab, the threat research team at Chinese security firm QiAnXin, published its analysis of a Linux implant it calls CWPdoor. Rather than dropping a separate piece of malware onto a server, the operators took the source code of cwpsrv, the bundled web server that serves the Control Web Panel (CWP) management interface, added their own functions, rebuilt it and swapped it for the genuine binary.

XLab first saw the tooling on 29 June, when its sensors captured a shell script masquerading as a cwpsrv version updater. The script pulled a modified binary from a server at 136.0.141.71 and only supported two cwpsrv builds, 1.15.10 and 1.24.0. On 30 September an archive named evidencia.tgz, uploaded to VirusTotal from Brazil, contained the trojanised server alongside a library that most security vendors flag as Ebury, the long-running Linux credential-stealing backdoor. At that point the CWPdoor binary had no detections at all.

BleepingComputer, reporting the research the same day, noted that XLab could not say who is behind the campaign or how the attackers first got in. The link with Ebury is unproven. What XLab is confident about is that compromised servers exist in the wild, and that its own scanning saw more than 340,000 CWP instances reachable from the internet over the previous month.

The technical picture

The interesting part of CWPdoor is not novelty for its own sake, but discipline. The fake updater needs root, so this is a persistence tool, not an entry point. Once running, it backs up the legitimate binary, stops the service, installs the replacement and restarts it. It then puts the original modification times back on the file and its parent directory, tidies up temporary files and clears the session’s shell history.

The implant itself is passive. It opens no listening port of its own and makes no outbound beacon, so there is nothing for a network sensor to spot until the operator chooses to speak to it. Commands arrive inside ordinary-looking HTTPS requests to the panel, carried in three custom headers that hold a timestamp, an encrypted payload and a signature. The server checks the signature against an RSA public key embedded (lightly obfuscated) in the binary, rejects anything outside a 300-second window to defeat replay, and decrypts the command with AES-256. A helper process, reached over a local Unix socket, runs the command and the encrypted output goes back in the response.

Two design choices stand out. First, signing means nobody else can drive the backdoor, even if they find it: a defender or a rival criminal cannot simply replay captured traffic. Second, the implant interferes with the server’s own logging module so that the triggering request is never written to the access log.

Flow diagram of the five stages by which the CWPdoor backdoor is installed and controlled on a Control Web Panel server

Why it matters for UK organisations

CWP, formerly CentOS Web Panel, is free and popular with small hosting companies, web agencies, managed service providers and individual developers running their own virtual private servers. Plenty of UK small businesses have a website, mailbox or customer portal sitting on exactly that kind of box, often set up years ago by a contractor and rarely revisited. Such servers rarely have integrity monitoring or anyone reading logs.

The panel has a rough security history. CVE-2025-48703, an unauthenticated command injection flaw, went into CISA’s Known Exploited Vulnerabilities catalogue in November 2025. On 3 November this year VulnCheck disclosed ten further CWP flaws, several allowing a hosting account to escalate to root, all fixed in version 1.29 released on 31 October. Nobody has tied CWPdoor’s initial access to any of these bugs, and I would not assume a connection. The point is simpler: a panel with that track record, exposed to the internet, is an attractive foothold, and once attackers are root they now have a tidy way to stay.

A compromised hosting server is rarely contained to one victim. It may hold dozens of customer sites, databases and mailboxes, which makes this a supply chain concern for any UK organisation whose web presence lives on someone else’s CWP install.

Expert view

In my experience, defenders spend a lot of energy looking for malware that sits beside legitimate software and far less checking whether the legitimate software is still legitimate. Replacing a trusted service binary is an old technique, but doing it with signed commands, replay protection and log suppression is the work of someone who expects the box to be examined and wants to survive it.

When we test hosting environments, management panels are a recurring weak spot: exposed admin ports, shared credentials and patch levels nobody owns. CWPdoor also exposes the limits of hash-based detection. The sample had zero detections on VirusTotal when it surfaced, and every operator could recompile with a different key. Behavioural and integrity checks on the host are what will catch this class of implant, not signature feeds.

What to do now

  1. Find your CWP estate. Ask hosting providers whether your services run on Control Web Panel, and inventory your own VPSs.
  2. Patch and reduce exposure. Upgrade CWP to 1.29 or later and remove the admin and user panel ports from the public internet, allowing only VPN or allow-listed addresses. This maps to the Cyber Essentials firewall and security update controls.
  3. Verify the cwpsrv binary. Compare the hash of the installed cwpsrv against a known-good copy from the vendor rather than relying on file dates.

Detection and hunting

  • Look for a Unix domain socket named ngx_http_integrity_helper on CWP hosts.
  • Check for unexpected child or helper processes running under cwpsrv.
  • Search the cwpsrv binary for strings beginning X-Ngx-Integrity, which a clean build should not contain.
  • Look for backup files named cwpsrv.prev followed by a timestamp in the cwpsrv bin directory, a by-product of the fake updater.
  • Search network and proxy logs for any contact with 136.0.141.71, and check XLab’s published file hashes against your estate.
  • Because the implant suppresses its own access log entries, use network flow data or a reverse proxy in front of the panel as an independent record of inbound requests.
  • Given the Ebury overlap, check SSH and shared library integrity too.
  1. If you find it, treat the host as fully compromised. Restoring the old binary is a stopgap; rebuild where you can, rotate every panel, SSH, database and hosted account credential, and investigate how root was obtained. Consider whether personal data on the server triggers an ICO notification.

Bottom line

CWPdoor is a quiet, well-engineered persistence tool aimed at a panel widely used for budget and small-business web hosting. Its operators have planned for scrutiny, so defenders need to check the integrity of the server software itself, close the panel off from the internet and stop treating an empty access log as proof of a clean box.

Sources