top of page

Hunt BeyondTrust CVE-2026-102764: Logs Off the Box

Writer: Inception Security
Inception Security
10 hours ago
12 min read

A help desk technician starts a remote session to fix a laptop, and the tool does its job. Behind that session sits one appliance that holds the access for everything the help desk can reach. Mandiant says root on it gives an attacker access to every credential the appliance stores or brokers, and both Mandiant and BeyondTrust say this actor deleted logs. The box is the last place to ask what happened.


BeyondTrust published advisory BT26-05 on 15 October 2026 for CVE-2026-102764, a Critical flaw in Remote Support. Mandiant says it found evidence during an incident response engagement that a suspected PRC-nexus actor, which it now calls ARMORY CASTLE, exploited the bug as a zero-day in late August 2026.


Why this one is different


BeyondTrust is withholding the technical details of the bug while self-hosted appliances are patched, so there is no request pattern to match. Mandiant published a few indicators from one intrusion, but BeyondTrust says the actor rotates infrastructure and tooling for every victim, so those rarely survive to the next. That leaves the actor's behavior as the thing to hunt.


The evidence worth trusting sits off the appliance. Mandiant found its evidence in logs reachable only through an encrypted partition on the box, and Mandiant says the actor deleted many on-box logs. So the hunt starts in the syslog collector, the reverse proxy or WAF, the perimeter firewall, and the endpoints the appliance can reach. Treat any hit as a lead to investigate, because none of these hunts can prove this CVE was used.


This is the second edge appliance in two days where root access can erase the evidence on the box. Our post on Cisco Secure Email Gateway CVE-2026-76519 covers the other.


BeyondTrust adds one lesson from the instance it hosted: its sensors fired when the actor escalated privileges, and an automated triage tool in its third-party detection platform closed those alerts as false positives. BeyondTrust says it is working with the vendor so automated triage tools cannot close high-severity signals on their own. That is one vendor and one instance. Even so, BeyondTrust advises keeping the alerts a triage tool closes in scope for your hunts.


Which appliances were exposed


BeyondTrust and NVD both list Remote Support, all versions up to 26.2.3. Mandiant says an unauthenticated remote attacker can perform file operations on the appliance.


BeyondTrust says it shipped the patch on 8 October and that all Remote Support SaaS customers were patched by 9 October. Self-hosted customers on 24.3.1 through 26.2.3 should apply the BT26-05-RS patch unless automatic updates have already installed it. Older versions must upgrade first.


Do not treat Privileged Remote Access as cleared. BeyondTrust says its internal testing has not found a way to exploit the bug in PRA, but PRA shares the affected code, so it released the patch there too and recommends self-hosted PRA customers apply it immediately.


Our reading is that the fix predates the 15 October disclosure, so many self-hosted shops first heard about the bug when the advisory went out. A patch applied now does not show the appliance was clean before it: Mandiant says any appliance reachable from the internet on a vulnerable version during the exploitation window should be treated as potentially compromised until reviewed.


BeyondTrust says the actor exploited the bug on 29 August against one BeyondTrust-hosted instance and one self-hosted appliance. That is BeyondTrust's count, and nothing rules out earlier use. BleepingComputer reports that Shadowserver tracks more than 1,400 BeyondTrust remote support instances exposed online, but it does not say how many are patched, still vulnerable or honeypots.


What BeyondTrust, Mandiant and NVD published


BeyondTrust rates the bug CVSS v4.0 9.3, Critical, CWE-290, with the synopsis "Improper Origin Validation in an Internal Messaging Component." As of 11:16 AM Arizona time on 16 October, NVD shows status Awaiting Analysis and lists only BeyondTrust's 9.3 score, with no NVD score of its own. Update, 16 October: CISA added the bug to its Known Exploited Vulnerabilities catalog in release 2026.10.16, published at 10:15 AM Arizona time. Under BOD 26-04, which binds Federal Civilian Executive Branch (FCEB) agencies, the entry sets a 19 October due date. It also directs those agencies to follow CISA's Forensics Triage Requirements.


