The sensors raised the alarm and the automation closed the alert: the BeyondTrust case

A tool that IT teams use to reach computers remotely was breached by an espionage group. The most uncomfortable detail is not the flaw itself but what the company itself reported: the sensors fired, and an automatic triage closed the alerts as false positives.

In 30 seconds

What happened

BeyondTrust makes privileged remote access tools. Remote Support (formerly called Bomgar) lets a technician remotely control an employee's computer or a server to solve problems. For that very reason, it is connected to many internal systems and holds credentials to reach them.

Timeline

• Aug 29: the group exploits the zero-day against a BeyondTrust-hosted instance and against an appliance installed at a customer (BeyondTrust).
• Sep 27: successful exploitation against another security vendor's appliances becomes public. BeyondTrust starts hunts on its threat intelligence platform, and Mandiant sends a brief, non-specific warning.
• Sep 28: the defense team finds indications at a cloud customer. The instance is contained 27 minutes after detection, with evidence preserved. About seven hours after containment, the product security team had already identified the entry point and reproduced it in a lab.
• Sep 30: Mandiant shares what it saw at the customer with its own appliance, confirming BeyondTrust's observations. The fix is validated in a test environment.
• Oct 8: BeyondTrust releases patch BT26-05 for cloud and self-hosted customers. Cloud instances receive the fix automatically (the advisory records it as applied by Oct 9).
• Oct 15: coordinated disclosure: CVE, public advisory, BeyondTrust post and Mandiant analysis. Google delayed publication to give customers time to apply the fix.

What is known and what is not

The attack chain, in pictures

Executive view: risk, gain and decision

Risk

Concentration of trust. A privileged remote access tool gathers the keys to several systems in a single point. Whoever controls it can use legitimate connections to reach the rest. Google describes the group opening remote sessions on internal computers and taking out sensitive documents; the areas the group usually targets, according to The Record, include law firms, software-as-a-service providers, business process outsourcers and technology companies.

Alert discarded by automation. When triage closes a signal without human review, the intrusion becomes invisible to the team. BeyondTrust drew the public conclusion that automatic triage "cannot close high-severity signals independently". Who answers for this, in the end, is the business owner, not the vendor of the triage tool.

Cost. There is no public estimate of losses for this case, and this text does not invent one. What can be said is the type of cost: rebuilding appliances, changing passwords and keys that were stored on them, investigating the systems reached and, when personal data is involved, reporting the incident (general guidance: confirm LGPD obligations with legal).

Gain

The governance rule that comes out of the case is cheap: define which classes of alert are never closed without a person, and review by sampling what the automation discarded. It does not require buying a new tool.

Decision for the next 30 days

1. List the remote access and privileged administration tools in use (including those of IT vendors that access your network) and who owns each one.
2. Find out whether any of them is reachable from the internet and which version it runs.
3. Ask the security team: which alerts can a machine close on its own?
4. Define who checks, every week, a sample of the closed alerts, and record the check.
5. Ask the security tools vendor, in writing, for the rule it applies to close high-severity alerts.

Commercial application: where there is revenue, savings, advantage or brand and contract risk

• Brand and contract risk. A company that provides services with access to customers' systems (IT providers, consultancies, outsourcers) lives on trust. If its remote access tool is breached, the problem reaches the customers. It is worth reviewing contracts: incident notice period, the right to receive records (logs), the maximum time to apply critical fixes and who pays for the investigation.
• Competitive advantage. My opinion: showing customers and partners, in an objective way, that there is human review for high-severity alerts and an inventory of privileged access tends to weigh in vendor audits and in tenders that require evidence of security.
• Savings. Automating triage reduces the team's load, and that is a real gain. The case shows the limit: automating the queue is not the same as handing the machine the final verdict on high-severity signals.
• Market context. According to Dark Reading, BeyondTrust says it serves more than 20,000 customers, including 75 of the Fortune 100 companies. It is the company's own data about itself; it helps size the potential reach, not the actual one.

