本文へ移動
技術を、自社の仕事に。
判断と実行を助けるメディア

記事を検索

BeyondTrust Remote Supportのゼロデイ 修正の後に確かめること

目次 · 6項目

社内のPCや取引先の端末を遠隔で操作するリモートサポートの製品は、多くの端末に入れる権限と、そのための資格情報を1か所に集めています。そのため、製品の機器そのものが乗っ取られると、被害はその機器だけにとどまりません。

GoogleのMandiant(脅威インテリジェンスの部門)は2026年10月15日(米国時間)、BeyondTrust Remote Support(旧称Bomgar)の脆弱性CVE-2026-102764が、公表前の8月下旬からゼロデイとして攻撃に使われていたと報告しました。報告は、侵入の後に何が行われたかと、利用している組織が取るべき対応を詳しく示しています。

この記事では、Mandiantの報告をもとに、修正を当てた後にも確かめるべきことを整理します。BeyondTrust Remote Supportを使っている情報システムの担当者や、この製品で保守サービスを提供している事業者が対象です。ほかのリモートサポート製品を使っている場合も、同じ観点で自社の設定を見直す材料になります。

何が起きたか

BeyondTrustは10月15日に、告知BT26-05とCVE-2026-102764を公表しました。告知によると、製品の内部の部品が、受け取ったメッセージの送り元を十分に確かめていませんでした。条件がそろうと、遠隔の攻撃者が機器(アプライアンス)の上でファイルを操作できます。深刻度はCritical(CVSS v4で9.3)で、対象は26.2.3以前のすべての版です。Mandiantの報告は、認証なしで機器に任意のファイルを置けると説明しています。

Mandiantが対応した事案では、攻撃者(中国との関係が疑われるARMORY CASTLE。以前はUNC5221として追跡)が、8月下旬にこの脆弱性を使っていました。BeyondTrustのブログによると、8月29日にBeyondTrustが運用するSaaS版の1件と、自社運用の機器1台が攻撃を受けました。BeyondTrustは9月28日に兆候を見つけ、10月8日に修正を公開しています。ブログの最終更新(10月16日)の時点で、BeyondTrustが把握している被害はこの2社で、8月より後に攻撃者の活動は見つかっていないとしています。

米国のCISA(サイバーセキュリティ・インフラストラクチャ安全保障庁)は10月16日、この脆弱性を「悪用が確認された脆弱性」のカタログ(KEV)に加えました。

侵入の後、攻撃者は次のことを行っていました。

  1. Webシェル(SAWFLY)を置き、サイトのサービス用のアカウントの権限で命令を実行する
  2. シェルの実行ファイルを別名でコピーし、rootの権限で動くように設定して、root相当の裏口を作る
  3. 機器が保管する資格情報の金庫(vault)を、機器に備わる管理用のコマンドで取り出そうとし、その操作のログを消す
  4. 起動のたびに実行されるスクリプトを置き、サービス用のアカウントにパスワードなしの管理者権限を与える設定を、再起動や設定の初期化の後も残るようにする
  5. 管理画面に管理者のアカウントでログインし、そのアカウントのJump Item(遠隔操作できる端末)とチームの権限を「No Access」から「Administrator」に引き上げる
  6. 社内の端末にリモートサポートのセッションをつなぎ、ファイル転送の機能でソフトウェアの一覧などの資料を持ち出す
  7. 通信を中継するツール(BARECLAW)を置き、機器の中のリバースプロキシの設定を書き換えて、インターネットから届くようにする

報告は、攻撃者が機器のログを繰り返し消していたことも示しています。機器の中のログだけでは、何があったかを追えない可能性があります。

修正の当て方

第一の対応は、BeyondTrustの修正(BT26-05)を当てることです。BeyondTrustの告知とMandiantの報告による整理は次のとおりです。

利用の形態告知と報告が示す対応
SaaS版2026年10月9日までに全顧客へ適用済み。BeyondTrustは追加の作業は不要としているが、Mandiantは資格情報と設定の確認(後述)は必要としている
自社運用で24.3.1〜26.2.3管理画面(/appliance)からBT26-05-RSを適用する。自動更新を登録している場合は、適用されたかを確かめる
自社運用で24.3.1より前新しい版に上げてから修正を当てる。上げても、それ以前の侵入は取り除かれない(Mandiantの報告)

告知は、修正をv24.3.1〜v26.2.3向けのBT26-05-RSとしています。Mandiantの報告は、/applianceに修正が表示されない場合はBT26-05を挙げてBeyondTrustのサポートに問い合わせるよう案内しています。また、脆弱な版のまま攻撃の期間中にインターネットから届く状態だった機器は、確認が済むまで侵害されたものとして扱うよう求めています。

同じ会社のPrivileged Remote Access(PRA)について、BeyondTrustのブログは、社内の試験では悪用の方法は見つかっていないものの、影響のあるコードを共有しているため念のため修正を出したと説明しています。自社運用のPRAにも、直ちに修正を当てるよう勧めています。