After exploitation, Mandiant describes:


  • A webshell and a SOCKS5 tunneler, which it names SAWFLY and BARECLAW.

  • A copy of the system shell given root ownership and the SUID bit.

  • Attempts to read the appliance's credential vault with its own command line tool, then deletion of that tool's log. Mandiant does not say the vault was dumped.

  • A startup script adding passwordless sudo for the site service account, so it survives reboot and configuration reset.

  • An edit to the appliance's HAProxy reverse proxy configuration that routed a custom URI path to the localhost-only tunneler, so it was reachable from the internet.

  • Repeated log deletion, including one command that removed many on-box logs at once.

  • A login to the web admin portal with an Administrator account, a user_changed event raising that account's Jump Item and Team permissions from No Access to Administrator, then a Remote Support session to internal endpoints and file transfer of documents such as software inventories.


Mandiant also published the staging filename app_84304470%2Ephp, which it could not recover and gives no hash for, and two filenames with SHA-256 hashes: mangoapi.php (SAWFLY, dc14e215269a93fdbc4c1a80b984c23faf7af0911c6dbb85309796a6f2ae95fb) and ingredi_ws (BARECLAW, 1f19b9a27d79c11bda00a1e8faf74a7fdd683d38ccef1b60df2fd0307e3aa462), plus YARA rules. The public post lists no IP addresses or domains, and it says further indicators are in a GTI Collection for registered users. BeyondTrust says the actor changes tooling between victims, so run these once as a check and do not build a hunt on them.


Mandiant says that in past campaigns ARMORY CASTLE moved to widespread, opportunistic exploitation once a bug it had used selectively as a zero-day became public, and that the same could happen here. The sources we read report no mass exploitation yet.


What to change this week


  1. Inventory every self-hosted Remote Support and PRA appliance: version, patch state and internet reachability. SaaS tenants need no appliance patch, but Mandiant says the credential and configuration steps still apply.

  2. If you suspect compromise, preserve the evidence first. Snapshot virtual appliances with memory and export the disk; for B Series hardware and SaaS, ask BeyondTrust Support. Collect syslog, proxy or WAF and firewall logs for the whole window. If you find evidence, BeyondTrust asks for a Sev 1 support request citing BT26-05.

  3. Patch from /appliance, or confirm automatic updates applied BT26-05-RS. Appliances older than 24.3.1 must upgrade first, and Mandiant notes that upgrading closes the hole but does not remediate prior exposure.

  4. Rebuild a suspect appliance from a clean, fully patched image rather than cleaning it in place, and restore only a configuration backup that predates the window. Issue a new TLS certificate for the rebuilt appliance before you redeploy clients.

  5. Only after patching or rebuilding, rotate credentials in dependency order: /appliance and /login admins, local users, API secrets, bind accounts and SAML signing keys, Vault, Password Safe and PRA credentials at the target, integration credentials, and anything typed into a session in the window. Mandiant warns that rotating earlier exposes the new credentials to an attacker who still controls the appliance. Redeploy Jump Clients, Jumpoints and the representative console.

  6. Review /login against a pre-window baseline: roles raised to Administrator, new users, API accounts, security providers, and outbound event or syslog destinations.

  7. Restrict /login and /appliance by IP, and put a reverse proxy or WAF with full URI logging in front of the appliance. Deny egress except to BeyondTrust update and licensing endpoints and your own syslog and directory servers. Send syslog over TLS, and set the default Jump Item role to No Access in every group policy.


Four hunts to run (test first)


These hunts use data that lives off the appliance. We have not run them on live customer data. Replace every YOUR_* placeholder before you trust a zero, and confirm syslog was retained back to the window start. Every window starts on 1 August 2026, which covers Mandiant's late August date with margin, and first-seen logic uses 1 May to 31 July 2026 as the baseline. The table under the hunts, "Interpret before you escalate", says what is benign and what is not.


