# BRICKSTORM Malware: Hardening vSphere & VCSA Against Advanced Threats

> Defend VMware vSphere and VCSA against BRICKSTORM malware. Learn hardening strategies, identity management, Zero Trust networking, and advanced logging to thwart…

- Published: 2026-04-02T16:29:31.000Z
- Severity: high
- Category: Threat Intel
- Tags: BRICKSTORM, vSphere, VCSA, ESXi, VMware, Photon OS, Hardening, Virtualization, TTPs, Ransomware, Espionage, CVE-2021-21972, Mandiant
- Author: Runtime Rebel Intel
- Primary source: https://cloud.google.com/blog/topics/threat-intelligence/vsphere-brickstorm-defender-guide/
- Canonical: https://runtimerebel.com/blog/brickstorm-malware-hardening-vsphere-vcsa-against-advanced-threats

## Key points

- Threat actors establish persistence below the OS, gaining administrative control over vSphere environments, affecting critical Tier-0 workloads.
- VMware vSphere ecosystem, specifically vCenter Server Appliance (VCSA) and ESXi hypervisors, especially vSphere 7 End of Life, are affected.
- Implement comprehensive hardening, identity, network segmentation, and advanced logging for VCSA and ESXi hosts today.

## Overview: BRICKSTORM Malware Targets vSphere Environments

Advanced threat actors, as detailed by [Google Threat Intelligence Group (GTIG)](https://cloud.google.com/blog/topics/threat-intelligence/vsphere-brickstorm-defender-guide/), 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](/glossary#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](/glossary#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](https://github.com/mandiant/vcsa-hardening-tool) 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](/glossary#ttp):

*   **V-258910 (MFA)**: Prevents [Privilege Escalation](/glossary#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](https://en.wikipedia.org/wiki/Privileged_access_management) 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](https://en.wikipedia.org/wiki/Multi-factor_authentication) support.

A critical [Lateral Movement](/glossary#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](/glossary#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](/glossary#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](/glossary#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](/glossary#rce) vectors targeting services like CIM Server, which has been exploited by ESXi-specific [ransomware](/glossary#ransomware), as seen in VMSA-2021-0002. This vulnerability, tracked as [CVE-2021-21972](/cve/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](/glossary#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](/glossary#ttp), 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](/glossary#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](/glossary#phishing)-resistant [MFA](https://en.wikipedia.org/wiki/Multi-factor_authentication) 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](/glossary#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](/glossary#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.

**Related:** [M-Trends 2026: Evolving Ransomware, Persistence, and SaaS Attack Vectors](/blog/m-trends-2026-evolving-ransomware-persistence-and-saas-attack-vectors), [Beast Gang OpSec Fail: Ransomware Server Exposes TTPs](/blog/beast-gang-opsec-fail-ransomware-server-exposes-ttps)

---

AI-generated analysis from the primary source above; not human-reviewed before publication — verify anything operational against the original (https://runtimerebel.com/editorial). Quote with attribution and a link to the canonical URL: https://runtimerebel.com/blog/brickstorm-malware-hardening-vsphere-vcsa-against-advanced-threats