Rooting Recovery: The Dell RP4VMs Hardcoded Horror Show

Imagine buying a high-end safe to store your crown jewels. You lock it up tight, spin the dial, and go to sleep. Meanwhile, the manufacturer left a sticky note on the back of the safe that says 'Master Code: 1234'. That is effectively what happened with Dell RecoverPoint for Virtual Machines (RP4VMs).

RP4VMs is a critical piece of enterprise kit. It sits deep inside virtualized environments, orchestrating disaster recovery and continuous data protection. To do its job, it needs intimate access to your vCenter, your ESXi hosts, and your storage arrays. It is a privileged, trusted asset. And for the last few years, it has been serving as a VIP entrance for the Chinese cyber-espionage group UNC6201.

The vulnerability isn't in some proprietary, complex Dell protocol. It's in the bundled Apache Tomcat instance. Tomcat is the workhorse of Java web apps, and like any workhorse, it needs to be broken in properly. Dell apparently skipped that part, leaving the default management interface exposed with credentials that were hardcoded into the configuration files. This gave attackers a 'God Mode' button accessible from the network.

Let's get technical. The root cause here is CWE-798: Use of Hard-coded Credentials. In the world of secure development, this is a cardinal sin, usually reserved for IoT toasters and cheap routers, not enterprise disaster recovery appliances.

The vulnerability resides in the tomcat-users.xml file. For those unfamiliar with Tomcat, this XML file defines the users, passwords, and roles for the Tomcat Manager application (/manager/html). The Manager App is a powerful administrative interface that allows you to list, start, stop, and—crucially—deploy web applications.

Dell's engineering team seemingly left a user account defined in this file (let's call it the 'support' user) with a static password. This file was present on every single installation of the affected versions. Because the password was static across the fleet, once UNC6201 cracked it (or perhaps reverse-engineered a patch or installer), they had a skeleton key for every internet-facing RP4VM instance on the planet.

> [!NOTE] > The terrifying part is the role assignment. The hardcoded user wasn't just a read-only viewer; it was assigned the manager-gui and manager-script roles. These roles are effectively 'Root by Proxy' in the Tomcat world.

While I won't publish the exact password string to keep the script kiddies at bay (though it's likely already in your favorite wordlist by now), we can reconstruct the crime scene based on the remediation scripts and standard Tomcat architecture.

Normally, a secured tomcat-users.xml should look empty or use a lock-out mechanism. Here is a reconstruction of the vulnerable configuration structure found in /home/kos/tomcat9/tomcat-users.xml:

<!-- VULNERABLE CONFIGURATION (RECONSTRUCTED) -->
<tomcat-users>
  <!-- The 'admin' role allows access to the Manager App -->
  <role rolename="manager-gui"/>
  <role rolename="manager-script"/>
  
  <!-- The fatal flaw: Hardcoded credentials -->
  <user username="admin" 
        password="[STATIC_HARDCODED_STRING]" 
        roles="manager-gui,manager-script"/>
</tomcat-users>

The fix provided in Dell's remediation script (ID: 000426742) is brutal but effective. It parses this XML and nukes the offending lines, or rotates the password to a randomized value generated at install time. It effectively moves the authentication mechanism from 'Hardcoded' to 'Unique per Install'.

It is worth noting that this file is often world-readable depending on the umask settings during installation, meaning a local attacker (LPE) could also easily grab these credentials if they had shell access. But in this case, the remote attack vector via port 8082 or 443 was the main event.

Exploiting this is trivially easy. It requires zero memory corruption, no ROP chains, and no heap feng shui. It is strictly a logic and configuration abuse. Here is the kill chain used by UNC6201:

1. Reconnaissance: The attacker scans for RP4VMs exposing ports 8082 or 443. The banner often screams 'Apache Tomcat'.
2. Access: The attacker navigates to /manager/html. The browser prompts for Basic Authentication. The attacker enters the hardcoded credentials found in the CVE details.
3. Deployment (The 'Malware' Phase): Once logged in, the Tomcat Manager provides a 'WAR file to deploy' section. A WAR (Web Application Archive) is just a ZIP file containing Java classes and JSP pages.
4. Execution: The attacker uploads a malicious WAR file. UNC6201 used a specific webshell known as SLAYSTYLE (or BEEFLUSH). This is a JSP file that takes command input via HTTP parameters and executes them on the host OS.

Because the Tomcat service on these appliances typically runs with high privileges (often root or a user with unrestricted sudo access to manage system recovery), the web shell inherits these permissions.

Once they had this shell, UNC6201 didn't stop there. They deployed BRICKSTORM, a Go-based backdoor, and later GRIMBOLT (C#), utilizing 'Ghost NICs' to hide their C2 traffic from the appliance's standard network monitoring. That is high-tier tradecraft on top of a low-tier vulnerability.

This is a CVSS 10.0 for a reason. It checks every box for 'Worst Case Scenario'.

Confidentiality: The attacker can access all data stored on the appliance. More importantly, they can harvest credentials for the vCenter server that RP4VMs is paired with. This allows lateral movement into the hypervisor layer.

Integrity: The attacker can manipulate backup data. Imagine a ransomware scenario where your live data is encrypted, you go to restore from RP4VMs, and find that your recovery points are also corrupted or deleted. Game over.

Availability: The attacker can wipe the appliance, halt replication, or use the appliance as a botnet node for DDoS attacks (though UNC6201 was more interested in espionage).

The persistence mechanisms used by the threat actors (modifying iptables to hide traffic, clearing Tomcat logs) suggest they intended to stay for a long time. Mandiant reports they were active for nearly two years before detection. That is a massive dwell time.

If you are running Dell RP4VMs, assume you are compromised until proven otherwise. Check your Tomcat logs (if they haven't been wiped) for uploads of unknown WAR files or access to /manager/html from unknown IPs.

Immediate Remediation:

1. Upgrade: Update to version 6.0.3.1 HF1 immediately. This version removes the hardcoded account.
2. Script: If you cannot upgrade, apply the Dell remediation script. This script modifies the XML configuration to remove the vulnerability.
3. Network Segmentation: Why is your backup management interface exposed to the internet? Put this thing behind a VPN and restrict access to the management ports (8082, 443) to trusted admin subnets only.

Forensics: Look for files named slaystyle.jsp, brickstorm, or suspicious Go binaries in /tmp or the Tomcat webapps directory. Check for rogue virtual network interfaces (Ghost NICs) that shouldn't be there.