Securing VMware vSphere Against BRICKSTORM: A Comprehensive Hardening Guide

Overview

BRICKSTORM, as detailed by Google Threat Intelligence Group (GTIG), is a sophisticated campaign that targets the VMware vSphere ecosystem—specifically the vCenter Server Appliance (VCSA) and ESXi hypervisors. Unlike typical malware exploiting software vulnerabilities, BRICKSTORM leverages weak security architecture, poor identity management, and limited visibility at the virtualization layer. By establishing persistence beneath the guest operating system, attackers bypass traditional endpoint defenses (EDR) and gain administrative control over the entire vSphere environment. This guide provides a step-by-step approach to hardening your vSphere infrastructure against such threats, focusing on the VCSA and underlying Photon Linux OS. It draws on Mandiant’s released vCenter Hardening Script to automate many of these controls. By following these recommendations, you can transform the virtualization layer into a monitored, resilient defense against BRICKSTORM and similar persistent threats.

Skip to Prerequisites

Prerequisites

Before implementing the hardening steps, ensure you have:

• Administrative access to the vCenter Server Appliance (VCSA) and managed ESXi hosts.
• SSH access to the VCSA (Photon Linux) and ESXi hosts (if required for specific commands).
• Familiarity with vSphere Web Client, CLI basics, and the concept of tiered security (especially Tier-0 assets).
• Backup of the VCSA configuration and current state of all virtual machines—hardening changes should be tested in a non-production environment first.
• Download the latest version of Mandiant’s vCenter Hardening Script from the official repository (see Step 6 for details).
• Network segmentation planning: ensure management networks (vCenter, ESXi) are isolated from production traffic.

Step-by-Step Hardening Instructions

1. Assess and Harden Identity and Access Controls

BRICKSTORM often exploits weak identity design. Begin by enforcing strong authentication and least privilege:

1. Integrate with a central identity provider (e.g., Active Directory, LDAP) and require multi-factor authentication (MFA) for all vCenter administrative access. This can be achieved using VMware’s identity federation or third-party solutions.
2. Restrict default roles: remove the "Administrator" role from default accounts (e.g., vpxd) and create custom roles with minimal permissions for each operational need.
3. Audit and rotate credentials: immediately rotate all default passwords (e.g., root on ESXi, vCenter root, appliance_root) and enforce strong password policies (20+ characters, complexity).
4. Enable session timeout: configure the vSphere Web Client and CLI sessions to expire after 15 minutes of inactivity.

2. Secure the Network Layer

Attackers often move laterally from the guest OS to the hypervisor. Isolate management traffic:

1. Create a dedicated management VLAN for vCenter, ESXi management interfaces, and vMotion. Place this VLAN behind firewalls with strict ACLs—only allow trusted admin IPs.
2. Disable unused services on ESXi: SSH, ESXi Shell, NTP, and SNMP should be disabled unless strictly required. If needed, restrict access via firewall rules.
3. Use encrypted protocols: ensure all management communication uses TLS 1.2/1.3 (disable older versions) and enforce certificate validation.

3. Patch and Update Regularly

While BRICKSTORM does not exploit CVEs, staying patched reduces the attack surface. Keep the VCSA and ESXi at the latest supported version. Apply security patches monthly. Use VMware Update Manager or automated scripts to audit patch levels.

4. Enable Logging and Monitoring

Visibility is the key to detecting BRICKSTORM. The virtualization layer lacks native EDR, but you can:

1. Forward VCSA logs (syslog) to a SIEM (e.g., Splunk, Sentinel) using the included rsyslog configuration. Capture logs from /var/log/vmware/ and /var/log/audit/.
2. Enable ESXi host auditing through the vCenter alarm system and forward to syslog. Monitor for unusual events like unauthorized SSH logins, changes to admin accounts, or VM migration attempts outside maintenance windows.
3. Deploy the Mandiant vCenter Hardening Script (see Step 6)—it enables additional auditd rules and reduces noise.

5. Harden the Photon Linux OS (VCSA)

Since the VCSA runs on a custom Photon Linux, apply OS-level hardening beyond vSphere defaults:

1. Configure the host firewall (iptables/nftables) to restrict inbound access to necessary ports only—typically TCP 443 (HTTPS) and 5480 (appliance management) from a whitelist of admin IPs. Disable all other ports.
2. Harden SSH: disable root login, use key-based authentication, set a short idle timeout, and restrict access via AllowUsers.
3. Apply security benchmarks (e.g., CIS for Photon OS) or use the Mandiant script which automates hardening configurations such as removing unnecessary packages, setting file permissions, and enabling SELinux.

6. Deploy Mandiant’s vCenter Hardening Script

This PowerShell-based script automates many of the above controls at the Photon Linux layer. It is designed for VCSA version 7 and 8.

1. Download the script from the official Mandiant GitHub repository: https://github.com/mandiant/vcenter-hardening-script.
2. Review the README for prerequisites: the script requires direct SSH access to the VCSA with root privileges, and a backup of the original configuration files.
3. Execute the script in a test environment first. Use the command: ./vcenter_harden.ps1 -VCSA_IP -SSHCredential (Get-Credential).
4. Customize the JSON configuration file to match your organization’s policies (e.g., allowed admin IPs, log retention).
5. Verify applied changes by reviewing the generated report and checking key settings (firewall rules, auditd status).

7. Test and Validate Hardening

After applying all steps, perform validation:

• Penetration testing of the management interface from an untrusted network (e.g., simulate an attacker with guest OS access).
• Review log sources to ensure logging is flowing to the SIEM without gaps.
• Test failover: verify that HA and DRS continue to work after firewall changes.
• Documentation: record all changes in a change management system.

Common Mistakes

• Relying on default settings: The VCSA out-of-the-box is not secure. Assuming defaults are sufficient is the biggest vulnerability.
• Neglecting the Photon OS layer: Hardening vSphere features alone leaves the underlying Linux OS exposed. Attackers can exploit misconfigured accounts or services.
• Insufficient network segmentation: Placing vCenter management on the same subnet as production VMs allows lateral movement from compromised guests.
• Skipping backup before hardening: Some configurations (e.g., firewalls) can lock out administrators if misconfigured. Always test in a lab first.
• Overlooking credential rotation: BRICKSTORM uses stolen or weak credentials. Regular rotation and MFA are critical.
• Incomplete log monitoring: Sending logs to a SIEM without defined alerting rules leaves threats undetected.

Summary

BRICKSTORM demonstrates that the virtualization layer is a prime target for attackers aiming to bypass traditional security controls. By hardening identity management, network segmentation, OS-level configurations, and deploying automated scripts like Mandiant’s vCenter Hardening Script, organizations can significantly reduce the risk. The key is to treat the VCSA and ESXi as Tier-0 assets requiring dedicated, layered defense. Regular validation and monitoring turn the control plane from a blind spot into a monitored fortress. Implement these steps today to stay ahead of emerging threats.