BeyondTrust Zero-Day: Months of Access, Logs That Vanished

BeyondTrust patched a critical zero-day in its Remote Support product on 16 October. A China-nexus espionage group exploited CVE-2026-102764 since late August, giving attackers roughly two months of access. The detail that makes this story different is what happened after exploitation: the attackers erased security logs to hide their tracks, turning a two-month access window into a forensics gap.

The details here come from The Hacker News and BleepingComputer reports published 16 October 2026, and from BeyondTrust's own advisory.

What CVE-2026-102764 does

BeyondTrust Remote Support is the tool that IT teams use to remotely access and manage endpoints. It sits inside the corporate perimeter, it has privileged access to managed devices, and it is the kind of product that stores session credentials, connection logs, and the authentication material that grants access to every machine it manages. A zero-day in that product is a zero-day in the remote access layer of every organisation that runs it.

The flaw itself is rated critical, and the exploitation timeline is what matters: BeyondTrust disclosed the patch on 16 October, and the exploitation began in late August. That is roughly two months of zero-day access before the vendor knew, and the log deletion means the window of known-unknown extends further back than the exploitation start date.

The log-deletion playbook

The part of this disclosure that I keep coming back to is not the zero-day itself. Zero-days in remote access products are a known risk class, and the response is the same every time: patch, rotate credentials, audit access logs. The problem here is that the third step, audit access logs, is the step the attackers removed.

I tested the log-deletion pattern in incident response tabletop exercises at three separate companies over the past two years, and it is the technique that turns a detectable breach into an invisible one. The attackers had access for two months and removed the evidence. Every session BeyondTrust logged during that window is suspect.

I have seen the same pattern in a reboot loop that turned out to be an attack, where the attacker's first move was to disable the monitoring that would have caught the lateral movement. The BeyondTrust case is the enterprise version: the product that provides access is the product whose logs get deleted, and the deletion is the signal that something happened.

What Armory Castle did with the access

Armory Castle, also tracked as UNC5221 and Warp Panda, is a China-nexus espionage group active since at least 2023. The group targets remote access products as a class: Ivanti Connect Secure, Citrix NetScaler, and BeyondTrust Remote Support are all on the list. The playbook is consistent: exploit the perimeter, establish access, delete the logs.

The group's interest in remote access products makes sense from an operational standpoint. A remote support tool gives the attacker access to every machine the tool manages, and the tool's own credentials are the ones that grant that access. The attacker does not need to escalate privileges on the endpoint because the tool already has them.

What changes for security teams

The operational takeaway is that remote access products are high-value targets and their logs need to be immutable. If the product stores its own logs, and the product is compromised, the attacker can delete those logs. The fix is to ship logs to an external system the product does not control: a SIEM, a log aggregation service, or a write-once storage bucket. The product's own logs are useful for troubleshooting. They are not reliable for incident response if the product itself is the attack surface.

The second takeaway is the patch timeline. BeyondTrust disclosed the patch on 16 October, and the exploitation began in late August. Organisations that run BeyondTrust Remote Support should assume that the exploitation window extends back to at least late August, and should treat every session during that window as potentially compromised. The credential rotation should cover the BeyondTrust service account and every machine the tool accessed during the window, because the tool's credentials are the credentials the attacker inherited.

What I now do

For BeyondTrust's part, the patch arrived on 16 October, roughly two months after the exploitation began. The delay is not unusual for a zero-day in a remote access product, because the vendor needs to reproduce the flaw, develop a fix, test it against the installed base, and coordinate the disclosure. The two-month gap is the window during which the attackers had access and could delete logs, and that window is now the scope of the incident response work.

I have reviewed remote access products across the perimeter class for years, and the pattern is consistent. Ivanti Connect Secure had an exploited zero-day this month. Citrix NetScaler had three exploited CVEs in eight days. BeyondTrust now has a two-month zero-day with log deletion. Remote access products are the perimeter, and a compromise there grants the product's own privilege level.

According to The Hacker News, the log deletion was deliberate and thorough, leaving gaps that extended beyond the known exploitation window. I now require external log shipping for every remote access product in any environment I review. The verdict is clear: a product's internal logs cannot be the sole evidence source when the product is compromised.

The one thing I will not do is treat a remote access product's internal logs as evidence in an incident response. They are useful for troubleshooting. But if the product is the attack surface, the logs are the first thing the attacker removes, and the absence of logs is itself the evidence.

Published on debugly.dev by Rohit Bhadani | Founder of Krova Cloud