TL;DR: CISA, NSA, and the Canadian Centre for Cyber Security say BrickStorm combines long-term persistence, credential theft, stealthy C2, and lateral movement in VMware vSphere and Windows environments, with defenders needing to harden vCenter, restrict service accounts, and block covert DNS-over-HTTPS channels. The lesson is that virtualization estates fail when identity, privilege, and monitoring are treated as separate problems.
NHIMG editorial — based on content published by SafeBreach covering BrickStorm and CISA AR25-338A: Dec 4, 2025 coverage and response guidance
By the numbers:
- 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years.
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
- Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging (37%) and over-privileged accounts (37%).
Questions worth separating out
Q: What breaks when service accounts have broad access in virtualized environments?
A: Broad service account access turns virtualization management into a persistence and lateral movement layer.
Q: Why do vSphere environments need identity governance as much as malware detection?
A: Because the attacker’s durable foothold often comes from trusted identities, not from a single executable.
Q: What do security teams get wrong about encrypted command and control traffic?
A: They often assume encryption is the core problem, when the real issue is encrypted traffic from systems that should not be talking that way.
Practitioner guidance
- Tighten service account scope in virtualization estates Inventory every account that can administer vCenter, ESXi, snapshot access, or remote access paths.
- Block covert DNS-over-HTTPS pathways Restrict approved DoH resolvers and alert on encrypted DNS egress from servers that should not initiate it.
- Harden startup and persistence locations Watch VMware init scripts, PATH order, and binary naming conventions for unexpected changes.
What's in the full article
SafeBreach's full post covers the operational detail this analysis intentionally leaves for the source:
- Simulation coverage mapped to specific BrickStorm techniques across initial access, persistence, privilege escalation, command and control, and exfiltration.
- A concrete list of updated behavioral attacks that practitioners can run against their own environments to test detections.
- Platform-specific instructions for running the new BrickStorm scenarios on demand.
- The playbook update path for coverage as new indicators and variants emerge.
👉 Read SafeBreach's analysis of the BrickStorm backdoor and updated CISA guidance →
BrickStorm in vSphere: what identity and access teams need to fix?
Explore further
BrickStorm is an identity governance problem hiding inside a malware story. The report shows that persistence in virtualisation estates depends on trusted access paths, not only executable code. Service accounts, snapshot permissions, and management-plane credentials become the real control surface. For IAM and PAM teams, that means vSphere should be treated as a privileged identity environment, not a separate infrastructure domain.
A few things that frame the scale:
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
- Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging (37%) and over-privileged accounts (37%).
A question worth separating out:
Q: Who is accountable when hidden VMs or snapshot theft appear in a breach?
A: Accountability usually spans infrastructure, IAM, and security operations because the failure cuts across administrative access, monitoring, and platform hardening. If snapshot access, service account scope, or vCenter logging were not governed tightly, the issue is not only malware response. It is a control ownership problem that should be assigned before the next incident.
👉 Read our full editorial: BrickStorm persistence shows why vSphere identity controls matter