ScreenConnect不正アクセス事例に学ぶ AIで侵入を早期検知する方法

ScreenConnect管理パネルが乗っ取られた事例の要点

2026年11月11日、セキュリティ企業Huntressは、MSP6社のクラウドホスト型ScreenConnectパネルが乗っ取られたことを初観測したと報告した（cybersecuritynews.com）。攻撃者はScreenConnectの「Run Command」機能を悪用し、SYSTEMレベル権限でコマンドを実行。不正インストーラ（sc.msi）をWindowsの一時フォルダに投下し、288台以上のエンドポイント・48組織に影響を与えた。被害は約90分以内に広がり、そのうち3分の1は最初の10分で侵害されていた（cybersecuritynews.com、Cryptika Cybersecurity）。

この事案で確認された「SCKit」は16ファイルで構成されるツールキットで、マシン固有の鍵でペイロードを暗号化するためファイルハッシュによる検出が難しく、スケジュールタスク「TrapWatch」で永続化する仕組みを持つ。ConnectWise社はScreenConnect自体の脆弱性は確認されていないと発表しているが、被害を受けた組織の実務担当者にとっては、侵害の経緯を軽く受け流せる状況ではない。

関連記事AIセキュリティ対策で企業が知るべきリスクは？ ／ AIによる情報漏洩の原因と2つの経路は？

なぜリモート管理ツールは繰り返し標的になるのか

今回の事案が示す課題は、ScreenConnect固有の問題ではなく、リモート管理・監視ツール（RMM）全般に共通する構造的な弱点から来ている。

第一に、RMMツールはシステム管理者と同等かそれ以上の権限で動作するよう設計されているため、一度制御を奪われると被害が連鎖しやすい。SYSTEMレベルでのコマンド実行が設計上の正規機能として存在する以上、利用される可能性は常にある。

第二に、MSPの管理下に複数の顧客テナントが存在する構造が、被害の横断的な拡大を促す。攻撃者がMSP側のパネルを掌握すれば、個別組織の防御とは無関係に、管理対象の端末全体に一斉到達できる。今回の288台・48組織という被害規模も、この構造が背景にある。

第三に、正規の管理操作と不審な操作の区別が難しい。ScreenConnectのRun Commandは管理業務で日常的に使われる機能であり、個別のコマンド実行ログを逐一目視で確認するには、実務上の限界がある。ログが存在しても、見落とされれば意味をなさない。

これらの課題が重なる中で、AIによる異常検出が補完手段として機能しうる余地がある。

AIで何ができるか：未然に防ぐ・早く見つける・被害を小さくする

未然に防ぐ：アクセスパターンの異常をリアルタイムで検出する

不正アクセスの多くは、正規アカウントによる操作に見せかけて行われる。AIを活用した「ユーザー・エンティティ挙動分析（UEBA：User and Entity Behavior Analytics）」は、管理者ごとの操作パターン（接続元IP、接続時間帯、実行コマンドの種類・頻度）を学習し、ベースラインから外れた挙動をスコアリングして警告する。

例えば、普段は日本国内から日中にのみ接続する管理者アカウントが、深夜に海外IPから大量のRun Commandを実行した場合、ルールベースの閾値では検出しにくくても、機械学習モデルが異常スコアを上げてアラートを出す。今回の事案のように、攻撃開始から10分以内に複数組織へ展開するような速度は、UEBAが最も価値を発揮する場面の一つだ。

Microsoft Sentinel、Splunk UBA、Elastic Security などのプラットフォームは、RMMツールのログをデータソースとして取り込み、このような挙動分析を提供している。

早く見つける：ネットワークトラフィックとログの自動相関分析

SCKitのような多段階ツールキットは、単一のイベントではなく複数の操作が組み合わさって初めて攻撃の全体像が見える。AIを活用したSIEM（セキュリティ情報・イベント管理）やEDR（エンドポイント検出・応答）は、端末ログ・ネットワークトラフィック・認証ログを横断的に相関分析し、個別には無害に見えるイベントの連鎖を「一連の攻撃」として識別する。

今回の事例で言えば、「C:\Windows\TEMP\への.msiドロップ」「スケジュールタスクの新規登録（TrapWatch）」「C:\ProgramData\下への新規ディレクトリ作成（RelayTrap）」という3点は、単独では管理業務と区別しにくいが、短時間に同一セッション内で発生した場合、AIモデルが高リスクのパターンとして検出できる。

また、今回のSCKitについてHuntressは、RelayTrapのC#コードがAIモデルで生成された可能性を指摘している（cybersecuritynews.com）。攻撃側がAIを活用し始めている現状では、防御側も同等以上の自動化が必要になっている。

被害を小さくする：セッション制御とインシデント対応の自動化

AIが異常セッションを検出した後、人間が対応するまでの時間を短縮することが被害軽減の鍵になる。今回の事例では、288台が約90分で侵害されており、人間のオペレーターが気づいて対処するには短すぎる時間軸だった。

SOAR（セキュリティオーケストレーション・自動化・応答）プラットフォームと組み合わせることで、AIが異常を検出した時点で自動的にセッションを失効させる、疑わしいアカウントを一時ロックする、担当者にアラートを送る、といった初動対応を人手を介さず実行できる。これにより、実害が出る前の段階で連鎖を止める余地が生まれる。