BeyondTrust's docs show syslog as a header followed by semicolon-separated key=value pairs on the local0 facility, with field order not fixed. Mandiant prints the same events as JSON, which looks like a rendering of the syslog, so the queries accept either form; test them on a known login event first. Messages over 1 KB are split into segments, so on a long event the role fields can land on a different line than the event name. The jump_item_role field names in the role-raise hunts come from Mandiant's Figure 7, and BeyondTrust's own events documentation does not list them.


Hunt in Splunk: role raises and forwarding gaps (test first)


Search 1: role raises


index=YOUR_BT_INDEX earliest="08/01/2026:00:00:00" "jump_item_role" "Administrator"
| rex field=_raw "\bevent\"?\s*[:=]\s*\"?(?<bt_event>[a-z_]+)"
| rex field=_raw "\bwho\"?\s*[:=]\s*\"?(?<who>[^\";]+)"
| rex field=_raw "who_ip\"?\s*[:=]\s*\"?(?<who_ip>[0-9a-fA-F:.]+)"
| rex field=_raw "old_username\"?\s*[:=]\s*\"?(?<target_user>[^\";]+)"
| rex field=_raw "old_permissions:jump_item_role:default:name\"?\s*[:=]\s*\"?(?<old_default_role>[^\";]+)"
| rex field=_raw "new_permissions:jump_item_role:default:name\"?\s*[:=]\s*\"?(?<new_default_role>[^\";]+)"
| rex field=_raw "new_permissions:jump_item_role:teams:name\"?\s*[:=]\s*\"?(?<new_team_role>[^\";]+)"
| where new_default_role="Administrator" OR new_team_role="Administrator"
| table _time host bt_event who who_ip target_user old_default_role new_default_role new_team_role

Search 2: forwarding gaps


| tstats count where index=YOUR_BT_INDEX host IN ("YOUR_APPLIANCE_HOST_1","YOUR_APPLIANCE_HOST_2") earliest="08/01/2026:00:00:00" by host _time span=1m
| sort 0 host _time
| streamstats current=f window=1 last(_time) as prev_time by host
| eval gap_minutes=round((_time-prev_time)/60,1)
| where gap_minutes>=YOUR_GAP_MINUTES
| eval gap_start=strftime(prev_time,"%Y-%m-%d %H:%M:%S"), gap_end=strftime(_time,"%Y-%m-%d %H:%M:%S")
| table host gap_start gap_end gap_minutes

Compare every role-raise row to your change tickets. Mandiant's event shows old_username as the user who was changed, so confirm on a known event which field names the person who made the change.


For the gap search, confirm on a known event that host holds the appliance name and not your syslog collector's. It finds only gaps that have ended, so also check the latest event time for each appliance. Set YOUR_GAP_MINUTES from the appliance's normal chatter, then line each gap up with the logins and sessions on either side, since Mandiant says a gap that starts and ends inside one session is a strong sign of log tampering. Planned role changes, maintenance and collector restarts will show up as noise. An empty result can mean the logs were never forwarded, a segment split hid the role fields, or retention stops short of 1 August.


Hunt in Kibana: unknown PHP paths at the proxy (test first)


Search the proxy or WAF with KQL in Discover against the index pattern YOUR_PROXY_INDEX_PATTERN:


http.request.method:"POST" and (url.path:*.php or url.original:*%2Ephp*) and destination.ip:("YOUR_APPLIANCE_IP_1" or "YOUR_APPLIANCE_IP_2") and not url.path:("YOUR_KNOWN_PHP_PATH_1" or "YOUR_KNOWN_PHP_PATH_2")

Set the time picker to an absolute start of 1 August 2026. Mandiant points at PHP paths outside the known Remote Support set, but the appliance may serve legitimate .php, so build the known-path list from a month of traffic before 1 August first, then use a Lens table of the earliest @timestamp per url.path to find paths that first appear late in the window. A path that was in use before August but is missing from your list will show an earliest time inside the window, so check it against pre-August traffic before you treat it as new. Servers log the encoded dot differently, so test both url.path and url.original on a known request.


