CVE-2026-22769: The Dell RecoverPoint Backdoor That Ran for 18 Months

A maximum-severity zero-day in Dell RecoverPoint for Virtual Machines gave a suspected China-linked threat cluster quiet, root-level access to enterprise backup infrastructure for roughly 18 months before anyone noticed. The credential that made it possible was sitting in a plain-text config file the whole time.

When Mandiant and Google's Threat Intelligence Group (GTIG) disclosed CVE-2026-22769 in February 2026, the vulnerability itself was severe enough — a CVSS 10.0, no authentication required, root-level access on a box that sits at the center of enterprise disaster recovery. But the timeline made it worse. The earliest confirmed exploitation traces back to mid-2024, meaning a China-nexus threat cluster had been living inside backup appliances at targeted organizations for well over a year before the flaw was even named.

What Is Dell RecoverPoint for Virtual Machines?

Dell RecoverPoint for Virtual Machines (RP4VM) is a cyber-resilience platform designed to protect VMware virtual machine environments. It handles continuous data protection and replication, and is used to enable quick recovery after ransomware, hardware failure, or other disruptive events. In short, it is the appliance an organization depends on when everything else has gone wrong.

That positioning makes it a high-value target. Compromising a backup and recovery system gives an attacker visibility into the data being protected, potential access to credentials stored or cached during recovery operations, and a foothold on a device that routinely communicates with vCenter, ESXi hosts, and internal storage infrastructure. It is also the kind of appliance that security teams tend not to scrutinize the way they do perimeter devices or endpoints — which likely contributed to the 18-month dwell time here.

Only RecoverPoint for Virtual Machines is affected by CVE-2026-22769. RecoverPoint Classic, including both physical and virtual appliances, is not vulnerable.

The Vulnerability: Hardcoded Credentials in Tomcat Manager

CVE-2026-22769 is a hardcoded credential vulnerability affecting RecoverPoint for Virtual Machines versions prior to 6.0.3.1 HF1. The flaw earned a perfect CVSSv3.1 score of 10.0 with the vector string AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, reflecting network-accessible exploitation that requires no privileges, no user interaction, and produces impacts across all three security pillars. It is classified under CWE-798 (Use of Hard-Coded Credentials).

The root cause is straightforward: Dell RecoverPoint ships with Apache Tomcat Manager as part of its internal software stack, and the admin credentials for that Tomcat instance are hardcoded in a configuration file located at /home/kos/tomcat9/tomcat-users.xml. An unauthenticated remote attacker who knows those credentials — and thanks to this disclosure, that is now a much larger group — can reach the Tomcat Manager interface and deploy arbitrary applications to the appliance.

In the attacks Mandiant investigated, the exploitation path worked exactly that way. The threat actor sent web requests to the Tomcat Manager using the hardcoded admin username, then used the manager's WAR file deployment functionality to install a malicious web application containing the SLAYSTYLE web shell. From there, the appliance was effectively under the attacker's control.

UNC6201 and the Malware Deployed

The threat cluster behind this campaign is tracked by Google as UNC6201, a suspected People's Republic of China (PRC)-nexus group with notable overlaps with UNC5221 — another activity cluster associated with the well-known Chinese APT Silk Typhoon. GTIG does not currently consider the two clusters identical, but the tool overlap and targeting patterns are close enough to be operationally relevant for defenders. Confirmed victims have been identified in North America, and Google told The Hacker News that the campaign was specifically oriented toward organizations in that region. CrowdStrike has separately linked BRICKSTORM tooling to a third China-aligned actor tracked as Warp Panda (also reported as Clay Typhoon and Storm-2416) in attacks aimed at U.S. targets, adding additional attribution complexity to the shared toolset.

The malware story here spans nearly two years of evolution. Mandiant's investigation found that UNC6201 initially deployed BRICKSTORM, a Go-written backdoor with a history of targeting VMware vCenter servers and support for Linux and BSD-based systems, including built-in SOCKS proxy functionality. BRICKSTORM provided remote access and command-and-control capabilities from at least mid-2024 onward. The web shell used in the initial deployment, SLAYSTYLE (also tracked as BEEFLUSH by some researchers), is a JavaServer Pages (JSP) web shell that functions as a persistent backdoor and staging point on the appliance.

Then, in September 2025, something shifted. Investigators observed the existing BRICKSTORM binaries being replaced with a new backdoor called GRIMBOLT. Whether that swap was a planned lifecycle rotation or a reaction to Mandiant's ongoing incident response work is not definitively known, but the timing aligns with the period when investigators were actively working inside victim environments.

