At 03∶37, a Domain Controller Was Quietly Cloned — Inside BRICKSTORM's 393-Day Shadow

1 At 03:37, a second domain controller appeared

At 03:37:40 UTC on April 1, 2025, a vCenter server recorded an ordinary-looking administrative task: VirtualMachine.clone. Nine seconds later, another event named the source and destination. DC01 was being copied from esxi01 to a new machine called DC01-clone on esxi02. The job completed at 03:42:07. At 04:05:40, an administrator asked vCenter to destroy the copy. Seven seconds later, it was gone.

The five lines were published by Google Threat Intelligence Group from an anonymized incident handled by Mandiant. They contain no cinematic malware alert, no command shell scrolling across a screen, and no desperate race between attacker and analyst. The actor used the local VSPHERE.LOCAL\Administrator account. vCenter accepted the request, moved the virtual disks, reported success, and later removed the inventory object. Every individual event resembled something a legitimate infrastructure team might do.

Taken together, however, the sequence describes a theft that endpoint security was structurally unable to witness. The clone did not have to boot. Its antivirus agent did not start, its EDR sensor did not call home, and its Windows event log did not record a new interactive session. The valuable part of the server—the virtual disks—could be mounted and read from outside the guest. For a domain controller, that can place the Active Directory database, system registry material, and other credential-bearing files within reach. For an identity provider or password vault, the exact files differ, but the attraction is the same: copy the machine first, then examine its secrets somewhere its own defenses never wake up.

The clone existed in vCenter for roughly twenty-three minutes after the copy completed. Deleting it removed the convenient object an operator could click in the inventory. It did not necessarily remove every trace of the operation. The task had a key. The source and destination had managed-object identities. Datastore files had been created and moved. VPXD, host, storage, authentication, and network systems had each seen a different edge of the same act. The investigation therefore begins with a practical question, not a malware name: can those edges still be joined after the object in the middle has disappeared?

1.1 The silence inside the guest was part of the method

Security programs are usually built from the guest outward. A process starts, a module loads, a user logs in, a script runs, or a file changes; an agent inside the operating system observes it and sends telemetry to a console. Virtualization reverses that perspective. vCenter and ESXi can copy, snapshot, mount, reconfigure, or move a machine while the operating system inside it remains unaware. An actor who controls the management layer does not need to defeat each guest sensor. The actor can work one floor above it.

That is why “no EDR alert on DC01” cannot clear the clone interval. No process executed on DC01-clone because no process needed to execute there. The useful question is whether the control plane handled the disks: which account requested the task, which session carried it, where the VMDKs landed, whether the copy was ever registered or powered on, how many bytes crossed the storage path, and what happened between completion and deletion. The absence of guest telemetry is not evidence that nothing happened. In this particular technique, it is what success looks like.

The same shift changes the order of triage. If an analyst begins by searching the cloned server's Windows logs, the search starts inside a room that was never entered. Begin instead with VPXD tasks and events, vCenter SSO audit records, VAMI access, hostd and vpxa activity, datastore metadata, and network flow from management addresses. Then use the source VM's identity to determine what the copied disks could expose. The server's business role decides the credential-rotation and downstream-review scope even when the clone itself has vanished.

A clone called DC01-clone is an unusually readable clue, but names are weak anchors. Administrators can rename machines; automation can recycle labels; an actor can choose something that resembles a backup convention. Preserve the vCenter instance UUID, VM managed object ID, VM instance UUID, task key, event key, source and destination host IDs, datastore and folder identifiers, authenticated principal, session, and collector time. Those fields let one system's record recognize the same operation in another system after the display name has changed.

1.2 Five lines are a doorway, not a complete diary

The public log excerpt came from one case. The broader BRICKSTORM report combines techniques seen across multiple investigations, with customer details removed. Reading it responsibly does not require draining the story of momentum; it requires keeping the camera honest. The five lines show that one sensitive clone sequence happened. Other parts of the report show that similar actors reached appliances, stole or reused credentials, installed BRICKSTORM on VMware systems, captured authentication material, browsed files, accessed mail, and downloaded code in different engagements. They illuminate how the 03:37 scene could fit an operating model, but they are not one victim's unbroken diary.

This distinction matters most when an organization turns the report into a hunt. A domain-controller clone is strong local evidence of a management-plane action. It is not, by itself, proof of BRICKSTORM or UNC5221. Conversely, an environment should not wait for that exact VM name, account, or five-event cadence before looking. Mandiant reported cloning of sensitive Windows servers in at least two cases; it also described other ways the actor pursued credentials and information. The useful unit is the behavior: unexpected control-plane authority used to make a short-lived, offline copy of a system that holds durable secrets.

The opening also gives the case its first missing piece. An account with enough vSphere authority carried out the task, but the logs shown here do not explain how that authority was obtained. To find the earlier handoff, investigators have to move backward from vCenter: authentication, newly created local users, SSH enablement, appliance-sourced connections, and the systems that may have exposed credentials. That search runs into the campaign's defining number. By the time Mandiant arrived, the average reviewed intrusion had already been present for 393 days.

2 After 393 days, the first page of the case was missing

Three hundred and ninety-three days is long enough for an annual certificate to expire, a project team to change, and several generations of security data to roll out of ordinary storage. Mandiant calculated that average across the BRICKSTORM intrusions it reviewed. In many of those cases, the available logs no longer reached back to the initial entry. Responders could see the actor living in the environment, but the door through which the actor first arrived had already fallen outside retention.

That gap is easy to fill with a confident story. BRICKSTORM has been associated with operators who exploit edge devices. Mandiant confirmed zero-day exploitation in at least one investigation and found the actor operating from several other edge appliances early in other lifecycles. Yet the evidence did not establish vulnerability exploitation in every case. Some first-hop records were simply gone. The accurate conclusion is more useful than a neat one: at least one zero-day was real, perimeter and remote-access systems repeatedly mattered, and many organizations could no longer prove exactly how their own sequence began.

