DEV Community

facilishz
facilishz

Posted on

When the Logs Are Gone: Detecting a Remote-Support Intrusion From Outside

#zoomeye #detection #beyondtrust #telemetry

When the Logs Are Gone: Detecting a Remote-Support Intrusion From Outside

One line in Mandiant's report on the BeyondTrust intrusion deserves more attention than it usually gets: the actor systematically deleted system, web server and application-level logs. Whatever evidence the appliance held about the intrusion was removed by the people who knew where it lived.
That single fact rearranges the detection conversation. For an appliance compromised through CVE-2026-102764, the native audit trail is not merely incomplete. It was the target of a deliberate step in the attack.

What the actor removed, and what survived

The published account lists several clean-up actions, not one. Logs were wiped. The injector binary unlinked itself after running. The configuration change that granted passwordless root to the site service account was made through existing templates, so it looked like configuration rather than an intrusion artefact.
The actions that leave traces are the ones that touch other systems. Jump Items raised to Administrator produce session activity downstream. The Bareclaw tunneler moves traffic through the appliance. Outbound denials, if a firewall is logging them, record what the appliance tried to reach. None of that evidence lives on the appliance, which is precisely why it matters.

What external measurement adds

Internet-wide scanning does not detect compromises, and treating it as detection is a category error. What it can do is bound the population that needs investigating and show whether an organisation's own estate is part of that population.
ZoomEye queries for BeyondTrust-branded interfaces on 2026-10-23 returned the following counts.
| Query executed 2026-10-23 (UTC) | Matching assets |
| --- | ---: |
| title="BeyondTrust" | 966 |
| title="BeyondTrust" && is_domain=true | 584 |
| app="BeyondTrust Privileged Remote Access" | 226 |
| title="BeyondTrust" && port="443" | 269 |
| title="BeyondTrust" && port="80" | 203 |
A branded title search is a blunt instrument, and here it is blunt for a defensible reason: the product-specific fingerprints are thin. The app fingerprint for Privileged Remote Access returns 226, while the equivalent for Remote Support returns nothing in this dataset. Searching only the precise product name finds three assets globally, which would be a dangerously reassuring number for anyone with a fleet of them.
The counts describe reachability of a branded interface. They say nothing about whether any given appliance was compromised, and they cannot be used to reconstruct what happened on one.

Building a detection story from the perimeter inward

When the host's own logs are unreliable, the useful sequence starts at the firewall and works inward.

  1. Recover and preserve firewall and proxy logs for the exploitation window before anything is rebuilt. Google's guidance is explicit about preserving telemetry.
  2. Check for inbound sessions to the appliance's public address that were not preceded by a change ticket or a support case.
  3. Check outbound traffic from the appliance to anything other than vendor update and licensing endpoints.
  4. Review support-session records for sessions opened from the appliance to downstream hosts, particularly sessions launched by accounts whose Jump Item permissions were recently elevated.
  5. Compare configuration templates and account permissions against a known-good baseline, since persistence here was achieved by configuration rather than by a dropped file. The fifth step is the one that catches this actor. Mandiant describes persistence through configuration templates and permissions, both of which survive a reboot and a configuration reset. A rebuild from a clean image removes them; a reboot does not.

Where scanning helps an investigation

Three uses are defensible. First, finding appliances nobody remembers deploying, which is common in organisations where a regional team bought one and left. Second, confirming that a host was reachable from the public internet at all, which decides whether the exploitation window applies. Third, checking after remediation that the interface is no longer exposed in the way it was.
Three uses are not. Scanning cannot tell you an appliance is compromised. It cannot tell you which version is running reliably enough to substitute for logging into the device. And it cannot substitute for the vendor's advisory when deciding whether a given build is affected.

The uncomfortable conclusion

For this class of appliance, detection depends on infrastructure that lives outside the appliance: firewalls, proxies, identity providers and downstream session logs. Organisations that treat the security appliance as self-monitoring have, in this incident, lost the evidence that would have answered the question. Building those external logs into the response plan is cheaper than discovering their absence during the investigation.

References

Top comments (0)