BRICKSTORM Malware: Hardening vSphere & VCSA Against Advanced Threats

Overview: BRICKSTORM Malware Targets vSphere Environments

Advanced threat actors, as detailed by Google Threat Intelligence Group (GTIG), are actively targeting VMware vSphere ecosystems, specifically the vCenter Server Appliance (VCSA) and ESXi hypervisors, using malware like BRICKSTORM. These sophisticated operations aim to establish persistence beneath the guest operating system, exploiting a critical visibility gap where traditional EDR agents are ineffective. The threat does not stem from a specific vulnerability in VMware products but rather from weaknesses in security architecture, identity design, and insufficient host-based configuration enforcement.

A compromise of the vCenter control plane grants attackers full administrative authority over all managed ESXi hosts and virtual machines. This effectively bypasses traditional organizational tiering, allowing access to Tier-0 workloads, such as domain controllers and privileged access management (PAM) solutions. Such a compromise provides threat actors with centralized command, total data access (including underlying storage like VMDKs for exfiltration), and command-line logging gaps within the Photon OS shell.

Organizations still relying on vSphere 7, which reached End of Life in October 2025, face an elevated risk due to the absence of critical security patches. Proactive measures are essential to secure these environments, focusing on technical hardening and high-fidelity signal analysis rather than static IoC blocklists.

BRICKSTORM Malware Mitigation for vSphere Environments

Defending against threats like BRICKSTORM requires a robust infrastructure-centric defense strategy. Mandiant offers a vCenter Hardening Script to automate many of these recommendations directly at the Photon Linux layer.

Phase 1: Benchmarking and Base Controls

Establishing a strong security posture begins with adhering to Security Technical Implementation Guides (STIGs) and maintaining a strict patching and upgrade strategy. This includes applying an enhanced security baseline focused on the Photon Linux DISA STIG and VMware security hardening guides. Key STIG controls directly counter common attacker TTPs:

• V-258910 (MFA): Prevents Privilege Escalation from compromised Active Directory credentials.
• V-256337 (Real-time Alert on SSO Account Actions): Detects rapid creation and deletion of local accounts used for backdoor deployment.
• V-258956 (Limit ‘BashShellAdministrators’ membership): Blocks the “VAMI-to-Shell” pivot, preventing access to the Photon OS bash shell even with compromised vSphere Admin accounts.
• V-258968 (Disable SSH Enablement): Inhibits initial access by preventing threat actors from enabling SSH via the VAMI (Port 5480).

Beyond these, robust cryptographic enforcement is critical for protecting against vSphere infrastructure-level data exfiltration. This includes mandatory vSphere VM encryption for all critical Tier-0 virtual machines, cryptographic isolation using separate Key Management Server (KMS) clusters, and de-coupling “Clone” and “Export” privileges from standard administrative roles, reassigning them to highly restricted “break-glass” identities.

Phase 2: Identity Management

Hardening administrative access to vSphere infrastructure focuses on dedicated Privileged Access Workstations (PAWs) and PAM solutions. PAM tools can mitigate threats like BRICKSTEAL credential harvesting by mandating credential injection and enforcing automated secret rotation. Accounts in the default vsphere.local Single Sign-On (SSO) domain, especially administrator@vsphere.local, should be treated as emergency credentials due to their lack of modern MFA support.

A critical Lateral Movement vector involves the vpxuser account, a high-privilege system account on each managed host. vSphere 8.0+ introduced a control to disable shell access for vpxuser using esxcli system account set -i vpxuser -s false, effectively severing the vCenter-to-Host attack path. Further ESXi host hardening includes renaming the root account, enforcing 15+ character password policies, and vaulting all local host credentials.

Phase 3: vSphere Network Hardening

Establishing a vSphere Zero Trust network posture is foundational, especially given the lack of native MFA support for local privileged accounts. A strictly segmented architecture with physical network isolation and host-based micro-segmentation can neutralize underlying attack vectors, preventing BRICKSTORM intrusions from compromising the vCenter control plane.

