China-Linked Spies Turned BeyondTrust Help Desks Into Skeleton Keys

A suspected Chinese espionage group was quietly breaking into BeyondTrust Remote Support appliances for weeks before anyone had a patch. Google Threat Intelligence Group and Mandiant say the group they now call ARMORY CASTLE (formerly UNC5221) has exploited CVE-2026-102764 as a zero-day since late August. Once inside, the attackers took root, dumped the appliance’s stored credentials and used the support tool itself to reach internal machines. BeyondTrust shipped the fix in its BT26-05 update, and Google expects broader exploitation now that the bug is public.

127.0.0[.]1:19800 (BARECLAW listener behind HAProxy)
/uidchanarge (WebSocket path)
/app_84304470%2Ephp (staging request path)

dc14e215269a93fdbc4c1a80b984c23faf7af0911c6dbb85309796a6f2ae95fb (SAWFLY, mangoapi.php)
1f19b9a27d79c11bda00a1e8faf74a7fdd683d38ccef1b60df2fd0307e3aa462 (BARECLAW, ingredi_ws)

Source article: ARMORY CASTLE Exploits BeyondTrust (CVE-2026-102764)
Publisher: Google Threat Intelligence Group (GTIG) / Mandiant, Google Cloud Blog (authors: Jayson Frost, Bryce Greathouse, Brian Meyer, John Palmisano, Rajesh Rajeshirke, Steve Rasch, John Wolfram)
Published: October 15, 2026
URL: https://cloud.google.com/blog/topics/threat-intelligence/armory-castle-exploits-beyondtrust/

Executive Summary

ARMORY CASTLE, a suspected PRC-nexus espionage group tracked by GTIG and formerly tracked as UNC5221 (CrowdStrike reports the same actor as WARP PANDA, per Cybersecurity Dive), exploited CVE-2026-102764 in BeyondTrust Remote Support (formerly Bomgar) appliances as a zero-day starting in late August 2026. The flaw lets an unauthenticated remote attacker upload and operate on files on the appliance; BeyondTrust rates it CVSS v4.0 9.3, it affects all supported Remote Support versions up to 26.2.3, SaaS tenants were patched on October 9, 2026, self-hosted appliances on 24.3.1 or later need the BT26-05-RS patch, and CISA has added it to the Known Exploited Vulnerabilities catalog. GTIG says only a small number of organizations are known to be impacted so far, but the group has been active since at least October 2023 against many countries and sectors, and after its Ivanti Connect Secure zero-days (CVE-2023-46805 and CVE-2024-21887) became public in 2024 it moved to broad, opportunistic exploitation; GTIG expects the same here. In the intrusion Mandiant investigated, the actor sent POST requests to a staging file, wrote the SAWFLY PHP webshell into the appliance’s Laravel web root about 11 minutes later, copied /bin/sh to a root-owned SUID file named /usr/bin/dbus-authd to become root, dumped the appliance’s credential vault with BeyondTrust’s own bt-secrets CLI and deleted that tool’s log, planted a boot-time script that re-grants the site service account passwordless sudo on every startup, and repeatedly wiped host, web and application logs. It then logged into the /login portal with stolen Administrator credentials, raised the account’s Jump Item and Team roles from No Access to Administrator, opened remote support sessions to internal endpoints and pulled documents such as software inventories through the product’s file transfer feature, and exposed the BARECLAW SOCKS5-over-WebSocket tunneler to the internet through the appliance’s own HAProxy. The objective is espionage: the appliance holds or brokers every credential it uses and gives trusted reach into internal endpoints, so a compromised appliance means credential exposure across everything it touches, and patching does not remove an existing compromise. The Hunt Leads below give detection logic, false-positive expectations, the two YARA rules GTIG published, and the published indicators.

ATT&CK chain: Initial Access → Persistence → Privilege Escalation → Credential Access → Defense Impairment → Lateral Movement → Collection → Exfiltration → Command and Control

Hunt Lead Grid

Unknown PHP Staging Requests to Remote Support