Operational view: processes, people and routines

• Alert owner. Each class of alert needs a named owner and a response deadline. An alert with no owner is what automatic triage tends to close.
• Sampling. Set aside a weekly routine to check a sample of what was closed as a false positive. If there is no error, the routine becomes evidence; if there is, the triage rule is adjusted.
• Threat hunting. BeyondTrust describes its hunts as starting from threat intelligence and running "whether or not an alert has fired". For smaller companies, a lean version is to contract this function from a provider, with a written scope.
• Response plan. Rehearse the script Mandiant recommends: preserve evidence before rebooting, rebuild the appliance from a clean image and only then change the credentials.
• Continuity. Know how long the support team goes without the tool while it is rebuilt, and what the fallback procedure is.

Infrastructure view: cloud, network, servers and dependencies

• Cloud versus self-hosted. In this case, BeyondTrust's cloud instances received the fix with no action from the customer. Self-hosted appliances require the company itself to apply the patch through the administration interface, and versions prior to 24.3.1 must be updated first.
• Internet exposure. Google recommends treating as potentially compromised any appliance that was reachable from the internet, on a vulnerable version, during the exploitation window. Restricting the /login and /appliance pages to known addresses reduces this risk.
• Outbound traffic. Limiting what the appliance can reach on the internet (only the manufacturer's addresses) gets in the way of tunnels like the one used in the attack.
• Logs off the appliance. Send logs and session events, in near real time, to a central system (SIEM). The group deleted local logs; without an external copy, there is no way to reconstruct what happened.
• Proxy and web application firewall (WAF) in front. They make it possible to see out-of-the-ordinary request paths, such as unknown .php files or WebSocket connections from people who are not on the support team.
• Dependencies. The same code is in Privileged Remote Access (PRA), another product of the company. The researchers found no way to exploit it, but the fix was published as a precaution.

Security view: prevent, detect and respond

Prevent

• Apply patch BT26-05 without delay on self-hosted appliances.
• Require single sign-on (SAML SSO) with phishing-resistant two-step authentication on administrative interfaces, as Google recommends.
• Set the default Jump Item role to "No Access", so that a compromised account does not reach everything by default.
• Reduce what is exposed: expose only what is needed and limit administrative interfaces to trusted networks.

Detect

• Alerts on permission changes (user_changed event) that raise Jump Item or team roles to administrator, and on creation of accounts or API keys without a change ticket.
• Successful logins at /login from residential internet ranges or commercial VPNs, and administrative logins outside business hours.
• File transfers in remote sessions, sessions started by accounts whose role changed, and gaps in log forwarding (Google says an interruption limited to one session is a strong sign of tampering).
• Request paths outside the product's known set.

Respond

1. Preserve evidence before acting: a snapshot of the appliance with memory and disk, plus proxy, WAF and firewall logs.
2. Isolate the public address and restrict outbound network traffic.
3. Rebuild instead of cleaning. In Google's words: "Customers cannot audit the appliance host file system, and host-level persistence survives reboot and configuration reset". In plain terms: the customer cannot audit the appliance's file system, and whatever the intruder left installed survives a reboot and a configuration reset.
4. Change credentials only after the patch or the rebuild, because changing them earlier hands the new password to whoever still controls the appliance. Google suggests following the order of dependency: appliance administration, local users, API keys, identity integration accounts and SAML certificates, vaults and target-system passwords, integration credentials (email, logs, tickets) and any password typed into a support session during the exposure window.
5. Expect mass attempts. Google assesses that broad attempts against this flaw may be seen after disclosure, as happened with Ivanti in 2024. It is a forecast, not an event that occurred.

Technology view: how it works inside

This section gives the technical detail, with the terms explained. The file names, paths and commands come from the Google/Mandiant analysis; the plain-language explanation is mine.

The flaw and the 9.3 score

Advisory BT26-05 describes the flaw as "Improper Origin Validation in an Internal Messaging Component" and classifies it as CWE-290. In simple terms: a part of the program that exchanges internal messages did not properly check where the messages came from, and an outside attacker could perform file operations on the appliance. Mandiant speaks of arbitrary file upload. Affected: all Remote Support versions up to 26.2.3.

The score comes from CVSS 4.0, a severity scoring system. The published vector is CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. Reading it piece by piece:

NoteThe score measures the flaw in isolation. The real campaign went further: the group used the appliance as a starting point for other systems. That is why the 9.3 does not sum up the risk for those who have the tool connected to the whole network. (Explanation of the CVSS codes: general knowledge; check against the official FIRST specification.)

Note on dates: the advisory records publication on Oct 15, 2026 and states that, "as of Oct 9, 2026", the patch had already been applied to all cloud customers. BeyondTrust's blog says the patch was released on Oct 8. One news report gave Oct 9 as the patch date, which matches the cloud deployment, not the release.

Step by step through the attack (according to Google/Mandiant)

1. Entry. Requests to a file called app_84304470%2Ephp (not recovered). About 11 minutes later, a web shell appears in the web service folder.
2. SAWFLY web shell (mangoapi.php). A web shell is a small program hidden on a web server that accepts commands from outside. This one is written in PHP and obfuscated. It communicates in encrypted form and only responds if the request carries a secret parameter (_c94mfe); without it, it returns "404 page not found" to look harmless. The code it receives is run with eval().
3. Privilege escalation. The intruder copied the program /bin/sh to /usr/bin/dbus-authd (a name similar to a legitimate service), changed the owner to root (full Linux administrator) and enabled the SUID bit, which makes the program always run with the owner's powers. Result: administrator access ready for use by the site's service account.
4. Persistence. It created the script /home/bomgar/sbin/post_boot.d/zz-root-persist, run at every startup. It appends to the sudoers.template file a line that lets the service account use sudo without a password, and then regenerates the system rules file. That is why rebooting the appliance does not remove the access.
5. Credential vault. It used the native utility /ns/sbin/bt-secrets, with syntax variations, to try to read the vault where the appliance stores passwords, API keys and computer credentials. Then it deleted that utility's log. Google reports that these were access attempts; the list of secrets actually obtained was not disclosed.
6. Jump inside. It logged into the portal with a compromised administrative account and raised the permissions of Jump Items and teams from "no access" to "administrator". Jump Items are pre-configured connections to internal computers, useful for support and equally useful to an intruder. It opened remote sessions on those computers, browsed the files and took out documents such as software inventories.
7. Tunnel. It installed BARECLAW (ingredi_ws), a SOCKS5 proxy over WebSocket written in C, listening on TCP port 19800 and using the path /uidchanarge. A SOCKS5 proxy relays network traffic through a device; here, it let the intruder reach internal destinations from the appliance. It changed the HAProxy configuration (the appliance's reverse proxy) to forward that path to the tunnel, making it reachable from the internet without opening a new port.
8. Anti-forensics. It removed system, web server and application logs throughout the incident. Google notes that customers cannot audit the appliance's file system and that host-level persistence survives a reboot. That is why the guidance is to rebuild.

Google also published YARA rules (search patterns to identify malicious files) for SAWFLY and BARECLAW, and additional indicators (hashes) on the Google Threat Intelligence platform, for registered users. There are no hashes in the public text.

How automatic triage entered the story

The common detection model has layers: sensors generate alerts; an automatic triage decides which ones reach a person; the team investigates. BeyondTrust describes using this model. In the central passage of its post:

"Our sensors fired in real time when the actor escalated privileges, but the built-in triage tool in our third-party detection platform closed those alerts as false positives."
(In Portuguese: “Nossos sensores dispararam em tempo real quando o ator escalou privilégios, mas a ferramenta de triagem integrada à nossa plataforma de detecção de terceiros fechou esses alertas como falsos positivos.”)

A false positive is an alert about something that is, in fact, harmless. Triage exists to filter this noise; the risk is filtering out a true alert too. What the company says it is doing: working with the vendor so that automatic triage "cannot close high-severity signals independently"; re-verifying external verdicts with its own hunting platforms before closing alerts; and treating the triage verdict as "one input", keeping the closed alerts within the scope of the hunts.

The discovery, according to the company, did not come from an alert but from a threat hunt: an active search for attacker behavior, started from intelligence about new threats. BeyondTrust writes that the hunts "look for what an attacker does on a system, not a vendor's verdict on an alert".

InferenceThe passage suggests two independent layers as good practice: one that reacts to alerts and another that looks for behaviors without depending on them. This is my reading of the text, not a claim by the company. OpinionThe lesson also applies to AI automations that gain autonomy to decide: the control point is who can close the decision without a human looking.

Same week, same pattern

According to Dark Reading, flaws exploited in edge devices from other vendors were disclosed in the same week (Ivanti Connect Secure, Cisco Secure Email Gateway and Palo Alto PAN-OS, the last two in CISA's KEV catalog). Single source for these details; it serves as context, not as a conclusion. Google assesses, with high confidence, that ARMORY CASTLE will keep using zero-days in edge devices.

For the general reader: what to do today

• If you work at a company that uses remote IT support, ask the person in charge: "Do we use BeyondTrust Remote Support? Is it cloud or installed here? Is it up to date?"
• If the tool is installed in-house and reachable from the internet, ask for confirmation that patch BT26-05 was applied and that someone looked at the logs for the period.
• For any security tool that raises alerts: ask who looks at what the automation throws away.
• If you have an IT provider with access to your network, ask in writing how it protects the remote access tool and how it will notify you in case of an incident.

Terms in this article

These terms should go into the channel's glossary. Until they are added, they are defined here.

Zero-day

A flaw exploited before a fix is available. The manufacturer had "zero days" to fix it.

CVE

A public identifier for a security flaw (CVE-2026-102764, for example), so that everyone talks about the same flaw.

CVSS

A scoring system for flaw severity, from 0 to 10. A score of 9.3 is classified as critical.

CWE

A catalog of types of programming flaws. CWE-290 is the category cited in the advisory.

Web shell

A program hidden on a web server that accepts commands from outside and gives the intruder remote control.

Privilege escalation

When an intruder with limited access gains greater powers, such as those of an administrator.

SUID

A special permission on Linux systems that makes a program run with its owner's powers, even when someone else runs it.

Persistence

A way for the intruder to keep access even after reboots or password changes.

Credential vault

An area of the system that stores passwords, keys and other credentials for automatic use.

Jump Item

A pre-configured connection, in Remote Support, to an internal computer or server, so support can get in without typing everything again.

SOCKS5 proxy (tunnel)

A passage that relays network traffic through a device, making it possible to reach destinations that only that device can see.

Reverse proxy (HAProxy)

A server that receives connections from outside and forwards them to the right service inside the appliance.

Appliance

A device or system image delivered ready for one function, such as the Remote Support server installed at the company.

Automatic alert triage

A program that separates serious alerts from noise and decides which ones reach a person, like the spam filter in email.

False positive

An alert about something that is actually harmless. Closing a true alert as a false positive lets the intrusion through.

Threat hunting

An active search, done by people, for signs of an attacker in the environment, without waiting for an alert.

SIEM

A central system that gathers records and alerts from several devices for analysis and evidence retention.

Phishing-resistant two-step authentication

A second-step method (such as a physical key or passkey) that cannot be handed to a scammer by mistake.

YARA

Search rules to identify malicious files by patterns.

Sources

Primary

• BeyondTrust. Security advisory BT26-05, "Improper Origin Validation in an Internal Messaging Component", Oct 15, 2026: beyondtrust.com/trust-center/security-advisories/bt26-05
• BeyondTrust. Incident account (ARMORY CASTLE and BT26-05), published Oct 15, 2026 and updated Oct 16, 2026: beyondtrust.com/blog/entry/bt26-05
• Google Threat Intelligence Group and Mandiant, ARMORY CASTLE analysis, Oct 15, 2026: cloud.google.com/blog/topics/threat-intelligence/armory-castle-exploits-beyondtrust

Journalistic

• CSO Online, Oct 16, 2026: BeyondTrust zero-day tied to Chinese spies puts Remote Support users on alert
• Dark Reading, Oct 16, 2026: BeyondTrust Remote Support zero-day continues trend of exploited edge bugs
• The Record, Oct 16, 2026: therecord.media/beyond-trust-cyberattack-china
• The Hacker News, October 2026: China-Linked Hackers Exploited BeyondTrust Zero-Day to Take Over Remote Support Servers
• SC Media, Oct 16, 2026: BeyondTrust zero-day exploited by China-linked group Armory Castle

Public agencies, independent research and administrator blogs

• Canadian Centre for Cyber Security, alert AL26-025, Oct 16, 2026: cyber.gc.ca
• watchTowr, technical FAQ on CVE-2026-102764: watchtowr.com
• The Back Room Tech, guidance for administrators: thebackroomtech.com
• WindowsForum, thread on patching, hunting and rebuild guidance: windowsforum.com (the page read had no user replies)

I could not open Reddit (r/sysadmin, r/netsec), the NVD or CISA's KEV catalog in this review. What is said here about KEV comes from the press and blogs.

Method note: the 9.3 score, the CVSS vector, the publication date and the version window were checked on the BT26-05 advisory page and on the Canadian alert. The incident dates come from BeyondTrust's post and Google's report. Pages read on Oct 19, 2026, partly through automatic summaries. The account of the automatic triage appears only in BeyondTrust's post (CSO Online repeats it); THN, SC Media and watchTowr do not address the subject.

Cross-check: where the sources differ

• Patch date. BeyondTrust's post says Oct 8. The advisory records the cloud instances as fixed by Oct 9. THN and Dark Reading say Oct 9 and watchTowr says Oct 15 (the advisory date). Use "from Oct 8, with the cloud fixed by Oct 9".
• Alert date. Advisory and coordinated disclosure: Oct 15. The post was updated on Oct 16, and THN and the Canadian alert use Oct 16.
• Number of victims. BeyondTrust speaks of two (an instance hosted by it and a customer appliance). THN mentions a single appliance. The primary source prevails, and the count is the known one, not the total.
• Versions. The advisory lists "all versions up to 26.2.3". The patch covers 24.3.1 to 26.2.3; anyone below that must update first. One blog (SafeGuard) wrote "prior to 26.2.3" and contradicts the advisory, so the advisory prevails.
• Product. Some outlets also cited Privileged Remote Access (PRA). The advisory lists only Remote Support. BeyondTrust says it found no way to exploit PRA but applied the patch as a precaution, because the affected code is shared.
• CISA KEV. THN, Back Room Tech and SafeGuard say the flaw entered CISA's catalog of exploited vulnerabilities on Oct 16, with a deadline of Oct 19 for US federal agencies. I could not open the catalog. [CONFIRM]
• How the group hid. THN adds the use of commercial VPNs and compromised home or small-office routers, and alteration of the HAProxy configuration file to expose the tunnel to the internet.

"They sit at the boundary of the enterprise while holding privileged access to what lies behind it." Justin Moore, Arctic Wolf, quoted by SC Media (passage read through an automatic summary [CONFIRM]).

Final question

At your company, who checks what the automation discarded? Reply by Instagram direct message to @techtraduzida and tell us how your team handles this point. If this content helped, follow the profile, like and share: it helps develop and spread the channel.