1. Immutable Virtual Local Area Network (VLAN) Segmentation

Enforce strict 802.1Q VLAN IDs to isolate management networks from less secure zones (DMZ, guest VMs). This prevents attackers from pivoting from a low-trust zone to the Management VAMI (Port 5480) or SSH access (Port 22).

2. Routing as a Security Barrier

Transform the Management Network into a secured zone, physically isolating it from corporate subnets and Wi-Fi networks. This involves:

• Virtual Routing and Forwarding (VRF) Segmentation: Isolate infrastructure VLANs into a dedicated VRF instance on the core routing layer, ensuring no route exists from untrusted VRFs to the management VRF.
• PAW Exclusive Access: Deconstruct direct routes from the general corporate LAN to management subnets, requiring all access to originate from designated, hardened PAW IP ranges.

3. Hardened Perimeter Ingress and Egress Filtering

Implement restrictive ingress and egress policies at the hardware firewall or Layer 3 Core gateway for the Management Subnet. Since the VCSA’s native firewall lacks egress policy enforcement, upstream network devices must block unauthorized outbound C2 communications and data exfiltration. The ingress rules should strictly define what sources can access specific management ports (e.g., PAW IPs for 443/902, VCSA IP for ESXi host communication), explicitly denying SSH (22) and VAMI (5480) from any unauthorized source, including guest VMs. For example, the VAMI port (5480) should only be accessible from PAW IPs to prevent unauthorized SSH enablement or log tampering.

Host-Based Firewalls for VCSA and ESXi

Host-based firewalls complement network firewalls by addressing “East-West” traffic within the same VLAN. For VCSA, the Photon OS iptables or nftables should be used to enforce a “Default Deny” policy with explicitly defined authorized IP addresses for each management service. While the VAMI GUI firewall is a basic control, it has limitations, including lack of port-specific granularity (forcing an “all-or-nothing” approach), circular administrative dependency (firewall managed by the application it protects), forensic visibility gaps (no remote logging of denied attempts), and inbound-only policy focus. Overcoming these requires OS-level hardening for granular control, tamper-proof integrity, and robust logging to a SIEM.

For ESXi, restricting individual services to authorized management IPs is crucial. This means deselecting “Allow connections from any IP address” for services like SSH, vSphere Web Client, vCenter Agent (vpxa), vMotion, and Storage, and instead specifying PAW subnets or VCSA IPs. This is vital for neutralizing RCE vectors targeting services like CIM Server, which has been exploited by ESXi-specific ransomware, as seen in VMSA-2021-0002. This vulnerability, tracked as CVE-2021-21972, allowed for local privilege escalation in ESXi, vCenter Server, and Cloud Foundation.

Hardening transforms the infrastructure into a detection enabler. In a “Default Deny” posture, actions like port scans or lateral movement attempts become high-fidelity indicators of compromise, visible through network-level logging, host-based firewall logging (IPtables), and immutable remote logging.

Phase 4: Logging and Forensic Visibility

Comprehensive telemetry across the VCSA’s underlying operating system is vital. The typical visibility gap is caused by the lack of kernel-level audit log forwarding, restricted logging pipelines (rsyslog only), and fragmentation of operational telemetry.

