Chinese Hackers Exploited Dell Backup Flaw for Months Using Hard-Coded Password

What makes this particularly alarming is the timeline. Mandiant's research indicates that a threat cluster it tracks as UNC6201, assessed to be linked to the People's Republic of China (PRC), has been exploiting this zero-day vulnerability since approximately mid-2024 — roughly 20 months before a patch became available. During that window, UNC6201 deployed multiple custom malware families, established persistent footholds, and in some cases used the compromised appliances as launchpads for deeper intrusions into VMware ESXi and vCenter environments.

Dell was notified in late 2025 and released the fix — version 6.0.3.1 HF1 — on February 17, 2026, alongside a remediation script for organizations that cannot immediately upgrade.

Understanding the Vulnerability

At its core, CVE-2026-22769 is a textbook example of CWE-798: Use of Hard-coded Credentials. The RP4VMs appliance ships with a static admin account for Apache Tomcat Manager. The credentials live in a configuration file that is identical across every deployment:

Because this file is part of the appliance image, every single RP4VMs installation — regardless of version, customer, or environment — shares the same username and password. The Tomcat Manager web application is bound to the appliance's HTTPS interface, meaning it is reachable on the same ports used for legitimate management traffic.

Think of it this way: Dell shipped every copy of this backup appliance with the same front-door key, and that key was written on a sticky note inside the appliance itself. Anyone who obtained a copy of the appliance — or simply knew where to look — had the master key to every RP4VMs deployment on the planet.

The Attack Chain

Mandiant's research provides a detailed, step-by-step breakdown of how UNC6201 weaponized this flaw. The attack chain is straightforward and requires no special tools, no exotic exploits, and no user interaction:

1. Network Reconnaissance: The attacker identifies an RP4VMs appliance reachable over the network, typically via its HTTPS management interface on port 443 or 8443.
2. Authentication with Hard-Coded Credentials: The attacker connects to the Tomcat Manager endpoint and authenticates using the static admin username and password embedded in tomcat-users.xml. No brute-forcing is necessary — the credentials are known.
3. Malicious WAR File Deployment: Once authenticated, the attacker uses the Tomcat Manager's built-in deployment API to upload a malicious WAR (Web Application Archive) file. The HTTP request looks something like this:

1. Code Execution as Root: The WAR file is written to /var/lib/tomcat9, compiled by Tomcat, and executed. Because the Tomcat process runs as root on the appliance, the attacker immediately has root-level code execution.
2. Web Shell Deployment (SLAYSTYLE): The WAR payload contains a custom web shell that Mandiant tracks as SLAYSTYLE. This shell provides interactive command execution on the compromised appliance, giving the attacker a persistent, browser-accessible backdoor.
3. Backdoor Installation (BRICKSTORM and GRIMBOLT): Using the SLAYSTYLE web shell, UNC6201 drops and executes two additional malware families:
4. Persistence via Startup Script Modification: To survive reboots, the attacker modifies a legitimate boot-time script:

This script is invoked via rc.local during system startup, ensuring the backdoors are re-established every time the appliance boots.

1. Lateral Movement via "Ghost NIC" Techniques: In some cases, UNC6201 used the compromised RP4VMs appliance to pivot into connected VMware ESXi and vCenter environments using what Mandiant describes as "Ghost NIC" techniques — leveraging the appliance's privileged network position within the virtualization infrastructure to reach systems that would otherwise be isolated.

The entire attack — from initial access to persistent root-level compromise — can be executed in minutes by an attacker who knows the credentials. No vulnerabilities need to be chained. No memory corruption exploits are required. It is, as multiple analysts have assessed, trivially exploitable.

Who Is Affected

Every version of Dell RecoverPoint for Virtual Machines prior to the patched release is vulnerable. The following table summarizes the affected and fixed versions based on Dell's security advisory DSA-2026-079:

RP4VMs is deployed by enterprises and service providers who rely on VMware-based virtualization for their production workloads. These are typically mid-to-large organizations in sectors including financial services, healthcare, manufacturing, and government — environments where backup and disaster recovery infrastructure is mission-critical. The appliance's position within the data center gives it access to replicated copies of production data, stored credentials, and direct network connectivity to VMware management planes.

Organizations running RP4VMs on older 5.3.x branches will need to first migrate to the 6.0 SP3 branch before applying the 6.0.3.1 HF1 hotfix, which adds complexity and potential downtime to the remediation process.

Real-World Risk

Active Exploitation by a Nation-State Actor

