BRICKSTORM dwell time shows why VMware visibility now matters

At a glance

What this is: This warning describes BRICKSTORM-linked espionage activity that remained undetected for years, using VMware and upstream provider access to reach downstream targets.

Why it matters: It matters because identity, access and asset visibility controls must extend into hypervisors, service providers and edge systems, not stop at the endpoint or perimeter.

By the numbers:

• The group is warned to have an average victim dwell time of 393 days.

👉 Read Swarmnetics' analysis of the BRICKSTORM campaign and long-dwell intrusion risk

Context

BRICKSTORM highlights a familiar governance gap in modern infrastructure: attackers do not need to win quickly if they can remain invisible across virtualised environments, upstream providers and weakly monitored edge devices. For IAM and PAM teams, the identity angle is clear, because privileged access in VMware, service-provider tooling and administrative control planes can become the path of least resistance.

The article argues that the campaign has been active since at least 2022 and that defenders need better visibility into the hypervisor layer, where many traditional detection and review processes are thin. That makes this relevant to identity governance as well as cloud and infrastructure security, because standing administrative access and weak inventory discipline create the conditions for long-dwell intrusions.

Key questions

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. That means standard endpoint controls may miss the intrusion for months. Teams need logging, alerting and access review coverage at the control-plane level, because the attacker is operating where normal host-based telemetry is weakest.

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. That creates inherited trust debt. If those access paths are not lifecycle-managed, a single breach can become a multi-tenant intrusion rather than a contained incident.

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. If the answer depends on after-the-fact forensics, the controls are not working as intended. Detection speed and audit completeness are the clearest indicators.

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.

Technical breakdown

How BRICKSTORM evades detection in virtualised environments

BRICKSTORM is described as a persistent malware family with strong obfuscation features, which makes it difficult for signature-led tools to identify once it is resident. The article says the operators often target VMware and other virtualisation layers, where activity can blend into administrative operations and evade endpoint-centric monitoring. Persistence is reinforced by the malware reinstalling itself if removed, which raises the bar for remediation. In practice, that means defenders need visibility that spans hypervisors, management planes and privileged workflows, not just hosts and users.

Practical implication: extend monitoring to VMware vSphere and adjacent management planes, not only endpoints.

Why upstream service providers expand downstream blast radius

The campaign reportedly favours upstream targets such as SaaS and security providers because a single compromise can create access paths into multiple downstream customers. This is a supply chain pattern rather than a one-off intrusion, and it changes how risk should be assessed. Once attackers inherit trusted relationships, they can move from one environment to many without repeating the initial breach. For identity teams, the lesson is that third-party access must be governed as a lifecycle, not a static trust grant.

Practical implication: review third-party access paths, offboarding, and service-provider entitlements as a single control surface.

What long dwell time means for detection and response

An average dwell time of 393 days means the intrusion can survive through routine patch cycles, staff changes and many standard assurance checks. That duration also suggests that detection is failing at multiple stages, including discovery, escalation and containment. If a threat actor can remain active for more than a year, then weak inventory, incomplete audit logging and limited behavioural baselining are all contributing factors. This is why the article frames the issue as a visibility problem as much as a malware problem.

Practical implication: treat long-dwell intrusions as a governance failure and validate audit, inventory and containment coverage.

Threat narrative

Attacker objective: The objective is long-term espionage, including access to source code, vulnerability research and downstream customer environments.

1. Entry appears to begin with scanning for known vulnerabilities in VMware and exposed edge devices, giving the operators a foothold in targeted environments.
2. Escalation follows through persistent malware deployment, lateral movement and reinstallation behaviour that helps the intrusion survive removal attempts.
3. Impact comes from espionage access to public sector, IT and upstream service-provider environments, with downstream client compromise extending the blast radius.

Breaches seen in the wild

• MITRE ATT&CK Enterprise Matrix — MITRE ATT&CK Enterprise — adversary tactics and techniques, threat detection, attack chain mapping, credential access, lateral movement, privilege escalation.
• BeyondTrust API key breach — compromised BeyondTrust API key led to unauthorized SaaS access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Hypervisor visibility gap: the attack surface defenders under-instrument is often the one attackers prefer. The article’s emphasis on VMware and hypervisor-layer monitoring shows why host-based visibility is insufficient in virtualised estates. When tools do not see control-plane activity, persistence and lateral movement can remain hidden for months. The practical conclusion is that identity, logging and asset inventory must align across virtualisation, not only at the server or endpoint tier.