For role raises, search forwarded syslog for jump_item_role and Administrator. The appliance name can sit in log.syslog.hostname, host.name (often the collector) or log.source.address, so test all three. Mandiant also recommends watching for WebSocket upgrades from addresses outside your support staff and endpoint ranges, but ECS has no standard Upgrade header field, so that is a manual search. An empty result can mean the wrong index, a hostname field mismatch, a proxy that records the appliance as an upstream address instead of in destination.ip, or no proxy in front of the appliance.


Hunt in Falcon CQL: support sessions on endpoints the appliance reached (test first)


event_simpleName=ProcessRollup2 event_platform=Win
| ParentBaseFileName=/^(sra-scc|bomgar-scc|bomgar-pec)\.exe$/i
| default(field=ComputerName, value="unknown")
| in(field="FileName", values=["cmd.exe","powershell.exe","pwsh.exe","wmic.exe","reg.exe","net.exe","whoami.exe","systeminfo.exe"], ignoreCase=true)
| groupBy([aid, ComputerName], function=[count(as=Events), min(@timestamp, as=FirstSeen), max(@timestamp, as=LastSeen), collect([CommandLine])], limit=20000)

The appliance usually has no sensor, so this goes downstream to the endpoints it reached. BeyondTrust's community notice says the Windows client files bomgar-scc.exe and bomgar-pec.exe became sra-scc.exe in version 25.1, so clients that were not upgraded may still run the old names and the pattern covers all three; confirm the process name on one known session. Start the time range on 1 August 2026. FirstSeen and LastSeen come back as epoch milliseconds, and ComputerName is often missing or empty on raw events, so the query fills a placeholder and you should resolve aid against your host inventory.


Help desk staff run these tools in sessions all day, so a bare hit means little. The lead is a session on a host that lines up with a role raise, an odd admin login or a syslog gap. An empty result only means something if the endpoints have sensors and retention reaches back to 1 August.


Hunt in KQL: Sentinel first-seen logins and appliance egress (test first)


Search 1: first-seen login sources


let windowStart = datetime(2026-08-01);
let baselineStart = datetime(2026-05-01);
let applianceNames = dynamic(["YOUR_APPLIANCE_HOST_1","YOUR_APPLIANCE_HOST_2"]);
let logins = Syslog
    | where TimeGenerated >= baselineStart
    | where Computer in~ (applianceNames) or HostName in~ (applianceNames)
    | where SyslogMessage has "web/login" and SyslogMessage has "success"
    | extend Who = extract(@'\bwho"?\s*[:=]\s*"?([^";]+)', 1, SyslogMessage)
    | extend WhoIp = extract(@'who_ip"?\s*[:=]\s*"?([0-9a-fA-F:.]+)', 1, SyslogMessage)
    | extend Who = trim(" ", tostring(split(Who, " using ")[0]))
    | where isnotempty(Who) and isnotempty(WhoIp);
let baseline = logins | where TimeGenerated < windowStart | distinct Who, WhoIp;
logins
| where TimeGenerated >= windowStart
| join kind=leftanti baseline on Who, WhoIp
| summarize FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), Logins=count() by Who, WhoIp
| order by FirstSeen asc

Search 2: first-seen appliance egress


let windowStart = datetime(2026-08-01);
let baselineStart = datetime(2026-05-01);
let applianceIps = dynamic(["YOUR_APPLIANCE_IP_1","YOUR_APPLIANCE_IP_2"]);
let allowedDestinations = dynamic(["YOUR_ALLOWED_IP_1","YOUR_ALLOWED_IP_2"]);
let seenBefore = CommonSecurityLog
    | where TimeGenerated >= baselineStart and TimeGenerated < windowStart
    | where SourceIP in (applianceIps)
    | distinct DestinationIP;
