China-Linked Hackers Hid Inside Dell’s Disaster-Recovery Appliances Since 2024
A suspected China-linked espionage group exploited Dell RecoverPoint CVE-2026-22769 from at least mid-2024. The attackers did not merely breach a recovery appliance. They turned infrastructure built to restore virtual machines into a concealed route back into them.
Google Threat Intelligence Group tracks the activity as UNC6201. Its investigation found the group using hard-coded Tomcat Manager credentials to upload a malicious web application archive, execute code as root and install a collection of malware that included SLAYSTYLE, BRICKSTORM and GRIMBOLT.
Dell assigned the flaw a maximum CVSS score of 10.0. RecoverPoint for VMs before version 6.0.3.1 HF1 is affected, and Dell warns that older 5.3 SP4 and earlier deployments may also require migration or upgrade. An organisation that treats the hotfix as closure could miss the larger problem: the appliance may already have been a privileged, low-visibility foothold for months.
The recovery system became the persistence layer
| Question | Verified answer | Operational meaning |
|---|---|---|
| What is the flaw? | CVE-2026-22769, hard-coded Tomcat Manager credentials in RecoverPoint for VMs | An unauthenticated network attacker can upload code and obtain root-level execution. |
| Is exploitation confirmed? | Yes. GTIG observed exploitation from at least mid-2024 and attributes the cluster to suspected PRC-nexus UNC6201. | Exposed or reachable appliances should enter incident response, not only patch management. |
| What is affected? | RecoverPoint for VMs before 6.0.3.1 HF1. Dell also provides additional guidance for 5.3 SP4 and earlier. | Inventory the appliance itself, not only the protected VMware environment. |
| What fixes it? | Upgrade to 6.0.3.1 HF1 or follow Dell’s remediation-script guidance where applicable. | A reimage with an older image can reintroduce the condition, so the remediation may need to be applied again. |
How UNC6201 moved through the trust boundary
The vulnerability exposed a management interface that should never have relied on a shared embedded secret. Once inside, the actor uploaded a malicious WAR package through Tomcat Manager. Because the appliance’s services ran with extensive privileges, the result was code execution as root rather than a narrowly contained application compromise.
GTIG found more than one persistence and access method. BRICKSTORM provided a covert backdoor. GRIMBOLT supported in-memory execution. The actor also created what the researchers described as ghost network interfaces and used iptables rules with single-packet authorization. Those choices reduced ordinary network visibility and created a controlled route from the appliance toward protected virtual machines.
The architectural lesson is uncomfortable. Disaster-recovery products are intentionally connected to high-value workloads, hypervisors and storage. They often have broad permissions because restoration must work when normal systems do not. That makes the recovery plane a strategic target, especially when it receives less telemetry and patch attention than production servers.
What defenders should do now
- Upgrade or remediate immediately. Move to RecoverPoint for VMs 6.0.3.1 HF1 or follow Dell’s version-specific remediation procedure.
- Repeat remediation after an older reimage. Dell says reimaging with an affected image can require the remediation script to be run again manually.
- Isolate the management plane. Limit access to dedicated administration networks and enforce tightly scoped firewall rules between the appliance, hypervisors and workloads.
- Hunt beyond the appliance. Review VMware activity, unusual virtual-machine access, new interfaces, unexpected iptables rules, Tomcat uploads and outbound connections associated with the malware described by GTIG.
- Rotate reachable credentials. Treat secrets and privileged service accounts accessible from the appliance as potentially exposed, but preserve evidence before rotating them.
- Validate recovery integrity. Test that recovery images, replication state and administrative workflows have not been modified by an intruder.
The BlackTree view
This was not simply a vulnerable appliance at the edge of the network. It was a compromise of the mechanism organisations expect to trust after everything else fails. The actor’s long dwell time and layered persistence show why recovery infrastructure needs the same detection engineering, credential hygiene and segmentation as primary production systems.
Patch the flaw, but investigate the trust relationship. If RecoverPoint could reach the systems needed to rebuild the business, an attacker controlling RecoverPoint may have been able to reach them too.
Sources and publication details
- Google Threat Intelligence Group: UNC6201 Exploiting Dell RecoverPoint Zero-Day, published 17 February 2026. No publication time was provided.
- Dell Security Advisory DSA-2026-079, initially released 17 February 2026. No publication time was provided.
- Dell: RecoverPoint for VMs remediation-script guidance, accessed 1 September 2026.
Continue the series: APAC Cyber & Digital Law Series index