Upstream compromise creates inherited trust debt for downstream customers. When a provider is breached, the customer does not just inherit service risk. It inherits the provider’s identity and access decisions, including how credentials, admin paths and support workflows are segmented. This is where NHI governance becomes relevant, because service accounts, vendor tokens and operational credentials often outlive the trust assumption that justified them. Practitioners should reassess third-party access as a controlled lifecycle, not a permanent integration.

Long-dwell espionage exposes the limits of pattern-based detection. The article’s warning that signature or pattern logic is no longer enough is accurate because stealthy actors can behave inside expected admin noise. That forces a shift toward control assurance, such as inventory completeness, privileged session review and hypervisor logging. For security leaders, the lesson is that detection maturity must be measured against dwell time, not tool count.

Named concept: hypervisor blind trust. This is the assumption that visibility and policy enforcement at the host layer are enough to govern what happens in virtualised control planes. BRICKSTORM shows that assumption fails when attackers operate below the level most teams monitor. The result is a governance gap where legitimate administrative trust becomes the carrier for persistent intrusion. Practitioners should close the blind spot by aligning identity, logging and change control in the virtualisation layer.

From our research:

• 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.
• From our research: 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.
• If persistence is the problem, the next step is lifecycle control, and the Ultimate Guide to NHIs , Key Challenges and Risks shows where visibility and privilege gaps usually start.

What this signals

Hypervisor blind trust is becoming a repeatable failure mode. Security programmes that stop at the endpoint will continue to miss threats that live in management planes, especially where virtualisation and upstream service-provider access overlap. The practical signal is to treat hypervisor telemetry, privileged session review and infrastructure inventory as core assurance inputs, not optional hardening measures.

The dwell-time figures in this warning point to an operational reality that identity teams already know from NHI governance: compromise is often sustained by access that was never fully revoked. That is why lifecycle discipline, including offboarding and rotation, belongs in the same conversation as detection. The issue is not just who got in, but how long the access remained viable.

For teams mapping this to broader control frameworks, NIST Cybersecurity Framework 2.0 remains a useful anchor for aligning govern, identify, detect and respond activities across virtualised estates. The near-term priority is to prove that your monitoring can see privileged activity where attackers are most likely to hide.

For practitioners

• 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. Include edge devices that can serve as initial footholds and confirm they are covered by patch and monitoring baselines.
• 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. Remove access that exists only because the integration was never formally offboarded.
• 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.
• Tighten edge-device and vulnerability inventory discipline Keep a live inventory of exposed edge devices, map them to patch status, and prioritise any system that can bridge into VMware or SaaS management layers. Vulnerability scanning must be coupled with ownership and remediation SLAs, not just findings.

Key takeaways

• BRICKSTORM-linked activity shows that virtualisation-layer persistence can outlast normal detection and response cycles by months.
• The attack pattern matters because upstream provider compromise turns one intrusion into a downstream trust problem, not just a malware incident.
• Teams that want to reduce this risk need visibility, lifecycle control and privileged access governance in the control plane, not only on the host.

Key terms

• Hypervisor Layer: The hypervisor layer is the virtualisation control plane that creates, runs and manages virtual machines. It matters because attackers who operate here can hide beneath normal host-based monitoring, gaining persistent administrative reach over multiple workloads at once.
• Dwell Time: Dwell time is the period between an attacker gaining access and defenders detecting or removing them. Shortening dwell time matters because most damage happens while the attacker remains unnoticed. In identity-led environments, reducing dwell time depends on visibility into access paths, privileges, and session behaviour.
• Upstream Service Provider: An upstream service provider is a trusted third party whose compromise can expose many dependent customers. In security governance, this creates inherited risk, because one access path, support workflow or integration can become a bridge into multiple environments.

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.

👉 Swarmnetics' full article covers the campaign timeline, named victims and VMware-focused mitigation points.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management in a practitioner-friendly format. It gives identity and security teams a common baseline for managing non-human access across modern environments.