This is not a semantic caution for a footnote. It changes remediation. If a team declares one product vulnerability to be the universal entrance, patches that product, and closes the case, it may leave another compromised appliance, a valid account, or a management-plane implant untouched. If it treats every unexplained edge event as confirmed exploitation, it may waste time proving a mechanism that the remaining evidence cannot recover. A good investigation holds both ideas at once: patch and isolate every plausible exposed route, while using surviving behavior to find where access actually traveled.

The missing first page also explains why the 03:37 clone deserves so much attention. Initial-access indicators are fragile. A short-lived exploit request may survive for days in a reverse-proxy log, if it was logged at all. A year later, a vSphere task, a backup image, an account change, a mailbox audit event, or a long-lived network relationship may be the better witness. The case has to be reconstructed from the middle outward.

2.1 Retention became part of the threat model

Most retention policies are priced around routine operations: enough raw detail to investigate a recent alert, then aggregation or deletion as data ages. BRICKSTORM turns retention into a security control. If an appliance can host privileged access for more than a year, the organization needs some year-plus memory of that appliance's identity, configuration, egress, authentication, and file state. Full packet capture for every interface is rarely necessary or affordable. A small set of durable indexes can preserve where to look.

For each appliance, retain a stable asset identity, management and data-plane addresses, product and exact build, owner, lifecycle status, last configuration backup, expected vendor destinations, and whether the device exports logs. For network activity, keep destination first seen, last seen, protocol, byte count, and the device interface or address that initiated it. For identity, keep account, source, target, result, session or request identifier, and any role change. For vSphere, keep task and event keys, object identities, actor, source, target, result, and storage location. These records are small compared with full raw telemetry, but they can select the right backup or verbose interval months later.

Centralization matters because a live appliance is not a neutral archive after suspected compromise. An intruder with root access can alter local files and logs. A configuration backup stored on the same device can disappear with them. Send the records to storage whose credentials and deletion path are separate from the appliance. Preserve clock source and ingestion time as well as device-reported time; otherwise a drifted or modified clock can make two genuinely related events appear unrelated.

The 393-day number should not become a magical minimum copied into every policy. It is an observed average, not a guarantee that an operation ends on day 394. It does provide a design test: can the organization answer who controlled a Tier 0 appliance, where it connected, what changed, and which backups contain its earlier state across at least the longest credible intrusion window? If not, “we found no earlier activity” really means “our memory ends here.”

2.2 The investigation moved from the missing entrance to the surviving foothold

When the entry request is gone, responders can still search for the first durable thing the actor had to maintain. In the BRICKSTORM cases, that often meant a Linux- or BSD-based network appliance. Appliances are attractive not because they are mysterious boxes, but because organizations routinely grant them three advantages at once: a privileged position, sparse monitoring, and a long service life. A VPN concentrator may authenticate users and route internal traffic. A security gateway may inspect secrets while being trusted to contact the internet. A virtualization appliance may hold authority over every guest beneath it. Few support the same endpoint tooling deployed to laptops and servers.

Inventory gaps magnify the problem. A device acquired for a proof of value can remain connected after its project owner leaves. A management interface can sit on an address range omitted from endpoint searches. A vendor image may be updated through a separate process and keep no centrally searchable package history. When Mandiant describes appliances as poorly inventoried or excluded from centralized logging, the operational consequence is stark: the system most capable of bridging trust zones can also be the system least likely to appear in the incident map.

The first useful sweep therefore asks for assets, not indicators. Enumerate firewalls, VPN and remote-access concentrators, storage controllers, conference systems, access-control devices, virtualization appliances, management servers, and vendor-managed evaluation equipment. Resolve every management IP to an owner and exact build. Mark which devices can initiate connections to internal addresses, which can reach the public internet, which store or relay credentials, which have protected backups, and which produce logs outside their own file system. An unanswered cell is not administrative debt anymore; it is a place where the first page can vanish again.

Once the inventory exists, a second question becomes possible: which of those appliances behaved like a workstation or a jump host? Search for management addresses initiating SSH, RDP, SMB, WinRM, LDAP, database, or vCenter sessions that their role does not require. Compare egress with a vendor-owned allowlist; the internet as a whole is not an acceptable baseline. Look for destinations first seen long after installation, long-lived encrypted sessions, direct IP services, unexpected DNS patterns, and connections continuing through maintenance windows. The public report says BRICKSTORM offered a SOCKS proxy. That means the appliance could become both a hiding place and a route to the next system.

The trail from the missing entrance now reaches a machine that endpoint tooling may never have covered. To understand why such footholds stayed quiet—and how cross-case reporting linked appliance access to later VMware authority—the investigation has to study the backdoor's operating model, then demand local evidence for every handoff.

3 The foothold lived on a machine nobody treated like an endpoint

BRICKSTORM is a Go backdoor with a built-in SOCKS proxy. That short description explains both its portability and its place in the campaign. Go programs can carry much of what they need inside one executable, making them practical on Linux- and BSD-based appliances with different vendor layouts. A SOCKS proxy lets the operator route interactive traffic through the compromised device, so an internal system sees a familiar appliance address while the operator's workstation remains out on the internet.

Mandiant recovered BRICKSTORM from appliances made by multiple vendors. Its investigators did not observe a Windows variant in their cases, although other evidence indicated that one existed. The distinction says something about operational preference: the activity Mandiant handled was concentrated in places where conventional endpoint visibility was weakest. The backdoor did not need to win a prolonged fight with a Windows EDR product if it could live in a system that had no supported agent, little file-integrity monitoring, and an administrator likely to read unexplained load as an appliance fault before considering a security signal.

The malware was also being adjusted for its surroundings. Some recovered builds were obfuscated with Garble; some carried a newer custom wssoft library. Names and behavior could be made to resemble legitimate appliance components. One sample contained a timer that waited until a hard-coded date months in the future before contacting its configured command server. Across the victims in the report, Mandiant found no reuse of command-and-control domains. Infrastructure included Cloudflare Workers, Heroku applications, and domains that resolved directly to an IP through services such as sslip.io or nip.io.

3.1 A victim-specific beacon made yesterday's blocklist age overnight

Atomic indicators remain useful. The report published three SHA-256 values associated with filenames pg_update, spclisten, and vmp. A direct match deserves immediate preservation and scoping. But Mandiant also said it had not observed the actor reuse a malware sample and considered exact-indicator hunting unlikely to find the broader activity. That sentence should change how a hunt is staffed: hash searches are the fast first pass, not the finish line.

