Your Backup Was the Backdoor

The system Chinese intelligence operators spent 18 months living inside was not your firewall, your email server, or your domain controller. It was the appliance you trusted most: the one designed to save you when everything else fails. CVE-2026-22769 is a CVSS 10.0 vulnerability in Dell RecoverPoint for Virtual Machines. It was not discovered by a researcher. It was discovered by Mandiant — while already inside a compromised victim network.

Security teams spend enormous energy defending the perimeter. They harden the edge, monitor the endpoint, and audit the identity layer. What they rarely do is treat the backup infrastructure like adversarial territory. That assumption — that recovery tools are safe by definition — is exactly the gap that a suspected Chinese state-backed threat cluster exploited for over a year and a half without detection. This is the story of how that happened, technically and strategically, and what it means for every organization running VMware in a production environment.

The Security Assumption That Became a Weapon

Dell RecoverPoint for Virtual Machines (RP4VMs) is a data replication and disaster recovery appliance purpose-built for VMware environments. It connects directly to vCenter and ESXi hosts, giving it broad, privileged access to virtualized infrastructure. It replicates data continuously, manages snapshots, and enables point-in-time recovery of virtual machines. In an enterprise context, it is one of the most deeply trusted components in the stack — precisely because its job is to be the last line of defense.

That trusted status comes with a set of unstated assumptions. Security teams assume the appliance is hardened by the vendor. They assume it is monitored by the vendor's own quality processes. They assume that something designed to protect data could not itself be the source of a data loss event. These assumptions are understandable. They are also wrong, and in this case, they were catastrophically so.

"Appliances are often poorly inventoried, not monitored by security teams, and excluded from centralized security logging solutions." — Mandiant / Google Threat Intelligence Group, September 2025

This observation from Mandiant's earlier BRICKSTORM research was made months before the Dell RecoverPoint zero-day came to light. It describes the structural blind spot with precision. Recovery appliances exist outside the normal security monitoring loop. They rarely have EDR tools installed. They do not generate the kind of telemetry that feeds a SIEM. And because they are managed by infrastructure teams rather than security teams, they often go unreviewed for months or years at a time. UNC6201 did not stumble into this blind spot. They targeted it deliberately.

What CVE-2026-22769 Actually Is

The vulnerability has a CVSSv3.0 score of 10.0. That is not a rounding convention or a dramatic flourish — it is the actual maximum score, and it reflects a near-perfect set of conditions for exploitation: no authentication required, network-accessible, no user interaction needed, full root access upon success.

The root cause is straightforward and brutal. During development, a set of default administrator credentials was embedded in the Apache Tomcat Manager configuration file at /home/kos/tomcat9/tomcat-users.xml on the RecoverPoint appliance. Those credentials were never removed before the product shipped. Every version of RecoverPoint for Virtual Machines prior to 6.0.3.1 HF1 contained them. That includes versions 5.3 SP4 P1 and multiple releases in the 6.0 family.

Apache Tomcat Manager is the web-based administration interface that manages and deploys Java web applications to the Tomcat server. On a RecoverPoint appliance, it handles deployment of the appliance's own software components. An attacker with valid credentials can upload a WAR file — a Web Application Archive — to Tomcat via the /manager/text/deploy endpoint. That WAR file can contain arbitrary code. Once deployed, that code executes on the appliance with root privileges. The attacker did not need a zero-day exploit in the traditional sense. They needed a username, a password, and the knowledge that both were sitting in a plaintext configuration file on a networked appliance.

"Using these credentials, a threat actor could authenticate to the Dell RecoverPoint Tomcat Manager, upload a malicious WAR file using the /manager/text/deploy endpoint, and then execute commands as root on the appliance." — Mandiant and Google Threat Intelligence Group, February 2026

The Kill Chain: From Config File to Ghost Network

Mandiant's incident response teams uncovered CVE-2026-22769 while already investigating compromised RecoverPoint appliances — appliances that were actively communicating with command-and-control infrastructure. What they found when they traced back the initial access was a kill chain that is both technically elegant and operationally devastating.

Stage One: Authentication via Hardcoded Credentials

The attacker authenticates to the Tomcat Manager interface using the default admin credentials found in tomcat-users.xml. Web logs stored in /home/kos/auditlog/fapi_cl_audit_log.log reveal this activity as requests to /manager using the username admin. In victim environments, Mandiant observed multiple such requests preceding the compromise, documenting the reconnaissance pattern before the payload deployment.

Stage Two: WAR File Deployment and SLAYSTYLE Web Shell

