Critical exposure
RecoverPoint appliance risk
The source pack centers on CVE-2026-22769 in Dell RecoverPoint for Virtual Machines. The practical model is recovery-plane compromise, not a generic web-app story.
The source pack centers on CVE-2026-22769 in Dell RecoverPoint for Virtual Machines. The practical model is recovery-plane compromise, not a generic web-app story.
The RecoverPoint exploitation is strongly supported, but the initial access vector into victim environments was not confirmed.
This model keeps tooling evidence separate from modeled movement. Tool deployment is evidence; path order is defensive reasoning.
The model uses the UNC6201 article, the BRICKSTORM campaign article, the GTIG AI Threat Tracker, and Dell advisory context as separate source layers.
UNC6201 activity has reportedly been present since at least mid-2024, so remediation should include retrospective hunting, not just patch deployment. The most distinctive operational risk is the recovery-plane pivot: RecoverPoint compromise can become a path toward VMware/vCenter control, including Ghost NIC-style virtual networking changes and iptables-based Single Packet Authorization.
Green means quote-backed or directly extracted. Amber means modeled or caveated. Red means a useful validation gap. Treat the page as a defensive model, not a confirmed incident timeline.
Source evidence anchors: Main UNC6201 article | BRICKSTORM espionage campaign | GTIG AI Threat Tracker
UNC6201 is treated as a suspected PRC-nexus threat cluster. Overlap with UNC5221 / Silk Typhoon remains a caveat, not identity equivalence.
RecoverPoint for Virtual Machines is modeled as a high-trust recovery and replication control surface adjacent to VMware, ESXi, vCenter, and restore workflows.
Appliance management access can cross into command execution, persistence, recovery-plane operations, and modeled internal pivot paths if segmentation and logging are weak.
This is the working threat model for UNC6201 against RecoverPoint-backed VMware recovery environments. It separates confirmed source evidence from modeled internal-access risk and from environment-specific validation work.
| Stage | Asset / surface | Entry point | Preconditions | Trust boundary crossed | Abuse case | Telemetry and controls |
|---|---|---|---|---|---|---|
| Caveated initial access | Edge or internal route to RecoverPoint management | Unknown for the observed incidents; RecoverPoint exploitation is supported, first entry is not confirmed. | Actor can reach appliance management or already has internal access. | External or untrusted network into management plane. | Turn reachable appliance management into a path toward recovery infrastructure. | Restrict management access, review VPN and edge appliance auth, correlate first-seen RecoverPoint activity with perimeter logs. |
| Identity control | Apache Tomcat Manager on RecoverPoint | Hard-coded/default administrative credentials. | Management interface reachable; credentials are not rotated or mitigated. | Unauthenticated network actor into appliance administration. | Use legitimate manager access to blend with administrative deployment behavior. | Review Tomcat auth logs, rotate/remediate credentials, block manager access outside jump hosts. |
| Execution | RecoverPoint appliance operating system | WAR deployment and command execution through Tomcat Manager. | Manager credentials work; Tomcat can deploy applications with appliance privileges. | Application administration into root-level appliance execution. | Execute commands on a recovery-plane appliance that may have limited endpoint visibility. | Hunt for /manager/text/deploy, unexpected WAR/JSP files, process execution from Tomcat paths. |
| Persistence | Tomcat webapps, startup scripts, appliance filesystem | SLAYSTYLE web shell and modified legitimate scripts such as convert_hosts.sh. | Write access to Tomcat and boot-time script paths. | Runtime compromise into durable appliance foothold. | Survive reboots and maintain access while appearing close to normal appliance behavior. | File integrity monitoring, clean-baseline comparison, startup script review, Tomcat directory inventory. |
| Recovery-plane pivot | vCenter, ESXi, virtual networking, restore workflows | Modeled from RecoverPoint adjacency plus VMware/vCenter campaign context. | Appliance has network paths or credentials that touch VMware management functions. | Recovery appliance into virtualization control plane. | Reach high-value systems, inspect protected workloads, or support later credential and data access. The primary VMware concern is Ghost NIC-style activity: temporary network ports on existing ESXi VMs used to bridge toward internal or SaaS infrastructure and then disappear from normal inventory. | Monitor appliance-to-vCenter traffic, vNIC changes, VM clone/delete events, recovery-job audit trails, and short-lived virtual network adapter or port group changes. |
| Validation gaps | Identity stores, SaaS repositories, sensitive VMs, backup sets | Not directly proven for the RecoverPoint incident path in this page. | Requires victim-specific logs, EDR, identity telemetry, and VMware task history. | Management plane into enterprise identity and data planes. | Credential theft, account manipulation, internal discovery, and data access are plausible outcomes to test. | Use tabletop questions, retrospective hunts, privileged-account review, and restore-plane access audits. |
Review manager authentication, /manager/text/deploy, WAR/JSP deployment, Tomcat webapps/cache changes, and RecoverPoint audit logs.
Watch convert_hosts.sh, rc.local, Tomcat deployment paths, iptables state, and boot-time restoration behavior.
SLAYSTYLE is the web shell anchor. BRICKSTORM and GRIMBOLT are tooling and persistence context. Keep those separate from lateral-movement claims.
| Family | Role in this model | Behavioral notes | Evidence boundary |
|---|---|---|---|
| SLAYSTYLE | Observed web-shell / backdoor context. | In the RecoverPoint case, SLAYSTYLE is tied to malicious WAR deployment through Tomcat Manager. In the BRICKSTORM campaign article, SLAYSTYLE is described as a JSP web shell that receives operating-system commands through HTTP requests and returns command output in the HTTP response. | Use as web-shell persistence and command-execution evidence; do not treat every vCenter SLAYSTYLE behavior as confirmed for UNC6201 unless incident logs support it. |
| BRICKSTORM | Observed tooling for UNC6201 and broader campaign context. | The campaign article frames BRICKSTORM as backdoor malware used to maintain persistent access. The UNC6201 article ties BRICKSTORM to RecoverPoint activity and later GRIMBOLT replacement context. | Supports persistence/tooling and campaign memory; not a lateral-movement technique by itself. |
| GRIMBOLT | Observed UNC6201 backdoor/tooling context. | The UNC6201 article identifies GRIMBOLT as a novel C# foothold backdoor compiled with native ahead-of-time (AOT) compilation and packed with UPX. Those choices improve performance on resource-constrained appliances and complicate static analysis by removing common .NET intermediate-language metadata. GRIMBOLT provides remote shell capability and uses the same command-and-control infrastructure as previously deployed BRICKSTORM payloads. | Use for C2, persistence, file-hash hunting, and static-analysis expectations. AOT/UPX means defenders should not rely only on conventional .NET metadata or unpacked binary patterns. |
| Timeframe | What it means for defenders | Evidence status |
|---|---|---|
| Mid-2024 | Earliest identified exploitation activity for CVE-2026-22769. Hunt windows should reach back to this period where logs and backups allow. | Primary incident evidence. |
| September 2025 | Mandiant observed older BRICKSTORM binaries replaced with GRIMBOLT. The reason is uncertain: planned tooling lifecycle and reaction to incident response are both possibilities. | Primary incident evidence with stated uncertainty. |
| February 2026 disclosure | Dell remediation, public reporting, and CISA KEV pressure shifted the issue from stealth campaign to urgent remediation item. | Primary incident plus external vendor/government context. |
This graph shows entity-to-entity links from source relationships, plus one modeled trust-boundary pivot. It is meant for analyst reasoning, not a timeline.
Suspected PRC-nexus cluster in the RecoverPoint article.
Explicit source relationships connect UNC6201 to these malware/tooling names.
CVE, hard-coded credentials, WAR deployment, and command execution evidence.
Trust-boundary risk shaped by RecoverPoint adjacency and BRICKSTORM campaign context.
| Relationship | Source layer | Provenance | Confidence | Evidence note |
|---|---|---|---|---|
| UNC5221 uses BRICKSTORM | Campaign context | explicit | 0.9 | Google Threat Intelligence Group (GTIG) is tracking BRICKSTORM malware activity, which is being used to maintain persistent access to victim organizations in the United States.... |
| UNC5221 uses SLAYSTYLE | Campaign context | explicit | 0.9 | The threat actor has also created a web shell tracked by Mandiant as SLAYSTYLE on vCenter servers. SLAYSTYLE, tracked by MITRE as BEEFLUSH , is a JavaServer Pages (JSP) web shel... |
| UNC6201 uses SLAYSTYLE | Primary incident evidence | explicit | 0.9 | Mandiant and Google Threat Intelligence Group (GTIG) have identified the zero-day exploitation of a high-risk vulnerability in Dell RecoverPoint for Virtual Machines , tracked a... |
| UNC6201 uses BRICKSTORM | Primary incident evidence | explicit | 0.9 | Mandiant and Google Threat Intelligence Group (GTIG) have identified the zero-day exploitation of a high-risk vulnerability in Dell RecoverPoint for Virtual Machines , tracked a... |
| UNC6201 uses GRIMBOLT | Primary incident evidence | explicit | 0.9 | Mandiant and Google Threat Intelligence Group (GTIG) have identified the zero-day exploitation of a high-risk vulnerability in Dell RecoverPoint for Virtual Machines , tracked a... |
Technique rows are merged by ATT&CK ID. Source layers show whether the support comes from the UNC6201 incident article, broader BRICKSTORM campaign context, or actor-capability context. T1190 stays caveated because the first entry vector was not confirmed.
| ID | Technique | Status | Source layers | Validation note |
|---|---|---|---|---|
| T1190 | Exploit Public-Facing Application | caveated | Primary incident evidence | RecoverPoint exploitation is strongly supported, but the initial access vector into victim environments was not confirmed. |
| T1059.004 | Unix Shell | modeled from evidence | Primary incident evidence, campaign context | Supported by shell command execution evidence around Tomcat/web-shell activity; exact use depends on the source layer. |
| T1090 | Proxy | modeled from evidence | Primary incident evidence, campaign context | Represents proxy, tunneling, or pivot behavior in the source material; validate with network and appliance logs before treating it as observed locally. |
| T1497.001 | System Checks | modeled from evidence | Primary incident evidence, campaign context | Mapped from virtualization and VM environment checks; useful for hunting but not a standalone incident sequence. |
| T1505.003 | Web Shell | modeled / quote-supported | Primary incident evidence, campaign context | SLAYSTYLE web-shell evidence supports this mapping; the RecoverPoint and vCenter contexts should remain separated. |
| T1071.001 | Application Layer Protocol: Web Protocols | observed in campaign context | Campaign context | Explicit ATT&CK identifier appears in BRICKSTORM detection content. Use as campaign tradecraft context, not automatic UNC6201 incident proof. |
| T1587 | Develop Capabilities | actor capability context | GTIG AI Threat Tracker | Threat-tracker context only: capability development is not promoted into the RecoverPoint attack path. |
/manager and /manager/text/deploy.| Scenario | Logs needed | Analytic idea | Expected signal | False positives | Control that breaks it |
|---|---|---|---|---|---|
| Tomcat Manager WAR deployment on a RecoverPoint appliance. | RecoverPoint audit log, Tomcat access logs, filesystem change data for webapps/cache paths, process execution if available. | Alert when /manager/text/deploy or manager authentication appears on RecoverPoint, especially with new WAR/JSP files or Tomcat-spawned shell execution. | Manager request followed by deployment artifact and command execution from Tomcat context. | Rare vendor maintenance or controlled recovery operation; validate change ticket and administrator source. | Network restrict Tomcat Manager, rotate/remediate hard-coded credentials, enforce jump-host-only appliance administration. |
| Question | Evidence that would confirm | Evidence that would weaken |
|---|---|---|
| Did RecoverPoint reach vCenter or ESXi in an unusual way? | Firewall, proxy, NetFlow, or appliance logs showing unexpected RecoverPoint-to-vCenter/ESXi connections near the compromise window. | Only expected recovery-operation traffic from approved service accounts and scheduled jobs. |
| Were Ghost NICs used? | vSphere events showing short-lived virtual NIC or network-port creation on existing ESXi VMs, especially where the adapter is quickly removed after access to internal or SaaS infrastructure. | No unexplained network adapter additions, no temporary port group membership changes, and no related internal/SaaS access from the VM timeline. |
| Was virtual networking manipulated? | vSphere events showing short-lived vNIC additions, port group changes, or VM reconfiguration not tied to an approved change. | No unexplained VmReconfiguredEvent activity and no anomalous virtual switch membership changes. |
| Was VM cloning used for credential or data access? | vCenter task history showing clone, snapshot, export, or delete sequences involving sensitive VMs and high-privilege accounts. | Clone/delete activity aligns with documented backup, DR test, or administrative workflows. |
| Did credentials move from recovery plane to identity or SaaS access? | Privileged logons from appliance-adjacent hosts, unusual SSO activity, new OAuth/SaaS access, or access to document repositories after appliance compromise. | No identity events, SaaS audit entries, or privileged sessions connected to the appliance timeline. |
Repeated claims are grouped here so the same source quote is not shown over and over for every stage label or malware name.
| Claim group | Source layer | Confidence | Quote anchor | How to use it |
|---|---|---|---|---|
| RecoverPoint CVE and caveat | Primary incident evidence | high | Mandiant and Google Threat Intelligence Group (GTIG) have identified the zero-day exploitation of a high-risk vulnerability in Dell RecoverPoint for Virtual Machines , tracked as CVE-2026-22769 , with a CVSSv3.1 score of 10.0 . Analysis of incident response... | Use as the incident anchor; keep initial access caveated. |
| Tomcat Manager access path | Primary incident evidence | high | Mandiant discovered CVE-2026-22769 while investigating multiple Dell RecoverPoint for Virtual Machines within a victim’s environment that had active C2 associated with BRICKSTORM and GRIMBOLT backdoors. During analysis of the appliances, analysts identified... | Supports appliance-management access and WAR deployment review. |
| BRICKSTORM campaign memory | Campaign context | high | Google Threat Intelligence Group (GTIG) is tracking BRICKSTORM malware activity, which is being used to maintain persistent access to victim organizations in the United States. Since March 2025, Mandiant Consulting has responded to intrusions across a range... | Use as campaign/tradecraft context, not proof of every UNC6201 step. |
| AI capability context | Actor capability context | context_only | This marks a new operational phase of AI abuse, involving tools that dynamically alter behavior mid-execution. | Use as actor-capability context only, outside the RecoverPoint attack path. |
The GTIG AI Threat Tracker is included only because it was part of the three-article Google source set used to enrich actor-capability context. It does not prove AI use in the RecoverPoint intrusion path. Treat it as background on adversary capability development unless a future incident source directly connects those behaviors to UNC6201 activity in this campaign.
Dell guidance is operationally important for remediation and scoping. It is labeled as external vendor context so readers do not confuse vendor remediation facts with the Google incident and campaign evidence.
Dell rates the RecoverPoint for Virtual Machines issue as critical. The advisory describes CVE-2026-22769 as a hard-coded credential vulnerability that can allow unauthenticated access to the underlying operating system and root-level persistence.
Dell lists RecoverPoint for Virtual Machines 6.0 through 6.0 SP3 P1 as affected prior to 6.0.3.1 HF1. Dell also notes 5.3 SP4 P1 and earlier 5.3 releases require upgrade/remediation steps.
Dell recommends deploying RecoverPoint for Virtual Machines only within trusted, access-controlled internal networks protected by firewalls and segmentation. This reinforces the page's recovery-plane threat model.
CISA lists CVE-2026-22769 in the Known Exploited Vulnerabilities catalog. Treat that as a remediation urgency signal and a reason to hunt retrospectively, not just apply the vendor fix.
The Hacker News reported that Google said the activity targeted organizations across North America. This is external reporting context, not a replacement for internal exposure scoping.
| Vendor item | Dell context | How this changes the model |
|---|---|---|
| Primary fix path | Upgrade RecoverPoint for Virtual Machines to 6.0.3.1 HF1, or apply Dell's remediation script where upgrade is not immediately possible. | Adds an operational response layer without changing the evidence status of the attack path. |
| Legacy 5.3 path | Dell states 5.3 SP4 P1 should migrate to 6.0 SP3 and then upgrade to 6.0.3.1 HF1, or follow the remediation script path. | Useful for environment scoping and exposure review. |
| Product boundary | Dell says RecoverPoint Classic physical and virtual appliances are not affected by this CVE. | Prevents over-scoping the model to unrelated RecoverPoint product lines. |
| Exposure guidance | RecoverPoint for Virtual Machines is not intended for untrusted or public networks. | Supports the control recommendation to segment appliance management and recovery-plane traffic. |
| CISA KEV status | CVE-2026-22769 is listed in the CISA Known Exploited Vulnerabilities catalog. | Prioritize patching, compensating controls, and retrospective hunting. |
| External targeting note | The Hacker News reported that Google said the activity targeted organizations across North America. | Useful for regional awareness; still validate local exposure and telemetry. |
External sources: Dell DSA-2026-079 | NVD/CISA KEV reference for CVE-2026-22769 | The Hacker News targeting report. Dell, CISA, and media context are not counted in the three Google article totals.
This appendix keeps the heavier UNC6201 material: source roles, selected artifacts, long hashes, and YARA names. It preserves rigor without slowing down the main threat model.
| Google source | Contributes | Use in this model | Confidence effect |
|---|---|---|---|
| Primary incident evidence UNC6201 RecoverPoint article | RecoverPoint exploitation, CVE-2026-22769, Tomcat Manager/WAR deployment, SLAYSTYLE, BRICKSTORM/GRIMBOLT, caveats, IOCs, and YARA names. | Primary source for the UNC6201 RecoverPoint threat model and for the caveat that initial access was not confirmed. | Raises incident confidence with direct evidence, while qualifying initial access and path ordering. |
| Campaign context BRICKSTORM article | BRICKSTORM and SLAYSTYLE campaign context, VMware/vCenter tradecraft, VM cloning, long-dwell persistence, and hunting logic. | Enriches the recovery-plane and VMware pivot model without turning every campaign behavior into a confirmed UNC6201 RecoverPoint step. | Raises tradecraft confidence but remains contextual for this incident path. |
| Actor capability context GTIG AI Threat Tracker | AI/LLM abuse and capability-development context from the broader GTIG tracker. | Explains a possible actor capability layer only; it is not part of the RecoverPoint attack chain in this brief. | Context only; does not raise confidence for RecoverPoint exploitation, VMware pivoting, or data access. |
The UNC6201 source data used here provides one public network IOC, 149.248.11.71, and one C2 endpoint, wss://149.248.11.71/rest/apisession. The BRICKSTORM campaign material also includes local/private examples such as 10.0.0.255 and vCenter access URLs. No additional public C2 domains are shown in this page. Treat the absence of domains as a source limitation, not proof that no other infrastructure existed.
| Type | Value | Source layer |
|---|---|---|
| cve | CVE-2026-22769 | Primary incident evidence |
| file_path | /home/kos/tomcat9/tomcat-users.xml | Primary incident evidence |
| file_path | /manager/text/deploy | Primary incident evidence |
| port | 443 | Primary incident evidence |
| port | 10443 | Primary incident evidence |
| file_path | /home/kos/auditlog/fapi_cl_audit_log.log | Primary incident evidence |
| file_path | /var/lib/tomcat9 | Primary incident evidence |
| file_path | /var/cache/tomcat9/Catalina | Primary incident evidence |
| file_path | /var/log/tomcat9 | Primary incident evidence |
| file_path | /home/kos/kbox/src/installation/distribution/convert_hosts.sh | Primary incident evidence |
| ioc_ip | 149.248.11.71 | Primary incident evidence |
| file_path | /bin/sh | Primary incident evidence |
| Type | SHA256 | Source layer |
|---|---|---|
| ioc_hash_sha256 | 24a11a26a2586f4fba7bfe89df2e21a0809ad85069e442da98c37c4add369a0c | Primary incident evidence |
| ioc_hash_sha256 | dfb37247d12351ef9708cb6631ce2d7017897503657c6b882a711c0da8a9a591 | Primary incident evidence |
| ioc_hash_sha256 | 92fb4ad6dee9362d0596fda7bbcfe1ba353f812ea801d1870e37bfc6376e624a | Primary incident evidence |
| ioc_hash_sha256 | aa688682d44f0c6b0ed7f30b981a609100107f2d414a3a6e5808671b112d1878 | Primary incident evidence |
| ioc_hash_sha256 | 2388ed7aee0b6b392778e8f9e98871c06499f476c9e7eae6ca0916f827fe65df | Primary incident evidence |
| ioc_hash_sha256 | 320a0b5d4900697e125cebb5ff03dee7368f8f087db1c1570b0b62f5a986d759 | Primary incident evidence |
| ioc_hash_sha256 | 90b760ed1d0dcb3ef0f2b6d6195c9d852bcb65eca293578982a8c4b64f51b035 | Primary incident evidence |
| ioc_hash_sha256 | 45313a6745803a7f57ff35f5397fdf117eaec008a76417e6e2ac8a6280f7d830 | Primary incident evidence |
| Rule | Source layer |
|---|---|
| G_APT_BackdoorToehold_GRIMBOLT_1 | Primary incident evidence |
| G_Hunting_BackdoorToehold_GRIMBOLT_1 | Primary incident evidence |
| G_APT_BackdoorWebshell_SLAYSTYLE_4 | Primary incident evidence |
| G_APT_Backdoor_BRICKSTORM_3 | Campaign context |
| G_Backdoor_BRICKSTORM_2 | Campaign context |
| G_APT_Backdoor_BRICKSTORM_1 | Campaign context |
| G_APT_Backdoor_BRICKSTORM_2 | Campaign context |
| G_APT_BackdoorWebshell_SLAYSTYLE_1 | Campaign context |
| G_APT_BackdoorWebshell_SLAYSTYLE_2 | Campaign context |
| G_Backdoor_BRICKSTEAL_1 | Campaign context |
| G_Dropper_BRICKSTEAL_1 | Campaign context |
| G_Dropper_BRICKSTEAL_2 | Campaign context |