BRICKSTORM Backdoor: Appliance and Virtualization Targeting VMware and Windows

Chinese state-sponsored actors have been observed deploying a sophisticated backdoor called BRICKSTORM to maintain long-term, stealthy access across public‑sector and information technology environments — with confirmed targeting of VMware vSphere management infrastructure, Windows systems, and network appliances used at the enterprise edge. This campaign combines appliance-focused persistence, credential harvesting, and covert command-and-control to enable extended espionage and downstream compromise; defenders must treat exposures to appliance management interfaces and virtualization control planes as immediate, high‑risk priorities and begin hunt and remediation workflows now.

Background​

BRICKSTORM first surfaced in industry reporting in 2024 and has been the subject of intensifying analysis through 2025. Security researchers from Mandiant and Google’s Threat Intelligence Group (GTIG) attribute the backdoor family and related operations to a China‑nexus threat cluster tracked as UNC5221; public‑sector teams including CISA and multinational partners have since published guidance and advisories warning of related intrusions and recommended mitigations. Multiple independent incident responses and vendor analyses confirm a consistent pattern: attackers establish footholds on appliances and appliances‑like platforms (Linux/BSD-based management interfaces), then pivot into virtualization management (vCenter/ESXi) and Windows hosts to harvest credentials and exfiltrate high‑value data. Industry telemetry indicates BRICKSTORM campaigns can persist for months to more than a year in victim networks. Mandiant’s reporting highlights an average dwell time in observed incidents of approximately 393 days, illustrating how stealth‑first tradecraft on minimally instrumented appliances pays dividends for long‑term espionage operations. National guidance emphasizes the same threat model: edge/management appliances rarely run EDR and often have permissive access to internal networks, making them ideal platforms for lateral movement and covert exfiltration. Historical context: PRC‑linked APT activity has repeatedly favored credential theft, living‑off‑the‑land tactics, and pre‑positioning on infrastructure to support future operations — behavior documented across multiple U.S. Government advisories and decades of incident response. That broader pattern helps explain why BRICKSTORM’s appliance‑centric approach is effective and why virtualization control planes (vCenter/ESXi) are particularly attractive targets.

---

What BRICKSTORM is and how it works​

Core capabilities (high level)​

• Cross‑platform backdoor — BRICKSTORM is written in Go and targets Linux/BSD-based appliances as well as has variants observed in VMware vSphere environments and Windows hosts. Its cross‑platform design enables reuse across diverse embedded and appliance OS builds.
• Covert communications — multiple layers of encryption and tunneling (HTTPS, WebSockets, nested TLS), and DNS‑over‑HTTPS (DoH) to hide command‑and‑control (C2) and beaconing activity inside otherwise legitimate web traffic flows.
• SOCKS proxy and tunneling — BRICKSTORM can act as a SOCKS proxy to tunnel attacker sessions through compromised appliances and to pivot into internal networks using the appliance as a concealment pivot.
• Credential harvesting and VM theft — attackers use BRICKSTORM footholds to obtain credentials (via backups, LSASS/NTDS access, or snapshots), clone or snapshot VMs on vCenter to extract secrets, and create hidden/rogue VMs to evade detection.
• Long‑term persistence — implants modify init scripts/systemd or VAMI/startup scripts on vCenter appliances, and embed self‑watcher functionality that reinstalls or restarts components if disrupted. YARA detections and artifact strings reported by Mandiant/GTIG indicate explicit self‑monitoring code paths (e.g., main.selfWatcher, main.startNew).

Notable technical details​

• BRICKSTORM commonly lives on management appliances that do not have traditional EDR coverage: VPN appliances, firewalls, conferencing systems, backup appliances, and virtualization management appliances such as VMware vCenter. These devices often have direct access to internal subnets and domain services, making them privileged footholds.
• On VMware platforms, logs of interest include VPXD logs, VAMI (appliance management) logs, and vSphere audit events. Attackers have used the vSphere Appliance Management Interface to enable SSH, create short‑lived local accounts, install the implant via SSH, and then remove those accounts — behavior that appears in vCenter logs and must be hunted.
• BRICKSTORM’s network behavior includes queries to multiple DoH resolvers and simultaneous connections to web‑hosted services (e.g., cloud workers) that indicate multiplexed C2 over ostensibly normal HTTPS flows. Detection use cases should focus on a single internal source making DoH queries to multiple providers combined with web application‑hosted communications within narrow time windows. Mandiant/GTIG published Sigma/YARA logic and rule examples to convert this network behavior into hunt rules.

