Detect Dell RecoverPoint for Virtual Machines (RP4VMs) Hard-coded Credentials Exploitation in Google Chronicle
Detects exploitation of CVE-2026-22769, a hard-coded credentials vulnerability in Dell RecoverPoint for Virtual Machines (RP4VMs). Threat actors (including UNC6201) have actively exploited this zero-day to gain unauthorized access to RP4VMs appliances, enabling lateral movement, data exfiltration, and ransomware deployment within virtualized environments. The hard-coded credentials allow unauthenticated remote access to RP4VMs management interfaces.
MITRE ATT&CK
YARA-L Detection Query
rule dell_rp4vms_hardcoded_creds_cve_2026_22769 {
meta:
author = "df00tech Detection Engineering"
description = "Detects CVE-2026-22769 exploitation via hard-coded credentials in Dell RP4VMs"
severity = "CRITICAL"
priority = "HIGH"
reference = "https://www.dell.com/support/kbdoc/en-us/000426773/dsa-2026-079"
yara_version = "YL2.0"
rule_version = "1.0"
events:
$auth.metadata.event_type = "USER_LOGIN"
$auth.security_result.action = "ALLOW"
$auth.target.user.userid in (
"admin", "support", "boxmgmt", "root", "service", "recover"
)
(
$auth.target.hostname = /(?i)(recoverpoint|rp4vm|rpa\d)/
or $auth.target.asset.asset_id = /(?i)(recoverpoint|rp4vm)/
)
$auth.principal.ip = $src_ip
match:
$src_ip over 1h
condition:
#auth > 0
}Chronicle YARA-L rule detecting successful logins to Dell RP4VMs systems using known hard-coded or default usernames. Matches against USER_LOGIN events allowed by security controls where the target hostname or asset ID identifies an RP4VMs appliance.
Data Sources
Required Tables
False Positives & Tuning
- Legitimate RP4VMs administrators who have not renamed default accounts post-deployment
- Automated Dell support tooling using documented default service credentials
- Monitoring probes authenticating with default credentials as part of legacy health-check configurations
- Chronicle log parser misattributing system process events as user login events on RP4VMs hosts
Other platforms for CVE-2026-22769
Testing Methodology
Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1RP4VMs Default Credential SSH Authentication Simulation
Expected signal: SSH authentication event in /var/log/auth.log on the target RP4VMs appliance showing 'Accepted password for admin from <attacker_ip>'. SIEM should receive this via syslog forwarding from the appliance.
- Test 2RP4VMs Post-Exploitation Command Execution via Hard-coded Credentials
Expected signal: SSH session opened for user 'support' followed by process execution events (cat, ps, netstat/ss, find) visible in Auditd or Falco telemetry if deployed on the RP4VMs Linux host.
- Test 3RP4VMs Credential Discovery — Searching for Additional Credentials Post-Compromise
Expected signal: Auditd EXECVE syscall events for grep, cat, and env commands executed under the 'boxmgmt' user context on the RP4VMs host. File access events for /etc directory traversal.
- Test 4RP4VMs Persistence — Unauthorized SSH Key Installation
Expected signal: File write event to ~/.ssh/authorized_keys under the 'admin' user account on the RP4VMs host. Auditd or Falco should capture the open/write syscalls against the authorized_keys file path.
References (4)
- https://www.dell.com/support/kbdoc/en-us/000426773/dsa-2026-079
- https://www.dell.com/support/kbdoc/en-us/000426742/recoverpoint-for-vms-apply-the-remediation-script-for-dsa
- https://cloud.google.com/blog/topics/threat-intelligence/unc6201-exploiting-dell-recoverpoint-zero-day
- https://nvd.nist.gov/vuln/detail/CVE-2026-22769
Response Playbook
Triage
- Identify the source IP(s) of the authentication attempt and determine whether they are internal (trusted admin subnet, jump host) or external/unexpected. Cross-reference against your approved RP4VMs management access list.
- Confirm whether the RP4VMs appliance version is unpatched against CVE-2026-22769 by checking the installed firmware version against Dell DSA-2026-079 remediation guidance. Determine if Dell's remediation script has been applied.
- Enumerate all successful logins using the detected hard-coded username within the past 30 days from the affected appliance's authentication logs. Establish a timeline of attacker dwell time.
- Review RP4VMs management audit logs for configuration changes, replication job modifications, snapshot deletions, or credential changes occurring after the first suspicious authentication event.
- Determine whether the affected RP4VMs appliance has network access to production vCenter, ESXi hosts, or other management infrastructure that could be leveraged for lateral movement.
Containment
- Immediately isolate the affected RP4VMs appliance from management networks by applying firewall rules or VLAN segmentation to block inbound SSH and web management access, except from approved jump hosts, while investigation proceeds.
- Force credential rotation on all RP4VMs appliances in the environment — apply Dell's DSA-2026-079 remediation script which removes or disables hard-coded credentials. Validate script execution success before restoring management network access.
- Revoke any sessions or tokens issued to the hard-coded credential accounts and audit connected systems (vCenter, ESXi, backup targets) for evidence of lateral movement originating from the compromised RP4VMs appliance.
Evidence Collection
- Collect full SSH authentication logs from the RP4VMs appliance (/var/log/auth.log or equivalent), capturing timestamps, source IPs, and session durations for all hard-coded username activity within the investigation window.
- Export RP4VMs audit trail logs from the management UI or CLI, including all replication policy changes, consistency group modifications, snapshot operations, and admin account changes performed after the initial suspicious authentication.
- Capture network flow records (NetFlow/IPFIX) for the RP4VMs management interface showing all inbound connections from external or unexpected sources during the investigation period.
Escalation Criteria
- !Escalate immediately if evidence of lateral movement is found — specifically if the compromised RP4VMs credentials were used to access vCenter, ESXi hosts, or Active Directory from the appliance IP.
- !Escalate to incident response if replication jobs have been tampered with, snapshots deleted, or recovery point objectives modified, as this may indicate ransomware pre-positioning (consistent with UNC6201 TTPs documented in Google Threat Intelligence reporting).
Investigation Guide
Related Techniques
Forensic Artifacts
- >
RP4VMs SSH authentication logs: /var/log/auth.log or /var/log/secure — contains timestamps, source IPs, and username for all authentication events - >
RP4VMs management audit trail accessible via CLI command `rp_system_audit_log` or web UI — records all administrative operations including policy changes and user session activity - >
Bash history for default accounts: ~/.bash_history on the RP4VMs Linux filesystem — may contain attacker commands executed post-authentication - >
RP4VMs cron jobs and startup scripts: /etc/cron.d/, /etc/crontab, /etc/rc.local — check for persistence mechanisms installed by attacker - >
Network connection state: output of `netstat -antup` or `ss -antup` captured at time of incident — reveals active outbound connections potentially indicating C2 channels
Tuning Guidance
Reduce false positives by building a reference list of approved RP4VMs management source IPs (jump hosts, admin workstations) and filtering out events originating exclusively from those sources. Additionally, if your organization has already applied Dell's DSA-2026-079 remediation script and confirmed removal of hard-coded accounts, narrow detection scope to focus on any residual authentication attempts against those usernames (which would now fail) as an indicator of active scanning or exploitation attempts against unpatched sibling appliances. Increase confidence threshold to HIGH once an asset inventory of RP4VMs appliances with patch status is integrated into your CMDB and accessible for query-time lookup.
Hunting Queries
30-day retrospective hunt for successful hard-coded credential logins across all Dell RP4VMs appliances — surfaces dwell time, unique source IP count, and first/last activity per username and host to identify initial access timing and persistence patterns consistent with UNC6201 operations.
CommonSecurityLog
| where TimeGenerated >= ago(30d)
| where DeviceVendor =~ "Dell" or DeviceProduct has_any ("RecoverPoint", "RP4VM")
| where DestinationUserName has_any ("admin", "support", "boxmgmt", "service", "recover")
| summarize
TotalAttempts = count(),
SuccessfulLogins = countif(EventOutcome == "Success"),
UniqueSourceIPs = dcount(SourceIP),
FirstSeen = min(TimeGenerated),
LastSeen = max(TimeGenerated)
by DestinationUserName, DestinationHostName
| where SuccessfulLogins > 0
| order by LastSeen descindex=* sourcetype IN ("dell:recoverpoint", "linux_secure") earliest=-30d
("Accepted password" OR "Accepted publickey" OR "session opened")
("admin" OR "support" OR "boxmgmt" OR "service" OR "recover")
| rex "for user (?P<username>\S+) from (?P<src_ip>[\d\.]+)"
| stats count as total_events, dc(src_ip) as unique_src_ips, earliest(_time) as first_seen, latest(_time) as last_seen by username, host
| where username IN ("admin", "support", "boxmgmt", "service", "recover")
| sort -last_seenPersistence hunting query targeting RP4VMs appliances — looks for cron job creation, SSH authorized_keys modification, and service enablement that may indicate attacker persistence installation following initial hard-coded credential exploitation.
Syslog
| where TimeGenerated >= ago(14d)
| where Computer has_any ("recoverpoint", "rp4vm", "rpa")
| where SyslogMessage has_any ("crontab", "cron", "at ", "systemctl enable", "rc.local", "authorized_keys")
| project TimeGenerated, Computer, HostIP, ProcessName, SyslogMessage
| order by TimeGenerated descindex=* sourcetype="linux_secure" (host="*recoverpoint*" OR host="*rp4vm*") earliest=-14d
("crontab" OR "CRON" OR "authorized_keys" OR "systemctl enable" OR "rc.local")
| table _time, host, user, _raw
| sort -_timeAtomic Red Team Tests
Simulates an attacker attempting SSH authentication against a Dell RP4VMs appliance using known hard-coded default credentials. Tests whether authentication telemetry with default usernames is captured and alerted.
Command
ssh -o StrictHostKeyChecking=no -o ConnectTimeout=5 -l admin <rp4vm_lab_ip> 'id; hostname; uname -a; cat /etc/passwd | head -20' 2>&1 | tee /tmp/rp4vm_auth_test.txtCleanup
rm -f /tmp/rp4vm_auth_test.txt; ssh-keygen -R <rp4vm_lab_ip> 2>/dev/nullExpected Telemetry
SSH authentication event in /var/log/auth.log on the target RP4VMs appliance showing 'Accepted password for admin from <attacker_ip>'. SIEM should receive this via syslog forwarding from the appliance.
Expected Detection
Alert fires on successful authentication using username 'admin' from a non-approved source IP against a host matching the recoverpoint/rp4vm hostname pattern.
Simulates post-exploitation activity after gaining access via hard-coded credentials — executes reconnaissance commands consistent with UNC6201 initial access TTPs.
Command
ssh -o StrictHostKeyChecking=no -l support <rp4vm_lab_ip> 'cat /etc/os-release; ps aux | grep -E "(rpa|rp4vm|java)"; netstat -antup 2>/dev/null || ss -antup; find /etc -name "*.conf" -readable 2>/dev/null | head -10' 2>&1 | tee /tmp/rp4vm_recon.txtCleanup
rm -f /tmp/rp4vm_recon.txtExpected Telemetry
SSH session opened for user 'support' followed by process execution events (cat, ps, netstat/ss, find) visible in Auditd or Falco telemetry if deployed on the RP4VMs Linux host.
Expected Detection
EQL sequence rule fires matching successful authentication by 'support' followed within 5 minutes by shell process execution on the RP4VMs host.
Simulates an attacker searching for additional credentials and configuration data on a compromised RP4VMs appliance, consistent with T1552.001 post-exploitation behavior.
Command
ssh -o StrictHostKeyChecking=no -l boxmgmt <rp4vm_lab_ip> 'grep -r -i "password\|passwd\|secret\|token\|key" /etc/ 2>/dev/null | grep -v Binary | head -30; cat ~/.bash_history 2>/dev/null; env | grep -i -E "(pass|secret|key|token|cred)"' 2>&1 | tee /tmp/rp4vm_cred_hunt.txtCleanup
rm -f /tmp/rp4vm_cred_hunt.txtExpected Telemetry
Auditd EXECVE syscall events for grep, cat, and env commands executed under the 'boxmgmt' user context on the RP4VMs host. File access events for /etc directory traversal.
Expected Detection
Detection fires on 'boxmgmt' username authentication success combined with subsequent file-system enumeration process execution on RP4VMs host.
Simulates an attacker establishing persistence on a compromised RP4VMs appliance by installing an SSH authorized key for the hard-coded default account, enabling future keyless access.
Command
ssh -o StrictHostKeyChecking=no -l admin <rp4vm_lab_ip> 'mkdir -p ~/.ssh; chmod 700 ~/.ssh; echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQC_LABTEST_KEY_DO_NOT_USE attacker@lab" >> ~/.ssh/authorized_keys; chmod 600 ~/.ssh/authorized_keys; cat ~/.ssh/authorized_keys' 2>&1 | tee /tmp/rp4vm_persistence_test.txtCleanup
ssh -o StrictHostKeyChecking=no -l admin <rp4vm_lab_ip> 'grep -v LABTEST_KEY ~/.ssh/authorized_keys > /tmp/ak_clean && mv /tmp/ak_clean ~/.ssh/authorized_keys'; rm -f /tmp/rp4vm_persistence_test.txtExpected Telemetry
File write event to ~/.ssh/authorized_keys under the 'admin' user account on the RP4VMs host. Auditd or Falco should capture the open/write syscalls against the authorized_keys file path.
Expected Detection
Persistence hunting query fires on 'authorized_keys' modification event on RP4VMs host. Triggers analyst review of newly installed SSH keys for unauthorized entries.