遠隔保守の入口が狙われたら、パッチだけで対応は終わるのか

コンサルオジ

2026年10月22日 02:02

会社のパソコンが動かなくなったとき、保守担当者に、遠隔で画面を見てもらうことがありますよね。そのための入口そのものが、攻撃者に使われていた。

今日は、そんな重大な脆弱性の話です。

先に、対応の要点をお伝えします。使っている製品と管理方式を確認し、専用の修正パッチを適用する。

そして、すでに侵入されていないかを調べる。今回は、この二つを分けて進める必要があります。

こんにちは、限界コンサルおじです。取り上げるのは、ビヨンドトラストの、リモートサポートという企業向け製品です。

離れた場所のパソコンに接続して、トラブルを調べたり、操作を支援したりするための仕組みです。

問題は、危険なことができそうだ、という予測だけではありません。提供元と侵害調査の報告が、実際の悪用を確認しています。

危険度の評価は、十点満点で九点三。ただし、この点数は、九十三パーセントの会社が被害に遭う、という意味ではありません。

この製品を使っていない方も、保守の委託先が何を使っているかを確認するきっかけにしてください。自社で契約した記憶がなくても、接続を許可している保守の仕組みがあれば、その管理者をたどることが大切です。

前提の整理と全体の見取り図（何をすべきかの全体像）

まず、どこに問題があったのか。提供元の説明では、製品内部でやり取りするメッセージについて、どこから届いたものかを十分に確かめていませんでした。

条件がそろうと、遠隔の攻撃者が装置上でファイルを操作できる問題です。

たとえるなら、社内便で届いた指示書を、差出人の確認が不十分なまま受け付けてしまうようなものです。これは説明のための比喩で、実際の攻撃がメールで行われるという意味ではありません。

この脆弱性に付いた識別番号は、付録に正確に載せています。今日は、番号の暗記よりも、何を直し、どこまで調べるかを持ち帰ってください。

ここで、問題そのものと、その後の被害を混ぜないことが重要です。入口の弱点は、不正なファイル操作につながる問題。

一方、調査報告では、侵入後に権限を引き上げ、再び入れる仕掛けを残した行動も記録されています。

権限とは、その人やプログラムに許された操作の範囲です。閲覧だけの人が、設定を変更できる管理者になれば、できることが大きく変わります。

このように、より強い権限を得ることを、権限の昇格と呼びます。

侵入後に、外から命令を受け付ける不正なプログラムを置くこともあります。ウェブシェルという言葉が出てきたら、ウェブ経由で攻撃者の操作を受け付ける裏口、と考えてください。

ただし、すべての利用企業で、そこまで起きたと確認されたわけではありません。今回の調査で観測された行動と、いま自社で起きていることは別です。

被害を決めつけず、かといって、パッチを入れたから何もなかったと判断しない。この姿勢で進めます。

なお、確認した提供元の説明は、把握している被害は二つの顧客で、八月以降の攻撃活動の証拠は見ていない、と範囲を限っています。「実際に悪用された」と、「いま大規模攻撃が続いている」は別です。

後者を確認済みの事実として話しているわけではありません。

第1章：海外一次データが示す現場の変化

最初の作業は、対象の確認です。情報システムの担当者、ヘルプデスク、保守の委託先に、ビヨンドトラストのリモートサポートを使っているか尋ねてください。

機器やサービスの一覧、契約、保守の接続先と照らし合わせます。

次に、その仕組みを誰が管理しているかを分けます。一つは、提供元が管理するクラウド型。

もう一つは、自社や委託先が装置を管理する、自社設置型です。自社設置型は、必ずしも会社の建物の中にあるという意味ではありません。

クラウド上の仮想的なサーバーでも、自分たちで管理するなら、こちらに当たる場合があります。

提供元は、クラウド型のリモートサポートについて、十月九日までに修正を適用したと説明しています。これは、装置側のパッチの話です。