With Tomcat access established, the attacker uploads a malicious WAR file to the appliance via PUT /manager/text/deploy?path=/<MAL_PATH>&update=true. The uploaded WAR files are stored in /var/lib/tomcat9, with compiled artifacts in /var/cache/tomcat9/Catalina. The payload embedded in the WAR file is a web shell called SLAYSTYLE, which provides the attacker with a persistent, interactive command execution interface on the appliance. From this foothold, root-level access is established. The attacker is now running commands as the most privileged user on a system with direct connectivity to the organization's entire VMware environment.

Stage Three: Backdoor Implantation and Persistence

The SLAYSTYLE web shell provides a working foothold, but web shells are relatively easy to detect and remove. UNC6201 moved quickly to establish deeper persistence. The group deployed BRICKSTORM, a Go-written backdoor with SOCKS proxy functionality that supports cross-platform operation on Linux and BSD-based systems — exactly the kind of environments running backup appliances. Persistence was achieved by modifying a legitimate shell script named convert_hosts.sh, located at /home/kos/kbox/src/installation/distribution/convert_hosts.sh. This script is executed at boot time via rc.local. By inserting the path to the backdoor into this script, the attacker ensured that BRICKSTORM (and later GRIMBOLT) would automatically restart every time the appliance rebooted, surviving power cycles and routine maintenance restarts without any additional action.

Stage Four: Pivoting into VMware with Ghost NICs

The RecoverPoint appliance is connected to vCenter and ESXi hosts by design. That is its purpose. For UNC6201, it was a bridge. From the compromised appliance, the group pivoted deeper into the virtualized environment using a technique Mandiant had not previously documented in their investigations: Ghost NICs.

Ghost NICs are temporary virtual network interfaces created on existing virtual machines running on ESXi servers. By spinning up a hidden network adapter on a live VM, the attacker gains a covert channel to pivot from the compromised VM into internal networks and SaaS environments without going through the monitored network path. The interface is temporary — it can be created and destroyed at will — leaving minimal forensic trace and no persistent network configuration change that would trigger an alert.

Stage Five: Single Packet Authorization on vCenter

On compromised vCenter appliances, Mandiant recovered commands executed via the SLAYSTYLE web shell that implemented Single Packet Authorization (SPA) using iptables. The technique works by monitoring port 443 for a specific hexadecimal string. When that string is detected from a source IP, that IP is added to an approved list. If the approved IP then connects to port 10443, the connection is accepted. For the following 300 seconds, any subsequent traffic from that IP to port 443 is silently redirected to port 10443. This creates a covert, time-limited access channel that is invisible to defenders monitoring standard traffic. The attacker can knock once to open a door that closes automatically five minutes later, leaving no lasting configuration change and no open port to detect.

# iptables SPA sequence observed by Mandiant on compromised vCenter appliances
# Reproduced verbatim from the Mandiant/GTIG advisory (Feb 17, 2026).
# Note: the -m string rule omits the --algo flag (e.g. --algo bm) required
# for the match module to function. The commands are presented as recovered
# from the Systemd Journal on compromised appliances; defenders attempting
# to replicate or build detection logic should add the missing parameter.
iptables -I INPUT -i eth0 -p tcp --dport 443 -m string --hex-string <HEX_STRING>
iptables -A port_filter -i eth0 -p tcp --dport 10443 --syn -m recent --rcheck --name ipt -j ACCEPT
iptables -t nat -N IPT
iptables -t nat -A IPT -p tcp -j REDIRECT --to-ports 10443
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 --syn -m recent --rcheck --name ipt --seconds 300 -j IPT

In at least two documented cases, UNC6201 used their vCenter access to clone Windows Server virtual machines for high-value targets including Domain Controllers, SSO Identity Providers, and secret vaults. When you can clone a domain controller, you do not need to crack the password hash. You take a copy of the machine that generates the hashes.

GRIMBOLT and the Evolution of the Toolkit

In September 2025, Mandiant observed something notable on the already-compromised appliances: the BRICKSTORM binaries were being replaced. Not removed. Replaced. A new backdoor, tracked as GRIMBOLT, was taking their place.

GRIMBOLT is written in C# and compiled using Native Ahead-of-Time (AOT) compilation, a technique introduced to the .NET ecosystem in 2022. The difference from traditional .NET software matters from a defensive perspective. Standard .NET applications use Just-in-Time (JIT) compilation, converting code to machine language at runtime. This process generates Common Intermediate Language (CIL) metadata that analysis tools and reverse engineers use to understand and detect malicious code. Native AOT compilation converts the code directly to machine-native binary during the build process. There is no CIL metadata. Static analysis tools that rely on it see nothing meaningful. The malware is faster, runs better on resource-constrained appliances, and is significantly harder to analyze than its predecessor. GRIMBOLT was also packed with UPX for an additional layer of obfuscation and used the same command-and-control infrastructure as BRICKSTORM, meaning the transition happened without any interruption to the attacker's access.