GRIMBOLT is written in C# and compiled using .NET's native ahead-of-time (AOT) compilation, a technique introduced in .NET 2022 that produces machine code directly rather than relying on just-in-time compilation at runtime. The practical effect for defenders is significant: AOT-compiled binaries strip out the common intermediate language (CIL) metadata that static analysis tools use to reverse engineer .NET applications. The binary was also packed with UPX. It maintained the same command-and-control infrastructure as BRICKSTORM — communicating via WebSocket connections — while providing a remote shell capability, and was designed to blend with the system's own native files. Google noted that GRIMBOLT is "even better at blending in with the system's own native files," representing a deliberate evolution toward anti-forensic tradecraft.

Both backdoors were made persistent using a legitimate shell script called convert_hosts.sh, which RecoverPoint executes at boot time via rc.local. The script was modified to include the path to the backdoor binary, ensuring the malware would survive reboots and even some remediation attempts.

Beyond the RecoverPoint appliance itself, UNC6201 expanded into VMware infrastructure. Mandiant documented the creation of what researchers call "Ghost NICs" — temporary network interfaces added to virtual machines on ESXi hosts — enabling the actor to move laterally into internal and SaaS environments without generating the kind of network traffic that would stand out in standard monitoring. The group also used iptables rules deployed via the SLAYSTYLE web shell to implement Single Packet Authorization (SPA), a technique that hides an open port from standard scanning by requiring a specific knock sequence before traffic is forwarded.

Rich Reece, Manager of Mandiant Consulting at Google Cloud, warned that the actor is likely still active across both unpatched and previously remediated environments. Given that exploitation stretched back to mid-2024, the group had substantial time to establish persistence and conduct sustained espionage — and confirmed victim counts should not be treated as a ceiling on the true scope. — Rich Reece, Manager, Mandiant Consulting at Google Cloud

Charles Carmakal, CTO of Mandiant, identified the structural problem enabling campaigns like this one: nation-state actors specifically seek systems that lack EDR support. He observed that targeting appliances without endpoint detection makes it "very hard for victim organizations to know they are compromised." — Charles Carmakal, CTO, Mandiant Consulting

The BRICKSTORM Campaign Before CVE-2026-22769

CVE-2026-22769 did not emerge in a vacuum. BRICKSTORM — the backdoor that UNC6201 deployed on RecoverPoint appliances beginning in mid-2024 — had already drawn significant government attention months before Dell's advisory was published. On December 4, 2025, CISA, the NSA, and the Canadian Centre for Cyber Security released a joint Malware Analysis Report on BRICKSTORM, describing a campaign in which PRC state-sponsored actors had been using the tool to maintain long-term persistence in government and IT sector networks. That report was subsequently updated three more times: on December 19, 2025 with indicators for additional Rust-based samples; on January 20, 2026 with new detection signatures; and on February 11, 2026 with analysis of a new variant that differed from all prior samples.

The CISA engagement uncovered one victim where PRC actors had maintained persistent access from April 2024 through at least September 3, 2025 — using BRICKSTORM to embed themselves on an internal VMware vCenter server after first compromising a web server in the organization's demilitarized zone. From there, the actors moved laterally to two domain controllers and an Active Directory Federation Services (ADFS) server, where they successfully exported cryptographic keys. The significance of that ADFS compromise deserves emphasis: exporting ADFS signing keys enables an attacker to forge authentication tokens, potentially granting persistent, legitimate-looking access to any service the ADFS server federates with — including cloud platforms, SaaS environments, and Office 365 tenants. The intrusion's visibility was constrained not by its sophistication but by the absence of EDR tooling on hypervisor-layer infrastructure.

CVE-2026-22769 is therefore not the beginning of this story. By the time Dell's advisory was published on February 17, 2026, the BRICKSTORM ecosystem had been under active government analysis for over two months, Rust-based variants had been documented, and CISA had assessed with confidence that a significant portion of UNC5221 and UNC6201's activity likely remains unknown. CVE-2026-22769 is a new chapter in an ongoing campaign — not the first one.

What 18 Months of Access Actually Means

The 18-month dwell time in this campaign is discussed primarily as a detection failure, and that framing is correct. But it understates the operational consequences. A threat actor with undetected root-level access to a backup and recovery appliance for that duration does not simply observe — they can shape what the organization's recovery infrastructure believes is true.

