Session Auditing on a Remote-Support Appliance: What Survives a Rebuild

Remote-support sessions are recorded, in most deployments, for a reason that has nothing to do with security: someone wants to prove what was changed during a maintenance call. The BeyondTrust case turns that recording into an investigative asset, and raises the question of what survives when the appliance is rebuilt.
Mandiant's reporting describes ARMORY CASTLE using a compromised appliance to move through a network, and recommends redeploying Jump Clients, Jumpoints and the representative console from a patched or rebuilt appliance to invalidate existing tokens. The rebuild resets trust. It does not, by itself, produce a record of what happened before it.

Where the evidence lives

Appliance-local logs sit on an encrypted partition and are not centralised unless forwarding was configured. CISA's alert points to appliance syslog and session events as the material to forward to the SIEM immediately, alongside web application firewall, reverse proxy and perimeter firewall logs for the exposure window.
Session events answer a different question from network logs. Network logs show that a session existed. Session events show who initiated it, which account was used, and what was targeted. When the actor's advantage is a brokered credential, the session record is often the only place the credential's use is visible as a discrete event rather than as background authentication noise.

The audit properties worth configuring before the next event

Three properties make session records usable later: they leave the appliance, they are time-synchronised with the rest of the estate, and they are retained past the appliance's own lifecycle. The first is a forwarding decision. The second is an NTP decision, and it matters because correlating an appliance event with a firewall record requires a common clock. The third is a retention decision that usually belongs to the SIEM, not the appliance.
A fourth property is harder to buy: the record needs an owner who will read it during an incident. CISA lists unrecognised privileged and administrative sessions as a hunt artefact, which means someone has to compare a session list against an expected baseline. Without a baseline, the list is unreadable.

Reading a session record during an incident

The comparison that matters is between sessions and authorised work. A session opened outside a change window, from an unexpected source address, or against a host the helpdesk does not support is a question worth answering. The absence of a session during a period when one was expected is equally worth answering, since a gap in the record can indicate adjusted logging rather than inactivity.

Retaining what a rebuild destroys

The practical recommendation is unromantic. Forward session events to a system that survives the appliance, verify the forwarding works during a quiet week rather than an incident, and keep the retention window long enough to cover the interval between an intrusion and its discovery. In this case that interval was measured in weeks, and Mandiant warns that additional organisations may have been compromised before disclosure.