BRICKSTORM: Go Backdoor Targeting VMware vCenter and Appliances

A coordinated government and industry response has confirmed that a sophisticated Go‑based backdoor called BRICKSTORM has been used in targeted espionage campaigns to establish long-term persistence on appliances and virtualization management systems, with operators exploiting appliance blind spots to steal credentials and cloned virtual machine (VM) snapshots for offline credential extraction and data theft.

Background​

BRICKSTORM first surfaced in public reporting in 2024 as a stealthy, low‑noise backdoor deployed on appliances and management systems that commonly fall outside typical endpoint detection. Since then, multiple incident responders and government agencies have documented evolving variants and a clear operational focus on virtualization stacks—particularly VMware vCenter and ESXi—where the backdoor enables privileged lateral movement and targeted exfiltration of high‑value artifacts such as NTDS snapshots and cryptographic keys. The malware family is tied by industry analysts to the cluster tracked as UNC5221 (a suspected China‑nexus actor in public reporting), and the recent wave of reporting emphasizes long dwell times (averaging ~393 days in some analyses) and active development of the implant and its support libraries. These long dwell times have complicated forensic reconstruction of initial access vectors and complicated attribution in some cases.

---

Overview: What BRICKSTORM is and why it matters​

BRICKSTORM is a modular backdoor written in the Go programming language designed for cross‑platform deployment on appliances and virtual infrastructure. Its feature set is tailored to the operational goals of espionage operators:

• Persistent, low‑noise presence on devices that frequently lack EDR or centralized logging.
• Encrypted, nested C2 using legitimate cloud infrastructure, WebSockets over TLS, and DNS‑over‑HTTPS (DoH) resolution to blend with normal traffic.
• Interactive remote control via web API handlers and pseudo‑terminals providing full shell access.
• SOCKS proxy and tunneling to route operator sessions into compromised networks for hands‑on‑keyboard activity and direct access to internal services.
• VM‑focused tradecraft: copying and mounting VM snapshots for offline credential extraction and creating hidden, “rogue” VMs that persist outside inventory.

Why this matters to Windows administrators and virtualization teams: BRICKSTORM enables attackers to abuse legitimate management planes (vCenter/ESXi) to reach Windows domain controllers, certificate stores, and federation services without relying on noisy lateral movement techniques. That makes detection harder and raises the risk of credential theft leading to enterprise‑wide compromise, certificate misuse, and cloud tenancy abuse.

---

Technical summary: initiation, persistence, and C2​

Initiation and deployment vectors​

Public reporting and incident response data show BRICKSTORM is typically deployed after attackers gain a foothold on perimeter or management appliances. Observed steps include:

• Initial foothold on edge devices (network appliances, VPNs, other management appliances), sometimes via exploitation of vulnerabilities or via persistent web shells.
• Credential harvesting or theft from compromised appliances.
• Lateral authentication to VMware vCenter/ESXi using valid service or local accounts, followed by installation of BRICKSTORM blobs onto expected service paths (to blend with legitimate binaries).
• Use of short‑lived local accounts or seeded configuration changes to enable installation and later cleanup to reduce forensic visibility.

Note: Initial access techniques vary between incidents; some investigations point to zero‑day exploitation of appliances while others show credential reuse. Where zero‑day exploitation is claimed, that assessment is based on incident forensics; not all incidents provide public, independently verifiable evidence of the exact exploit chain. Treat zero‑day claims as high‑impact but, unless vendor advisories or public CVEs exist, label them as incident‑reported rather than independently proven.

Persistence design​

BRICKSTORM variants observed in public reporting implement robust self‑watch and reinstall logic: the implant copies itself into benign‑looking, management‑adjacent directories, modifies startup scripts (init.d, rc.local, systemd unit files or vCenter init scripts), and alters PATH or service launch sequences so a malicious binary is launched preferentially at boot. The implant will often monitor its own process and reinstantiate itself if killed. These persistence techniques are designed to survive reboots and basic “cleaning” attempts.

Command and control (C2)​

BRICKSTORM emphasizes covert C2:

• DNS‑over‑HTTPS (DoH) is used to resolve C2 domains through legitimate public resolvers (Cloudflare, Google, Quad9, NextDNS, etc., reducing the chance of straightforward DNS blacklist detection.
• HTTPS → WebSocket (WSS) upgrade flows are used to create persistent, multiplexed channels; additional nested TLS handshakes and in‑tunnel handshake authentication have been observed to further obscure the operator channel.
• Multiplexing libraries (examples: smux, yamux) enable multiple logical streams (command channel, SOCKS proxy, file transfer) to ride a single encrypted connection—compressing activity into a single encrypted flow.
• In‑memory certificates: later variants create ephemeral, self‑signed X.509 certificates in memory to run TLS without touching disk artifacts or relying on public CA trust chains.

These layered techniques intentionally blend with normal web traffic and complicate network‑level detection, especially where outbound HTTPS is permitted broadly.

---

Key observed capabilities and operational tradecraft​

File and process control​

BRICKSTORM exposes a REST‑like hidden API on infected hosts that allows operators to:

• Browse directory structures and list files.
• Upload, download, slice (partial reads), and checksum files.
• Create, rename, and delete files and folders.
• Execute arbitrary shell commands and spawn pseudo‑terminals for interactive sessions.

These file and command capabilities allow operators to remotely collect configuration files, credentials, code repositories, and other high‑value artefacts.

SOCKS proxying and tunneling​

A built‑in SOCKS proxy handler lets operators tunnel sessions from their workstation through the compromised host directly into the victim’s internal applications and services. That greatly simplifies exfiltration and targeted collection because attackers can browse internal web apps and code repositories directly from their workstation using the tunnel.

VM‑centric techniques (vSphere tradecraft)​

One of the most alarming operational patterns is the direct abuse of VMware management:

• VM cloning and offline extraction: Operators clone sensitive VMs (domain controllers, vaults), mount clones offline to extract credential material (for example, copying ntds.dit), then delete clones to minimize persistent artifacts visible in inventories and logs.
• In‑memory servlet filters (BRICKSTEAL): Java Servlet filters installed into vCenter’s Tomcat flow have been observed that intercept authentication flows, extract HTTP Basic auth headers, and capture credentials in transit.
• “VirtualGHOST” VMs: Rogue VMs started from the ESXi shell (not registered in inventory) are hard to detect via vCenter inventory but produce host artifacts (VM world IDs, vmx path activity) that can be hunted. CrowdStrike and other defenders have released scripts to detect these unregistered VMs.

Cross‑checking these behaviors across Mandiant/Google reporting and independent DFIR writeups shows this vSphere‑oriented modus operandi is consistent across multiple incidents.

---

Attribution and confidence: what is established, what is inferred​

Multiple government and private sector reports attribute BRICKSTORM activity to a China‑nexus cluster tracked as UNC5221 and describe the operations as consistent with state‑aligned espionage goals. Industry reporting and DFIR analyses consistently link the tool to long‑running, low‑noise campaigns focused on intellectual property and strategic targets. That said, attribution in cyber incidents is inherently probabilistic and is frequently based on tradecraft, targeting choices, infrastructure overlap, and classified telemetry—some of which is not publicly reproducible. Where possible:

• Treat operator linkage to UNC5221 as a high‑confidence industry assessment supported by multiple DFIR reports and government advisories.
• Treat specific statements about zero‑day exploit use or precise timeline dating (e.g., “first initial access on X date”) as incident‑specific findings; validate those elements against vendor advisories or CVE records where possible. Some incidents include strong forensic evidence of exploitation; in others initial access remains unclear due to long dwell times.

---

Detection: practical hunt techniques for Windows teams and vSphere admins​

Detection of BRICKSTORM requires a layered approach because the implant targets systems that often lack traditional host sensors. Use these complementary strategies together.

Network & proxy monitoring​

• Inspect outbound HTTPS flows to public DoH resolvers and cloud platforms that could be abused as a rendezvous (Cloudflare, Google, Heroku, Cloud Workers). Look for unusual persistent WSS sessions and nested TLS handshakes.
• Monitor for unexpected SOCKS proxy activity leaving management subnets or originating from appliance IPs.
• Block or tightly control DoH at network boundaries where policy permits; log and alert on DoH flows from management appliances.

vCenter / ESXi specific telemetry​

• Hunt VPXD logs for clone, snapshot, power on/off, and export events outside expected maintenance windows. Look for cloning of VMs that contain domain controllers, credential stores, or vaults—especially when followed by immediate deletion.
• Correlate vCenter events with SSH sessions to identify installation timelines and suspicious local account creation/deletion events in SSO/audit logs.
• Use CrowdStrike’s Detect‑VirtualGHOST PowerShell script or similar tooling to detect unregistered VMs running on ESXi hosts. This script compares inventory to running VM instances and flags discrepancies for investigation.

Host and file scanning​

• Run YARA rules on image backups and appliance file systems to find BRICKSTORM binaries. Mandiant and NVISO have published YARA rules and scanner scripts that are effective at finding Go‑based BRICKSTORM samples embedded on disk or in backups. When possible, scan backup images—and not just live file systems—because BRICKSTORM has been discovered in backups that missed earlier detection.
• Watch for obfuscated Go binaries masquerading as legitimate vSphere or appliance services (names and paths that mimic VMware or management binaries). Hashes in industry IOCs will quickly become outdated; prioritize behavioral and path‑based detections.

SIEM and log rules​

• Add detection rules for API endpoints commonly abused by operators (examples include vCenter SSO endpoints and VAMI management paths), and flag unusual GET /clone or POST /rest/* operations originating from appliance IPs or unexpected source geolocations.
• Inspect Entra/Microsoft 365 mailbox access logs for anomalous enterprise app tokens or mail.read (or full_access_as_app) grant creations that do not match planned third‑party app provisioning.

---

Incident response checklist (immediate actions)​

• Isolate affected appliances and management hosts from the network while preserving forensic integrity (do not reboot unless required for safety). Capture memory and disk images for analysis.
• Collect vCenter/ESXi host logs (VPXD, audit events, /var/log/*), SSH session logs, and VAMI access logs. Correlate times for suspicious clone and account activities.
• Run YARA scans against backups and mounted images; use Mandiant’s BRICKSTORM scanner and NVISO YARA rules where appropriate to find hidden implants.
• Quarantine compromised credentials and rotate service accounts used for management planes. Force rotation of passwords and secrets in credential vaults and any exposed Microsoft Entra application secrets.
• Revoke suspicious enterprise application grants (Entra) and review mail access logs for exfiltration. If ADFS or SAML certificates were exfiltrated or accessed, treat them as compromised and initiate key/certificate rotations.
• Notify appropriate authorities and incident response partners (follow legal and regulatory reporting obligations). Government agencies and major vendors have outreach channels that can provide active assistance and telemetry correlation.

---

Mitigations and hardening guidance (practical, prioritized)​

• Inventory and visibility: Take inventory of all appliances, management consoles, and virtualization hosts. Many successful intrusions begin on devices that were forgotten or excluded from centralized logging and EDR. Use network asset discovery to find unmanaged devices.
• Harden and patch management interfaces: Keep vCenter, ESXi, and dedicated appliance firmware up to date and follow vendor hardening guides for logging and management plane segmentation.
• Least privilege for service accounts: Restrict service accounts and avoid reusing credentials across management planes. Monitor service account behavior for deviations from established baselines.
• Control DoH and outbound tunneling: Where business policy allows, restrict DoH resolvers to managed resolvers and log tunnel‑like behaviors originating from management subnets.
• Network segmentation: Segregate management networks (vCenter, ESXi, appliance management interfaces) and limit administrative access to a well‑controlled jump host or bastion with MFA and just‑in‑time privileges.
• Backups and offline scans: Run YARA and artifact scanning across image backups to detect implants missed in production. Backups offer a reliable search domain when live evidence is sparse.

---

Tools and operational resources​

• Mandiant / Google published a BRICKSTORM scanner and YARA rules that are effective for scanning appliance images and live systems; these tools are recommended starting points for DFIR and hunting engagements.
• NVISO released Windows‑variant analysis, YARA rules, and Sigmac/KQL hunting suggestions—especially useful where BRICKSTORM is suspected to have targeted Windows VMs.
• CrowdStrike’s VirtualGHOST detection script (Detect‑VirtualGHOST.ps1) helps identify unregistered VMs that may indicate rogue, manually started VMs on ESXi hosts.
• Commercial SIEM vendors, threat intel feeds, and managed detection providers are rolling out BRICKSTORM detection packages and rule sets; coordinate with your vendor to prioritize vSphere and appliance telemetry ingestion.

---

Strengths and limitations of current defenses (critical analysis)​

Strengths in current reporting and tooling​

• Industry and government coordination has produced actionable artifacts (YARA, Sigma, hunting playbooks) that defenders can deploy immediately to hunt and triage suspected compromise.
• Public‑facing scanners and scripts (Mandiant, NVISO, CrowdStrike) enable organizations to run focused hunts even when EDR is not available on appliances.
• The combination of vCenter audit logging and backup scanning provides a credible path to detection even when live telemetry is sparse.

Practical limitations and risks​

• Appliance blind spots remain a major defensive gap. Many organizations lack EDR for appliance OSes or do not centrally collect log data, giving implants like BRICKSTORM fertile ground.
• The heavy use of DoH, nested TLS, and commercial cloud hosting for C2 reduces the signal‑to‑noise ratio of network detections and increases false negative risk.
• Long dwell times (industry average ~393 days reported in some analyses) mean initial access often cannot be reconstructed; remediation may require broad credential rotations and sweeping forensic actions rather than simple binary removal.
• Attribution and claims of zero‑day exploitation should be treated carefully: while some incidents show clear exploit traces, not every case publicly released includes independent proof of a zero‑day. Label exploit claims by their evidence strength in internal reports.

---

What Windows teams should prioritize right now​

• Treat VMware management systems and appliance OSes as high‑risk assets for credential theft and lateral movement; ensure logging and monitoring are enabled and logs are centrally collected and retained for long windows.
• If you run vCenter or ESXi in your environment, immediately:
• Validate that vCenter audit and VPXD logs are being exported and retained.
• Scan backups and snapshots with YARA rules provided by industry responders.
• Run the VirtualGHOST detection script to find unregistered or manual‑started VMs.
• Rotate and harden service accounts used for management and backup interactions; assume credentials found on appliances may be compromised if BRICKSTORM was present.

---

Open questions and claims that require further validation​

• Specific claims about initial exploit use (which CVE or zero‑day was used) vary per incident; where the initial vector is stated as a zero‑day, confirm the assertion against vendor advisories or CVE records before relying on that cause for broad mitigation.
• Some reports describe in‑memory servlet filters and custom in‑memory certificates; while multiple DFIR teams have reported such artifacts, the exact implementation details and sample‑level signatures vary across incidents. Use behavior and path‑based detection rather than relying purely on static hashes.

---

Conclusion​

BRICKSTORM is a high‑risk espionage backdoor that weaponizes the “appliance blind spot” and virtualization management planes to gain and maintain privileged access with minimal telemetry. For Windows and virtualization administrators, the combination of vCenter‑centric tradecraft (cloning DCs, extracting NTDS), stealthy C2 (DoH, nested WSS), and long dwell times makes BRICKSTORM particularly dangerous.
Immediate defensive steps include inventory and segmentation of management networks, YARA scanning of backups, rotation of exposed credentials, ingestion and retention of vSphere audit logs, and the use of community scanners (Mandiant, NVISO) and detection scripts (CrowdStrike VirtualGHOST) to hunt for indicators. Because initial access and exploit vectors differ by incident, defenders should cross‑validate vendor and government advisories, prioritize removal of lateral‑movement capability, and plan for credential and certificate rotations as part of a containment strategy.

---

For WindowsForum administrators and readers running virtualization infrastructure: treat BRICKSTORM as a wake‑up call to close appliance blind spots—inventory, monitor, and treat the management plane as critical infrastructure. The tooling and hunting playbooks now exist; the operational imperative is to deploy them and assume that any unmanaged appliance may already be a foothold unless proven otherwise.

---

Source: CISA BRICKSTORM Backdoor | CISA