RecoverPoint for Virtual Machines handles continuous data protection and replication. An attacker resident on this appliance can influence which copies of protected data get replicated, where those copies are routed, and what is ultimately restored during a disaster recovery event. Qualys security research manager Mayuresh Dani framed the risk directly: a compromised appliance can affect which copies of data get replicated, where they go, and what gets restored — making it a high-leverage target for an adversary whose goals extend beyond passive collection to disruption or sabotage.

Additionally, recovery appliances routinely handle or cache credentials — backup service accounts, vCenter admin tokens, domain credentials used during restore operations. An attacker monitoring these operations over 18 months has a sustained credential-harvesting window that no point-in-time audit would catch. The Ghost NIC technique documented by Mandiant — creating ephemeral virtual network interfaces and deleting them after use — fits this pattern precisely: it enables lateral movement while erasing the forensic evidence that would reveal where the actor went and what they accessed. MITRE ATT&CK maps this behavior to T1564 — Hide Artifacts.

The CISA-documented ADFS key export in the parallel BRICKSTORM campaign illustrates the downstream reach. Organizations running affected RecoverPoint versions should not assume that patching closes the risk. If credentials were observed or captured during the dwell period, those credentials — and any authentication tokens generated using them — require rotation. If ADFS federation keys were ever handled by systems the actor could access, those keys require rotation as well.

A Vendor Question Worth Asking

CWE-798 — Use of Hard-Coded Credentials — was first formally catalogued in 2010. It is not an obscure weakness. It appears on OWASP's list of top software risks, it is explicitly called out in CISA's Secure by Design guidance, and it has been at the root of numerous critical vulnerabilities in enterprise appliances over the past decade. The question this case forces to the surface is why a hardcoded admin credential was still shipping in a enterprise disaster recovery product in 2024, and why it was stored in a plaintext configuration file.

The answer is almost certainly not malice — it is the common pattern of internal-use service credentials being excluded from the security review process that governs external-facing authentication. Tomcat Manager is used by RecoverPoint's own deployment tooling; the hardcoded credential likely existed to support that internal function, and at some point in the product's history no one mandated that it be rotated, removed, or replaced with a deployment-time-generated secret. That is a process failure, and it is preventable.

Secure by Design principles — including guidance published by CISA in 2023 and updated since — are explicit on this point: default credentials of any kind, including internal service credentials on appliances, should not ship with products. The correct architecture is to generate unique credentials at installation time, enforce mandatory rotation, or eliminate the credential entirely in favor of certificate-based mutual authentication. For vendors shipping appliances that interact with privileged VMware infrastructure, the standard should be even higher: a credential with this level of access should never exist as a static secret in a file that root-level access can trivially read.

This is not a critique unique to Dell. CWE-798 remains a frequently cited weakness across network appliances, satellite receivers, industrial controllers, and enterprise backup tools in 2025 and 2026. The pattern is consistent: internal tooling credentials get treated as operational necessities rather than security liabilities, static analysis gates in CI/CD pipelines either don't exist or don't flag them, and the credential ships. The fix is institutional: mandatory secret-scanning in pre-commit and build pipelines, credential generation policies at the product architecture level, and regular third-party audits of appliance configuration files before release.

Mandiant discovered CVE-2026-22769 during incident response engagements, not through proactive product research. Investigators working inside a victim's environment noticed Dell RecoverPoint appliances communicating with known command-and-control infrastructure associated with BRICKSTORM and GRIMBOLT. That outbound C2 traffic was the thread that led them to the hardcoded credential and the full attack chain.

Dell published its security advisory (DSA-2026-079) on February 17, 2026. The following day, CISA added CVE-2026-22769 to its Known Exploited Vulnerabilities catalog and required Federal Civilian Executive Branch agencies to apply the patch by February 21, 2026 — a three-day remediation window that reflects how seriously the agency regarded active exploitation. Nick Andersen, executive assistant director for cybersecurity at CISA, stated the agency is "actively combating the multi-year Brickstorm threat campaign" through collaboration with government, industry, and international partners.

On March 5, 2026, Team Cymru security researcher Will Thomas published analysis of the GRIMBOLT command-and-control infrastructure, pivoting from the initial known C2 server at IP address 149.248.11[.]71 using the X.509 certificate subject field value CN=WIN-DO6FVJH67FN. That pivot uncovered two additional IP addresses — 140.82.18[.]134 and 66.42.111[.]219 — all three sharing the same X.509 certificate (SHA256: 8521f42ce73b1646ccf6d85d876e40662fd0560aeded05ce62b94e5e30233cbe) and hosted on the same VPS provider, Vultr. Team Cymru assessed with medium-to-high confidence that the identical certificate artifacts, matching ASN routing, and correlated open port profiles indicate cloned virtual machine images or an automated provisioning script, not coincidence. Because the certificates carried January 2026 issue dates, these IP addresses should not be treated as stale indicators.

