この記事のポイント
- 脆弱性
- CVE-2026-102764
- 深刻度
CRITICAL9.3
- 対象
- BeyondTrust Remote Support
- 悪用状況
- 確認済み
- 情報の種類
- 二次情報のみ
- 公表日
目次
BeyondTrustは2026年10月15日、Remote Supportの重大な脆弱性CVE-2026-102764を公表しました。Google Threat Intelligence Group（GTIG）とMandiantも同日付の分析で、8月下旬にゼロデイとして悪用された証拠を確認したと報告しています。遠隔保守の入口にある製品だけに、修正の適用と、その入口が扱っていた認証情報や接続先の点検を分けて進める必要があります。
本記事の情報確認日は2026年10月16日です。提供元と分析元のページに表示された公開日、確認された攻撃の時期、修正の展開時期を区別します。日本国内の被害件数を確認した記事ではありません。事実関係は一次情報に基づき、Web運営での担当分担や確認手順は本サイトの提案として示します。出典：BeyondTrust公式：セキュリティ勧告BT26-05、Google GTIG・Mandiant：ARMORY CASTLEによるBeyondTrust悪用の分析。
スポンサーリンク
公開前から悪用されていたという時間差
ゼロデイ悪用とは、公に修正や情報が整う前の段階で脆弱性が利用されたことを指します。今回、10月15日の公表だけを見て「15日以降のログを調べればよい」と決めると、過去の露出を見落とします。提供元の時系列と分析資料は、8月の活動を扱っています。
| 日付 | 一次資料に示された出来事 |
|---|---|
| 2026年8月29日 | BeyondTrustは、自社ホストのRemote Support 1インスタンスとセルフホスト1台への悪用を記載。 |
| 2026年10月8日 | 提供元の時系列ではBT26-05パッチをSaaS・セルフホスト向けにリリース。 |
| 2026年10月9日まで | セキュリティ勧告ではRemote Supportの全SaaS顧客へ修正を適用済み。 |
| 2026年10月15日 | 勧告と分析を公表。 |
| 2026年10月16日 | 本記事で情報を確認。攻撃開始日として扱う日付ではない。 |
リリース日と、SaaSへの適用が完了した日付は別の情報です。また、記載された事例数から、全体の被害規模を推定することも避けます。自環境の調査期間は、導入履歴、外部への公開期間、更新記録を保守先と照合して決めます。出典：BeyondTrust公式：ARMORY CASTLEとBT26-05への対応、BeyondTrust公式：セキュリティ勧告BT26-05。
対象と修正状況は製品名・版・パッチで判定する
勧告BT26-05の対象製品はRemote Support（RS）です。内部コンポーネントが受信メッセージの送信元を十分に検証しない問題で、条件が成立すると遠隔の攻撃者がアプライアンス上でファイル操作を行える可能性があると説明されています。CVSS v4.0の基本値は9.3、深刻度はCriticalです。
| 利用形態・版 | 確認すべき対応 |
|---|---|
| Remote Support SaaS | 提供元は10月9日までに全顧客への修正適用済みと案内。 |
| セルフホストのRemote Support 24.3.1〜26.2.3 | BT26-05-RSパッチの適用状況を確認。自動更新未登録なら手動適用を案内。 |
| セルフホストのRemote Support 24.3.1より前 | パッチを適用できる新しい版へアップグレードが必要。 |
影響範囲は26.2.3以前です。「自動更新を有効にしているはず」「画面の番号が新しく見える」だけで完了扱いにせず、対象パッチの適用結果を確認します。古い版では更新とパッチ適用の工程を分け、具体的な手順は提供元へ確認してください。出典：BeyondTrust公式：セキュリティ勧告BT26-05。
スポンサーリンク
Privileged Remote Accessは確認済みの影響と予防対応を分ける
提供元の補足では、Privileged Remote Access（PRA）も関連するコードを共有するため、予防的にパッチを提供し、セルフホスト利用者へ適用を推奨しています。一方、同社の内部試験ではPRAで悪用する方法を確認していないと明記しています。Remote Supportで確認された事実を、そのままPRAの悪用確認へ広げてはいけません。出典：BeyondTrust公式：ARMORY CASTLEとBT26-05への対応。
運用上は、製品が複数ある組織で資産を一つの「BeyondTrust環境」とまとめないことを提案します。RSかPRAか、SaaSかセルフホストか、どの担当が管理するかを分けて記録すれば、修正状況と調査対象を誤って混ぜにくくなります。
なぜWebサイトの担当者にも関係するのか
Web運営には、公開サイトそのものだけでなく、管理者端末、サーバー保守、委託先の遠隔支援といった裏側の経路があります。以下は説明用の仮想例です。制作会社が顧客サーバーの保守に遠隔支援基盤を使っているなら、サイト本体の更新が済んでいても、その保守経路について確認が必要になる場合があります。
今回の分析では、侵入後の権限昇格、認証情報を狙う動き、永続化、ログ削除が報告されています。これは全顧客で同じ行動があったという意味ではありません。しかし、製品の修正だけでなく、そこから何に接続できたかを確認する理由になります。出典：Google GTIG・Mandiant：ARMORY CASTLEによるBeyondTrust悪用の分析。
自社で製品を導入していなくても、保守委託先が使っている場合はあります。ただし、利用者名簿を推測したり、根拠なく自サイトの侵害を宣言したりするのではなく、契約上の連絡先へ利用有無と対応状況を確認します。一般のサイト閲覧者に、無関係な製品の設定変更を求める話ではありません。
スポンサーリンク
第一段階は露出の把握と公式の修正
Mandiantは、脆弱な状態でインターネットから到達できたアプライアンスについて、調査が済むまで侵害の可能性を考慮し、パッチを優先する段階的な対応を推奨しています。単に現在到達できないことではなく、過去にどの状態で公開されていたかが判断材料です。出典：Google GTIG・Mandiant：ARMORY CASTLEによるBeyondTrust悪用の分析。
本サイトの提案として、担当者はまず正式な製品名、稼働場所、版、パッチ、外部公開期間、管理責任者を一覧にします。保守会社が管理する場合は、回答日と対象範囲も残します。その上で公式の修正手順へ進み、証跡の保管や業務影響の調整を並行して行います。調査の準備を口実に、未修正の入口を長時間公開したままにしないことが重要です。
不審な挙動がある場合は、隔離や保守セッションの停止を含めて専門担当と判断します。隔離は遠隔支援業務を止めるため、代替の連絡方法と緊急時の操作手段を確保してください。端末の再起動だけで安全になったと判断したり、調査前に不審なファイルを手当たり次第に削除したりしないようにします。
パッチは脆弱性を修正するもので、侵入後に作られた永続化をすべて除去する保証ではありません。Mandiantは、侵害が確認された場合や侵害状況が不明な場合、クリーンで修正済みのイメージから再構築する選択肢を示しています。パッチ適用済みという一点だけで装置を信頼できると判断せず、調査結果に応じた復旧方法を専門担当と決めます。出典：Google GTIG・Mandiant：ARMORY CASTLEによるBeyondTrust悪用の分析。
第二段階は認証情報と既存セッションの扱い
認証情報を交換しても、交換先を扱う装置が侵害されたままなら、新しい秘密の値も再び見られるおそれがあります。Mandiantは、認証情報のローテーションをパッチ適用または再構築の後に行うよう注意しています。変更する順序は、失効の速さだけでなく、新しい値を信頼できる状態で扱えるかで決めます。出典：Google GTIG・Mandiant：ARMORY CASTLEによるBeyondTrust悪用の分析。
運用案としては、装置の管理アカウント、API連携、認証基盤との接続、保守先で使うアカウントを、依存関係ごとに確認します。リストには値そのものを書かず、所有者、用途、更新先、失効方法を記録します。一つのパスワードを交換して終わりではなく、そのアカウントがどの接続を許していたかを追えるようにします。
既存のセッションや登録済みクライアントの扱いも、パスワード交換とは別の確認事項です。どの経路を終了・再登録する必要があるかを、公式の復旧案内と自環境の構成で判断します。検証せずに全端末を切り離すと保守に支障が出るため、対象、実施順、再接続の責任者を明確にします。
第三段階はログと設定の整合を確かめる
提供元は、アプライアンスのログを外部へ転送することを推奨し、今回の攻撃者がローカルのログを削除すると説明しています。保存先が同じ装置だけなら、侵害と一緒に記録を失う可能性があります。出典：BeyondTrust公式：ARMORY CASTLEとBT26-05への対応。
自組織での点検案として、外部に保存した記録と変更申請を対応させます。たとえば、正規の担当者や作業依頼に結び付かない管理セッション、説明できないアカウントや権限の変更、ログ転送の途切れを調べます。外部IPや時間帯が珍しいだけで侵害と確定せず、業務上の根拠と組み合わせて確認します。
何も記録されていない場合も、記録が残っていない理由を分けます。アクセスがなかったのか、保存期間が短かったのか、収集が止まっていたのかでは結論が変わります。調査できた期間と調査できなかった期間を明示し、ログが空だから過去の侵害もない、と結論を飛ばさないようにします。
AIが使われたという評価は証拠と分ける
BeyondTrustは、攻撃者がAIを使って製品への理解を維持し、攻撃チェーンを開発しているとの作業仮説を述べています。ただし、AI対応ツールを使ったことのフォレンジック上の証明はないと明記しています。本件を「AIが自動で侵入した事件」と断定する根拠にはできません。出典：BeyondTrust公式：ARMORY CASTLEとBT26-05への対応。
防御側が行うべきことは、この未確認の点に依存しません。攻撃者がAIを使っていてもいなくても、未修正の公開経路、過大な権限、失効されない認証情報、失われるログは点検対象です。攻撃者の道具の推測より、確認できる公開状態と権限の範囲から対策を進めます。
スポンサーリンク
完了条件を一枚のチェック表へ残す
以下は本サイトの確認項目案です。公式の環境別手順や専門調査を置き換えるものではありません。製品の修正と、過去の影響を評価する作業を別々に記録するために使います。
- 対象判定：RS・PRA、提供形態、版、公開期間、管理者を確認した。
- 修正：環境に合う公式パッチの適用結果を確認した。
- 影響評価：調査できた記録と、確認できない範囲を残した。
- 認証情報：安全な状態で更新し、必要な失効や再登録を判断した。
- 再開判定：必要な保守経路だけが動作し、監視と記録が継続することを確認した。
SaaSで本体の修正が完了していることも、セルフホストでパッチが入ったことも、それ自体は重要な進捗です。ただし、自組織における過去の露出や認証情報の影響評価とは分けて扱います。今回の教訓は、遠隔保守基盤を「便利な裏方」として台帳の外へ置かないことです。最新の公式情報を確認し、変更と調査の責任者を決めて対応してください。