ConnectWiseが今回の対応として行ったのも、疑わしい外部拡張機能をクラウド側から一括無効化するという、一種の自動的・集中的な封じ込めだった（cybersecuritynews.com）。この判断を組織内で自動化できれば、より短い時間軸での対応が可能になる。

誰の役に立つか：日本の現場での具体的な場面

こうした対策が特に有効な場面は、次のような組織だ。

複数顧客を管理するMSP・ITベンダー：今回の被害を受けたのはMSP経由の顧客組織だった。管理パネルを持つ事業者は、自社のアカウント管理・MFA設定・拡張機能の監査を最優先で行う立場にある。UEBAやSOARは、自社スタッフの操作異常だけでなく、パネルへの不審なアクセス自体も検知対象にできる。

社内IT部門がRMMツールを運用する企業・自治体：ScreenConnectをはじめとするRMMツールを社内管理に使っている組織では、管理者アカウントの操作ログをSIEMに集約し、異常検出ルールを設定するだけでも、早期発見の確率が上がる。

医療機関・インフラ事業者：端末の稼働停止が直接サービス停止につながる組織では、被害の封じ込め速度が特に重要だ。SOARによるセッション自動失効は、担当者が不在の深夜帯でも初動対応を機能させる手段になる。

AIでは解決できないこと：注意点と限界

AIを使った異常検出は、あくまで「早期発見を補助する手段」であり、すべての侵害を防ぐ万能策ではない。実務担当者が認識しておくべき限界を整理する。

誤検知・見逃しの問題：UEBAや機械学習モデルは正常な業務操作を異常と誤判定することがある（False Positive）。逆に、十分に訓練されていないモデルは未知の攻撃パターンを見逃す（False Negative）。最終的な判断は人が行う必要があり、AIの警告を自動的にブロックに直結させる場合は、業務への影響を慎重に評価しなければならない。

ログが存在しなければ検知できない：AIはデータを学習・分析するが、そもそもログが取得・保存されていなければ機能しない。今回の事案でもConnectWiseは各パートナーに対し、オンプレミス環境での拡張機能の自動無効化は行われないと明示している（cybersecuritynews.com）。ログ取得の設定漏れや保存期間の短さは、AI検知の前段階の問題として残る。

監視の強化と個人情報・プライバシーの問題：従業員の操作ログを詳細に収集・分析することは、個人情報保護法や労働法上の観点から、事前の規定整備と従業員への周知が必要だ。監視範囲を広げることで、業務上不要な個人情報が収集・保存されるリスクもある。

AIだけでは社会工学的攻撃に対応できない：管理者アカウントの認証情報が正規の経路（フィッシング・パスワード使い回し等）で流出した場合、AIは正規の操作と区別するのが難しい。今回の事案でも、ConnectWiseはMFAの強制と認証情報リセットを推奨しており（cybersecuritynews.com）、AI検知と並行した基本的な認証管理が前提となる。

次の一手：明日から試せる実務的な対応

大規模な投資を必要としない初期対応として、以下の手順から着手できる。

1. ScreenConnectの拡張機能と接続元IPを今週中に棚卸しする。ConnectWiseが今回無効化した5つの外部拡張機能（Labtech Plus、RMM Plus、RMM+、RMM Plus Password Link、RMM+ Password Link）が自社環境に存在しないかを確認する。クラウド環境であっても、オンプレミス環境は各組織が自ら無効化する必要がある（cybersecuritynews.com）。

2. MFAを全管理者アカウントに強制適用する。RMMツールへのアクセスにMFAが設定されていない場合、認証情報の漏洩が即座に侵害につながる。これはAIを導入する前の最低限の前提条件だ。

3. 既存のSIEMやEDRにRMMログを取り込む設定を確認する。すでにSIEMを運用している場合、ScreenConnect等のRMMツールのイベントログが取り込まれているかを確認する。取り込まれていなければ、コネクタの追加設定から始める。ログが集約されることで、既存ツールのルールエンジンやAI機能の適用範囲が広がる。

4. Run Command等の高権限操作に特化したアラートルールを追加する。UEBAの導入前であっても、SIEMに「深夜帯のRun Command実行」「過去に使われたことのないIPからの接続」「TEMP・ProgramDataへのファイル書き込み」を条件にしたルールを追加するだけで、異常の早期発見につながる。

今回の事案が示したのは、高速な横展開を人間のオペレーターだけで止めることの難しさだ。AIによる自動検出と初動対応の自動化は、その速度差を埋める現実的な選択肢になっている。ただし、AI検知は適切なログ基盤・認証管理・人間による最終判断と組み合わせて初めて機能する。単体での過信は、別の見落としを生む。

AIを活用したセキュリティ対策の基礎知識

機械学習・深層学習の仕組みをセキュリティ文脈で理解しておくと、UEBAやSIEMの異常検出モデルがどのように動いているかの判断軸になる。

参考文献

• cybersecuritynews.com https://cybersecuritynews.com/connectwise-screenconnect-hijacked/
• Cryptika Cybersecurity https://www.cryptika.com/hackers-hijack-connectwise-screenconnect-to-deploy-sckit-malware-across-288-devices-at-48-organizations/
• x.com https://x.com/i/trending/2120723821762084965