BeyondTrust Remote SupportのCVE-2026-102764で実悪用を確認、BT26-05の適用と侵害確認を

この記事は約5分で読めます。

BeyondTrustは2026年10月15日付で、Remote Supportの重大な脆弱性CVE-2026-102764を公表しました。Mandiantによると、認証されていないリモート攻撃者によるファイル操作につながる問題で、BeyondTrustのCVSS v4.0評価は9.3(Critical)です。

メーカーの調査報告とMandiantの分析では、修正前の8月に実際の攻撃で悪用されたことが確認されています。Remote SupportのSaaS環境は修正済みですが、自己管理環境ではBT26-05-RSパッチの適用状況を確認する必要があります。修正前に外部へ公開していた機器は、過去の侵害についても調査が必要です。

内部メッセージの検証不足からファイル操作へ

BT26-05の公式告知によると、Remote Supportの内部コンポーネントが、受け取ったメッセージの送信元を十分に検証していませんでした。条件がそろうと、攻撃者がアプライアンス上でファイル操作を行える問題です。脆弱性の種類はCWE-290(なりすましによる認証回避)に分類されています。

メーカーのCVSS評価では、事前の権限と利用者の操作はいずれも不要です。Mandiantは、任意ファイルのアップロードが可能になると説明しています。観測された侵害では、その後にWebシェルの設置、root権限への昇格、認証情報の取得を狙う操作が続きました。

影響するバージョンと修正方法

公式告知が示す対象はRemote Support 26.2.3以前の全バージョンです。24.3.1から26.2.3にはBT26-05-RSパッチが提供されています。製品のバージョン番号に加え、このパッチが実際に適用されているか確認してください。

利用形態・バージョン 確認と対処
Remote Support SaaS メーカーが10月9日までに修正を適用済み。利用者によるアプライアンスへのパッチ適用は不要
自己管理のRemote Support 24.3.1~26.2.3 /appliance画面でBT26-05-RSの適用を確認。自動更新の対象でなければ手動で適用
自己管理のRemote Support 24.3.1未満 サポート対象版へ更新したうえでパッチを適用。更新先のバージョンは、メーカーのサポート範囲と機器構成を確認して選択

メーカーの調査報告ではパッチの提供開始は10月8日で、公式告知は10月9日までにSaaS全体へ適用済みとしています。自動更新を利用している自己管理環境も、設定が有効というだけで判断せず、適用結果を確認してください。パッチが画面に表示されない場合、MandiantはBT26-05を明記してBeyondTrustサポートへ問い合わせるよう案内しています。

Privileged Remote Access(PRA)も該当コードを共有しており、メーカーは予防的に修正を提供しています。ただし、内部テストではPRAでの悪用経路は見つかっていないとしています。Remote Supportで確認された悪用と同一視せず、自己管理のPRAについてもメーカーの案内に従いパッチを適用してください。

8月29日の攻撃と、把握されている被害範囲

BeyondTrustが10月16日12時(米国東部夏時間、日本時間10月17日1時)に更新した報告によると、8月29日に攻撃を受けたのは、同社がホストするRemote Support環境1件と、自己管理のRemote Support 1台です。この更新時点で同社が把握している被害は、顧客2件です。

Mandiantは、この活動を中国との関連が疑われるスパイ活動グループARMORY CASTLE(旧UNC5221)によるものと評価しています。同社は、公開後に悪用が広がるおそれがあると警戒しています。

調査では、WebシェルSAWFLYやトンネリングツールBARECLAW、再起動後も権限を維持するための改変、ログの削除が報告されています。侵害した管理者アカウントでサポートセッションを開始し、製品のファイル転送機能で内部端末から文書を持ち出した操作も観測されています。アプライアンス上のログが残っていないことだけでは、侵害を否定できません。

米CISAも10月16日、CVE-2026-102764を悪用が確認された脆弱性のカタログ(KEV)へ追加しました。

パッチ適用後も確認したい認証情報と接続先

Mandiantは、悪用期間中に脆弱なバージョンでインターネットから到達できた機器を、調査が済むまでは侵害の可能性があるものとして扱うよう勧めています。SaaS環境でも、修正済みであることが、修正前の認証情報や設定の安全性を保証するわけではありません。

  1. 修正を適用し、必要に応じて再構築する。 通常はパッチ適用を優先します。侵害が疑われる場合は、変更や再起動で証拠を失わないよう、メーカーや調査担当者と証拠保全・隔離の順序を調整してください。侵害が確認された機器や、侵害の有無を判断できない機器には、修正済みのクリーンなイメージからの再構築をMandiantは推奨しています。利用者はホストのファイルシステムを監査できず、ホストに仕込まれた永続化の仕組みは再起動や設定リセットでは取り除けないためです。
  2. 機器の外に残るログと設定を調べる。 SIEM、リバースプロキシ、境界ファイアウォールなどの記録と照合し、覚えのない管理セッション、ユーザーや権限の変更、ログ転送の途切れを確認します。Jump ItemやTeamの権限変更、サポートセッションの接続先も調査対象です。
  3. 修正または再構築の後で認証情報を更新する。 調査に応じて、管理者アカウント、APIシークレット、Vault内の情報、連携先の認証情報などを対象にします。攻撃者が機器を制御したまま認証情報だけを変えると、新しい情報も取得されるおそれがあります。セッションや登録済みクライアントの失効・再展開、特権アカウントに追加されたMFA登録の確認も、公式手順に沿って進めてください。
  4. 管理画面の公開範囲を見直す。 /loginや/applianceを信頼できるネットワークに限定し、必要なサポート通信と管理用の通信を分けます。アクセス制限は補完策であり、パッチの代わりにはなりません。

管理製品を狙った別の事例として、N-able N-centralの脆弱性を扱った記事も参照してください。今回とは別製品・別CVEの問題です。

参考情報

本記事は2026年10月17日時点で確認した公開情報に基づいています。

コメント

タイトルとURLをコピーしました