For every appliance management address, build an egress history long enough to expose novelty. Group DNS, firewall, proxy, and flow data by the device, not merely by user subnet. Identify the destinations required for licensing, updates, time, vendor support, telemetry, and business function. Everything else needs an owner and an expiry. A new low-volume TLS connection from a VPN or virtualization appliance is not automatically malicious, but it should no longer disappear inside a policy that says “infrastructure may access the internet.”

The actor also used commercial VPNs, proxy providers, and evidence consistent with a purpose-built network of compromised small-office or home routers when reaching internet-facing services. Exit addresses change too quickly to support a durable allow-or-deny story. Mailbox and application investigations should therefore ask whether a session behaves like the person or service it represents: familiar client ID, expected source estate, usual geography, plausible user agent, ordinary target mailboxes, and normal working pattern. An address can be new for innocent reasons; a session that changes addresses while retaining the same unusual intent is harder to explain away.

3.2 The proxy was useful because the appliance already stood inside trust

A SOCKS proxy does not grant privileges by itself. It changes where the operator appears to be. From a compromised appliance, internal reconnaissance and administrative traffic can originate inside an allowed segment. If network policy lets that appliance reach broad internal ranges, the actor can test services, present stolen credentials, and operate web consoles through a source address that defenders associate with infrastructure.

Mandiant repeatedly saw the path continue toward VMware. In multiple cases, BRICKSTORM was placed on a network appliance before the actor moved to VMware systems. The actor entered vCenter with valid credentials that investigators assessed were likely captured by malware on the appliances. The wording matters operationally: “valid” explains why an authentication system may record a successful login with no exploit event, while “likely captured” tells responders to investigate every system through which administrators authenticated—not just the account's directory record.

One published VAMI pattern is almost prosaic. The source first requested GET / on port 5480. It then created a session with POST /rest/com/vmware/cis/session. Finally it changed SSH access using PUT /rest/appliance/access/ssh. Each request returned HTTP 200 in the example. No exotic packet was required. A valid administrative session used the product's own management interface to open a service that the operator could then reach directly.

That three-request sequence gives a hunt several joins. Preserve source IP, vCenter address, timestamp, user agent, referrer, authenticated principal, VAMI session, and the SSH service state before and after the request. Find the first subsequent SSH connection from that source or neighboring appliance address. Link it to sshd, PAM, sudo, command history where available, file creation, and persistence changes. If SSH was later disabled, retain the closing state change too. A short administrative window can contain the entire implant operation.

3.3 The adversary kept working after the defenders arrived

One detail in the report prevents a comforting interpretation of delayed beaconing. Mandiant recovered a BRICKSTORM sample that had been deployed on an internal vCenter server after the victim had already begun incident response. The operator was not merely a forgotten program waiting on an old schedule. Someone was watching the environment, recognized pressure, and moved persistence deeper into the management layer.

It also explains why an adversary might maintain more than one foothold. Mandiant described a typical arrangement in which at least one BRICKSTORM instance served as the main source of hands-on activity while two or more compromised appliances provided backup access. A clean image from one device may therefore show successful removal without showing successful eviction. The inventory must identify peer appliances, shared credentials, common management networks, and unexplained connections between them.

Across the reported case set, once the trail reaches vCenter, the problem is no longer “find one backdoor.” It is “identify every place where appliance access became administrative authority.” One published investigation found a web login path used by real administrators. There, the actor installed something that did not need a file-backed configuration change or an application restart to begin collecting credentials.

4 The actor stole the machine without waking it