利用企業側の設定や、過去の不審な接続まで、すべて調べ終えたという意味に広げないでください。

一方、自社設置型では、自動更新の設定と、実際にパッチが入ったかを確認します。自動更新を有効にしている、という設定と、今回の更新が成功した、という結果は別です。

また、似た名前の別製品に、特権リモートアクセスがあります。こちらは、強い権限で機器へ接続する業務を管理する製品です。

提供元は、共通するコードへの予防的な対応として、こちらにもパッチ適用を勧めています。

ただし、提供元の試験では、この別製品で今回の弱点を悪用する方法は確認されていない、としています。二つの製品をまとめて、どちらも悪用が実証されたと説明するのは正確ではありません。

製品名を確かめ、それぞれの案内に沿って対応してください。

第2章：技術的・構造的な仕組みと落とし穴

ここから、具体的な更新です。自社設置型のリモートサポートを管理する担当者は、まず製品のバージョンと、適用済みパッチを確認します。

公式が今回の影響対象として挙げているのは、二十六点二点三までの版です。そして、修正として案内しているのは、二十四点三点一から二十六点二点三の範囲に対する、専用パッチです。

正確な名前は付録に載せています。

ここで、「自分は二十六点二点三だから、もう大丈夫」とは判断できません。同じ版番号でも、専用パッチを適用したかどうかを、別に確かめる必要があります。

管理画面では、アプライアンスという、装置を管理する画面に入ります。そこから、アップデーツ、更新のページを開きます。

チェック・フォー・アップデーツという、更新を探す操作を行い、今回のパッチが表示されるか確認します。

パッチを入れる前には、設定のバックアップと、作業を行う時間を確認してください。バックアップは、元に戻すための控えです。

通常の更新に備える控えと、侵入の痕跡を残すための証拠保全は、目的が違います。侵入が疑われるときの順番は、このあと説明します。

製品の更新で接続が途切れる場合があるため、保守作業中の人と調整します。表示された配布物を公式案内と照合し、該当する更新を適用します。

装置専用の更新手順を使い、一般的なサーバーの更新命令を、自己判断で代用しないでください。

二十四点三点一より古い版では、先に製品を更新してから、専用パッチを適用する必要があります。古い環境を、一度で最新まで上げられるとは限りません。

途中の更新が必要な場合は、その順番と、接続用ソフトへの影響を、提供元に確認します。

更新が見つからない場合も、安全と決めつけず、今回の注意喚起の番号を添えて問い合わせます。最後は、適用済みパッチの一覧など、製品が示す記録で確認します。

新しい修正を含む版への移行を案内された場合も、今回の問題への対応を、提供元の説明で照合してください。

第3章：海外ポッドキャストの肉声と実務の壁

ここまでが、脆弱性を直す作業です。次に、侵入された可能性への対応です。

調査報告は、攻撃が行われた期間に、弱点のある装置がインターネットから到達できたなら、調査を終えるまで、侵入された可能性を考えて扱うよう求めています。だからといって、公開していた会社は全社、侵入されたという意味ではありません。

調べる必要がある、ということです。

不審な接続や、覚えのない変更がある場合は、セキュリティ担当者と提供元へ連絡します。そこで大切なのが、証拠を残すことです。

ログという記録や、装置の状態を、調査に使える形で保全します。

仮想的な装置なら、メモリを含む状態の保存や、ディスクの控えが必要になる場合があります。自分たちでは取り出せない情報もあるので、提供元や調査担当者と方法を決めます。

疑わしい状態で、何度も再起動したり、初期化したりする前に相談してください。

同時に、攻撃者からの接続を止めるため、装置の外側にある通信制御で隔離することを検討します。隔離とは、その装置と外部、あるいは社内の他の機器との通信を制限することです。

保守業務も止まるため、代わりの連絡方法と対応窓口を決めます。