Whether GRIMBOLT's deployment was a planned upgrade or a response to Mandiant's incident response activity remains unclear. Mandiant themselves stated they could not determine which. That ambiguity is itself informative: it suggests a threat actor operating with enough operational maturity to maintain a toolkit lifecycle and transition between tools without revealing whether they are reacting to pressure or simply running a scheduled rotation. Either interpretation is concerning.

Who Is UNC6201 and Why It Matters

UNC6201 is a suspected People's Republic of China-nexus threat cluster tracked by Mandiant and Google's Threat Intelligence Group. They are known to focus on VMware-related enterprise infrastructure and have demonstrated a clear pattern of targeting the management and recovery layer of virtualized environments rather than the workloads themselves. By compromising the tooling that administers virtual machines, the attacker gains influence over an entire environment rather than a single endpoint.

Mandiant and GTIG have identified notable overlaps between UNC6201 and UNC5221, a separate China-linked cluster known for exploiting zero-day vulnerabilities in Ivanti products to target government agencies. UNC5221 has been associated by various reporting entities with the broader Chinese espionage ecosystem including activity linked to Silk Typhoon, the group responsible for the December 2024 breach of the U.S. Treasury Department and for targeting Microsoft Exchange servers in 2021. GTIG does not currently assess UNC6201 and UNC5221 to be identical clusters, but the shared tooling — BRICKSTORM and SLAYSTYLE appear in both clusters' activity — indicates at minimum shared resources or coordination.

"The value of these targets extends beyond typical espionage missions, potentially providing data to feed development of zero-days and establishing pivot points for broader access to downstream victims." — Mandiant / Google Threat Intelligence Group, September 2025

Previous BRICKSTORM activity attributed to UNC5221 targeted legal services firms, SaaS providers, business process outsourcers, and technology companies. CrowdStrike has separately tracked related BRICKSTORM attacks targeting VMware vCenter servers of legal, technology, and manufacturing companies in the United States under the name Warp Panda. In at least one documented case, the actor used vCenter access to clone Windows Server VMs for domain controllers, SSO identity providers, and secret vaults — effectively photographing the organization's authentication and secrets infrastructure in one operation.

The targeting pattern reveals the strategic intent. These are not opportunistic attackers looking for quick monetization. They are intelligence collectors establishing long-term, persistent access to organizations that handle sensitive legal, technical, and business process data — organizations whose information has intelligence value to a nation-state actor regardless of whether they hold classified government data. There is a supply chain dimension here that deserves explicit attention: when a SaaS provider or legal services firm is compromised, the attacker does not just gain access to that organization's data. They gain a potential pivot point into every downstream customer environment that trusts that provider. Mandiant has noted this directly — the objective in targeting SaaS providers is often to gain access to the customer environments they serve or the customer data they hold. That makes any organization that handles data on behalf of others a target of elevated strategic interest, even if the organization itself does not appear to be a high-value espionage target in isolation.

The Blind Spot That Made All of This Possible

CVE-2026-22769 is a hardcoded credential vulnerability. It is not sophisticated. It does not require a novel exploitation technique, a memory corruption chain, or an advanced bypass of security controls. It requires knowing that a username and password exist in a plaintext file on a network-accessible appliance. The sophistication in this campaign is not in the initial access — it is in everything the attackers did after they walked through a door that should never have been left unlocked.

This points to a structural problem in how enterprise security teams relate to vendor-supplied appliances. When an organization purchases a backup or recovery appliance, they are typically focused on whether it works correctly, not whether it is secure by design. Vendor hardening documentation exists but is rarely reviewed with the same rigor as internal configuration standards. Appliances are enrolled in the network, verified to function, and then largely left alone. They are not enrolled in patch management with the same urgency as servers. They are not monitored by EDR tools because those tools cannot be installed on them. They do not generate SIEM-compatible logs by default. And they are often managed by infrastructure or operations teams who do not have a security mandate and lack the tooling to detect anomalous behavior even when it is occurring.

Mandiant has documented that BRICKSTORM-related actors were going undetected in victim environments for an average of 393 days. The Dell RecoverPoint campaign ran for at least 18 months before it was uncovered. These are not failures of individual organizations. They are the predictable output of an industry-wide assumption that the things we trust to save us do not need to be secured as aggressively as the things we are afraid of losing.

What You Need to Do Right Now