• auditd (Linux Audit Daemon): auditd tracks security-relevant system calls, recording shell commands, file modifications, and privilege escalation. It is essential for detecting “living-off-the-land” (LotL) techniques used by BRICKSTORM, such as binary injections, startup script modifications, and sudo usage for credential harvesting (BRICKSTEAL). Modern VCSAs ship with STIG rules, but remote forwarding is not enabled by default. Activating the auditd bridge to the remote syslog is critical to prevent attackers from wiping local logs (rm -rf /var/log/audit/*). Standard STIG rules map directly to attacker TTPs, such as useradd/userdel for establishing foothold, execpriv for binary execution, perm_mod for weaponization, and privileged for credential theft.

• Advanced Intrusion Detection Environment (AIDE): As a host-based File Integrity Monitoring (FIM) tool, AIDE provides digital validation by creating a cryptographic baseline of critical system files. It detects modifications regardless of how a file was changed or if auditd logs were wiped. This complements auditd by providing state monitoring (AIDE captures the result) alongside auditd’s behavioral monitoring (auditd captures the action). Configuring AIDE involves initializing its database (when the VCSA is clean), appending BRICKSTORM-specific rules (e.g., for /root/.ssh, /lib64, /etc/aide.conf, /etc/audit/, /etc/audisp/), and enabling automated checks with remote logging via logger -t AIDE_TRAP -p local6.crit.

• VCSA Shell History: The /root/.bash_history file is not remotely logged and can be easily wiped (unset HISTFILE, history -c, rm /root/.bash_history). Remote auditd logging bypasses this by intercepting system calls at the kernel level, creating an immutable, real-time audit trail off-appliance.

Centralizing logs to a remote SIEM with TLS encryption (TCP Port 6514) and certificate validation is paramount. Mandiant and CISA reporting highlight the abuse of management interfaces, configuration changes, and VM access. The logging strategy should prioritize management-plane audit trails, service-state changes, identity events, hypervisor telemetry, and centralized forwarding. This unified logging architecture provides a multilayered detection capability, spanning vCenter application events (VmClonedEvent, HostSshEnabledEvent), identity events (PrincipalManagement), auditd kernel logs (execpriv, useradd), AIDE integrity checks (AIDE_TRAP), and IPtables OS firewall (VCSA_FW_DROP). These logs can detect initial access (e.g., requests to /manager/text/deploy for deploying malicious WAR files like SLAYSTYLE, associated with CVE-2026-22769 as described in the source), lateral movement (VmNetworkAdapterAddedEvent, VmReconfiguredEvent for ghost NICs), takeover (VAMI logs, BashShellAdministrators changes), persistence (startup script injections, transient SSO accounts), and data exfiltration (INTERNET_BLOCKED from the VCSA).

Actionable Recommendations

To effectively counter sophisticated threats like BRICKSTORM, organizations must prioritize proactive security measures that transform the vSphere environment into a resilient and self-defending infrastructure. Implement the following critical actions:

• Comprehensive Hardening: Follow VMware and DISA STIG guidelines for both VCSA (Photon OS) and ESXi hosts. This includes disabling unnecessary services (like SSH when not in use), enabling Secure Boot, and strictly limiting shell access for administrative accounts, especially the vpxuser.
• Identity and Access Management: Mandate phishing-resistant MFA for all administrative interfaces. Ensure all vSphere administrative sessions originate from dedicated Privileged Access Workstations (PAWs) integrated with a PAM solution for credential management and rotation. Restrict vsphere.local accounts to emergency-only scenarios.
• Zero Trust Network Segmentation: Implement strict network segmentation at both Layer 2 (VLANs) and Layer 3 (VRFs) to isolate management networks from all other traffic. Enforce hardened ingress and egress firewall rules on physical and host-based firewalls (VCSA iptables / nftables, ESXi host firewall) to block unauthorized access and prevent C2 communication and data exfiltration from compromised appliances.
• Advanced Logging and Monitoring: Establish a comprehensive, unified logging architecture. Activate and remotely forward all auditd kernel logs and AIDE integrity monitoring events (via logger pipes) to a centralized, encrypted SIEM in real time. Configure alert rules for high-fidelity signals such as execpriv (auditd), AIDE_TRAP events, unauthorized firewall drops, and abnormal VmClonedEvent or VmNetworkAdapterAddedEvent occurrences. Implement a minimum log retention of 400 days.

By building a defense-in-depth strategy that leverages these hardening and logging controls, organizations can create the necessary friction to expose threat actors at the earliest stages of an intrusion, ensuring immediate and immutable forensic responses.