SparTech Software CyberPulse – Your quick strike cyber update for December 20, 2025 10:41 AM

BRICKSTORM: Long-Dwell Chinese Backdoor Targeting VMware and Windows in Critical Infrastructure

A newly detailed malware family dubbed BRICKSTORM is being actively deployed by Chinese state-sponsored actors to maintain long-term, covert access in VMware vSphere and Windows environments, especially across public sector, IT services, and critical infrastructure. The campaign focuses on stealing virtual machine snapshots, abusing DNS-over-HTTPS for command-and-control, and building stealthy persistence mechanisms that can survive normal operational cycles, forcing defenders to rethink how they monitor and secure virtualized and hybrid IT/OT estates.

Campaign Overview and Target Profile

The BRICKSTORM activity cluster is characterized by multi-month to multi-year dwell time within target networks, with at least one confirmed case of continuous access from April 2024 through September 2025 before discovery. Primary targets include government agencies, IT service providers, and operators of critical infrastructure where VMware vSphere and Windows-based management domains are widely deployed. The operation fits an espionage and pre-positioning profile rather than smash-and-grab ransomware, enabling both data theft and potential disruptive operations at a later stage.

Initial Access and Lateral Movement

Initial access vectors appear to include exploitation of internet-facing management interfaces, weak or reused credentials on vCenter and Windows administrative accounts, and potential supply-chain or MSP-mediated access paths. Once inside, operators rapidly enumerate domain trusts, vSphere topology, and backup infrastructure to identify high-value systems and data stores. Windows domain controllers, vCenter servers, backup management servers, and bastion hosts are prioritized for lateral movement and persistence.

Lateral movement leverages a blend of legitimate administrative tools and custom malware tooling. Use of standard management protocols such as Remote Desktop Protocol, Windows Management Instrumentation, and PowerShell Remoting allows operators to blend in with normal administrative activity. Within virtualized environments, the actors pivot to ESXi hosts and vCenter APIs for control over guest VMs, storage, and snapshots, significantly amplifying their access and impact radius.

Backdoor Architecture and Capabilities

BRICKSTORM functions as a modular backdoor with distinct components for command-and-control, credential access, lateral movement, and data exfiltration. The core implant supports execution of arbitrary commands, file transfer operations, process and service manipulation, and the deployment or removal of additional payloads. Configuration data is strongly encrypted and designed to resist static analysis, with multiple fallback communication options to ensure resilience if a primary channel is disrupted.

The operators consistently tune the malware to the topology of each victim network. This includes custom hardcoded internal addresses, victim-specific domain names, and tailored process names that mimic local tooling. The goal is to make the implant appear as a normal part of the operational stack, especially on virtualization management servers and jump hosts frequently used by administrators.

Abuse of VMware vSphere and Rogue Virtual Machines

A distinguishing feature of BRICKSTORM is its deep integration with VMware vSphere infrastructure. The malware can access vCenter APIs to enumerate virtual machines, snapshots, virtual switches, and datastores, giving the operators a comprehensive view of the virtualized environment. With this access, attackers can create, modify, or delete virtual machines, as well as interfere with virtual networking.

One advanced technique involves the creation of hidden or rogue virtual machines on existing ESXi hosts. These rogue VMs can run additional tooling, act as internal command-and-control relays, or serve as covert data staging points prior to exfiltration. Because such VMs may not be referenced in normal change management records and can be given innocuous names, they are difficult for defenders to spot without direct comparison to baseline inventories and configuration histories.

The ability to clone or snapshot critical VMs also gives BRICKSTORM operators a powerful means to both exfiltrate data and prepare for destructive actions. Compromised snapshots can be used to harvest credentials, reconstruct database contents offline, or roll systems back to attacker-controlled states during a later phase of operations.

Snapshot Theft and Credential Extraction

BRICKSTORM is optimized to steal virtual machine snapshots containing complete images of critical systems and application servers. These snapshot files include operating system volumes, application binaries, and in-memory sensitive material that can be reconstructed offline. Once exfiltrated, attackers can mount the snapshots in isolated environments to extract credentials, cryptographic keys, configuration files, and proprietary data without the time pressure and visibility risks of operating directly within the victim network.

Credential extraction from these snapshots targets domain controller databases, password vaults, service accounts, and database connection strings embedded in application configuration files. By operating on snapshots instead of live systems, the actors avoid many endpoint detection and response hooks and log-based detections that depend on runtime behavior. The resulting credential corpus then feeds follow-on lateral movement both within the initially compromised organization and across any connected or managed environments.

DNS-over-HTTPS Command-and-Control Evasion

BRICKSTORM’s command-and-control architecture makes heavy use of DNS-over-HTTPS to conceal traffic within seemingly legitimate, encrypted web requests to popular resolvers or fronted domains. Instead of traditional DNS queries, the implant issues HTTPS requests that embed encoded command and status data within query parameters or request bodies, with responses similarly encoded as DNS answers or custom data blocks.