After exploiting CVE-2026-102764, which eSecurity Planet reports BeyondTrust traced to an internal messaging component, ARMORY CASTLE sent POST requests to /app_84304470%2Ephp, a staging file whose name hides the dot as the URL-encoded %2E. Mandiant could not recover that file, and no exploit request content beyond “arbitrary file upload” has been published, so the request to the staging path and what follows it are the only hunt anchors. Roughly 11 minutes after the first POST, the file system recorded the creation of the SAWFLY webshell at /%SITE_SERVICE_ACCOUNT%/ingredi/app/laravel/public/. The detection logic is a sweep of request logs for any POST to /app_84304470%2Ephp, any request path containing %2E inside a file name, and any .php path outside the appliance’s known Remote Support path set, followed by a check for a new .php file appearing in the web root within minutes of such a request. GTIG’s own detection guidance calls out exactly this: paths outside the known path set, including unknown .php paths and WebSocket upgrades from outside support staff and endpoint address ranges.

Run the sweep against logs the appliance cannot alter: a reverse proxy or WAF with full URI logging in front of the appliance, perimeter firewall or load balancer logs, and syslog already forwarded to a SIEM, because the actor deleted the appliance’s own HTTP access and error logs. On the appliance itself, Mandiant found exploitation evidence in the access, syslog, messages, thin-scc, brain and SSL logs, which sit on a LUKS-encrypted partition holding /home and are not something a customer can browse, so on-box review means a disk export of a virtual appliance or forensic preservation requested through BeyondTrust Support. Sweep from the start of August 2026 to today on every internet-reachable self-hosted appliance that ran 26.2.3 or earlier, and do not stop at the patch date, since GTIG expects opportunistic exploitation by this and other actors now that the bug is public. Blocking the single staging file name at the WAF is the wrong control on its own because the name is trivially changed; the generalizable signal is any new .php path on an appliance whose path set is fixed. Treat any POST to an unknown .php path that is followed by a new file in the web root as a confirmed compromise and escalate to incident response rather than tuning it, and treat the appliance as compromised if it was exposed and vulnerable during the window even with no hit, as GTIG advises.

Hunt Lead Level: 1 (Junior Analyst)

ATT&CK: Initial Access → T1190 (Exploit Public-Facing Application); detection strategy DET0080 Exploit Public-Facing Application – multi-signal correlation (request → error → post-exploit process/egress)

Sources: “ARMORY CASTLE Exploits BeyondTrust (CVE-2026-102764)”, Google Threat Intelligence Group / Mandiant, Oct. 15, 2026, https://cloud.google.com/blog/topics/threat-intelligence/armory-castle-exploits-beyondtrust/ (source article); “Google Warns China-Linked Hackers Exploited BeyondTrust Zero-Day”, eSecurity Planet, Oct. 16, 2026, https://www.esecurityplanet.com/threats/news-beyondtrust-zero-day-china-hackers/ (additional source, same campaign; affected versions, CVSS, vulnerable component)

SAWFLY Webshell in the Laravel Public Web Root

About 11 minutes after the staging POSTs, SAWFLY (mangoapi.php, SHA-256 in the appendix) was written to /%SITE_SERVICE_ACCOUNT%/ingredi/app/laravel/public/, and GTIG says the actor used it as one of its primary footholds for the rest of the intrusion; the SUID escalation, the log wiping and other commands were run from it. SAWFLY inspects POST requests for an obfuscated parameter named _c94mfe. If the parameter is missing it calls http_response_code(404) and exits, so crawlers and vulnerability scanners only ever see a “not found” page. If the parameter is present it Base32-decodes the value, RC4-decrypts it with a hardcoded 32-byte key, runs the result through @eval(), and returns any output RC4-encrypted and Base32-encoded. The detection logic has three parts: scan the Laravel public directory and the rest of the service account’s tree for PHP files not shipped by the vendor and with GTIG’s YARA rule below; look in request logs for POSTs to a .php path that carry a body and receive HTTP 404, or for any request body containing _c94mfe; and look for shell, cp, chown, chmod, rm or sudo processes whose parent is PHP-FPM running as the site service account.