If your organization runs Dell RecoverPoint for Virtual Machines, the immediate action is to upgrade to version 6.0.3.1 HF1. If that upgrade cannot happen immediately, Dell has released a remediation script — apply it now and treat the upgrade as a critical priority. The relevant resources are Dell Security Advisory DSA-2026-079 and the separate remediation script advisory at Dell KB 000426742. For federal civilian executive branch agencies, this is not optional: CISA added CVE-2026-22769 to its Known Exploited Vulnerabilities catalog on February 18, 2026 and issued a remediation deadline of February 21 under Binding Operational Directive 22-01. That three-day window reflects CISA's assessment of active exploitation risk. Organizations outside the federal government should treat that urgency as directly applicable to their own environments.

Beyond the immediate patch, the deeper work is structural. Start by auditing your forensic coverage of backup and recovery appliances. Check whether they generate logs, whether those logs are being shipped anywhere, and whether anyone is actually reviewing them. Pull the Mandiant report and specifically check your RecoverPoint web logs at /home/kos/auditlog/fapi_cl_audit_log.log for any historical requests to /manager. If you see them and cannot explain them, assume compromise and start an incident response investigation.

Expand that audit to every network-connected appliance in your environment — backup systems, VPN concentrators, network management tools, storage controllers. For each one, ask whether it runs a web interface, whether it has default credentials that may not have been changed, and whether any credentials are hardcoded and non-changeable by design. The category of "trusted appliance" is not a security control. It is a category of device that adversaries have learned to prioritize precisely because defenders have not.

On network architecture, review whether your RecoverPoint management interface is accessible from the general internal network or is isolated to a dedicated management VLAN with strict access control lists. The vulnerability requires network access to the Tomcat Manager interface. RecoverPoint's privileged connectivity to vCenter is a functional requirement, but the management interface itself does not need broad network reachability to perform that function. Restricting access to the management interface to a small number of known management hosts is a meaningful control that reduces the attack surface regardless of whether credentials are hardcoded.

Finally, review how VMware management infrastructure is monitored. vCenter and ESXi hosts are high-value targets because they are the management layer for everything else. Audit which systems have connectivity to vCenter. Monitor for unexpected network interface creation on ESXi hosts. Review vCenter access logs for WAR file deployment activity and for VM cloning operations that were not initiated by your own operations team. Ghost NICs leave minimal trace, but vCenter does log the creation of virtual network adapters under VM reconfigure events in the vCenter Server event log (vpxd.log) and in vSphere Distributed Switch port group events — specifically looking for VmReconfiguredEvent entries that add a network adapter outside of your normal change management windows. CrowdStrike's VirtualGHOST PowerShell script, released in conjunction with the BRICKSTORM campaign coverage, can also identify unregistered VMs in your environment.

One additional detection note on the GRIMBOLT transition: because GRIMBOLT was deployed using the same command-and-control infrastructure as BRICKSTORM, any network-level IOCs from the September 2025 BRICKSTORM reporting — IP addresses and domain patterns from that advisory — remain relevant for detecting GRIMBOLT activity. If you already have those IOCs blocked or alerted on, you have partial coverage. If you do not, adding them now provides detection value for both malware families simultaneously.

Key Takeaways

1. Trusted infrastructure is high-value target territory: Recovery and backup appliances have privileged access to your entire environment by design. Adversaries know this. Your security program needs to treat them accordingly, with the same patch urgency, logging requirements, and monitoring expectations as production servers.
2. Hardcoded credentials are a critical vulnerability class: CVE-2026-22769 is a CVSS 10.0 because the attacker needed no exploit — only a credential that existed by default in every vulnerable version. Audit every appliance vendor's documentation for default credential warnings and verify removal before deploying to production.
3. Detection gaps compound over time: When an appliance generates no SIEM-compatible telemetry and sits outside your EDR coverage, the attacker's dwell time is limited only by operational mistakes. UNC6201 made very few of those. Average dwell time in related campaigns was 393 days. Build logging coverage for appliances now, before you need it.
4. Tool evolution signals operational maturity: The transition from BRICKSTORM to GRIMBOLT using Native AOT compilation to defeat static analysis is not the behavior of an opportunistic threat actor. This is a well-resourced group with a malware development lifecycle. Treat the threat accordingly.
5. VMware environments require dedicated monitoring: vCenter is the management plane for everything virtualized. Unexpected network interface creation, VM cloning operations, and WAR file deployments to Tomcat instances are actionable indicators. They need to be on your detection list.

The question Mandiant's report leaves open is how many organizations are still compromised and do not know it. The exploitation began in mid-2024. The advisory came in February 2026. That gap represents months of active intelligence collection inside enterprise networks by actors who have repeatedly demonstrated both the patience and the technical capability to stay invisible. Mandiant has confirmed fewer than a dozen known victims, but acknowledges the full scale is unknown. If you run RecoverPoint in any version prior to 6.0.3.1 HF1, the answer to "were we affected" is: start your investigation, not your assumptions.