How to Audit Remote Support Logs for Role Escalation

To audit remote support logs after a suspected compromise, pull every log source that lives off the appliance, then review role changes, new accounts, admin logins, unusual request paths, log gaps and file transfers for the whole exposure window. Attackers who reach root on the appliance can delete its local logs, so your remote support audit logs in the SIEM, reverse proxy and firewall are the record that counts.

This guide uses BeyondTrust Remote Support event names, taken from Google Threat Intelligence Group's guidance after CVE-2026-102764 was exploited by ARMORY CASTLE. Other products have equivalent events under different names.

What logs do you need for a remote support audit?

You need the appliance's forwarded syslog, logs from any reverse proxy or WAF in front of it, perimeter firewall logs and the session and user reports the product can export. Collect all of them for the full window, from the earliest possible exploitation date to the day you patched.

For CVE-2026-102764, that window starts on 29 August 2026, the first exploitation date Mandiant confirmed. Write the window down before you start. Every query below uses it.

If the appliance was not forwarding syslog, export what the admin console still shows, but treat it as incomplete. An attacker with host access may have edited or removed it.

Step 1: Preserve before you query

If you suspect the appliance is compromised, preserve evidence first. GTIG recommends snapshotting virtual appliances with memory and exporting the disks, and requesting forensic preservation through the vendor for hardware or SaaS. Block inbound traffic at the perimeter rather than inside the appliance's own settings, so the configuration stays intact for review. Disable sessions, Jump Clients and API accounts instead of deleting them; deletion destroys audit trail.

Step 2: Review role and policy changes

Role escalation is the clearest sign of hands-on activity. In the BeyondTrust intrusion, the operators raised a local account's Jump Item and Team roles from "No Access" to "Administrator" to get standing access to downstream systems.

Search forwarded syslog for:

• user_changed events that raise a Jump Item role or Team role, especially jumps straight to Administrator
• user_added events with no matching change ticket
• api_account events that create or modify API accounts
• security_provider events that change directory or SAML configuration
• changes to outbound event destinations or syslog targets, which can silently redirect or cut your visibility

For each hit, match it to a ticket or a named administrator. Anything you cannot explain goes on the suspect list, along with the account that made the change.

Step 3: Review admin logins

Pull every successful /login administrator session in the window. Flag:

• logins from residential broadband or commercial VPN address space
• logins outside your team's working hours
• logins by accounts that rarely sign in, including the built-in Admin account

Also check for new MFA registrations on privileged accounts. A fresh authenticator added during the window can keep an attacker in after a password reset.

Step 4: Review request paths at the proxy or WAF

A web shell or tunnel shows up as traffic that does not match the product's normal URL set. At the reverse proxy or WAF, list requests in the window to:

• .php paths that are not part of the product
• WebSocket upgrades from sources that are not your technicians or Jump Clients
• known indicator paths; for this campaign GTIG published the WebSocket path /uidchanarge

If you do not have a proxy or WAF with full URI logging in front of the appliance, add one. GTIG lists it as a compensating control, and without it this step is guesswork.

Step 5: Look for gaps in forwarded logs

Plot syslog volume from the appliance by hour across the window. A sudden stop that starts and ends within a single admin session is a strong sign of tampering. Normal maintenance gaps line up with change tickets or reboots; tampering gaps do not.

Step 6: Review sessions and file transfers

Export support session reports and file transfer records for the window. Prioritize:

• sessions started by any account flagged in steps 2 and 3
• file transfers outbound from endpoints, especially documents, inventories or configuration exports
• sessions to servers or admin workstations rather than end-user laptops

Every endpoint those sessions touched is now in scope for its own investigation. Hand that list to whoever owns endpoint detection.

How do you know when the audit is done?

The audit is done when every role change, new account, admin login and file transfer in the window is either tied to a legitimate change or escalated. A clean result reduces risk but does not prove the appliance host is clean, because host-level persistence can exist without leaving traces in application logs.

What should you do if you find evidence of compromise?

Rebuild the appliance from a clean, patched image and rotate every credential it stored or brokered, in that order. Open a support case with the vendor so it can check for indicators you cannot see from the console.

The order matters more than most teams expect, and we cover the reasoning in why you rotate credentials only after the rebuild. For background on what the appliance holds and why it is such a valuable target, read what a remote support appliance can reach in your network. The same approach works for VPN appliances; see how to hunt VPN logs for sessions that never entered a password.

Make the next audit easier

Most of this work is hard only because the logs were not there. Forward appliance syslog to a SIEM over TLS with multi-month retention, put a logging proxy in front of the portals, and schedule regular exports of session, team activity and user audit reports. Then build alerts for the role and account events in step 2, so a change from "No Access" to "Administrator" pages someone the day it happens.