Because customers cannot audit the appliance host file system, the YARA and file sweep is run against an exported disk of a virtual appliance or an image obtained through BeyondTrust Support, after snapshotting with memory and before any reboot or upgrade; for SaaS tenants, request preservation from BeyondTrust. The request-log half of the hunt runs on reverse proxy or WAF logs from the start of August 2026 forward, and the “POST with a body returns 404” pattern is worth keeping as a standing rule for this appliance because legitimate clients do not repeatedly POST to a page that does not exist. Blocking the SHA-256 is the wrong primary control: the webshell is a few kilobytes of PHP that changes hash with any edit or key change, so rely on the YARA rule, which keys on the Base32 alphabet, RC4 loop, pack('H*',, @eval( and forced 404 together. Any YARA match or any _c94mfe request is a confirmed compromise that goes straight to incident response, and because a webshell gives the actor arbitrary code as the service account, the response is a rebuild from a clean, patched image rather than deleting the file. The 404-cloaking design is common to many PHP webshells, so the request pattern generalizes beyond this campaign.

Published rule, reproduced verbatim from the source article (GTIG):

rule G_Hunting_Webshell_SAWFLY_1 {
  meta:
author = "Google Threat Intelligence Group"    
  strings:
    $b32 = "ABCDEFGHIJKLMNOPQRSTUVWXYZ234567" ascii wide
    $rc4 = "range(0,255)" ascii wide
    $pack = "pack('H*'," ascii wide
    $eval = "@eval(" ascii wide
    $code404 = "http_response_code(404)" ascii wide
  condition:
    filesize < 20KB and
    all of them
}

Hunt Lead Level: 1 (Junior Analyst)

ATT&CK: Persistence → T1505.003 (Server Software Component: Web Shell); detection strategy DET0394 Web Shell Detection via Server Behavior and File Execution Chains

Sources: “ARMORY CASTLE Exploits BeyondTrust (CVE-2026-102764)”, Google Threat Intelligence Group / Mandiant, Oct. 15, 2026, https://cloud.google.com/blog/topics/threat-intelligence/armory-castle-exploits-beyondtrust/ (source article)

SUID Shell Masquerading as dbus-authd

SAWFLY ran as the site’s unprivileged service account, so the actor’s next step from the webshell was to copy /bin/sh to /usr/bin/dbus-authd, change its owner to root and set the SUID bit. Any local user, including the web service account, can then run that file and get a root shell, and the file survives reboots, which GTIG describes as a persistent root-level backdoor that gave the actor every credential the appliance stores or brokers and the ability to change files that survive reboot and configuration reset. The name resembles a D-Bus system component, which makes it easy to overlook in a directory listing. The detection logic is to enumerate every SUID and SGID file on the appliance, compare the list and hashes against a known-good image of the same version, flag any SUID file whose content is identical to /bin/sh or another shell, and check specifically for /usr/bin/dbus-authd. Where process history is available, the sequence to look for is cp of a shell binary into /usr/bin, then chown root and chmod u+s or 4755 on the copy, then later executions of that file with PHP-FPM or the service account as the parent.

This is an artifact sweep on a preserved image of the appliance, since customers cannot audit the appliance host file system and EDR is not normally present on it; run it as part of any review of an appliance that was exposed on a vulnerable version from late August 2026 onward. The sweep scales to other Linux servers where EDR or file-integrity monitoring is present, and there the generalizable rule is a SUID bit set on any file whose hash matches a system shell. Do not hash-block this file: it is an unmodified copy of the legitimate system /bin/sh, so its hash is the hash of the appliance’s own shell, and blocking it would break the system; detect the path, the SUID bit on shell-identical content, and the parentage instead. A hit means the actor reached root, which puts every credential on the appliance in scope, so escalate to incident response and plan a rebuild and credential rotation rather than removing the file and its SUID bit in place.

Hunt Lead Level: 1 (Junior Analyst)

ATT&CK: Privilege Escalation → T1548.001 (Abuse Elevation Control Mechanism: Setuid and Setgid); detection strategy DET0110 Setuid/Setgid Privilege Abuse Detection (Linux/macOS)

Sources: “ARMORY CASTLE Exploits BeyondTrust (CVE-2026-102764)”, Google Threat Intelligence Group / Mandiant, Oct. 15, 2026, https://cloud.google.com/blog/topics/threat-intelligence/armory-castle-exploits-beyondtrust/ (source article)

Boot Script Sudoers Persistence

For long-term root access that would outlive the SUID file, the actor created /home/bomgar/sbin/post_boot.d, a directory reserved for scripts the appliance runs automatically at startup, and placed a shell script named zz-root-persist in it. GTIG published its contents: the script uses grep -qF to check whether /ns/config/sudoers.template already contains %SITE_SERVICE_ACCOUNT% ALL=(ALL) NOPASSWD: ALL, appends that line if it is missing, and then runs '/ns/sbin/bt-sysconfig' --no-restart misc, which makes the appliance rebuild the live /etc/sudoers from the template immediately. Because the appliance regenerates /etc/sudoers from the template, a manual edit to /etc/sudoers would be overwritten by a configuration reset, but this change is re-applied on every boot and survives both reboots and configuration resets. The detection logic is to list every file in /home/bomgar/sbin/post_boot.d (any file named zz-root-persist is a direct hit, and any script there that touches sudoers is suspect), diff /ns/config/sudoers.template and /etc/sudoers against a clean image of the same version for any NOPASSWD entry tied to the site service account, and flag executions of bt-sysconfig with the misc argument that are not tied to an upgrade or an administrator change.

Run the sweep on a preserved image of every appliance that was exposed on a vulnerable version, using the same acquisition path as the other host leads, and include configuration backups in the review because a backup taken after the change will carry the poisoned template into a rebuilt appliance; GTIG advises restoring only a backup dated before the exposure window or reviewing a newer one while isolated. Vendor upgrades legitimately rewrite the template and run bt-sysconfig, so do not alert on the tool alone; anchor on the service-account NOPASSWD: ALL line and on unknown scripts in post_boot.d. Cleaning the line out of /etc/sudoers is the wrong fix because the boot script will put it back, and even removing the script is not enough because GTIG notes that host-level persistence survives reboot and configuration reset and that customers cannot audit the host file system; the correct response to a hit is to escalate to incident response and redeploy from a clean, fully patched image. The pattern of abusing a vendor’s own startup hook and configuration template to re-apply privileges applies to other managed appliances with similar template-driven configuration.

Hunt Lead Level: 1 (Junior Analyst)

ATT&CK: Persistence → T1037 (Boot or Logon Initialization Scripts), detection strategy DET0112 Boot or Logon Initialization Scripts Detection Strategy; Privilege Escalation → T1548.003 (Abuse Elevation Control Mechanism: Sudo and Sudo Caching), detection strategy DET0052 Behavioral Detection Strategy for Abuse of Sudo and Sudo Caching. T1037 is mapped at the parent level because the appliance’s post_boot.d directory is a vendor mechanism that does not match a specific sub-technique.

Sources: “ARMORY CASTLE Exploits BeyondTrust (CVE-2026-102764)”, Google Threat Intelligence Group / Mandiant, Oct. 15, 2026, https://cloud.google.com/blog/topics/threat-intelligence/armory-castle-exploits-beyondtrust/ (source article)

Vault Dumping with bt-secrets

With root, the actor abused /ns/sbin/bt-secrets, BeyondTrust’s proprietary administrative CLI for managing and retrieving stored passwords, API keys and endpoint credentials, and worked through several syntax variations to dump the vault. GTIG recovered the commands from message logs in this order: /ns/sbin/bt-secrets get -p %SITE_SERVICE_ACCOUNT% vault, then /ns/sbin/bt-secrets get %SITE_SERVICE_ACCOUNT% vault, both aimed at the site service account’s own vault, and finally /ns/sbin/bt-secrets get vault as a fallback against the global, appliance-level password safe. The actor then ran /usr/sbin/sh -c 'rm -f /home/bomgar/log/bt-secrets.log /home/bomgar/log/bt-secrets.log.* 2>/dev/null;' to delete the tool’s own log and its archives. The detection logic is any execution of bt-secrets with a get argument and the word vault, weighted up when there are several attempts with differing syntax within a few minutes, when the parent chain leads back to PHP-FPM, the site service account or the /usr/bin/dbus-authd SUID shell, when the execution falls outside a vendor support or maintenance window, and above all when it is followed by deletion of bt-secrets.log.

The command history lives in the appliance’s message logs, which are on the encrypted /home partition and may themselves have been wiped, so review them in a preserved image and in whatever has already been forwarded off the appliance; the log deletion half of this lead also feeds the log-wiping lead below. Look back to the start of August 2026, and allowlist only executions that match a documented support case or upgrade rather than allowlisting the binary, because bt-secrets is a legitimate vendor tool and blocking or quarantining it would break the appliance; the signal is the argument pattern, the parentage and the cleanup. Any confirmed hit means full credential exposure: everything the appliance stored or brokered must be rotated, but only after the appliance has been patched or rebuilt, because rotating earlier hands the new credentials to an actor who still controls it. GTIG’s rotation order is /appliance administrative credentials, then /login administrators and local users, API client secrets, security provider bind accounts and SAML signing keys, Remote Support Vault and integrated Password Safe or Privileged Remote Access credentials (rotated at the target system), integration credentials such as SMTP, syslog, ITSM connectors and outbound event secrets, and any credential typed into a support session during the window.

Hunt Lead Level: 2 (Pro)

ATT&CK: Credential Access → T1555 (Credentials from Password Stores); detection strategy DET0430 Detect Credentials Access from Password Stores

Sources: “ARMORY CASTLE Exploits BeyondTrust (CVE-2026-102764)”, Google Threat Intelligence Group / Mandiant, Oct. 15, 2026, https://cloud.google.com/blog/topics/threat-intelligence/armory-castle-exploits-beyondtrust/ (source article)

Jump Item Role Escalation and Support Session Abuse

After taking the appliance, the actor pivoted into the Remote Support application itself with compromised Administrator credentials, first logging in to the /login web portal with a password (GTIG published the resulting syslog login event with "target": "web/login" and "who": "[REDACTED_USERNAME] using password"). After testing that it could temporarily join the native Administrators group policy, it changed tactics for long-term access and edited the account directly so that both its default and team Jump Item roles moved from “No Access” (id 1) to “Administrator” (id 3), which GTIG shows as a user_changed syslog event with old_permissions:jump_item_role:default:id 1 and new_permissions:jump_item_role:default:id 3 and the matching teams fields. That gave it permanent authority to start remote sessions to every system in the Jump Item list, and it then opened a support session to internal endpoints, requested and obtained full file-system access, and used the built-in file transfer service to take documents useful for reconnaissance, such as software inventories, from a user’s desktop. The detection logic is a rule on forwarded appliance syslog for user_changed events where any jump_item_role or team role field changes to Administrator, plus user_added, api_account and security_provider events and any change to outbound event or syslog destinations with no matching change record, followed by a pivot to sessions started and file-transfer events by any account whose role changed.

Build this on appliance syslog forwarded to a SIEM over TLS with retention that covers a multi-month window, supplemented by scheduled exports of the /login session, team activity and user audit reports, and sweep back to the start of August 2026. Tune it by joining role changes to the change-management record and the named owner of the account; an approved change with an owner closes the alert, while anything else stays open. Add GTIG’s authentication signals as raisers rather than standalone alerts: /login successes from residential broadband or commercial VPN address space, and administrative logins outside business hours. Disabling the account is the right containment step, but deleting it is the wrong one, because GTIG advises disabling rather than deleting so the audit trail survives. A role raised to Administrator with no change record is an escalation to incident response, and every endpoint touched by a session from that account, along with every file transferred, is in scope for downstream hunting. The rule generalizes to any remote support or privileged access platform, because silently widening a compromised admin’s reach and then using the product’s own session and file transfer features is a durable abuse pattern.

Hunt Lead Level: 2 (Pro)

ATT&CK: Persistence / Privilege Escalation → T1098 (Account Manipulation), detection strategy DET0096 Account Manipulation Behavior Chain Detection; Command and Control → T1219 (Remote Access Tools), detection strategy DET0496 Behavior-Chain Detection for Remote Access Tools (Tool-Agnostic). The document theft through the support file-transfer feature is described in the source but is not mapped to a separate exfiltration technique here.

Sources: “ARMORY CASTLE Exploits BeyondTrust (CVE-2026-102764)”, Google Threat Intelligence Group / Mandiant, Oct. 15, 2026, https://cloud.google.com/blog/topics/threat-intelligence/armory-castle-exploits-beyondtrust/ (source article)

Appliance Log Wiping and Syslog Gaps

GTIG says the actor deleted logs repeatedly throughout the intrusion. The recovered example is a single rm -f run with sudo from the SAWFLY webshell that removed /ns/log/auth.log, ssl.log, proto-handler.log, bt-docker.log, http-access.log, http-errors.log, php-fpm.log, php-fpm-access.log, php_debug.log and php_web_errors.log under /ns/log/, plus /var/log/messages, /home/%SITE_SERVICE_ACCOUNT%/ingredi/log/httpd_access.log and httpd_error.log, and temporary SSH authentication files matching /tmp/sshauth.*; separately, it deleted /home/bomgar/log/bt-secrets.log and its archives right after dumping the vault. On-box evidence is therefore incomplete by design. The detection logic has two halves: on the host, deletion or truncation of files under /ns/log/, /var/log/ and the service account’s ingredi/log/ directory, especially many log files removed in one command or by a process descending from PHP-FPM or the service account; and off the host, gaps in syslog forwarding from the appliance, which GTIG calls out as a key signal, with an interruption bounded by a single session treated as a strong indicator of tampering.

The off-box half is the one most organizations can actually run, and it needs detection engineering: build a per-appliance baseline of forwarded event volume by hour, alert on drops to zero or near zero that are not explained by a recorded reboot, upgrade, network outage or collector maintenance, and then correlate each gap with session start and end events and with web requests from the proxy or WAF in the same window. Look back across the whole exposure window from late August 2026, keep the baseline running afterwards, and treat a gap that lines up with one session or one burst of requests to an unknown path as a hit. Do not rely on the appliance’s own logs to rule a compromise out, and do not reboot, upgrade or restore before preserving evidence: GTIG advises snapshotting virtual appliances with memory, exporting the disk, requesting preservation through BeyondTrust Support for B Series hardware and SaaS tenants, and collecting syslog, reverse proxy or WAF and perimeter firewall logs for the full window. A confirmed tampering gap is an escalation to incident response, and the gap-baselining approach generalizes to any appliance that forwards logs but cannot run an agent.

Hunt Lead Level: 3 (Elite)

ATT&CK: Defense Impairment → T1685.006 (Disable or Modify Tools: Clear Linux or Mac System Logs); detection strategy DET0520 Behavioral Detection of Log File Clearing on Linux and macOS. Older content maps this behavior to T1070.002, which current ATT&CK has replaced with T1685.006.

Sources: “ARMORY CASTLE Exploits BeyondTrust (CVE-2026-102764)”, Google Threat Intelligence Group / Mandiant, Oct. 15, 2026, https://cloud.google.com/blog/topics/threat-intelligence/armory-castle-exploits-beyondtrust/ (source article)

BARECLAW Tunnel Exposed Through HAProxy

To reach the internal network through the appliance, the actor ran BARECLAW, a C tunneler that serves SOCKS5 over WebSocket, statically embeds the CivetWeb web server and uses OpenSSL for TLS, from /tmp/ingredi_ws with the command line /tmp/ingredi_ws --listen 19800 --token <redacted> --obfs -q --ws-path /uidchanarge. That configuration listens for plain WebSocket on TCP 19800, requires a shared token, XOR-obfuscates tunneled data with a key derived from the token and an 8-byte client value, suppresses all logging, and does not use TLS. Instead of opening a new port, the actor edited /ns/config/haproxy.conf, the reverse proxy that fronts every appliance service, to add acl wswsws path /uidchanarge and use_backend webskd3 if wswsws, with a backend webskd3 (mode http) whose server websocks5srv points to 127.0.0[.]1:19800 and which sets timeout server 28s and timeout tunnel 5h, so internet traffic to /uidchanarge reaches the tunnel through the appliance’s normal HTTPS front end while the listener stays invisible to external scans. The detection logic joins three sources: at the reverse proxy or WAF, WebSocket upgrade requests to /uidchanarge or any path outside the vendor path set, especially from outside support staff and endpoint address ranges; on the appliance, executables in /tmp, a listener on loopback TCP 19800, and any ACL or backend in haproxy.conf that differs from the vendor baseline (named wswsws, webskd3 or websocks5srv, or routing to a loopback port); and in network telemetry, new outbound connections from the appliance to internal hosts that are not support-session endpoints.

Because WebSocket is normal for Remote Support, this lead cannot alert on WebSocket alone; it needs the path baseline at the proxy, a configuration baseline of haproxy.conf taken from a clean image of the same version, and egress or NetFlow data from the appliance’s internal interface to see what the tunnel reached. Expect long sessions, since the added backend allows a 5-hour tunnel timeout, and sweep from late August 2026 forward. Do not use the path or port as the only anchor, because BARECLAW takes both as arguments and defaults to /wsproxy and 8080 or 8443 for TLS, so the generalizable signals are an unknown HAProxy backend that routes to loopback and an unknown upgrade path; the default /wsproxy path is also worth adding to the proxy sweep. Scan any recovered /tmp binaries with GTIG’s YARA rule below rather than relying on the published hash. A hit is an escalation to incident response, and GTIG’s containment guidance applies: block inbound traffic at the perimeter firewall rather than in /appliance so the configuration stays intact for review, restrict appliance egress to BeyondTrust update and licensing endpoints plus the organization’s own syslog and directory servers, and log every denied connection.

Published rule, reproduced verbatim from the source article (GTIG):

rule G_Hunting_Backdoor_BARECLAW_1 {
  meta:
    author = "Google Threat Intelligence Group"

  strings:
    $s1 = "[%s ws_socks5d] " ascii wide
    $s2 = "--obfs requires --token" ascii wide
    $s3 = "mux: %s (frame[%lu]: %s)" ascii wide
    $s4 = "cannot create stream pump/writer thread (stream %d)" ascii wide
    $s5 = "reject: bad or missing token from %s" ascii wide
    $s6 = "listening on %s path=%s (token=%s obfs=%s max_tunnels=%d threads=%d)" ascii wide
    $s7 = "--ws-path must start with '/'" ascii wide
    $b_xorshift = { 48 c1 e0 17 48 31 c1 48 89 f0 48 c1 e8 1a 48 31 f0 48 31 c8 48 c1 e9 11 48 31 c8 }
  condition:
    uint32(0) == 0x464c457f and (5 of ($s*)) or ($b_xorshift and (3 of ($s*)))
}

Hunt Lead Level: 3 (Elite)

ATT&CK: Command and Control → T1572 (Protocol Tunneling), detection strategy DET0538 Detection Strategy for Protocol Tunneling accross OS platforms; Command and Control → T1090.001 (Proxy: Internal Proxy), detection strategy DET0075 Internal Proxy Behavior via Lateral Host-to-Host C2 Relay

Sources: “ARMORY CASTLE Exploits BeyondTrust (CVE-2026-102764)”, Google Threat Intelligence Group / Mandiant, Oct. 15, 2026, https://cloud.google.com/blog/topics/threat-intelligence/armory-castle-exploits-beyondtrust/ (source article)

Hash Appendix

SAWFLY webshell (mangoapi.php)

The SHA-256 comes from the source article; OTX AlienVault lists the SHA-256 in several pulses but has no file analysis giving an MD5 or SHA1, and VirusTotal could not be queried without an authenticated account, so MD5 and SHA1 are not available.

MD5s

(not available)  # mangoapi.php -> /%SITE_SERVICE_ACCOUNT%/ingredi/app/laravel/public/mangoapi.php (SAWFLY webshell)

SHA1s

(not available)  # mangoapi.php -> /%SITE_SERVICE_ACCOUNT%/ingredi/app/laravel/public/mangoapi.php (SAWFLY webshell)

SHA256s

dc14e215269a93fdbc4c1a80b984c23faf7af0911c6dbb85309796a6f2ae95fb  # mangoapi.php -> /%SITE_SERVICE_ACCOUNT%/ingredi/app/laravel/public/mangoapi.php (SAWFLY webshell)

BARECLAW tunneler (ingredi_ws)

The SHA-256 comes from the source article; OTX AlienVault lists the SHA-256 in several pulses but has no file analysis giving an MD5 or SHA1, and VirusTotal could not be queried without an authenticated account, so MD5 and SHA1 are not available.

MD5s

(not available)  # ingredi_ws -> /tmp/ingredi_ws (BARECLAW SOCKS5-over-WebSocket tunneler)

SHA1s

(not available)  # ingredi_ws -> /tmp/ingredi_ws (BARECLAW SOCKS5-over-WebSocket tunneler)

SHA256s

1f19b9a27d79c11bda00a1e8faf74a7fdd683d38ccef1b60df2fd0307e3aa462  # ingredi_ws -> /tmp/ingredi_ws (BARECLAW SOCKS5-over-WebSocket tunneler)

Staging webshell (app_84304470%2Ephp)

The source article lists this file as “N/A” because Mandiant could not recover it, so no hash of any type exists to look up.

MD5s

(not available)  # app_84304470%2Ephp -> appliance web root, requested as /app_84304470%2Ephp (staging webshell, not recovered)

SHA1s

(not available)  # app_84304470%2Ephp -> appliance web root, requested as /app_84304470%2Ephp (staging webshell, not recovered)

SHA256s

(not available)  # app_84304470%2Ephp -> appliance web root, requested as /app_84304470%2Ephp (staging webshell, not recovered)

SUID shell copy (dbus-authd)

The source article publishes no hash for this file, and none was looked up because it is an unmodified copy of the legitimate system shell /bin/sh: its hash is the hash of the appliance’s own /bin/sh, so blocking it would break the operating system. Detect the path /usr/bin/dbus-authd, the root-owned SUID bit on shell-identical content and its parentage instead.

MD5s

(not available)  # dbus-authd -> /usr/bin/dbus-authd (SUID root copy of legitimate /bin/sh; do not block by hash)

SHA1s

(not available)  # dbus-authd -> /usr/bin/dbus-authd (SUID root copy of legitimate /bin/sh; do not block by hash)

SHA256s

(not available)  # dbus-authd -> /usr/bin/dbus-authd (SUID root copy of legitimate /bin/sh; do not block by hash)

References Appendix

• “ARMORY CASTLE Exploits BeyondTrust (CVE-2026-102764)”, Google Threat Intelligence Group / Mandiant (Google Cloud Blog), Oct. 15, 2026, https://cloud.google.com/blog/topics/threat-intelligence/armory-castle-exploits-beyondtrust/ (source article; TTPs, timeline, commands, configuration excerpts, IOCs, YARA rules, remediation and detection guidance)
• “Google Warns China-Linked Hackers Exploited BeyondTrust Zero-Day”, eSecurity Planet, Oct. 16, 2026, https://www.esecurityplanet.com/threats/news-beyondtrust-zero-day-china-hackers/ (additional source; CVSS v4.0 9.3, affected versions, internal messaging component, Privileged Remote Access precautionary patch)
• “China-nexus espionage actor targets BeyondTrust support tool in zero-day campaign”, Cybersecurity Dive, Oct. 16, 2026, https://www.cybersecuritydive.com/news/china-espionage-beyondtrust-zero-day-hacker/833240/ (additional source; CISA KEV listing, “small number” of impacted organizations, CrowdStrike alias WARP PANDA)
• OTX AlienVault file indicator pages for the SAWFLY and BARECLAW SHA-256 values, AT&T Alien Labs, accessed Oct. 21, 2026, https://otx.alienvault.com/indicator/file/dc14e215269a93fdbc4c1a80b984c23faf7af0911c6dbb85309796a6f2ae95fb and https://otx.alienvault.com/indicator/file/1f19b9a27d79c11bda00a1e8faf74a7fdd683d38ccef1b60df2fd0307e3aa462 (hash provenance check; no MD5 or SHA1 available)
• MITRE ATT&CK Enterprise technique and detection-strategy pages linked above, MITRE, https://attack.mitre.org/