ScreenConnectの拡張機能が入口か、最新版でも288台に侵入

ScreenConnectを最新版に上げていても、今回の入口はふさがっていませんでした。遠隔サポートのツールConnectWise ScreenConnectには、別の会社が作って足す拡張機能があります。攻撃者はそのひとつ「RMM+」の鍵を通り、管理画面から命令を流したとみられます。

米国のセキュリティ会社Huntressによると、11月11日17時47分（協定世界時、日本時間12日2時47分）ごろから、少なくとも48組織の288台に攻撃者の遠隔操作ソフトが入りました。ConnectWiseは同じ日のうちに、RMM+を含む5つの拡張機能を、入っていた約400のパートナーの環境で止めました。¹

管理画面のRun commandから、90分で288台

攻撃者の足場は、クラウドで動くScreenConnectの管理画面で、それも1つではありません。Huntressの報告によると、攻撃者はRun commandの機能で、端末の群れにまとめて命令を送りました。命令はSYSTEMの権限で動き、攻撃者が用意したクライアントを黙って入れたうえで、「SCKit」と名付けられた16のファイルのツールキットを取りにいく流れでした。

SCKitは正規のクライアントを止め、手動で起動する設定に変えます。空いた位置には攻撃者のクライアントを置き、Microsoft Defenderには除外の設定を足します。端末の上では、いつものScreenConnectが動いているように見えるでしょう。

速さにも驚かされます。

288台の3分の1ほどには最初の10分で届き、90分ですべてに入りました。ConnectWiseが最初の告知を出したのは協定世界時の22時45分（日本時間12日7時45分）で、Huntressが動きに気づいてから5時間ほどあとです。告知が出たときには、もう配り終わっていた計算になります。

つまり、告知を読んでから身構えても間に合わない型でした。会社の側に残る手は2つ。入られたかをあとから調べることと、次の入口を前もって閉じておくことです。

SCKitには、もう一段広がる仕掛けもありました。感染した端末に技術者がScreenConnectでつなぐと、2.5秒後にファイルを送り込みます。そして技術者のPCのブラウザーからセッションのクッキー（.aspxauth）を盗み、管理画面で使い回して、技術者がつなげるほかの端末に広げようとする作りです。ただ、Huntressが調べた端末の記録では、この乗っ取りは今のところすべて失敗していました。

入口とみられる、MFAを通らない拡張機能の鍵

RMM+は、ScreenConnectの外のツールから、コンソールを開かずにセッションを動かすための拡張機能です。手間は省けますが、Huntressの説明では、RMM+はScreenConnectのユーザーアカウントもロールもMFAも通らず、設定に置いた共有のアクセスキーだけで要求を受け付けます。

そのキーについて、3つの文書の言い方は少しずつ違います。Huntressによると、1.0.31と1.0.32ではキーの既定が空で、誰も設定していなければ空のまま通りました。ConnectWiseの告知は「パートナーが導入のときに決めるパスフレーズ」で守られているとし、割り当てられたCVE-2026-127063の説明は、既定で固定の値を使うとしています。

言い方はばらばらです。でも、指している環境は同じでしょう。導入したときに、誰もキーを決めなかったRMM+です。Huntressによると、見つかったRMM+の多くは正規に入れられたもので、たいていは「案件のために足され、そのまま残っていた」といいます。

開発元はConnectWiseではなく、DataCommという別の会社です。11月12日付けのCVEの説明には、RMM+の修正版はまだ発表されていないとあり、今できるのは止めることだけ。深刻度と攻撃の条件は、SecPulseのCVE-2026-127063のページで読めます。²

リモートサポート9製品の地図では、こうしたツールの入口はPCのポートより担当者のアカウントだとみて、MFAとSSOを比べました。今回の件で、その見方には抜けがあったと分かります。担当者のアカウントにMFAを必須にしても、拡張機能のAPIは別の鍵で開く扉だったからです。だから、アカウントの棚卸しの横に、拡張機能とAPIキーの棚卸しも並べておきたいと考えます。

9月の件とは、入口も効く手当ても違う

