Threat Intelligence vSphere and BRICKSTORM Malware: A Defender's Guide April 2, 2026 Mandiant Mandiant Services Stop attacks, reduce risk, and advance your security. Contact Mandiant Written by: Stuart Carrera Introduction Building on recent BRICKSTORM research from Google Threat Intelligence Group (GTIG), this post explores the evolving threats facing virtualized environments. These operations directly target the VMware vSphere ecosystem, specifically the vCenter Server Appliance (VCSA) and ESXi hypervisors. To help organizations stay ahead of these risks, we will focus on the essential hardening strategies and mitigating controls necessary to secure these critical assets. By establishing persistence at the virtualization layer, threat actors operate beneath the guest operating system where traditional security protections are ineffective. This strategy takes advantage of a significant visibility gap, as these control planes do not support standard endpoint detection and response (EDR) agents and have historically received less security focus than traditional endpoints. This activity is not the result of a security vulnerability in vendors' products or infrastructure. Instead, these intrusions rely on the effectiveness of exploiting weak security architecture and identity design, a lack of host-based configuration enforcement, and limited visibility within the virtualization layer. By operating within these unmonitored areas, attackers can establish long-term persistence and gain administrative control over the entire vSphere environment. Figure 1: BRICKSTORM vSphere attack chain This guide provides a framework for an infrastructure-centric defense. To help automate some of this guidance and secure the control plane against threats like BRICKSTORM, Mandiant released a vCenter Hardening Script that enforces these security configurations directly at the Photon Linux layer. By implementing these recommendations, organizations can transform the virtualization layer into a hardened environment capable of detecting and blocking persistent threats. vCenter Server Appliance Risk Analysis The vCenter Server Appliance (VCSA) is the central point of control and trust for the vSphere infrastructure. Running on a specialized Photon Linux operating system, the VCSA typically hosts critical Tier-0 workloads, such as domain controllers and privileged access management (PAM) solutions. This means the underlying virtualization platform inherits the same classification and risk profile as the highly sensitive assets it supports. A compromise of the vCenter control plane grants an attacker administrative control over every managed ESXi host and virtual machine, effectively rendering traditional organizational tiering irrelevant. Because the VCSA is a purpose-built appliance, relying on out-of-the-box defaults is often insufficient; achieving a Tier-0 security standard requires intentional, custom security configurations at both the vSphere and the underlying Photon Linux layers. For a threat actor, the VCSA provides: Centralized Command: This provides the ability to power off, delete, or reconfigure any virtual machine combined with the ability to reset root credentials on any managed ESXi host providing full control of the hypervisor. Total Data Access: Access to the underlying storage (VMDKs) of every application, bypassing operating system permissions and traditional file system security. This provides a direct path for data exfiltration of Tier-0 assets. Command-Line Logging Gaps: If an attacker gains access to the underlying Photon OS shell via Secure Shell (SSH), there is no remote logging of the shell commands. Management Plane Dependencies Many organizations host their Active Directory domain controllers as virtual machines (VMs) within the same vSphere cluster managed by a vCenter that is itself AD-integrated. If an attacker disables the virtual network or encrypts the datastores, vCenter loses its ability to authenticate administrators. In a scenario where the VCSA is encrypted or wiped, the tools required for large-scale recovery are also lost. This forces organizations to rely on manual restores via individual ESXi hosts, extending the recovery timeline exponentially. vSphere 7 End of Life vSphere 7 reached End of Life (EoL) in October 2025. Organizations with this legacy technical debt will have vSphere software entering a window (until upgrade) where they will no longer receive critical security patches. This provides an opportunity for threat actors to exploit known vulnerabilities that will not be fixed. The Strategic Advantage of Proactive Measures To secure the control plane, organizations should adopt a strategy where the infrastructure itself acts as the primary line of defense. A resilient defense relies on two strategies: Technical Hardening: Defense-in-depth should be applied to the hypervisor layer to reduce the attack surface. Threat actors target insecure defaults. Hardening measures, such as enabling Secure Boot, strictly firewalling management interfaces, and disabling shell access, create “friction.” When a threat actor attempts to write a persistence script to /etc/rc.local.d or modify a startup file, a hardened configuration can block the action or force the actor to use methods that generate excessive log telemetry. High-Fidelity Signal Analysis: Threat actors are adept at rotating infrastructure and recompiling tools to change their signatures. Relying on a blocklist of bad IPs or a database of known malware hashes is not an effective strategy as threat actors utilize command-and-control servers and native binaries. Instead, the focus should shift entirely to behavioral patterns. Building on this strategic foundation where the infrastructure itself acts as the primary line of defense, this guide outlines four phases of technical enforcement: Phase 1: Benchmarking and Base Controls – Establishing the foundation with Security Technical Implementation Guides (STIG) and patching. Phase 2: Identity Management – Hardening administrative access to critical infrastructure via PAWs and PAM solutions. Phase 3: vSphere Network Hardening – Eliminating lateral movement with Zero Trust networking. Phase 4: Logging and Forensic Visibility – Transforming the appliance into a proactive security sensor. Phase 1: Benchmarking and Base Controls Organizations should use the hardening measures outlined in the Mandiant vSphere hardening blog post combined with a strict patching and upgrade strategy. This provides a standard foundation to develop a strong security posture. By implementing an enhanced security baseline centered on the Photon Linux DISA STIG and VMware security hardening guides, organizations can harden the OS-level components that actors target. Key Frameworks: VMware vSphere 7.0 VCSA Photon OS STIG VMware vSphere 8.0 VCSA Photon OS STIG VMware vSphere Security Hardening Guides VMware BRICKSTORM Resources and Defense STIG Control Mappings to Attacker TTPs STIG ID Control Title TTP Detail V-258910 Require Multi-factor authentication (MFA) Establish Foothold / Privilege Escalation MFA on vCenter web login prevents compromised Active Directory credentials from granting full access. V-256337 Real-time Alert on SSO Account Actions Persistence / Anti-Forensics Creates local accounts, deploys backdoors, and deletes the accounts within minutes. Real-time alerting on PrincipalManagement events is required to catch this activity. V-258921 Verify User Roles (Least Privilege) Data Exfiltration Identifies and removes excessive permissions from standard user roles that are aggregated into non-admin roles. V-258956 Limit membership to "BashShellAdministrators" Escalate Privileges Even if an attacker compromises a vSphere Admin account, they cannot access the Photon OS bash shell unless that account is in this specific single sign-on (SSO) group. It blocks the "VAMI-to-Shell" pivot used to deploy backdoors. V-258968 Disable SSH Enablement Initial Access Actors often use the VAMI (Port 5480) to enable SSH before deploying the backdoor. This control ensures that SSH is "Disabled." STIG controls mapping vSphere Infrastructure-Level Data Exfiltration Standard vSphere configurations typically mask high-risk permissions such as VM cloning and exporting within generalized administrative roles, allowing these actions to blend into the background noise of routine operations. This architecture provides a threat actor with the means to execute a silent exfiltration of a domain controller or credential repository. Organizations should transition from a model of permissive vSphere access control to a comprehensive cryptographic enforcement policy. Security Control What It Protects Against Implementation Method vSphere VM Encryption Theft of VMDK files from the datastore; offline analysis and snapshot of memory Enable in VM Policies (Requires a KMS) In-Guest Encryption (BitLocker) Mounting the VMDK to another VM; offline file system browsing Enable inside Windows OS (Requires a vTPM) vMotion Encryption Capture of in-memory credentials (krbtgt hashes) during live migration Set vMotion to "Required" in VM Options Virtual TPM (vTPM) & Secure Boot Bootkit persistence and tampering; strengthens in-guest features like Credential Guard Enable in VM Options (Hardware & Boot sections) Lock Boot Order & BIOS Booting from a malicious ISO to reset passwords or bypass security controls Set a VM BIOS password and configure boot options Disable Copy/Paste Silent data exfiltration of credentials or secrets via the VM console Set VM Advanced Settings ( isolation.tools.* = true ) Recommended controls for data exfiltration mitigation Resilience against vSphere data exfiltration requires a shift in how high-value virtual assets are governed: Mandatory Tier-0 Encryption: The enforcement of vSphere-native VM encryption is the primary and most essential control for all critical Tier-0 virtual machines. Organizations should mandate that every domain contro