---

Confirmed impacts and attack chain (examples)​

• Initial access: compromise of internet‑facing web servers or appliances (DMZ), sometimes via exploitation of vulnerabilities or through credential compromise obtained from other footholds.
• Lateral movement: use of stolen credentials and SSH or management interfaces to access internal VMware vCenter servers, enable SSH via VAMI, and install BRICKSTORM.
• Credential harvesting: cloning VMs or taking snapshots (targeting vaults, domain controllers, or other sensitive VMs) to extract NTDS.dit or other secrets offline. Attackers also exfiltrate backups or use administrative Windows tooling to copy Active Directory data.
• Persistent C2 and exfiltration: establish resilient C2 channels (DoH, nested TLS, WebSockets), operate a SOCKS proxy to tunnel sessions, and exfiltrate targeted data or access cloud services (e.g., Microsoft 365 mailbox access) via Azure/Entra application tokens.

Multiple incident responders and vendors corroborate elements of this pattern, and defenders should treat the presence of any one of the telltale behaviors — appliance‑origin DoH queries, vCenter cloning events by unusual accounts, or unexplained appliance‑to‑internal Windows logins — as high risk.

---

Why this is different (threat model and operational risk)​

• Appliance blind spots: Many appliances lack EDR agents and are excluded from central logging. An attacker on an appliance can move laterally and perform sensitive operations with little telemetry. The result is long dwell time and hard‑to‑detect lateral pivots.
• Virtualization abuse: vCenter and ESXi provide programmatic mechanisms to clone VMs, export snapshots, and interact with datastore images. When an attacker controls these systems, they can extract credential stores and create ghost VMs that conceal operations from typical host‑based monitoring.
• Protocol blending: Use of DoH and nested TLS/WebSocket channels allows C2 to blend into normal web traffic and bypass legacy DNS monitoring. This raises the bar for detection — defenders need deep network telemetry and protocol‑aware inspection.
• Supply‑chain and downstream risk: The observed targeting of SaaS and BPO providers means a single appliance compromise can become a vector into their customers’ environments. This multiplier effect amplifies impact far beyond the initially breached host.

---

Detection and hunting — immediate tactical playbook​

The following actions provide a prioritized, defensible hunt and detection workflow for SOCs and incident responders.

Priority hunting steps (immediate)​