As of publication, Mandiant is aware of fewer than a dozen confirmed victim organizations, but the researchers are explicit that the full scope of the campaign is unknown. Given the 18-month exploitation window, organizations that have not yet investigated should not interpret the low confirmed count as evidence of safety.

Remediation and Detection

Dell has published specific remediation steps under advisory DSA-2026-079. The target version is 6.0.3.1 HF1. Organizations running affected builds should follow the path that applies to their current version:

• Versions 6.0.x — upgrade directly to 6.0.3.1 HF1
• Version 5.3 SP4 P1 — migrate to 6.0 SP3 first, then upgrade to 6.0.3.1 HF1
• Versions 5.3 SP4, SP3, SP2 and earlier — upgrade to 5.3 SP4 P1 or any 6.x version, then apply the remediation steps in Dell's advisory

Where immediate patching is not possible, Dell has published a remediation script that can be applied manually. Note that the script must be re-run on any newly deployed or reimaged devices — it does not persist automatically across those operations.

Dell also recommends that RecoverPoint for Virtual Machines be deployed within a trusted, access-controlled internal network with appropriate firewalls and network segmentation in place. The product is not intended for use on untrusted or public networks — a recommendation that, if followed, would have significantly reduced the attack surface here even before the patch was available.

Deeper Solutions and Structural Defenses

Patching to 6.0.3.1 HF1 is necessary. It is not sufficient. The conditions that made this campaign possible — 18 months of undetected access on a trusted internal appliance — reflect architectural gaps that a single patch cannot close. What follows are structural controls that go beyond the standard patch-and-monitor advice.

Microsegmentation of the backup and recovery tier

Dell's advisory states that RecoverPoint for Virtual Machines should not be exposed on untrusted networks, and that network segmentation and firewalling are expected controls. The harder question is whether internal segmentation is enforced between the recovery appliance and the management plane. RecoverPoint requires communication paths to vCenter, ESXi hosts, and storage — but those paths should be defined, scoped, and monitored. Any outbound connection from a RecoverPoint appliance to a public IP, an unfamiliar internal host, or a WebSocket endpoint on port 443 that does not match a known management target is anomalous. GRIMBOLT's C2 channel runs over WebSocket and is specifically designed to blend with HTTPS traffic; the only practical way to surface it is to know exactly what outbound WebSocket connections are expected from that appliance and alert on everything else. This maps to T1071.001 detection engineering for defenders building coverage.

Privileged Access Workstations for recovery infrastructure management

RecoverPoint's Tomcat Manager interface and vCenter consoles should only be reachable from dedicated Privileged Access Workstations (PAWs) on isolated management VLANs, not from general-purpose endpoints. If a backup appliance management interface is reachable from the same network segment as user workstations or from any system that could be compromised through phishing or lateral movement, the blast radius of a stolen credential — hardcoded or otherwise — is unlimited. Jump servers alone are insufficient if they are not themselves hardened and monitored.

DNS-over-HTTPS (DoH) blocking

BRICKSTORM uses DoH to conceal its C2 communications, routing DNS queries through encrypted HTTPS channels to public DoH resolvers rather than the organization's own DNS infrastructure. This bypasses DNS-based monitoring and detection. CISA explicitly calls out DoH blocking as a mitigation in its BRICKSTORM advisory. Organizations should restrict outbound access to known DoH providers (Google 8.8.8.8, Cloudflare 1.1.1.1, etc.) from appliance network segments and monitor for DNS queries that do not route through internal resolvers. This addresses T1568 — Dynamic Resolution and T1090 — Proxy sub-techniques used for SOCKS tunneling.

ADFS and identity infrastructure review

For any organization that ran a vulnerable version of RecoverPoint and has not yet completed a forensic review, ADFS federation signing keys and token-signing certificates should be treated as potentially compromised. If the actor accessed domain controllers or ADFS servers during dwell time — which is consistent with the lateral movement patterns documented in the BRICKSTORM campaign — forged tokens may be in active use. Rotating ADFS keys, reviewing federation trust configurations, and auditing all service principal and OAuth application grants is warranted. This is not a contingency to address after incident confirmation; it should be initiated as part of any precautionary investigation.

