BRICKSTORM: CISA and NSA Alert on Evolving Rust Backdoor Targeting vSphere

CISA, the NSA, and the Canadian Centre for Cyber Security updated their Malware Analysis Report on February 11, 2026, regarding BRICKSTORM, an ELF backdoor specifically designed for VMware vSphere environments. The analysis identifies a new variant written in Rust, which offers significantly higher forensic resilience than previous Go-based samples. The report reconstructs a real-world compromise chain that resulted in full vCenter control. For organizations virtualizing critical workloads, the signal is clear: attackers are migrating to high-performance languages to evade analysis and maintain silent persistence.

The Shift to Rust: Why Language Matters

CISA analyzed 12 BRICKSTORM samples derived from real-world incidents, including an agency-led response effort. While the original eight samples were written in Go, two of the three samples added in December 2025 and the latest sample from February 11, 2026, are Rust-based. This transition is strategic: Rust produces compact binaries and safe memory management, creating a footprint that is significantly harder to reverse-engineer than traditional malware models.

"BRICKSTORM is a custom Executable and Linkable Format (ELF) Go-or Rust-based backdoor (eight originally analyzed samples are Go-based, and two of the three new samples in the Dec. 19, 2025, update are Rust-based)." — CISA Malware Analysis Report AR25-338A

While Go provided cross-compilation and standalone binaries, Rust increases resistance to static analysis and presents a steeper learning curve for defenders. CISA has not yet attributed the new variant to a specific group, leaving open the possibility that the language shift reflects either an evolution in TTPs or the emergence of a distinct threat actor. Regardless, the report treats both versions as part of an evolving arsenal updated over time.

Persistence in sysconfig: The Survival Mechanism

BRICKSTORM is built for resilience. The malware modifies the vSphere init file in /etc/sysconfig/ to ensure execution at boot from a hard-coded path within the same directory. If the binary is manually removed, a self-watching function triggers a reinstallation, restoring the malware's presence in the infrastructure. This mechanism ensures that superficial cleanup—such as simply deleting the malicious file—is insufficient to remediate the infection.

Persistence via init files is particularly dangerous on vSphere because it targets the core of the virtualization layer. A backdoor at this level can monitor, redirect, or compromise guest workloads without ever interacting with the guest OS. In the documented case, attackers reached this layer only after stealing Managed Service Provider (MSP) credentials, highlighting how external infrastructure management can expand the attack surface if privileged identities are not strictly segmented.

For security teams, mitigation must go beyond standard antivirus scans; it requires verifying the boot chain, monitoring system file integrity, and correlating anomalous processes with unauthorized modifications in /etc/sysconfig/.

Nested C2: WebSockets, TLS, and DNS-over-HTTPS

To maintain command and control (C2), BRICKSTORM employs a sophisticated layering of protocols. The joint report indicates the malware uses multiple encryption layers—including HTTPS, WebSockets, and nested TLS—to hide traffic to the C2 server. Additionally, it leverages DNS-over-HTTPS and web server emulation to blend into legitimate network traffic. This architecture provides operators with interactive shells, file management capabilities, and SOCKS proxies for further lateral movement.

Traffic camouflaged as web server activity makes it difficult to distinguish malicious sessions from administrative tasks, especially in MSP environments where RDP and HTTPS traffic toward vCenter is common. This creates a risk where the C2 remains active for weeks without generating significant perimeter firewall alerts, allowing for prolonged data collection and lateral expansion.

From Web Server to vCenter: Anatomy of a Breach

The report provides a detailed reconstruction of a specific intrusion discovered in April 2024. On April 12, attackers moved laterally from a web server to an internal domain controller using RDP and a secondary service account's credentials. From there, they exfiltrated the Active Directory database, extracting credentials for an MSP that managed the VMware environment. Using those keys, they accessed the vCenter server and subsequently propagated via SMB to a jump server and ADFS systems.

CISA notes that the investigation into this incident is ongoing. It remains unclear how the service account credentials were initially obtained, and the total impact of the compromise is still being quantified. However, the timeline illustrates how quickly an attacker can move from initial lateral movement to hypervisor control, emphasizing that MSP credentials often serve as an overlooked bridge to the heart of the network.

This rapid escalation confirms a critical security reality: vSphere security is as dependent on privileged credential protection as it is on perimeter defenses. When an MSP manages virtual infrastructure, a compromise of that identity is effectively an open door to the entire enterprise.

Recommended Actions

1. Audit Published IOCs: CISA has released hashes, YARA signatures, and Sigma rules in Malware Analysis Report AR25-338A. Teams should download these indicators and scan for binaries in /etc/sysconfig/ and vSphere boot paths, with specific focus on Rust samples that may bypass legacy signatures.
2. Isolate and Monitor vCenter: The 2024 incident proved that attackers prioritize MSP credentials to reach the hypervisor. Organizations must review RDP and SMB access, segment administrative provider accounts, and enable centralized logging for all vSphere client actions.
3. Validate the Boot Chain: Because of BRICKSTORM's self-watching function, deleting the binary is not enough. Defenders must implement persistent integrity checks on init files, utilize Secure Boot where supported, and perform recurring audits of /etc/sysconfig/ modifications.
4. Monitor DoH and WebSockets: The C2 infrastructure uses DNS-over-HTTPS and WebSockets to hide in plain sight. Organizations should analyze encrypted DNS queries and external WebSocket sessions, correlating anomalous connections with activity on vCenter and domain controllers.

BRICKSTORM is not just an isolated proof of concept; it is the fingerprint of a threat actor that has learned to inhabit critical infrastructure. The migration to Rust, boot-level persistence, and multi-layered C2 define an arsenal built for longevity. Agencies have provided the detection tools; it is now up to security teams to use this report to stress-test their defenses.

Frequently Asked Questions

Does BRICKSTORM only target vSphere?

The report analyzes 12 ELF samples targeting VMware vSphere, but CISA also notes the existence of Windows versions that have not been examined in detail. The virtualized environment remains the primary documented target.

Is deleting the malicious file enough to remove the backdoor?

No. BRICKSTORM features a self-watching function that automatically reinstalls the malware if it is missing. A structured response is required, including boot chain verification, integrity monitoring, and scanning with updated signatures.

Does the switch to Rust indicate a new threat group?

CISA has not confirmed a new attribution. It is unclear if the language change represents a shift in TTPs by the same actor or parallel development by a different entity. The report treats all variants as part of the same evolving toolkit.

Information verified against cited sources and current as of the date of publication.

Sources

• https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• https://www.cisa.gov/news-events/analysis-reports/ar25-338a
• https://thehackernews.com/