This is not a theoretical risk. According to Mandiant's February 17 blog post, UNC6201 — a threat cluster with assessed ties to the People's Republic of China — has been actively exploiting CVE-2026-22769 as a zero-day since approximately mid-2024. Mandiant also notes possible overlap between UNC6201 and other tracked Chinese threat clusters, including UNC5221 and the group Microsoft tracks as Silk Typhoon.

The campaign involved deploying three distinct malware families on compromised RP4VMs appliances:

• SLAYSTYLE: A custom web shell deployed via the Tomcat Manager WAR deployment mechanism, providing interactive command execution.
• BRICKSTORM: A backdoor communicating over WebSocket (WSS) connections to attacker-controlled infrastructure, specifically observed connecting to wss://149.248.11.71/rest/apisession.
• GRIMBOLT: A secondary backdoor providing redundant persistent access.

The threat actors achieved persistence by modifying the legitimate startup script convert_hosts.sh, which is executed via rc.local on every boot. This means that even if an administrator noticed and killed the malicious processes, they would return after a reboot.

CISA Known Exploited Vulnerabilities (KEV) Catalog

CISA added CVE-2026-22769 to its KEV catalog on February 18, 2026, with the following enrichment assessments:

• Exploitation: Active
• Automatable: Yes
• Technical Impact: Total

The "Automatable: Yes" designation is particularly significant — it means CISA assesses that exploitation can be scripted and executed at scale without manual intervention. Combined with "Technical Impact: Total," this places CVE-2026-22769 in the highest-risk category under CISA's Stakeholder-Specific Vulnerability Categorization (SSVC) framework.

Under Binding Operational Directive (BOD) 22-01, federal civilian agencies are required to remediate KEV-listed vulnerabilities within specified timeframes. CISA also notes possible use of this vulnerability by unattributed ransomware groups, though specific campaigns have not been publicly detailed.

What Could an Attacker Do?

The consequences of a compromised RP4VMs appliance are severe and far-reaching:

• Destroy or encrypt backups: An attacker with root access to the backup infrastructure can delete or encrypt the very data organizations would need to recover from a ransomware attack, eliminating the safety net.
• Exfiltrate sensitive data: Replicated data flowing through the appliance may include customer PII, financial records, intellectual property, and credentials — all accessible to an attacker with root privileges.
• Pivot into VMware environments: The appliance's network position and its integration with VMware ESXi and vCenter provide a natural pivot point for lateral movement into production virtualization infrastructure.
• Establish long-term espionage access: The persistence mechanisms observed (startup script modification, multiple backdoors) indicate that threat actors are building durable footholds for ongoing intelligence collection.
• Undermine disaster recovery confidence: Even after remediation, organizations may be unable to trust the integrity of their backup data if the appliance was compromised, potentially requiring a complete rebuild of their DR infrastructure.

What You Should Do

Organizations running Dell RecoverPoint for Virtual Machines should treat this as a maximum-priority emergency and take the following actions immediately:

1. Apply the Patch (6.0.3.1 HF1)

Dell released version 6.0.3.1 HF1 on February 17, 2026. This is the definitive fix that removes the hard-coded credential. Download and installation instructions are available in Dell's security advisory:

• Advisory: DSA-2026-079 (https://www.dell.com/support/kbdoc/en-us/000426773/dsa-2026-079)

For organizations on the 5.3 SP4 P1 branch, you must first migrate to the RP4VMs 6.0 SP3 branch and then upgrade to 6.0.3.1 HF1. Plan for the associated downtime and migration effort.

2. Run the Remediation Script (If Immediate Patching Is Not Possible)

Dell has published a remediation script in the knowledge base article titled "RecoverPoint for Virtual Machines: Apply the remediation script for DSA-2026-079." This script disables the use of the hard-coded credential without requiring a full upgrade. Be aware that:

• The script requires a temporary service interruption.
• It provides partial mitigation — it blocks remote use of the credential but does not remove it from the image.
• It is a stopgap measure; the full patch should be applied as soon as possible.

3. Change the Default Tomcat Manager Password Immediately

As an immediate compensating control, manually change the admin password in /home/kos/tomcat9/tomcat-users.xml to a strong, unique value. Note that this may require updating any internal automation or management scripts that reference the default credentials.

4. Restrict Network Access

The Tomcat Manager interface should never be exposed to untrusted networks. Implement the following network controls:

• Place RP4VMs appliances on a dedicated, isolated management VLAN.
• Enforce strict firewall rules that restrict access to the management interface (ports 443/8443) to known administrator IP addresses only.
• Block all inbound access from the internet or untrusted network segments.

5. Hunt for Indicators of Compromise

Given that exploitation has been ongoing since mid-2024, any organization running an unpatched RP4VMs appliance should assume potential compromise and conduct a thorough investigation. Look for the following IOCs:

• Successful authentication to Tomcat Manager with the username admin from unexpected source IPs.
• HTTP PUT requests to /manager/text/deploy?path=/*&update=true in Tomcat access logs.
• New or unexpected WAR files in /var/lib/tomcat9 or /var/cache/tomcat9/Catalina.
• Modifications to /home/kos/kbox/src/installation/distribution/convert_hosts.sh — compare against a known-good backup.
• Outbound network connections to 149.248.11.71 or WebSocket connections to wss://149.248.11.71/rest/apisession.
• Presence of GRIMBOLT or BRICKSTORM binaries on the appliance (hash values are available in Google Threat Intelligence collections).
• Unexpected privileged sessions or command execution in system audit logs.
• Entries containing /manager in /home/kos/auditlog/fapi_cl_audit_log.log.
• Tomcat deployment events in /var/log/tomcat9/Catalina logs (org.apache.catalina.startup.HostConfig.deployWAR).

6. Deploy Detection Rules

Mandiant has published the following detection rules that organizations can deploy:

• YARA: G_APT_BackdoorToehold_GRIMBOLT_1
• YARA: G_Hunting_BackdoorToehold_GRIMBOLT_1
• YARA: G_APT_BackdoorWebshell_SLAYSTYLE_4
• Sigma/Google SecOps rule: "Web Archive File Write To Tomcat Directory"
• Sigma rule: "Remote Application Deployment via Tomcat Manager"

Additionally, create custom alerts for:

• SSH logins with the known hard-coded credential hash.
• Authentication logs showing login success for the default admin user without a prior password change.
• Audit logs indicating execution of privileged commands shortly after login.

7. Conduct Forensic Review

If any indicators of compromise are found, conduct a full forensic investigation of the affected appliance. Given the persistence mechanisms employed by UNC6201 (startup script modification, multiple backdoors), a complete rebuild from known-good media is strongly recommended rather than attempting to clean a compromised system.

Verify the integrity of convert_hosts.sh and other startup scripts. Restore from known-good backups if modifications are detected.

8. Consider Decommissioning

For organizations running RP4VMs in cloud deployments, CISA's BOD 22-01 guidance suggests considering decommissioning unpatched instances if remediation cannot be applied within the required timeframe.

The Bigger Picture

CVE-2026-22769 is a stark reminder that backup and disaster recovery infrastructure is itself a high-value target — and that hard-coded credentials remain one of the most dangerous and preventable classes of vulnerability in enterprise software.

The fact that a PRC-linked threat group was able to exploit this flaw as a zero-day for approximately 20 months before a patch was available underscores several uncomfortable realities:

First, appliances that sit at the heart of data protection strategies are often the least scrutinized from a security perspective. Organizations invest heavily in endpoint detection, network monitoring, and cloud security, but the backup appliance — the last line of defense against ransomware — frequently operates in a blind spot. Threat actors know this, and they are increasingly targeting backup infrastructure precisely because compromising it eliminates an organization's ability to recover without paying a ransom.

Second, hard-coded credentials are a vulnerability class that should not exist in 2026. CWE-798 has been on every major vulnerability taxonomy and "top dangerous software weaknesses" list for over a decade. Yet vendors continue to ship products with static passwords embedded in configuration files and binaries. Every instance of this pattern is a ticking time bomb — it is not a question of if the credential will be discovered, but when.

Third, the timeline of this vulnerability is deeply concerning. Mandiant's assessment that exploitation began in mid-2024 means that threat actors had access to a trivially exploitable flaw in enterprise backup infrastructure for roughly 20 months before defenders received a patch. During that window, an unknown number of organizations may have been compromised without any awareness. The gap between exploitation and remediation availability is a recurring challenge in cybersecurity, but the length of this particular gap — and the criticality of the affected product — makes it especially noteworthy.

Organizations should use this incident as a catalyst to audit their own backup and DR infrastructure for similar issues: default credentials, unnecessary network exposure, and lack of monitoring. The attackers who targeted RP4VMs understood that the shortest path to devastating impact often runs through the systems organizations trust the most.

For those tracking the broader threat landscape, it is worth noting Mandiant's observation of possible overlap between UNC6201 and other Chinese threat clusters including UNC5221 and Silk Typhoon. This suggests a pattern of sophisticated state-linked actors systematically targeting enterprise infrastructure appliances — a trend that has accelerated significantly over the past two years with zero-day exploitation of VPN concentrators, email gateways, and now backup systems.

Patch immediately. Hunt for compromise. Segment your backup infrastructure. And never assume that the systems protecting your data are themselves protected.