VM snapshot integrity monitoring

CISA documented PRC actors stealing cloned VM snapshots for credential extraction in the broader BRICKSTORM campaign. Snapshots contain memory images, which can include plaintext credentials from processes running at snapshot time — domain join credentials, service account passwords, and authentication tokens. Organizations should audit who is authorized to take and copy VM snapshots, monitor snapshot creation events for anomalies, and consider encrypting snapshot storage at rest. An unexpected snapshot of a domain controller or an authentication server created outside of a maintenance window is a high-priority indicator.

Embedding CWE-798 detection in vendor procurement and CI/CD pipelines

For organizations evaluating new appliances or software renewals, requiring vendors to demonstrate static analysis results — specifically for CWE-798 and related credential management weaknesses — should be a procurement requirement, not a nice-to-have. For internal development teams building tools that interact with privileged infrastructure, secret-scanning tools should run at pre-commit and CI/CD build stages. Tools such as Gitleaks, TruffleHog, and SAST platforms with CWE-798 coverage can identify hardcoded secrets before they reach production. The cost of adding this gate is trivial relative to the cost of 18 months of undetected espionage.

Post-patch forensic review using Mandiant's investigative guide

Patching removes the vulnerability. It does not remove a backdoor that was installed before the patch. Organizations that ran any affected version of RecoverPoint between mid-2024 and February 2026 should conduct a forensic review even if no active indicators are present. Mandiant and GTIG have published an investigative guide for full-disk image analysis of affected appliances, along with YARA rules for GRIMBOLT and SLAYSTYLE detection. The absence of obvious C2 traffic is not evidence of a clean environment — SPA-based port concealment (T1205.001) and native AOT compilation (T1027) are specifically designed to evade exactly the monitoring that would surface normal indicators.

Key Takeaways

1. Hardcoded credentials are a critical vulnerability class: CVE-2026-22769 required no prior authentication and no exploitation complexity beyond knowing a credential that was shipped with the product. Organizations should audit backup and recovery appliances — not just perimeter devices — for hardcoded or default credentials as part of routine security hygiene. Vendors should be required to demonstrate CWE-798 scanning results as part of procurement.
2. Backup infrastructure is a priority target: RecoverPoint was chosen precisely because of its privileged position in VMware environments. Threat actors targeting backup systems gain visibility into protected data, legitimate credentials stored or cached during recovery operations, and a persistent foothold on a device that communicates extensively with core infrastructure. Compromising a recovery appliance also opens the door to influencing what data gets replicated and what gets restored — extending the threat from espionage to potential disruption.
3. Dwell time matters as much as the initial exploit: 18 months of undetected access inside critical infrastructure is the more consequential number in this story. Organizations with vulnerable versions of RecoverPoint should not assume a clean bill of health even after patching — a forensic review using Mandiant's investigative guide is warranted for any environment that ran an affected version. ADFS keys and service account credentials should be treated as potentially exposed.
4. This campaign predates the CVE: CISA had been publishing on BRICKSTORM since December 4, 2025. By the time CVE-2026-22769 was named, the malware ecosystem had been updated four times, Rust-based variants had been documented, and ADFS key theft had been confirmed in at least one victim engagement. Organizations should review prior CISA advisories on BRICKSTORM (AR25-338A) for indicators that predate the Dell disclosure.
5. Patch immediately if you have not already: CISA's KEV listing and the three-day federal remediation window signal the severity level. The target patch is version 6.0.3.1 HF1. Dell's advisory (DSA-2026-079) has the full remediation paths. After patching, implement the structural defenses described in this article — segmentation, PAWs, DoH blocking, and snapshot monitoring — to address the conditions that enabled this campaign to run undetected for as long as it did.

CVE-2026-22769 is a reminder that the security of disaster recovery infrastructure deserves the same scrutiny as the perimeter. When the appliance meant to save you from a crisis becomes the entry point for one, the assumption that backup systems are low-risk because they sit inside the network stops holding. But the deeper lesson here runs further: the BRICKSTORM ecosystem was already under government analysis months before this CVE was disclosed, ADFS keys had already been stolen in parallel campaigns, and the malware had already evolved from Go to Rust to C# with native AOT compilation. This threat cluster is not iterating slowly. The organizations that come through campaigns like this intact are the ones that treat backup and recovery infrastructure with the same adversarial skepticism they apply to edge devices — and do not wait for a named CVE to start asking the question.