BeyondTrustの告知のページは、編集部の環境から直接は開けませんでした。上の内容は、Internet Archiveに10月17日に保存された告知とブログの写しで確かめたものです。実際の作業では、BeyondTrustの最新の告知とサポートの案内を必ず確認してください。

BeyondTrust Remote Supportの対応の順番を示す図。まず修正のBT26-05を当てる、侵害の疑いがあれば機器のスナップショットとログを保全して境界で遮断し、クリーンなイメージから作り直す。修正や作り直しの後に、管理者・APIの資格情報や金庫の資格情報を順に変え、Jump Itemの役割や外部への送信先の設定変更を見直し、セッションの記録で持ち出しを確かめる。資格情報の変更は修正の後に行う

修正の後に確かめること

報告は、修正を当てただけでは侵入の痕跡は消えないとして、次の確認を挙げています。ここでは、作業の順番が分かるように整理しました。

侵害の疑いがある機器は、作り直す

仮想アプライアンスは、変更や再起動の前にメモリを含むスナップショットを取り、ディスクを書き出して保全します。そのうえで、機器の設定ではなくファイアウォールで外部からの通信を止め、外向きの通信はBeyondTrustの更新・ライセンスの宛先以外を止めます。報告は、利用者は機器の中のファイルを調べられず、再起動や設定の初期化をしても残る仕掛けがあるため、侵害が確認された機器や判断がつかない機器は、修正済みのクリーンなイメージから作り直すよう勧めています。

資格情報は、修正の後に、順番に変える

報告は、資格情報を変えるのは機器に修正を当てるか作り直した後にするよう注意しています。先に変えると、まだ機器を握っている攻撃者に新しい資格情報も渡ってしまうためです。変える対象は、機器の管理画面の資格情報、管理者とローカルの利用者、APIの秘密情報、認証の連携先のアカウントやSAMLの署名鍵、金庫に保管した資格情報(接続先の側で変える)、メール送信やログ転送などの連携の資格情報、そして期間中にセッションの中で入力された資格情報です。

設定とセッションの記録を見直す

攻撃の前の状態を基準に、利用者と役割の変更(特にJump Itemの役割がAdministratorに上がったもの)、グループやセッションのポリシー、APIのアカウント、認証の連携先、Jump ItemとJumpoint、外部へのイベント通知やログの送信先を見直し、変更の記録や担当者が分からないものは取り除きます。期間中のセッションの記録(ファイル転送を含む)から、どの端末に接続され、何が持ち出されたかを確かめ、接続された端末はすべて調査の対象にします。

次に備えて変えておく設定

報告は、今後の被害を小さくするための設定も挙げています。

  • 管理画面(/login と /appliance)は、接続元のIPアドレスやネットワークで制限する
  • 管理画面の利用者には、フィッシングに強い多要素認証付きのシングルサインオンを求め、ローカルのアカウントは緊急用の1つだけにする
  • グループのポリシーで、Jump Itemの役割の既定を「No Access」にする
  • 特権の資格情報は、機器の金庫ではなく、別の金庫の仕組みに置く
  • 機器からの外向きの通信は、既定で拒否する
  • ログは暗号化した通信で外部のログ基盤に送り、数か月分を保管する。ログの送信が途切れた時間帯は、改ざんの兆候として見る

最後の点は、機器の中のログが消されていた今回の事案から特に重要です。機器の外にログがなければ、何があったかを後から確かめる手段がほとんど残りません。

ここからは編集部の整理です。リモートサポートの機器は、委託先の保守の担当者が使う場合もある仕組みです。誰がどの端末に、いつまで接続できるかを常設の権限にしない考え方は、委託先の本番権限を「必要なときだけ」に切り替えるで扱っています。保守の契約の中で、こうした機器の更新やログの保管を誰が担うかを決めておくことも、システムの保守・運用契約で発注者が見るべきことの観点として重要です。

確認した範囲

2026年10月27日に、Google Cloud Blogに掲載されたMandiant(Google Threat Intelligence Group)の報告「ARMORY CASTLE Exploits BeyondTrust」(2026年10月15日、米国時間)、CVEの登録情報(cve.org、NVD)、CISAのKEVカタログを確認しました(資料調査)。BeyondTrustの告知BT26-05とブログは、編集部の環境から直接は開けず、Internet Archiveに10月17日に保存された写しで確認しました。それより後の告知の更新は確認できていません。製品の操作や、侵害の痕跡の調査は行っていません。

社内のIT機器の更新の体制や、ログの保管の仕組みづくりは、IT・Google Workspace 無料相談からお問い合わせください。

参考資料

この記事を共有XFacebook
鈴木 翔

技術の可能性に魅了され、学生時代からプログラミングとデジタルアートの分野に深い関心を持つ

この記事のテーマを、自社の次の一歩へ

自社での進め方を、具体的に。

つくりたい仕組み、既存システム、運用の条件を整理し、実現に向けた次の一歩を考えます。

  • 実現したい仕組み
  • 既存環境との接続
  • 運用の条件
開発・運用の構想を相談する

構想段階からご相談いただけます。この記事の情報を相談フォームに引き継ぎます。

最新記事をメールで受け取る