• Scan backups and images with YARA rules for BRICKSTORM patterns (Mandiant/GTIG YARA rules are available and effective against binaries discovered in incidents). If backup solutions support YARA scanning of snapshot repositories, run these scans first.
• Search vCenter VPXD and VAMI logs for:
• Creation and deletion of local accounts near installation times.
• Enabling of SSH via VAMI REST calls.
• VM clone, snapshot, or export actions performed by unexpected accounts or outside normal business hours (observed attacker activity often occurred between 01:00 and 10:00 UTC).
• Hunt for appliance management IPs making outbound DoH queries to multiple providers (Quad9, Cloudflare, Google, etc. and for simultaneous HTTPS connections to cloud‑hosted web applications or Workers—this multiplex behavior is a strong indicator of BRICKSTORM‑style C2.
• Check Windows domain controllers and backups for NTDS.dit access, Volume Shadow Copy manipulations, and any evidence of offline snapshot extraction. Correlate suspicious snapshot activity with vCenter events.
• Scan for artifacts and strings noted in published YARA rules (e.g., WRITE_LOGWednesday, /opt/vmware/sbin/, vami-httpdvideo/webm) and for files named like pg_update, spclisten, or vmp associated with public indicators of compromise.

Detection rules and telemetry to enable​

• File and backup scanning: YARA rules derived from Mandiant/GTIG; run against backup stores and appliance images.
• Network detection: rules that flag a single internal source performing DNS‑over‑HTTPS resolve queries to multiple DoH providers within short time windows and making near‑simultaneous HTTPS connections to cloud worker endpoints. Example Sigma/YARA/network rule patterns were published by GTIG.
• vSphere detection: monitoring for unusual VPXD events (clone, snapshot, VM creation/deletion), local account creation/deletion, and changes to SSH enablement via VAMI. Forward these logs to SIEM/UEBA and create alerts for off‑hours or geographically inconsistent activity.

---

Mitigation and hardening — prioritized roadmap​

Apply the following mitigations in a prioritized sequence to contain existing intrusions and reduce future risk.

Immediate containment (0–72 hours)​

• Hunt first: Do not assume containment until a full hunt is completed. Scan backups and images for BRICKSTORM with YARA rules before restoring from backups. Covert implants are often present in backup snapshots.
• Block unauthorized DoH: Deny outbound DoH to unknown providers and block external DoH traffic from appliance management subnets. Log allowed DoH providers explicitly and require approval.
• Isolate compromised appliances: If an appliance is confirmed compromised, remove its network access to internal subnets and isolate it for forensic analysis; do not immediately reimage without first collecting forensic data.

Short‑term remediation (3–14 days)​

• Inventory and visibility: Create an authoritative inventory of all edge devices, appliances, and management interfaces. Prioritize logging from anything that does not normally run EDR.
• vSphere hardening: Enforce vSphere lockdown mode, forward VPXD and VAMI logs to the SIEM, enable MFA for vCenter, and audit all local account creation/deletion events. Enforce least‑privilege for backup and management accounts.
• Credential hygiene: Rotate credentials for accounts used by appliances and any service accounts with cross‑tier access. Enforce strong, unique passwords and require MFA where possible. Consider treating credential vaulting systems as Tier‑0 assets and isolate them.
• Patch and mitigate known exploited vulnerabilities: Apply patches for known appliance and edge vulnerabilities; consult KEV lists and CISA advisories for prioritized CVEs.

Long‑term resilience​

• Zero Trust and segmentation: Implement strict network segmentation so management interfaces are not routable from general user subnets or the internet. Use firewalls to restrict vCenter and appliance management access only to vetted admin workstations and jump servers.
• Backup scanning and recovery hygiene: Integrate YARA scanning into backup validation and maintain immutable backup copies and air‑gapped recovery stores. Periodically test recovery from clean snapshots.
• Reduce appliance attack surface: Disable unused services (SSH, remote management) on appliances where possible. Use vendor guidance to harden management interfaces and apply strict egress controls to limit appliance internet access.
• Vendor engagement and responsible disclosure: Coordinate with appliance vendors to obtain patches and to understand recommended logging and instrumentation options; push for vendor support for telemetry export where missing.

---

Incident response and reporting​

If BRICKSTORM or similar activity is detected, follow standard incident response triage (contain, preserve evidence, eradicate, recover) with these specifics:

• Preserve logs and backups: Collect vCenter VPXD/VAMI logs, appliance filesystem images, and backup snapshots before making changes. Evidence from deleted implants may still be recoverable from backups.
• Coordinate credential resets: After isolating compromised systems, rotate and revoke credentials found to be in use or suspected stolen. Prioritize domain admin/service accounts, backup service accounts, and cloud application tokens.
• Work with vendors and cert teams: Notify appliance vendors, cloud providers, and enterprise incident response partners. Many vendors publish specific detection and lockdown guidance for vSphere and appliance hardening.
• Report to authorities and national incident response centers: U.S. entities should report to CISA’s 24/7 Operations Center; international organizations should notify their national CSIRTs. National guidance provides additional resources and may coordinate cross‑organizational hunts.

---

Practical checklist for VMware and Windows administrators​

• Ensure vCenter and ESXi management interfaces are not directly internet‑reachable.
• Forward VPXD, VAMI, and audit logs to a centralized SIEM and keep retention sufficient for forensic timelines (at least 1 year where feasible).
• Search logs for SSH enablement calls, local user creation/deletion, and VM clone/snapshot events by non‑standard accounts.
• Run YARA scans on backup stores and on appliance images for known BRICKSTORM indicators.
• Block unauthorized DoH and restrict outbound TLS traffic from appliance networks to known vendor update domains only.

---

What defenders should know about attribution and reporting​

Multiple public and private organizations have attributed BRICKSTORM incidents to a China‑nexus cluster tracked as UNC5221; national agencies (CISA, NSA partners) describe the activity as consistent with PRC state‑sponsored operations and have released joint advisories and hunting guidance. Attribution in public reporting is based on tradecraft, infrastructure reuse, victimology, and internal intelligence; however, attribution in cyber incidents can be complex and sometimes contested — defenders should rely on verified indicators and observable TTPs for remediation and coordinate with national authorities for attribution queries. When reporting, provide concrete artifacts (hashes, logs, timestamps, VPXD events) rather than relying on attribution statements alone.

---

Strengths and limitations of public reporting — critical analysis​

Strengths (what defenders gain)​

• Actionable detection artifacts: YARA rules, VPXD/VAMI log indicators, and DoH‑based detection heuristics give SOCs immediate technical paths to hunt and contain implants. This turns high‑level warnings into operational playbooks.
• Shared vendor and incident response intelligence: Mandiant/GTIG and other vendors provide scanner tools and example rules that are portable across backup systems and SIEMs. This reduces time to detection for organizations that adopt them.
• Clear mitigations: Practical guidance (inventory appliances, block DoH, forward vSphere logs) aligns with existing best practices and is immediately implementable in most environments.

Limitations and risks (what to watch for)​

• Telemetry gaps remain: Appliances commonly lack EDR and rich logging; many organizations cannot apply the published YARA/SIEM techniques without first expanding telemetry or extracting backups for scanning. This gap materially increases detection latency.
• Indicator expiry and evasive tradecraft: BRICKSTORM samples vary and operators frequently change C2 and file signatures. Overreliance on atomic indicators (hashes or filenames) will miss modified implants — behavioral and TTP detection is necessary.
• Attribution uncertainty: While multiple organizations point toward PRC‑linked clusters, public attribution lacks the absolute certainty some decision makers expect. Operational priorities must therefore emphasize containment and recovery over geopolitical attribution.
• Downstream exposure: Targeting of SaaS and BPO providers means remediation must often span provider/customer boundaries — coordination complexity raises response costs and time to full remediation.

---

Final assessment and recommended next steps (executive summary)​

BRICKSTORM represents a substantive escalation in appliance‑centric espionage tradecraft. Its combination of cross‑platform implants, advanced C2 (DoH, nested TLS), SOCKS proxy tunneling, and virtualization abuse to harvest credentials creates a high operational risk for organizations that rely on unmanaged or lightly monitored appliances and virtualization management platforms. The greatest immediate risk vectors are unmanaged appliance management interfaces, poorly segmented vCenter/vSphere control planes, and backup stores that have not been scanned for dormant implants. Top actionable steps:

• Run published YARA/scanner rules against backup and appliance images immediately.
• Block or strictly control DNS‑over‑HTTPS from appliance management networks and log any DoH use.
• Inventory edge devices, forward vCenter (VPXD) and VAMI logs to SIEM, and hunt for clone/snapshot events and local account lifecycle events.
• Harden vSphere (lockdown mode, MFA) and isolate management interfaces; rotate credentials used by appliances and backup systems.
• Report confirmed compromises to national incident response centers (e.g., CISA for U.S. entities) to support coordinated hunts and protective actions.

The combination of published detection artifacts and recommended mitigations gives defenders a clear path: expand visibility to appliances and backup stores, hunt for the described behaviors (DoH multiplexing, vSphere cloning), and treat any appliance‑originating Windows logins as high priority. Immediate action reduces the window for ongoing espionage and prevents a single compromised appliance from becoming a pivot point into dozens of downstream environments.

---

BRICKSTORM is a reminder that traditional EDR‑centric thinking is no longer sufficient: appliances, virtual management planes, and backup repositories are now first‑class targets. The defenders who win next year will be those who rapidly inventory and instrument those blind spots, convert published YARA/Sigma/network detections into enforcement and alerts, and treat vCenter/vSphere and backup snapshots as critical assets rather than peripheral infrastructure.

---

Source: CISA PRC State-Sponsored Actors Use BRICKSTORM Malware Across Public Sector and Information Technology Systems | CISA