Notifications
Clear all
Topic starter
14/07/2026 6:07 pm
TL;DR: CISA, the NSA and the Canadian Centre for Cyber Security say BRICKSTORM-linked activity has persisted in public sector and IT environments since at least 2022, with an average victim dwell time of 393 days and a focus on upstream providers, VMware and edge devices. Pattern-based detection alone is no longer enough when stealth, lateral movement and persistence operate below normal monitoring thresholds.
NHIMG editorial — based on content published by Swarmnetics: Alleged Chinese Hackers Using BRICKSTORM Malware Have Been Dwelling in Public Sector & IT Companies for Years Unobserved
By the numbers:
- The group is warned to have an average victim dwell time of 393 days.
Questions worth separating out
Q: What breaks when hypervisor activity is not monitored closely enough?
A: When hypervisor activity is invisible, attackers can hide persistence, administrative tampering and lateral movement inside trusted virtualisation workflows.
Q: Why do upstream service-provider compromises increase downstream risk so quickly?
A: Upstream compromises matter because one trusted provider can expose many downstream customers through shared administration, support pathways or integration credentials.
Q: How do security teams know whether their virtualisation controls are actually working?
A: They should test whether privileged actions in VMware and adjacent management planes are logged, correlated and reviewed fast enough to catch reinstallation, lateral movement and persistence.
Practitioner guidance
- Inventory and monitor VMware control planes Map every vSphere, ESXi and adjacent management endpoint into the security inventory, then verify that logging, alerting and change tracking are enabled for privileged actions.
- Reassess upstream provider trust paths Review SaaS, security and managed-service integrations for standing administrative access, then enforce lifecycle ownership for vendor credentials, support accounts and break-glass paths.
- Measure dwell-time resilience instead of tool coverage Test whether your monitoring stack can detect suspicious virtualisation-layer activity within days rather than months, and use purple-team exercises to validate response to reinstallation behaviour, lateral movement and control-plane tampering.
What's in the full analysis
Swarmnetics' full article covers the operational detail this post intentionally leaves for the source:
- Timeline detail on the BRICKSTORM campaign and how the operators maintained dwell time across multiple years.
- Named victim context, including the F5 disclosure and other affected organisations referenced in the article.
- Specific guidance on VMware vSphere hardening, weak-link edge device inventory and monitoring priorities.
- The article’s source references from CISA, the NSA and the Canadian Centre for Cyber Security for practitioners tracking official alerts.
👉 Read Swarmnetics' analysis of the BRICKSTORM campaign and long-dwell intrusion risk →
BRICKSTORM persistence in VMware environments: what teams need to do?
Explore further
14/07/2026 6:12 pm
Persistent infrastructure intrusion is now an identity problem as much as a malware problem. BRICKSTORM’s value to the operators comes from its ability to survive in VMware and management layers where privileged access is already concentrated. That means the weak point is not only detection logic, but the governance of administrative reach, especially where service accounts and platform operators have standing access. Practitioners should treat hypervisor and control-plane access as part of identity governance, not as a separate infrastructure concern.
A few things that frame the scale:
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs , Why NHI Security Matters Now.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to NHI Lifecycle Management Guide.
A question worth separating out:
Q: Who is accountable when a supplier breach affects downstream customers?
A: Accountability is shared, but it is not diffuse. The vendor is accountable for its own security failures, while the customer remains responsible for the trust it extends, the data it exposes, and the controls it enforces around third-party access. Frameworks such as the NIST Cybersecurity Framework 2.0 support that shared-responsibility view.
👉 Read our full editorial: BRICKSTORM dwell time shows why VMware visibility now matters
