🔥 CyberForge CVE of the Day #079
🚨 CVE-2026-102764 — BeyondTrust Remote Support: file operations and an exploited appliance trust boundary
A remote-support appliance connects people, credentials and managed endpoints. An investigation must follow both the box and the support activity it brokers.
BeyondTrust has disclosed an origin-validation flaw in internal Remote Support messaging. The vendor describes appliance file operations; Mandiant documents an intrusion that progressed from an upload to a web shell, later root escalation and persistent access.
Prove the named patch is applied, and preserve evidence to review activity before that repair.
🎯 THE QUICK HIT
What happened: internal RS components did not sufficiently validate where messages originated. Under suitable conditions, an attacker could perform file operations on the appliance. The published CVSS base vector models network access without privileges or user interaction. Exact triggering messages and request mechanics are withheld.
Why defenders should care: BeyondTrust and Mandiant report exploitation in late August. Mandiant's investigated chain used SAWFLY under an unprivileged site service account before later root escalation. Privileged persistence, credential access and unauthorised support activity are follow-on concerns; they are not interchangeable descriptions of the initial primitive.
Who should check: Remote Support through 26.2.3 without verified BT26-05-RS application. The named patch supports 24.3.1–26.2.3. Older releases need an eligible supported upgrade first, then that patch. A base-version screenshot or automatic-update enrolment alone does not prove completion.
First action: agree the site identity, build and patch receipt with the owner. Coordinate urgent repair with preservation of independent syslog, network and session records. Escalate suspected exploitation to BeyondTrust with a Sev 1 request citing BT26-05.
An empty IOC search, closed alert or current patch receipt cannot clear earlier exposure. The research includes log tampering and reboot-surviving persistence.
SaaS distinction: BeyondTrust says all RS SaaS was patched by 9 October. Mandiant's credential and configuration follow-up remains relevant to historical compromise review. Provider patch completion and customer incident closure answer different questions.
🔑 KEY DETAILS
• Product: BeyondTrust Remote Support, formerly Bomgar.
• Advisory: BT26-05; CVE Program status PUBLISHED.
• Weakness: CWE-290, authentication bypass by spoofing; internal message-origin validation.
• Severity: BeyondTrust CNA CVSS v4.0 9.3, Critical.
• Vendor/CNA vector: 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
• NVD: Received; the displayed Secondary v4 metric comes from BeyondTrust, not independent NIST scoring. No v3 score or SSVC assessment was verified in the retrieved records.
• KEV: no exact entry in the fetched 2026.10.15 catalogue of 1,746 entries. Its release time predates the CNA publication that evening. This is not evidence against reported exploitation.
• EPSS: FIRST returned HTTP 200 with no row. Score, percentile and score date are unavailable, not zero.
🧬 WHAT ACTUALLY WENT WRONG?
The confirmed weakness is trust in an internal message's origin. BeyondTrust deliberately withholds the exact technical trigger; do not fill that gap using a different appliance CVE.
Mandiant's account adds observed stages: upload, SAWFLY in the site service context, later escalation, persistence and tunnelling. Those later capabilities are not guaranteed direct effects of this one CVE.
Separate documented capability, behaviour in the published intrusion and your own findings. An affected appliance warrants action; it does not prove that entire intrusion chain occurred there.
The staging web-shell path is a post-exploitation lead, not an initial exploit endpoint. Distinguish scans, failed requests and a functioning planted script using outcome and context.
📦 WHICH DEPLOYMENTS BELONG IN SCOPE?
Inventory relevant sites/appliances, standby members and recovery images. Record build, model, owner, named patch state and historical access using approved management evidence; a banner cannot prove this patch is installed.
For RS 24.3.1–26.2.3, verify BT26-05-RS application. If the base release is older than 24.3.1, use the supported upgrade route before applying it. Do not invent a successor base build as the fixed release. When records are missing or a build is outside the published matrix, ask BeyondTrust for the current supported path.
The CNA's coarse affected range ends at 26.2.3, with default unaffected status; it does not encode the separate security patch. Keep the vendor's named-patch qualification alongside it.
For SaaS, retain provider/tenant patch evidence and review historical identity, configuration and sessions where warranted. Self-hosted installation instructions do not create a customer SaaS patch action.
PRA needs careful wording. BeyondTrust says Privileged Remote Access shares affected code, but its testing found no exploitable path; it recommends a precautionary patch. That does not establish confirmed PRA exploitation or provide a PRA build matrix for this edition.
🕰️ EXPOSURE WINDOW AND TIMELINE
BeyondTrust reports 29 August exploitation of one hosted RS instance and one self-hosted appliance. Mandiant independently describes late-August zero-day use in its response case. Do not treat those bounded reports as a current global victim count.
The vendor's hunt found the hosted event on 28 September; its 27-minute containment interval starts at detection. Fix validation followed by 30 September, shipment on 8 October and stated RS SaaS completion on 9 October.
Disclosure was on 15 October: CNA publication 20:30:32 UTC, NVD 21:17:00 UTC. The vendor supplies advisory calendar dates without an exact displayed time.
Investigate from the earliest plausible exposure supported by records, extending where findings lead. Disclosure, patching and first suspicious activity differ; record any interval that predates retention.
🧭 SOC INVESTIGATION TRAIL
C01 — SCOPE: which deployment was exposed, and when was it repaired?
Question: can the owner show the exact RS site/build and BT26-05-RS installation result for the appliance you are reviewing?
Evidence: approved inventory, patch/update history, ownership and perimeter changes. Use a stable appliance/site identifier across exports, rather than matching display names alone.
Join: asset identity → base build → named patch receipt → effective UTC time → historical network access. Separate active and standby members, aliases and restored copies where they matter.
Interpretation: missing/failed patch evidence remains unresolved. Verified application supports repair at that time, leaving earlier exposure to review. Reachability is not exploitation; an exploit probe is unnecessary to check the owner's patch record.
C02 — PRESERVE: can the trail survive appliance changes?
Question: which original records and independent copies cover the suspected window before update, reset, rebuild or normal retention removes them?
Evidence: off-device syslog, proxy/WAF, firewall, identity, session/file-transfer and alert records. Request protected host evidence through BeyondTrust/IR. Mandiant's access, syslog, messages, thin-scc, brain and SSL evidence came from protected storage; do not assume customer root or decryption access.
Join: appliance/site, source system, original timezone, clock offset and collection interval. Preserve raw exports and acquisition/custody details before parsing. Where feasible, Mandiant recommends a VM snapshot including memory and disk; B Series and SaaS evidence require the supported collection route.
Interpretation: privileged access may leave local logs manipulated or incomplete. Check independent delivery/retention too. Missing evidence remains a response gap, not a clean result. Coordinate preservation without indefinitely delaying urgent repair.
C03 — HUNT: do the published tooling leads have meaningful context?
Question: do authorised evidence copies contain the reported SAWFLY/BARECLAW artifacts, request paths or related unexpected service behaviour?
Evidence: published indicators/rules, supported acquisition, access/proxy records and available service/process telemetry. Hunt unrecognised web-directory scripts or a web service spawning shells where collected; ordinary RS exports may not contain those host events.
Join: the full observed artifact or request, appliance/site, content hash, timestamp, account context and subsequent session/activity. Keep raw and normalised URI forms if your proxy decodes them; document the transformation rather than silently changing the indicator.
Interpretation: content hashes carry more weight than basenames, but neither proves initial entry through this CVE. Rule matches need triage; negatives miss unrecovered/modified files and acquisition gaps. Preserve suspected artifacts before removal.
C04 — CORRELATE: did privilege or support activity change without approval?
Question: can the service owner explain the actor, permission change and downstream session as a legitimate authorised action?
Evidence: Mandiant's examples include successful login records, user_changed events, and Jump Item/Team permissions raised from No Access to Administrator, followed by support-session activity. Useful example fields include who, who_ip, target and status. Verify your local release/parser schema before building a production query around those names.
Join: site → actor → source address → affected permission → session → endpoint/file transfer → UTC. Compare tickets, expected admin access and pre-window configuration. A VPN/residential address alone cannot attribute an actor.
Interpretation: unapproved privilege/session changes or session-bounded log gaps warrant review, especially with corroboration. BeyondTrust says third-party triage closed real privilege-escalation alerts as false positives. Preserve original alerts/dispositions and hunt beyond the open-alert queue.
C05 — REMEDIATE: can you close the entry weakness without losing the case?
Question: is the deployment on the supported patch path, and does the incident evidence require more than routine patching?
Evidence: vendor eligibility, exact BT26-05-RS installation result and owner/support response plan. Use the supported appliance interface; the authenticated KB procedure was unreadable here. Obtain exact installation/restart steps from BeyondTrust.
Join: appliance identity → approved change → installation result → subsequent service state. Keep collection, patching, containment and rebuild decisions time-stamped separately. If compromise is suspected, involve BeyondTrust and IR before destructive changes where feasible.
Interpretation: patching does not remove unknown persistence or rotate credentials. Researched persistence survives reboot/configuration reset. Mandiant recommends clean redeployment for confirmed or unresolved compromise; that is an incident decision, not a version-number conclusion.
C06 — VERIFY: what has been established, and what is still unresolved?
Question: can the owner show the patch receipt, reviewed permissions/sessions and healthy independent logging for every relevant deployment?
Evidence: patch records, supported post-change checks, configuration/access review, authentication/session monitoring and confirmed log ingestion. Include standby members and restore images that could reintroduce the old state.
Join: the same site across change, role, credential and monitoring records. Assign an owner/review time to unresolved intervals or missing evidence. Current delivery cannot recover events never forwarded.
Interpretation: distinguish four outcomes in the handover: current vulnerability repair; historical compromise assessment; credential/configuration recovery; and restored monitoring coverage. Each needs its own evidence and limits. No single “patched” checkbox can carry all four.
The analyst handover
Hand over site/model/build/patch evidence; exposure and collection windows/timezones; original evidence/custody; correlated findings and alternatives; retention/parser gaps; containment; and owner/next action. Keep customer identifiers and raw logs private.
🔎 INDICATORS AND OBSERVABLE BEHAVIOUR
GTIG/Mandiant published these file leads on 15 October. They describe post-exploitation tooling, not universal initial-entry signatures.
SAWFLY — mangoapi.php
SHA-256: dc14e215269a93fdbc4c1a80b984c23faf7af0911c6dbb85309796a6f2ae95fb
BARECLAW — ingredi_ws
SHA-256: 1f19b9a27d79c11bda00a1e8faf74a7fdd683d38ccef1b60df2fd0307e3aa462
Staging lead — app_84304470%2Ephp. The file was not recovered; no hash is supplied. Do not replace that absence with the hash of a different web shell.
Other reported leads include the WebSocket URI /uidchanarge, the artifact /usr/bin/dbus-authd and a persistence location under /home/bomgar/sbin/post_boot.d/zz-root-persist. The research also identifies sudoers and HAProxy configuration templates for review. Preserve and compare with legitimate baselines through the supported acquisition route; these are not instructions to modify the appliance.
No verified actor IP/domain set was extracted for this edition. BeyondTrust says infrastructure rotates between victims. Combine content indicators with permission/session behaviour and off-device evidence rather than allowing a clean static search to end the hunt.
🧰 TOOLS AND BOUNDED CHECKS
Check A — does your SIEM have the records the hunt assumes?
Use supported exports and the SIEM to confirm site, source types, timestamps, parser fields and continuity. RS syslog documentation covers login/appliance/console events, up to three forwarding servers and local0. Confirm actual transport/format settings.
Expected result: documented coverage and reliable login/change/session joins. Absent records require a collection/parser/activity explanation; a zero-result query cannot supply one.
Check B — does an acquired file match the published artifact content or rules?
On an authorised acquired copy, use a trusted SHA-256 utility and YARA with the published G_Hunting_Webshell_SAWFLY_1 and G_Hunting_Backdoor_BARECLAW_1 rules. Retain source, rule version/hash and scope. No live sample is needed for this workflow.
Expected result: a reproducible content comparison or named rule match tied to that copy. SAWFLY's rule requires all its strings and a file smaller than 20KB. BARECLAW has two condition branches, and its byte-pattern/three-string branch is not restricted to ELF. Preserve the published logic; do not assume every match is a confirmed executable backdoor.
Limits: tooling patterns do not establish CVE entry or appliance integrity. Variants, collection gaps and string collisions affect results. Report the artifact, acquisition context, match and corroboration.
Check C — what did the remote-support service actually broker?
Use session reports, identity and endpoint/network records to review target, operator, approval and time. Check accounts authenticating outside expected managed sessions and unexpected MFA registrations with the identity owner.
Expected result: explained sessions or bounded downstream leads. Appliance compromise warrants reviewing its reach; it does not prove every managed endpoint was compromised.
🩹 REMEDIATION AND VERIFICATION
1. Prioritise supported repair. Confirm BT26-05-RS for eligible RS releases; upgrade older-than-24.3.1 deployments first. Automatic-update enrolment is only a setting: retain the actual installation result. If the patch is unavailable or ambiguous, ask BeyondTrust for the correct path.
2. Preserve before destructive recovery where feasible, without indefinitely delaying the urgent patch. Coordinate protected evidence, VM memory/disk collection and independent logs with support/IR. Preserve the original alert disposition history and the periods in which forwarding stopped.
3. If evidence suggests compromise, use a Sev 1 support case citing BT26-05. Coordinate isolation with operations. Perimeter restrictions can preserve local configuration evidence; account for required patch, licensing and logging connectivity. End active sessions and disable affected access paths/accounts rather than deleting audit-relevant objects.
4. Resolve integrity with the response team. Mandiant recommends clean, fully patched redeployment for confirmed or unresolved compromise, using a pre-exposure configuration backup where available. A newer backup should be reviewed while isolated before reconnection. Reboot or configuration reset alone does not establish trust.
5. Rotate relevant credentials after patch/rebuild. Coordinate administrators/users, API and identity bindings, stored/brokered secrets, integrations and target-system/session credentials in dependency order. Review certificate/client/Jumpoint/console renewal with support. Fresh credentials placed into a still-controlled appliance can be exposed again.
6. Recheck permissions, session policy, API access, security providers, Jump Items/Teams, logging destinations and downstream activity against approved baselines. Prove current log delivery and keep unresolved historical gaps visible. SaaS patch completion does not replace this separate follow-up when incident evidence warrants it.
🧾 EVIDENCE SEPARATION
Vendor/CNA establish the initial capability, score and repair scope. Mandiant supplies primary intrusion observations and defensive artifacts. CISA supplies a dated catalogue snapshot; FIRST supplies a no-row response. Forge's check order, joins and handover are defensive analysis, not customer incident findings.
Direct vendor captures returned 403, while the current web-rendered advisory/blog were readable and reviewed. The authenticated KB procedure remained a login/application shell. Access limitations are recorded; no missing content is treated as a negative finding.
Exact trigger, full escalation, local compromise, current infrastructure and real detection efficacy remain unestablished. Publisher attribution to ARMORY CASTLE, formerly UNC5221, cannot be proved by a filename hit.
💜 THE CYBERFORGE VERDICT
Prioritise unverified Remote Support patch state now. Reported field exploitation and the platform's privileged role justify an evidence-led review even when catalogue or IOC lookups are empty.
Prove the named patch. Preserve the independent session trail. Explain permission changes and downstream activity. Give historical integrity and credential recovery their own owners and evidence, so a successful repair does not silently close questions it cannot answer.
🛡️ Verify the patch. Preserve the session trail. Restore the trust.
🔗 PRIMARY SOURCES AND FOLLOW-UP
BeyondTrust advisory and named patch:
https://www.beyondtrust.com/trust-center/security-advisories/bt26-05
Vendor incident/timeline and defensive guidance:
https://www.beyondtrust.com/blog/entry/bt26-05
GTIG/Mandiant investigation, indicators and YARA:
https://cloud.google.com/blog/topics/threat-intelligence/armory-castle-exploits-beyondtrust/
CVE Program:
https://www.cve.org/CVERecord?id=CVE-2026-102764
NVD:
https://nvd.nist.gov/vuln/detail/CVE-2026-102764
RS syslog guide:
https://docs.beyondtrust.com/rs/docs/syslog
CISA KEV:
https://www.cisa.gov/known-exploited-vulnerabilities-catalog
FIRST EPSS:
https://www.first.org/epss/
#CyberForge #CVEOfTheDay #CVE2026102764 #BeyondTrust #RemoteSupport #SOC #BlueTeam #ThreatHunting #IncidentResponse