侵入のない通常の更新と、侵入が疑われる装置の復旧では、手順が変わります。後者では、パッチを入れて終わりにせず、残された裏口の有無を調べ、必要なら信頼できるイメージから再構築します。

再構築は、装置の中身を、確認できる土台から作り直すことです。

この判断を、現場の担当者一人に背負わせないでください。保守を続ける必要性と、侵入を広げない必要性を並べて、責任者と判断します。

第4章：私なりの解釈（何をすればいいか：構造変化の核心）

もう一つ、大切なものがあります。パスワードや、システム同士が接続するための秘密の文字列です。

これらをまとめて、認証情報と呼びます。誰が接続してよいかを判断するための、鍵に当たります。

遠隔保守の装置は、ほかの機器につながるための情報を扱うことがあります。装置の穴を直しても、持ち出された可能性のある鍵が、ひとりでに無効になるわけではありません。

ここは、建物で考えると分かりやすいと思います。侵入口になった窓を修理しても、部屋の中に置いてあった合鍵を持ち出されていたら、鍵の交換も必要です。

何を盗まれたかを調べる仕事と、窓を直す仕事は別です。

調査担当者と、どの認証情報が装置に保存され、どの接続で使われたかを洗い出します。管理者、連携先、接続先の機器。

それぞれの担当者と、変更する順番を決めます。

ただし、攻撃者がまだ装置を操作できる状態で、そこへ新しいパスワードを流してしまうと、新しい鍵まで見られるおそれがあります。パッチ適用や、必要な再構築によって装置を信頼できる状態に戻してから、認証情報を交換する順番を調整します。

さらに、誰がどの機器へ接続できるかという権限も見直します。知らないアカウントが増えていないか。

以前は閲覧だけだった人が、管理者になっていないか。変更の申請や承認記録と突き合わせます。

ログインを続けている状態も確認します。この接続中の状態を、セッションと呼びます。

パスワードの変更だけで、すべての接続が切れるとは限らないので、製品の案内に従って、不要なセッションや接続用の資格を無効にします。

ここからは、私からの運用上の提案です。認証情報の交換は、一覧を作ってから進めてください。

一斉に変えるだけでは、業務の連携まで止めるおそれがあります。変更担当、変更先、動作確認を一組にして、抜けと二重作業を防ぎます。

【実践・深掘りパート：具体的やり方・試行錯誤の記録】実務で機能する3層ハイブリッド設計

調査では、何を見ればよいのでしょうか。まず、ログイン、権限変更、遠隔接続、ファイルの受け渡しなどの記録を確認します。

誰が、いつ、どこから、何をしたかを、正規の保守作業と照合します。

たとえば、深夜の接続があった。それだけで攻撃とは限りません。

夜間保守の予定があったかもしれません。一方、担当者も作業依頼も分からない接続なら、調べる理由になります。

見覚えがないから即座に削除するのではなく、記録を残し、関係者へ確認します。

今回、提供元の説明では、装置の中のログを消す行動も観測されています。だから、記録がないことだけで、何も起きなかったとは判断できません。

装置の外にも記録を残せるようにすることが、今後の備えになります。ログを別の場所に転送して保管する仕組みです。

装置の中の記録が消えても、別の管理下にある記録が残れば、調査の手掛かりになります。

このとき、保存の設定をしただけで満足しないでください。私なら、正規の試験操作を一つ行い、転送先に時刻と内容が届くことまで確認します。

装置から送っているつもりでも、受け取る側が保存できていなければ、調査には使えません。

また、攻撃の痕跡を探す資料に、特定のファイル名や通信先が載っていることがあります。これは、ある攻撃で見つかった手掛かりです。

その名前がないから安全、その通信先がないから無事、と単純には言い切れません。

提供元も、被害先ごとに使う仕組みが変わることを踏まえ、行動を調べるよう勧めています。見覚えのない管理者の操作、承認のない権限変更、説明できない記録の途切れ。