CommonSecurityLog
| where TimeGenerated >= windowStart
| where SourceIP in (applianceIps)
| where not(ipv4_is_private(DestinationIP))
| where DestinationIP !in (seenBefore) and DestinationIP !in (allowedDestinations)
| summarize FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), Events=count(), BytesOut=sum(SentBytes) by SourceIP, DestinationIP, DestinationPort
| order by FirstSeen asc

The first query lists web login pairs of user and source address that were not in the baseline, and it cannot tell administrators from other users. It only works if the Syslog table keeps data from May, and with shorter retention every pair will look new. The egress query has the same limit on CommonSecurityLog. BeyondTrust advises looking for unrecognized privileged or admin sessions from residential broadband or commercial VPN addresses that map to no administrator or ticket, so check each address against your admin ranges and VPN ownership, starting with privileged accounts. Confirm your connector stores the appliance under Computer or HostName. New staff, travel and VPN changes will show up as first-seen sources.


Mandiant says to let the appliance reach only BeyondTrust endpoints and your own syslog and directory servers, so fill the allowlist from BeyondTrust's own documentation for your deployment. The second query calls a destination new only if the table keeps data from May. SentBytes is filled by only some firewall parsers, and ipv4_is_private covers just RFC 1918 and returns null for IPv6, so review IPv6 egress by hand. An empty result can mean a connector mismatch, firewall logs that do not record the appliance's addresses, or no firewall events for those addresses.


Interpret before you escalate


Finding

Benign read

Escalate when

Role raised to Administrator with no ticket

A planned access change nobody logged

Immediately: preserve, then follow the rebuild steps

Web login from a first-seen address

New staff, travel, a changed VPN

The address maps to no administrator or ticket

Syslog gap that starts and ends inside one session

Collector restart, maintenance

It lines up with a role raise or an odd login

Unknown .php POST at the proxy

A legitimate path missing from your baseline

The path is first seen late and the appliance answered

First-seen external destination from the appliance

An update or licensing service

Outbound bytes to a destination nobody can explain

Shell tools under the support client

Routine help desk work

The host lines up with any hit above

Empty across all four hunts

Nothing matched in the data you have

Not a clean bill of health until you confirm logs were forwarded and retained back to 1 August


Sources



What This Means for Your Team


The appliance that brokers your privileged access is also the machine whose own logs you can least trust after a compromise. Check the version and the patch today, and secure the off-box logs before you touch anything suspect. Then hunt back to August from the outside, and rotate credentials only after the appliance is patched or rebuilt.


Inception Protection


Inception Protection is our managed detection and response service, and it works with the Microsoft licenses you already have. For an appliance like this, the evidence that survives is off the box: syslog, proxy, firewall and endpoint data. We look at that data for unexplained role changes, new admin sources and odd outbound connections, and we work through containment with your team.


Inception Foresight


A remote access appliance is one door among several. To see what your Microsoft 365 tenant shows about sign-ins and activity behind it, you can run the free Inception Foresight M365 Assessment: https://www.inceptionsecurity.com/m365assessment. You can also follow Inception Security on LinkedIn and @inceptionsec on X.


Tags: BeyondTrust, BeyondTrust Remote Support, Privileged Remote Access, CVE-2026-102764, BT26-05, ARMORY CASTLE, sra-scc.exe, Mandiant, SAWFLY, BARECLAW, improper origin validation, CWE-290, CVSS v4.0, zero-day, remote access appliance, Jump Items, privileged access, syslog, off-box logging, reverse proxy logs, firewall logs, log tampering, threat hunting, Splunk, Kibana, Falcon CQL, KQL, Microsoft Sentinel, Inception Security, Inception Protection


bg-map-white.png

INCEPTION SECURITY™

A cybersecurity company with in depth knowledge of the threat landscape and security controls.

NAVIGATION

Home

About 

Services

Partners

Privacy

Contact us

Cyber Incident

Terms and Conditions

GET IN TOUCH

Phone: +1 (888) 427-2937

© 2025 All Rights Reserved by INCEPTION SECURITY™ .

bottom of page