On a vCenter server examined in one investigation, Mandiant found a malicious Java Servlet filter running inside the Apache Tomcat web application. Servlet filters normally inspect or transform HTTP requests as they pass through an application. This one, tracked as BRICKSTEAL, watched requests to the vCenter web login path /web/saml2/sso/*. When an HTTP Basic authentication header was present, the filter decoded it and could obtain the submitted username and password.

The installation method was as important as the target. Ordinarily, adding a filter requires changing configuration and restarting or reloading the application. The actor used a custom dropper that installed the malicious filter entirely in memory. There was no necessary configuration-file edit to catch and no restart event to announce the change. The credential collector lived in the process serving a legitimate authentication path and waited for administrators to bring valuable material to it.

Many organizations connect vCenter to Active Directory. The people who administer virtualization also tend to have meaningful privileges elsewhere. A captured credential could therefore become a bridge from the management plane to the rest of the enterprise—or back into vCenter after another foothold was removed. MFA can reduce the usefulness of a stolen password, particularly when vSphere authentication is designed so the password alone cannot create a fresh session, but response still has to examine existing sessions, tokens, service credentials, and every downstream system the account could reach.

4.1 vCenter turned one credential into authority over every sleeping guest

A virtualization administrator does not need to log on to a Windows guest to touch its most valuable state. The management layer can snapshot a disk, clone a VM, attach storage, change boot media, alter networking, or move workloads between hosts. Those abilities are essential for operations and recovery; in the wrong session, they are also a way around controls that assume the guest mediates access to its own data.

Mandiant saw the actor clone Windows Server VMs holding key functions in at least two cases: domain controllers, SSO identity providers, and secret vaults. With a clone available, an operator can mount the filesystem and extract files of interest. The public report names ntds.dit as an example for Active Directory. A credential vault presents a different task, and product protections still matter, but the underlying server should be treated as Tier 0 because operating-system or disk access can expose protected material, application keys, configuration, or paths to decryption.

There is a subtle investigative trap in the twenty-three-minute window. Teams may search for “power on” after “clone” and, finding none, downgrade the event. Here, never powering on the copy is the point. The useful sequence is clone requested, data transferred, clone completed, possible datastore or host access, and clone removed. If storage telemetry shows large reads or writes while the guest remains off, that is not contradictory evidence. It is the management plane doing the work.

4.2 Deleting the clone removed the object, not the obligation to respond

A destroyed clone leaves two kinds of uncertainty. First, the team may not know which data was read during the interval. Second, it may not know what credentials derived from that data were used later. Waiting for proof of each extracted secret can leave the actor holding durable access while responders debate an unknowable detail. The safer scope follows what the disks made reachable.

For a domain controller clone, assume that domain credential material and directory data may have been exposed, then design staged rotation appropriate to the organization's Active Directory recovery plan. That work is more involved than changing a single administrator password; service accounts, Kerberos keys, privileged groups, trusts, certificates, and systems that embed credentials can all create dependencies. For an identity provider, examine signing and encryption keys, federation configuration, administrative accounts, connectors, and issued sessions. For a secret-management server, include stored credentials, application encryption material, database access, backup keys, and accounts that retrieved secrets during the suspect period.

Rotation order matters. Changing a password while an active implant or stolen session remains able to capture the replacement gives the adversary a fresh credential. Preserve evidence, isolate the collection point, revoke sessions, remove unauthorized application grants, and restrict management access before or alongside rotation. Use clean administrative workstations and a trusted communications path. Record each changed secret, the system that depended on it, the time, the operator, and the post-change check that confirmed the old material no longer worked.

4.3 Across the case set, objectives included mail, source code, and the secrets between them

The reported missions continued beyond infrastructure. Across the investigations, the actor showed recurring interest in the mailboxes of key people. Some targets were developers and system administrators; others were involved in matters aligned with Chinese economic and espionage interests. Mandiant observed access through Microsoft Entra enterprise applications carrying Mail.Read or full_access_as_app, permissions capable of reading mail across many accounts instead of representing one mailbox user.

The actor also logged in to internal source-code systems with legitimate credentials and downloaded repositories as ZIP archives. In other cases it browsed specific remote files through Windows UNC paths. A SaaS or technology provider can hold downstream customer access, internal engineering knowledge, and code useful for finding future weaknesses. A legal organization can hold communications about national security, trade, negotiations, and clients. These public observations identify high-value objectives across the case set; they do not prove that the 03:37 clone supplied credentials for later mail, code, or UNC access. In a local case, a copied secret vault or domain controller creates an exposure hypothesis that must be tested against accounts, tokens, sessions, sources, and target-system audit records.

The public record supplies investigative joins, not one continuation of the sleeping-clone scene. The 03:37 excerpt proves a quiet control-plane copy; separate investigations document mail, code, UNC browsing, vault, and downstream interests. Responders should test whether local identity material connects those systems and state where the evidence stops. That is also why exact hashes and command domains are insufficient: tools can change while the relationships among assets, authority, sessions, and targets remain available to test, even after the malware file is removed.

5 When the malware had gone, its behavior outlived the hash

In several cases, responders did not find BRICKSTORM on the live compromised system. The actor had removed the sample. Mandiant recovered evidence by examining backup images and finding the malware in an earlier state. That discovery turns a routine recovery asset into a time machine: the live appliance shows what exists after cleanup; a protected backup can show the executable, startup edit, account, or configuration that existed while the operation was active.

It also complicates the first question an executive may ask after a scan: “Are we clean?” A positive file-level answer exists only when a candidate completes every implemented gate and emits MATCH:; an absence of MATCH: does not prove that every discovered candidate was read successfully. The scanner cannot tell whether a different build ran last month, whether the binary was deleted, whether a root-level intruder altered the live evidence, or whether the actor reached vCenter without leaving the particular sample behind. The answer has to name the work completed, not convert one negative into a universal verdict.

Mandiant released a shell scanner for environments where installing YARA on a network appliance is impractical. Upstream history first adds find_brickstorm.sh at commit 68e66ae3c1ee2d7c3775b430c2aa9d2c814d1f37 on September 24, 2025. SOSEC's earlier source review used commit 03103ea6b651827407336e1e8529ba5f6094b7f8, a later October 27 Photon OS xxd-compatibility revision—not the scanner's upstream origin. This review pins the repository's later state at fb2129cecd9561332608fbaac05884217c793a17. It includes a separate ESXi-oriented script, but both paths pursue the same published rule, G_APT_Backdoor_BRICKSTORM_3.

5.1 The scanner asks three questions, and every answer must be yes

The general Bash script does not discover every path under a directory. For each directory argument, find selects regular files smaller than 10M with -type f -size -10M and hard-codes four path-regex exclusions: /proc/.*, /tmp/[0-9]{10}/.*, /var(/crash)?/nsproflog/newproflog.*, and /var(/crash)?/log/notice.log. An explicit single-file argument bypasses that find-time size selection and the path-regex exclusions, enters the candidate list directly, and is passed to the same check_file() function. A directory-mode run with no MATCH: therefore describes only paths that passed those discovery filters and were delivered to check_file(); it does not establish that every delivered path was successfully read through every gate. A directly named file can be attempted even when it is not smaller than 10M, but bypassing discovery does not bypass the read, timeout, and tool-failure limits.

The general script's check_file() function first rejects files it cannot read. It then reads the beginning of the candidate and requires 7f45, the first two bytes of the ELF magic in the byte order produced by the command. A document, image, archive, script, or other non-ELF file stops there. This keeps later work focused on the executable format represented in the YARA rule.

Next, the function searches for every required token, accepting ASCII or UTF-16LE encodings. The set includes regex, mime, decompress, MIMEHeader, ResolveReference, and a long numeric value used by the rule. The checks are not votes. If one token is absent, the function returns without reporting a match. A file that merely contains several Go-library strings is not promoted on resemblance.

Only after those cheaper checks pass does the script transform the file into a continuous hexadecimal stream and apply a pattern derived from the YARA byte sequence. This is the most expensive step, so placing it last reduces unnecessary full-file processing. If the ELF test, all string tests, and the byte-pattern test succeed, the script writes MATCH: <path>. In the general script, discovery and progress messages go to stderr, while MATCH: records and end-of-run status summaries remain on stdout. The general script suppresses find errors, returns silently for unreadable or one-byte-read/timeout failures, and can treat header, string, or hexadecimal-tool failures like ordinary mismatches. Its final no-signature message is emitted whenever foundHits remains false, so it is not an audited completion status. The ESXi script likewise sends periodic progress to stderr but leaves its start, target, and completion messages on stdout. Operators should preserve both streams and identify hits explicitly by the MATCH: prefix.

5.2 The ESXi script traded conveniences, not investigative responsibility

The later find_brickstorm_esxi.sh exists because ESXi's shell environment does not offer the same tools and Bash behavior found on a general-purpose Linux host. It uses a more limited sh-compatible path and built-in-style utilities. At the reviewed commit, it scans regular files smaller than 50000k and excludes only full-path prefixes configured in EXCLUDE_DIRS; the pinned snapshot's default is the example entry /root/excludeme. The nearby comment presents /proc, /dev, and /sys as an illustrative exclusion pattern. An operator scanning / must explicitly configure any required pseudo-filesystem exclusions. The remaining candidates are then sent to the ELF, complete-string, and byte-pattern gates.

A run with no MATCH: is bounded by the exact starting paths, active EXCLUDE_DIRS, the <50000k selection, and any traversal, read, or required-tool failures. This ESXi path has no equivalent of the general script's one-second read/timeout gate, and its final Scan complete. is unconditional rather than proof that every discovered path completed every check. Record the starting paths, exclusions, script commit and hash, host and build, file-system or snapshot time, failures, both output streams, and output hashes. That turns “we ran the scanner” into a task another responder can repeat.

A matching file should trigger immediate preservation, static analysis, host scoping, and a search for related execution, persistence, network, and credential activity. It should not be deleted on sight before acquisition. Its timestamps can be false or altered, but they remain fields to compare with backup history, package manifests, startup scripts, account activity, and first-seen egress. A match is the moment the file joins the timeline, not the moment the timeline ends.

5.3 A run without MATCH sends the story backward into backups and outward into behavior

The repository's README says plainly that the script does not find every BRICKSTORM variant, assess whether a device is vulnerable, or inspect logs, processes, and persistence. It also warns that results from a live system may be affected by an attacker who has modified that system. Those are not defects in a focused scanner. They are directions for the next four searches.

First, repeat the file review across protected backups and snapshots that cover the suspected interval. Use the device identity and backup catalog to choose images before and after important account, egress, or vCenter events. Compare file inventories and hashes, startup paths, package manifests, crontabs, service definitions, configuration, SSH keys, authorized users, and unexpected executable locations. Mandiant reported persistence changes involving init.d, rc.local, and systemd, sometimes made with sed against legitimate startup scripts. A removed binary can leave the launcher or the changed line behind.

Second, inspect running state where the platform and response plan allow it. Process listings, open sockets, mapped executables, deleted-but-open files, loaded modules, parent-child relationships, and memory acquisition can expose an active implant that the fixed file rule misses. BRICKSTEAL reminds responders that meaningful malicious state may exist only in memory. Collection commands and tools should be approved and captured because they alter the system they inspect.

Third, search the device's behavior. A management interface establishing unexplained internet TLS, an appliance initiating SSH to vCenter, a source address appearing in Windows network logons, a local account created and removed within minutes, or a sensitive VM cloned outside change control remains important whether or not a binary survives. These actions connect to business roles. A scanner cannot know that the storage controller should never log on to an identity server; the asset inventory can.

Fourth, test exposure and configuration without confusing them with malware detection. Verify exact product builds, vendor advisories, management-interface reachability, authentication configuration, administrative accounts, installed extensions, support tunnels, and update integrity. Patch plausible entry points, but keep the incident timeline open until the surviving evidence shows where access did and did not travel.

At this point the hunt has many witnesses and no single omniscient one. The live appliance may be altered. The backup may be a day old. vCenter knows a task but not why it was requested. The firewall knows two addresses but not the credential. Entra knows an application session but not where its secret was stolen. The next job is to test which partial records can be joined without forcing any of them to say more than they observed.

6 Build a local timeline only from witnesses that can be joined

An incident timeline is often displayed as a sorted list of timestamps. For BRICKSTORM, sorting is only the beginning. The crucial work is joining: testing whether an appliance address in a firewall record belongs to the device that opened VAMI, whether that VAMI session enabled the SSH service used by a newly created account, whether the SSH session wrote a file or changed a startup script, and whether local evidence connects that authority to a sensitive-VM clone or mail access. The public report places these observations in the same campaign set; only local join keys can place them in the same incident sequence.

Start a case table with one row per observed action, not one row per theory. Keep source system, device-reported UTC time, ingestion time, actor or account, source and destination addresses, session or request ID, object ID, action, result, raw-record location, collector, and confidence in the clock. Add a separate link field that says why two rows belong together: same VAMI session, same vSphere task key, same VM moid, same SSH process, same client ID and session ID, same file hash, or a documented NAT translation.

6.1 A management IP can become a thread through four different systems

Return to the appliance management IP introduced when the inventory was built. In DNS and firewall data, it may identify the source of an unusual outbound connection. In VAMI access logs, it may appear as the client that requested a session and enabled SSH. In vCenter or ESXi authentication, it may be the origin of a local or directory account. In Windows Security or User Access Logging, it may appear as the source of an authenticated connection. The address is valuable because it can cross products, but only if assignment and translation are known for the relevant time.

For each address, preserve DHCP or static configuration, NAT rules, load balancers, proxy headers, cluster ownership, failover history, and time synchronization. A high-availability pair may move an address between nodes. A reverse proxy may replace the true client unless configured to retain it. IPv4-mapped IPv6 notation such as ::ffff:<address> can cause exact-string searches to miss an otherwise identical source. Normalize for search while keeping the raw form.

Then test whether the source behavior fits the appliance's job. A VPN concentrator may legitimately contact LDAP to validate a login, but it may have no reason to create an interactive SSH session on vCenter. A backup appliance may legitimately read datastores, but its named service account, schedule, host targets, and clone naming should match an approved workflow. Role-aware review reduces noise without granting blanket trust to infrastructure ranges.

The management IP can also expose backup footholds. If two appliances contact the same internal targets at different times, share an unexplained destination, use the same captured account, or alternate as the source of vCenter administration, map them as separate assets. Mandiant's description of one primary BRICKSTORM instance and multiple backup appliances means a source change may signal the actor failing over, not the start of an unrelated incident.

6.2 vSphere object IDs keep speaking after the clone name is gone

Within vSphere, search the longest retained VPXD interval for clone, snapshot, relocate, register, unregister, power, export, and destroy activity involving sensitive VMs. Mandiant noted that the actor often operated between 01:00 and 10:00 UTC, so that window can prioritize review. It cannot exclude activity at other hours. Compare every candidate with approved backup, disaster-recovery, migration, testing, and administrative schedules.

Collect the vCenter instance UUID, datacenter, cluster, ESXi host identity, datastore identity, VM moid, instance UUID, task key, event key, principal, session, source object, target object, destination folder, power state, and result. Where a raw event redacts or omits one field, use the task/event chain and inventory history to recover it. A destroy event that references the same task or object lineage as an earlier clone is stronger than a search for names containing “clone.”

Cross-check hostd and vpxa records on the involved ESXi hosts, datastore browser and storage audit data, file timestamps and sizes, network telemetry between hosts and storage, and backup-platform jobs. The five published VPXD lines tell us the control plane believed the copy completed; surrounding systems can show where bytes traveled and whether the operation resembled the organization's normal automation. Preserve raw exports before vCenter retention or log rotation removes them.

Next, search SSO and appliance audit data for the authority around the task. Mandiant published another example in which the local Administrator created a new vCenter user, added it to Administrators and SystemConfiguration.BashShellAdministrators, used it over SSH from a compromised system, obtained a root session, created BRICKSTORM, removed the user from the group, and deleted the account—all within minutes. A current-account inventory will miss that user. Creation, role assignment, login, privilege elevation, file creation, group removal, and deletion must be retained as separate events.

A useful way to read that chain is as four witnesses answering four different questions. Standard vCenter application events such as VmClonedEvent or HostSshEnabledEvent say what the control plane accepted. SSO audit records say which principal received or exercised authority; principal-management activity deserves particular attention when a local identity appears and disappears quickly. Linux audit records then describe how authority reached the operating system: keys such as execpriv, useradd, privileged, and perm_mod can preserve the original audit user even after a process crosses sudo. A file-integrity record, compared with a clean baseline kept away from vCenter, shows what state changed after that session. None is a complete account alone. Together they turn “Administrator did something” into a principal, a session, a privileged process, and a changed object.

Shell history is too fragile to carry this burden. On the VCSA, /root/.bash_history may not be written until logout, and a shell can suppress, clear, or bypass it. Standard forwarding also does not automatically make that file an off-box record. Treat a useful history entry as a lead, never as proof that commands absent from the file did not run. Kernel audit and service records need an explicit bridge—such as a tested audit dispatcher or rsyslog route—to storage the compromised appliance cannot rewrite. Acceptance must exercise local buffering, queue backlog, interrupted-link recovery, and confirmed remote persistence; a server address in a configuration file does not prove that the evidence arrived.

Time is the last join key, and it fails quietly. NTP health for VCSA, ESXi, administrative workstations, network devices, identity services, and collectors belongs in the case record. Keep both device time and ingestion time. A two-minute skew can invert the apparent order of account creation and login; a collector backlog can make a response-time event look earlier than the intrusion that provoked it. Correct on a derived investigation timeline, but never overwrite the timestamp in the raw event.

6.3 Identity and mail records test where suspected authority was used

Infrastructure events show reach; identity events show how that reach was exercised. For every vCenter, appliance, vault, repository, Windows, and cloud account in the path, assemble successful and failed authentication, source, target, authentication method, MFA result, session, token or application ID, role changes, credential changes, and administrative actions. Mark where the record is absent because it expired or was never collected. Missing data should stay visible on the timeline and must never be silently converted into “no activity.”

Windows User Access Logging can sometimes retain attempted authenticated use of server roles longer than ordinary event logs. Security and Terminal Services logs, EDR telemetry, file-server auditing, and UAL each describe a different layer. A UAL record sourced from an appliance does not prove which command ran, but it can place an account, source, destination, and role in the same interval. Shellbags may preserve folders browsed through Explorer, including UNC paths and credential-related locations. Treat parser output as a lead back to the acquired artifact and user context.

For Microsoft 365, enumerate applications that can read mail broadly and search audit data by client ID. MailItemsAccessed records, when available under the tenant's audit and retention configuration, can include mailbox user, client address, client information, session ID, and access type. Group activity by application and session before judging individual IPs. Commercial VPN and compromised-router exits can move; an unusual session repeatedly focusing on developers, administrators, legal matters, or a narrow set of executives across several days is more informative than one unfamiliar address.

Build the mail view from the inside out. Begin with the application or service principal and its granted permissions, then split records by session, mailbox, access pattern, and time. A single synchronization event can summarize many items, while bind-style access may produce a different shape; counting rows without reading the access type can exaggerate one session and hide another. Compare the client ID and session with token issuance, consent and credential changes, known automation, source-address history, and the appliance timeline. If the same application begins reading a new cluster of mailboxes shortly after a credential-bearing VM was cloned, the timing deserves investigation even when every individual authentication succeeded; it becomes a relationship only if local account, token, session, source, or target records join the events.

Apply the same method to code platforms. Begin by describing what a normal automation identity reads in a day, which repositories it reaches, which network supplies the requests, which token class it uses, and whether a build job accompanies the activity. Then identify what changed. A legitimate account that arrives from an appliance segment, calls an archive endpoint, enumerates an organization, downloads unrelated repositories in sequence, and then changes a deploy key may produce individually valid requests while forming an abnormal session. Preserve HTTP request IDs, token identifiers, repositories, object and byte counts, source, and the corresponding change ticket so a temporary release can be distinguished from directed collection.

The same discipline prevents collection goals from being collapsed into one imagined victim. One reported intrusion may reveal repository downloads, another mailbox access, and another UNC-path browsing. Preserve which source supports each observation. In the local case, the analyst's job is to ask whether the stolen authority could reach those systems and then look for records that answer it—not to paste every public objective into an empty hour on the timeline.

By the end of this reconstruction, the team should be able to narrate each confirmed handoff in one sentence backed by original records: this appliance address opened this VAMI session; this principal enabled SSH; this process and account created this file; this vSphere task copied this object to this datastore; this application session read these mailboxes. Where a handoff cannot be proven, say what is missing and contain the reachable risk anyway. The purpose of the timeline is not literary certainty. It is to decide what must be preserved, isolated, rotated, rebuilt, and watched next.

7 Eviction has to last longer than the intrusion

A team that has followed the trail this far faces an uncomfortable problem: the systems needed to remove the actor are the same systems whose trust has been called into question. The appliance may hold altered evidence. vCenter may contain an in-memory credential collector. Administrative passwords may already be known. Backups may include both the last clean state and the implant. A hurried rebuild can destroy the timeline; a leisurely investigation can give the operator time to move again.

Use a clean coordination channel and trusted administrative devices. Limit knowledge of precise containment timing to people who need it. If the actor has been monitoring internal mail, tickets, or vCenter, ordinary response communications may reveal the plan. That is not a reason for secrecy theater; it is a reason to assume that systems already named in the case should not carry the only copy of the response plan.

1. Freeze the disappearing record. Export volatile state, management events, identity logs, network telemetry, and the backup points that bracket first-seen activity before routine rotation changes them.
2. Narrow the routes while they are observable. Restrict appliance, vCenter, ESXi, and administrative paths in measured changes; retain each rule revision and watch denied retries for a fallback foothold.
3. Move the response onto a clean path. Use a verified privileged workstation and independent communications before introducing any replacement password, key, certificate, or token.
4. Invalidate authority in dependency order. Revoke sessions and rotate the identities, application grants, vault secrets, and directory material reachable from the appliance and copied disks.
5. Rebuild trust, not just services. Recover from verified media, restore reviewed configuration, establish off-box logging and restricted management first, then reconnect business dependencies.
6. Make the rebuilt system prove itself. Exercise a controlled clone, SSH state change, mailbox session, and appliance egress event; recovery closes only when each action reaches protected monitoring with its join keys intact.

7.1 Preserve the disappearing evidence while closing the actor's routes

Before changing a suspected appliance, capture its exact product, build, serial or stable identity, management addresses, uptime, clock, interfaces, routes, connections, processes, mounts, users, keys, services, startup configuration, package state, file metadata, logs, and configuration using vendor-supported or forensically approved methods. Acquire volatile memory where the platform, expertise, and operational risk permit it. Export upstream DNS, firewall, proxy, flow, authentication, and management records before their own retention windows rotate.

Protect relevant backups immediately. Record snapshot times, chain relationships, storage locations, integrity information, access logs, and who can delete or expire them. Prevent routine retention from removing the images that bracket first-seen egress, account creation, vCenter access, or clone activity. Copy the most important artifacts to case storage with independent credentials. A backup that the compromised appliance can rewrite is not yet a trustworthy witness.

Select backup points as a sequence, not a single “last known good” image. Keep one before the earliest suspicious network activity, one around each major identity or management event, one after the five-line clone sequence, and the state first acquired by responders. Record the parent chain and whether a synthetic full, deduplication, or later merge changed the physical blocks. Hash exported files and manifests, retain restore logs, and test a copy in an isolated workspace. If an old image produces a scanner match while the live appliance does not, preserve both results: the difference may explain deletion, but it can also reflect a changed build or an incomplete acquisition.

For vCenter and ESXi, export VPXD, VAMI, SSO audit, sshd, PAM, sudo, hostd, vpxa, task, event, inventory, role, account, extension, certificate, and datastore records. Capture process and application state before restarting services if BRICKSTEAL or another memory-resident component is plausible. Record current SSH state, lockdown mode, execInstalledOnly, log forwarding, identity sources, local users, group membership, and every principal with administrative authority.

At the same time, reduce reach in changes small enough to observe. Restrict appliance management addresses to required internal targets and vendor destinations. Block unexpected appliance-to-vCenter, appliance-to-Windows, and broad east-west administration. Constrain vCenter and ESXi management to dedicated, monitored administrator paths. Disable unneeded internet egress from management planes. Preserve firewall before-and-after state and watch denied connections; a newly blocked BRICKSTORM instance may reveal itself by attempting the route it previously used.

Revoke suspect cloud and management sessions, tokens, application credentials, SSH keys, support tunnels, and temporary local accounts. If a session cannot be safely revoked before acquisition, increase monitoring and shorten the delay. Do not let an in-memory filter or compromised appliance observe replacement passwords. Move credential changes to a known-clean path, then verify that old sessions and credentials fail from both expected and previously suspicious sources.

7.2 Rotation and rebuild follow what the clone could reach

Build the rotation list from the evidence graph. Start with accounts used on the compromised appliance and vSphere, then include administrators who authenticated through suspect login paths, credentials stored in scripts or vaults the actor accessed, secrets on cloned disks, certificates and keys held by identity systems, application credentials with broad mail or repository access, and service accounts reachable from those systems. Mark dependencies and safe order before changing them so recovery does not create an outage that forces teams to restore an untrusted backup.

Highly privileged directory material may require a staged domain-recovery procedure, not an improvised password reset. Coordinate changes to Kerberos keys, privileged identities, service accounts, trusts, certificate services, federation, break-glass accounts, and stored credentials. Revoke tokens and sessions after key changes where the platform requires it. For secret-management systems, rotate both stored secrets and the keys or accounts that protect and retrieve them. For Entra applications, remove unexplained grants, replace secrets or certificates, review owners and consent, and confirm that old credentials no longer produce audit activity.

Perform that work from a privileged access workstation reached through a known-clean administrative path. Where the platform permits it, let PAM inject a short-lived credential so an administrator does not type the replacement secret into a browser or shell that may still carry a credential collector. Separate the daily vSphere identity from the emergency vsphere.local superuser, constrain membership in BashShellAdministrators, and require an independently logged reason to open the emergency path. Before rotation begins, verify that the vault, jump host, browser, support tunnel, and vCenter login path chosen for the operation are not among the systems whose integrity is still unresolved.

The clone also changes how Tier 0 virtual machines should be protected. Encrypting their disks can reduce what a datastore copy yields, but only when the key-management authority is separate from the compromised virtualization authority and recovery has been tested. Require encryption for vMotion where the design supports it. Remove Clone, Export, snapshot, and datastore-browse privileges from routine roles that do not need them; place exceptional use behind approval, a named ticket, a narrow time window, and post-action review. These controls do not erase the need to monitor a legitimate administrator, but they make a silent offline copy harder to perform with ordinary credentials.

Rebuild compromised appliances and management servers from verified vendor media or a state whose integrity can be established. Merely deleting the matching binary leaves startup edits, web shells, in-memory modifications, local accounts, SSH keys, altered packages, and backup footholds unanswered. Validate firmware or image provenance, apply current fixes, restore only reviewed configuration, and compare the result with an approved baseline. If vendor architecture does not support meaningful forensic acquisition or trusted rebuild, document the limitation and use segmentation, replacement, and increased external telemetry as compensating controls.

Bring systems back in an order that prevents immediate recapture. Establish restricted management networks and centralized logging first. Then introduce clean identities and MFA, restore reviewed configurations, enable file and configuration monitoring, validate egress, and reconnect necessary internal services. Only afterward should ordinary administrative use resume. Watch the old management IPs, destinations, account names, client IDs, and vSphere objects for attempted reuse.

Search for the backup footholds Mandiant's cases teach us to expect. Re-scan peer appliances and historical images, examine devices sharing credentials or management segments, and look for alternating egress or administrative sources. Review vCenter, ESXi, identity, vault, mail, code, and legal or executive targets for activity after the first known compromise and after response began. The later vCenter deployment reported by Mandiant means a “new” artifact during response can be the actor's reaction, not evidence that the original timeline was wrong.

8 The next 03:37 should not be silent

The five VPXD lines at the beginning were never truly silent. vCenter recorded the actor, the task, the source, the destination, completion, destruction, and removal. The silence was organizational: the event could pass as routine, the guest emitted no endpoint alert, the clone vanished from inventory, and the systems surrounding it did not necessarily share one investigation key or one retention horizon.

That is the hopeful part of this campaign. BRICKSTORM was built to live where endpoint security had little reach, but the operation still depended on relationships defenders can own. Across the public case set, investigators observed appliance egress, valid credentials entering management consoles, SSH state changes, role grants, file writes, virtual-disk movement, and application mail access; the report does not establish all of them as one victim's sequence. In a local case, each action may look ordinary in isolation. Shared assets, principals, sessions, sources, object IDs, time, and change records are what can turn selected observations into an evidenced chain.

8.1 Turn the investigation into controls that can be tested

Start with ownership. Every appliance and management plane needs a named technical owner, security owner, exact build, lifecycle state, management address, required egress and internal reach, credential stores, backup location, log destination, and review date. New or evaluation devices enter that inventory before receiving production connectivity. Devices that cannot support an agent receive explicit external monitoring, so the endpoint count no longer makes them invisible.

Make management traffic narrow and legible. Internet-facing appliances should not receive unrestricted internal reach. Management interfaces should not initiate arbitrary connections simply because they live on an infrastructure subnet. vCenter and ESXi administration should come through dedicated, strongly authenticated paths. Enforce phishing-resistant MFA where supported, apply vSphere lockdown controls appropriate to operations, consider execInstalledOnly, restrict SSH, and forward logs to storage outside the management plane.

Alert on changes of authority and on sensitive actions, then attach business context. A local user created, granted Bash shell administration, used over SSH, and deleted within minutes deserves a single correlated case. So does a sensitive VM cloned, never powered on, and removed without a matching ticket. An enterprise application granted broad mail access needs an owner, expected source, credential expiry, and mailbox purpose. A first-seen external destination from an appliance management IP needs a vendor or business explanation.

Exercise the evidence, not just the alerts. In a controlled test, clone a non-sensitive VM through the approved workflow and verify that VPXD, host, storage, identity, and change records can be joined by task and object identity. Toggle SSH on a test management appliance and confirm the source, actor, session, state transition, and subsequent connection are retained. Use a test application to access a test mailbox and confirm client ID, session, source, and mailbox activity are searchable. Restore an appliance backup and reproduce a fixed scanner run with recorded scope and output hashes.

Treat the logging system itself as Tier 0. The team administering vCenter should not be the only team able to alter its evidence, and one credential should not control the platform, collector, and archive deletion. Monitor collection health alongside event content: last received time by source, expected volume, parser failure, clock drift, queue depth, disk use, and retention consumption. After every upgrade, certificate replacement, or collection-rule change, run a small end-to-end test. A suddenly quiet management plane is reassuring only when the collector still has a heartbeat.

8.2 Keep enough memory to recognize the second visit

Long retention does not require every raw event to remain forever on the most expensive storage tier. Keep replayable high-detail records for the first several weeks, then retain daily compact indexes that still point to the original interval: destinations contacted by an appliance, principals that gained roles, clone or export tasks against sensitive VMs, mailbox categories read by each client ID, and file paths and hashes present in each backup point. Regularly sample a path from index to raw archive to backup and restore it. After 393 days, the record is useful only if an analyst can find the summary, retrieve the source, and verify its integrity.

Review those histories when the environment changes, not only after an alert. A firmware upgrade, vCenter migration, identity redesign, new SaaS integration, or vendor support engagement can introduce new addresses and credentials. Capture the approved change so later novelty has an explanation. After an incident, continue watching old routes, accounts, destinations, certificates, client IDs, and management objects long enough to catch delayed beaconing or a fallback implant.

Finally, preserve uncertainty as work with an owner. If initial-access logs expired, record the missing period and the controls used to cover plausible routes. If an appliance could not be imaged, record which external sources compensate. If a cloned secret system made some credentials impossible to enumerate, record the recovery assumption and the staged rotations used to invalidate them. An empty field silently becomes reassurance; a named gap remains something the organization can reduce.

At 03:37, the actor in the published case relied on a simple asymmetry: vCenter could see the clone, but the defenders watching the guest could not. The way out is not a more dramatic alert. It is to make the management plane, appliances, identity systems, storage, and cloud audit retain their own events long enough for evidence-backed joins to be recognized. Then a short-lived clone cannot take the story with it when it disappears at 04:05.