ScreenConnectが絡むワームのような動きは、2か月前にもありました。Huntressが8月下旬から追った件です。ConnectWiseは9月8日に26.6.5を出し、クライアントのファイル転送にあった脆弱性CVE-2026-84869を修正しました。CVSSは9.9で、米CISAは9月11日にKEVへ加えました。

どちらも、版を上げて閉じられたのは広がる手口のほうで、入口ではありませんでした。違うのは入口の場所です。9月はだまされた社員で、11月は保守業者の管理画面に足された拡張機能でした。

ただ、9月の修正は今回も役に立ちます。技術者のPCに入れるクライアントが26.6.5以上なら、端末から技術者へ広げる手口は止まると、ConnectWiseが確かめました。同社はあわせて、クラウドの管理画面を上げても技術者のクライアントは自動では上がらない、と念を押しています。わざわざ断ったところをみると、古いままのPCがまだ残るとみているのでしょう。

社員が見ることのない管理画面が入口なら、社員にいくら注意を呼びかけても止められません。閉じられるのは、拡張機能を入れた側だけです。

自社で契約していなくても、対象になる会社

自社でScreenConnectを契約していなければ関係ない、とは言い切れません。ConnectWiseの告知は、ScreenConnectを使う事業者を「パートナー」と呼び、その先にある顧客の端末と技術者のPCも調べるよう求めました。契約していなくても、保守業者がScreenConnectを使っていれば、その管理画面から自社のPCに命令が届くわけです。

対象になるのは、次のどちらかに当たる会社です。

• 自社のPCやサーバーに、保守業者が入れたScreenConnectのクライアントがある。
• 自社でScreenConnectを運用していて、5つの拡張機能のどれかを入れたことがある。オンプレミス版は、ConnectWiseが代わりに止められません。

ScreenConnectのクライアントが1台にも入っていない会社は、この件の対象外です。拡張機能が入っていた環境でも、入っていたこと自体は侵害の証拠ではないと、ConnectWiseは断っています。日本での提供や日本の利用者への影響は、ConnectWiseとHuntressの発表に書かれていません。

ConnectWiseは、入られたあとにパートナーの環境の中で何が起きたかを見る手段を持たない、とも明かしました。何が起きたかは、保守業者と会社の側でしか調べられません。

保守業者と自社のPCで確認すること

1、2、5は、今日のうちに保守業者へまとめて頼みます。5はConnectWiseが真っ先に挙げた手当てなので、後回しにしないほうがよいでしょう。3は自社で進め、4は怪しい端末が見つかったときの手順です。

1. 保守業者に、ScreenConnectを使っているか、クラウド版かオンプレミス版かを聞きます。使っていれば、管理画面で拡張機能のページを開いてもらいます。止まっているべき5つは、Labtech Plus、RMM Plus、RMM+、RMM Plus Password Link、RMM+ Password Linkです。止めた拡張機能は、同じページのInactiveの欄に移ります。クラウド版では、ConnectWiseが止めたうえで消したとCVEの説明にあるので、一覧から消えている場合もあります。
2. 日本時間11月12日の未明をはさむ数日について、Run commandとToolboxの履歴に、保守業者が出していない命令がないかを調べてもらいます。ConnectWiseは、記録を残してから片づけるよう求めました。
3. 資産管理ツールで自社のPCを見て、ScreenConnectのクライアントが2つ以上入っている端末を探します。正規のクライアントのサービスが手動起動に変わっていないかも見ます。Huntressは、スケジュールされたタスク「TrapWatch」と、C:\ProgramData\RelayTrapのフォルダーも手がかりに挙げました。
4. 怪しい端末が見つかったら、ScreenConnectではつながずに、EDRのリモート対応など別の経路で隔離して調べます。つないだ技術者のPCに広がるおそれがあるからです。隔離を解いてすぐに再び感染した例も、Huntressの報告に出てきます。
5. 保守業者の技術者が使うクライアントが26.6.5以上かも聞いておきます。上がるまでは、ファイル転送の権限（Transfer Files）を要らないロールから外すよう、ConnectWiseは一時の手当てとして勧めます。

保守の契約書や作業の報告に、遠隔操作のツールの名前と、足した拡張機能の一覧は載っていますか。今回の件でいちばん手間取りそうなのは「どの業者が、どのツールで、うちのPCにつながっているか」に答えることでしょう。