This approach leverages the fact that many organizations allow outbound HTTPS traffic broadly, including to public DNS resolvers and major content delivery networks, and do not inspect encrypted DNS traffic deeply. Because the communication pattern closely resembles benign DNS-over-HTTPS behavior, it is difficult to distinguish without careful traffic baselining and inspection of request characteristics such as endpoint domains, query frequency, and payload entropy.

Multiple encryption layers within the payload add another cloak of obfuscation. Even if defenders decrypt the HTTPS layer via TLS inspection, they still face an additional layer of custom encryption protecting the commands and responses, complicating both detection and forensic reconstruction.

Persistence, Stealth, and Long-Term Access

Persistence for BRICKSTORM is implemented at several layers to survive routine maintenance and partial remediation. On Windows systems, the malware uses scheduled tasks, service installations, and registry-based autostart entries. It may also hijack existing services or scheduled jobs to minimize the appearance of new artifacts. On vSphere management servers, persistence can be tied into legitimate management agents or monitoring services to blend into expected process lists.

The actors emphasize log minimization and anti-forensic measures, including selective log deletion or tampering, use of in-memory or fileless components, and preference for living-off-the-land commands. They avoid noisy automated scanning when possible, opting instead for manually guided reconnaissance tuned to the victim environment, which further reduces detection opportunities.

The demonstrated ability to remain undetected for over a year in some environments illustrates that BRICKSTORM is engineered more like a long-term access platform than a disposable backdoor. It is designed to survive password rotations, infrastructure updates, and even partial incident response efforts unless defenders specifically target the virtual infrastructure and DNS-over-HTTPS channels it relies upon.

Operational Technology and Critical Infrastructure Risk

For critical infrastructure operators, BRICKSTORM poses unique risks because many modern operational technology environments are increasingly virtualized and integrated with IT networks via VMware and similar platforms. By gaining control over vSphere, attackers indirectly gain flexible access to supervisory control and data acquisition servers, engineering workstations, and historian systems that may be running as virtual machines.

Even when direct control over field devices is not immediately possible, persistent access to these OT-adjacent virtual machines enables detailed mapping of industrial processes, collection of sensitive configurations, and preparation for coordinated disruption. The same snapshot theft technique used for credential harvesting could be applied to capture and analyze control system configurations and custom industrial software.

Detection Strategies and Defensive Priorities

Detecting BRICKSTORM requires defense teams to move beyond endpoint-only monitoring and incorporate deep visibility into virtualization platforms and DNS-over-HTTPS usage. Key areas include continuous inventory and integrity monitoring of all virtual machines, snapshots, and vSphere configuration objects, with alerting on unapproved VMs, unexpected snapshot activity, and anomalous changes to virtual networking. Regular reconciliation of vSphere inventories with change management records and infrastructure-as-code definitions helps highlight rogue or manipulated assets.

Network-level defenses should profile normal DNS-over-HTTPS behavior and flag deviations, such as rare external resolvers, unusual volumes of queries, or atypical request patterns from management servers. Where possible, organizations can restrict DNS-over-HTTPS to sanctioned resolvers, log all such traffic, and apply TLS interception at secure egress points to inspect request payloads for signs of covert channels, subject to privacy and regulatory constraints.

On endpoints and management servers, behavior-based detection focusing on abuse of vSphere APIs, unusual snapshot operations, and suspicious process chains involving administrative tools can surface BRICKSTORM activity. Incident response procedures should explicitly include investigation of virtual infrastructure, not just traditional servers and workstations, and ensure that remediation plans cover rogue virtual machines and malicious configuration artifacts that may not appear in standard endpoint views.

Hardening VMware and Hybrid IT/OT Environments

To reduce exposure, organizations should enforce strong authentication and least-privilege access to vCenter and Windows domain administration, including multifactor authentication, hardware-backed credentials where possible, and rigorous role-based access controls. Segmentation between management networks, production workloads, and internet-facing systems is essential to prevent a single foothold from scaling into full control of virtual and physical infrastructure.

Applying security baselines to vSphere environments, including disabling unnecessary services, restricting direct access to ESXi hosts, and enforcing secure logging and audit configurations, helps shrink BRICKSTORM’s maneuvering space. Regular review of snapshot policies, retention schedules, and backup workflows can reduce the volume of sensitive snapshot data available for theft and make anomalous snapshot creation more conspicuous.

For critical infrastructure, integrating operational technology security frameworks with virtualization security practices is increasingly important. This includes aligning with updated guidance from national cybersecurity agencies and industry standards bodies that emphasize governance, continuous risk management, and executive accountability for both IT and OT cyber resilience. As advanced state-backed campaigns like BRICKSTORM blur the boundary between corporate IT, cloud, and industrial control environments, treating virtualization platforms as critical infrastructure in their own right becomes a fundamental security requirement.

Comments

No comments yet. Why don’t you start the discussion?

Leave a Reply