こうした変化を、複数の記録で照合します。

もちろん、記録の欠落には、保存期間や通常の障害など、別の理由もあります。一つの兆候だけで侵入を断定せず、調査結果と、まだ分からないことを分けて残してください。

結論：現場で実際に試してつまずいた箇所・修正手順と明日からの3大アクション

最後に、対応をどう終えるかです。私は、三つに分けて記録することを勧めます。

一つ目は、弱点の修正です。どの装置に、どのパッチを、いつ適用したか。

管理画面の記録や提供元の回答で確認します。「担当者へ依頼済み」は、ここでは完了になりません。

二つ目は、侵入の可能性への対応です。過去に外部から接続できた期間を調べ、必要な記録を保全し、侵入の痕跡を確認します。

追加の調査が必要なら、修正自体は完了していても、こちらは調査中と残します。

三つ目は、業務の再開確認です。許可された担当者が、必要な機器へ接続できるか。

不要な権限が戻っていないか。記録が届くか。

通常の保守作業を試し、実際に使えることまで確認します。

緊急時には、いくつかの選択肢があります。侵入の疑いがなく、更新が可能なら、確認のうえで速やかにパッチを適用する。

侵入が疑わしいなら、証拠を残し、隔離や再構築を含めて進める。すぐ更新できないなら、接続範囲を制限し、提供元と最短の対応を決める。

どの方法にも業務への影響があります。隔離すれば、遠隔保守が止まる場合があります。

公開を続ければ、その間の危険が残ります。だから、止めるか止めないかを、担当者の気分で決めず、代替手段とリスクを責任者へ示してください。

ここからは、私の見立てです。遠隔保守の仕組みは、困ったときだけ思い出す道具になりがちです。

でも、どこへ接続でき、どんな鍵を扱うかを考えると、会社の重要な入口です。製品を導入したときだけでなく、更新、権限、記録を、継続して管理する必要があります。

今回の事案は、すべての会社が侵入されたという話ではありません。実際の悪用が確認された製品について、自社の対象を確かめ、必要な修正と調査を進める話です。

正確な製品名、専用パッチ、確認先は付録にまとめました。保守担当者と共有して、対応の範囲をそろえてください。

今回の内容が現場の確認に役立ったら、高評価とチャンネル登録をお願いします。皆さんの環境で遠隔保守の更新や確認を進めるなかで気になった点があれば、ぜひコメント欄で教えてください。

画面に表示されている関連動画や概要欄の詳細なノート記事もあわせてご覧ください。限界コンサルおじでした。

それでは、また次回お会いしましょう。

付録：対象製品・識別番号・専用パッチ一覧

対象製品：BeyondTrust Remote Support（RS）／Privileged Remote Access（PRA、予防的対応推奨）
アドバイザリ／脆弱性識別番号：BT26-05 / CVE-2026-102764（CVSS v4 9.3、内部メッセージ送信元検証不備による認証不要の任意ファイル操作、CWE-346 / CWE-73）
影響対象バージョン：Remote Support 26.2.3 以前（専用パッチの対象範囲は 24.3.1〜26.2.3。24.3.1 より古い版は先に製品本体の更新が必要）
専用パッチ名：Remote Support 用 BT26-05-RS ／ Privileged Remote Access 用 BT26-05-PRA
管理画面での確認先：/appliance ＞ Updates ＞ Check for Updates（適用後は Installed Patches 等で適用記録を確認）
侵害調査の参照先：Google Cloud Threat Intelligence / Mandiant 報告（脅威クラスター ARMORY CASTLE、Option 2：不審兆候の洗い出し、Option 3：侵害疑い時の隔離・証拠保全・信頼できるイメージからの再構築）

参照した海外一次資料・出典リンク一覧

この記事は、ポッドキャスト放送回の台本と一次資料をもとに再構成しました（確認日：2026年10月22日）。