RMM悪用とは？正規リモート保守ツール悪用の危険性と対策方法を徹底解説

RMM悪用とは何か

正規の遠隔保守ツールが、そのまま侵害導線になります

RMM悪用は、AnyDesk や ScreenConnect などの正規の遠隔監視・遠隔管理ツールが攻撃者に使われ、端末制御、ファイル転送、追加ツール投入、横移動に悪用される状態です。CISA のGuide to Securing Remote Access Software↗でも、正規遠隔保守ソフトは可用性を支える一方で、構成不備が大きな露出面になると整理されています。

厄介なのは、これが「怪しい専用 malware」ではなく、すでに組織が許可しているツールで起こることです。許可済み通信や許可済み実行の顔をしているため、境界だけでは止めにくく、発見も遅れやすいのが特徴です。

実務では、既存の RMM アカウントや委託先導線を乗っ取られる型と、侵害済み端末へ新しい遠隔保守ツールを後から入れられる型の二つがあります。前者は台帳、権限、利用条件の甘さが主因になり、後者は許可外ツール追加の検知不足が主因になります。どちらも「正規ツールだから怪しく見えにくい」という点が共通です。

公開RDPや VPN とは、悪用される前提が少し違います

公開RDPや VPN は「外から見える入口」そのものが主役です。一方で RMM悪用は、外部入口だけでなく、正規保守の名目で常時接続やエージェント配布が許されていることが主役になります。

そのため、RMM悪用対策は単にポートを閉じる話だけでは終わりません。利用者、委託先、管理権限、エージェント配布、無人接続の設計まで見直さないと、正規導線のまま侵害を許します。

委託先導線と共有アカウントが残るほど危険になります

多くの組織で RMM は、社内 IT だけでなく委託先、保守会社、ヘルプデスクも使います。この時、共有アカウント、長期間残るエージェント、停止忘れの保守ポータルがあると、攻撃者はそこを最短経路として使います。

だから RMM悪用は、ツールの安全機能の有無より先に、業務委託先アカウント管理やMFA未適用アカウントのような運用側の負債と合わせて見る必要があります。

なぜ成立するのか、どこが盲点になるのか

CISA もリモートアクセスソフトの構成不備を重視しています

CISA のリモートアクセスソフト保護指針は、遠隔保守ツールを例外運用の集合として放置しないことを重視しています。とくに、誰が使うか、どの端末へ入れるか、いつ無効化するかが曖昧だと、製品を変えても本質は変わりません。

企業側は「保守用だから必要」という事情で統制を緩めがちですが、そこが攻撃者にとって最短経路になります。便利さのために残した常時接続は、侵害側から見れば persistence です。

Royal / Play 系の advisory でも、正規遠隔ツール悪用が繰り返し出ます

CISA のAA23-025A↗やAA25-163A↗でも、正規遠隔保守やリモート access の悪用は繰り返し触れられます。ここから分かるのは、攻撃者が「新しい専用ツール」より、既存の保守導線を使う方が安くて目立ちにくいと考えていることです。

つまり、遠隔保守の正当性は防御になりません。正当な用途があるからこそ、異常検知と使用条件の制限を先に整える必要があります。

RMM悪用は、その後の横移動や資格情報濫用とつながります

RMM で端末へ入られると、そこで終わりではありません。横移動、認証情報の追加取得、EDR 停止、共有ファイル探索までつながりやすく、ラテラルムーブメント対策やEDR未導入と24時間監視不足の弱さがそのまま後続被害になります。

被害の広がり方と企業側のリスク

見分けるときは『誰が、どこから、いつ入ったか』を先に疑います

RMM悪用は、通信先や実行ファイル名だけでは切り分けにくいので、まず利用主体を疑うのが現実的です。深夜や休日の接続、委託先申請にない端末からの接続、台帳にない新規エージェント登録、普段は触らない端末への無人接続は、正規利用に見えても優先確認すべき兆候です。

さらに、接続直後にスクリプト実行、資格情報変更、EDR 停止、共有フォルダ探索が続くなら、単なる保守ではなく侵害後活動として扱う方が安全です。検索上位の解説でも、RMM悪用は「何のツールか」より「どの文脈で使われたか」を追う方が実務に合います。

一度入られると、業務端末の正常運用に見える形で広がります

RMM悪用の怖さは、侵害が「おかしな通信」ではなく「保守の延長」に見えることです。画面共有、スクリプト実行、ファイル転送が正規画面から行われると、現場が異常と判断する材料が少ないまま被害が進みます。

とくにヘルプデスク、委託先、運用会社の文脈が混ざる環境では、「誰が何のために入ったのか」が曖昧になり、検知より先に情報持ち出しや横移動が起こりやすくなります。

止めるべきは『攻撃者の道具』ではなく『常時開いている運用穴』です

RMM悪用対策で重要なのは、特定の製品を怖がることではありません。製品名が変わっても、常時接続、共有アカウント、停止忘れ、委託先例外が残れば同じ問題が起きます。

だから対策も、「AnyDesk を禁止する」だけでなく、「誰に、いつ、どの端末へ、どこまで入らせるか」を再設計する方向で考える必要があります。

検知・防御・運用で押さえるべき対策

実務で優先すべきなのは、RMM の全面禁止ではなく、高リスク領域から承認制・時間制限・端末制限へ戻すことです。許可済みツールを使う以上、利用条件を絞る方が現実的です。

あわせて、接続ログ、スクリプト実行、権限変更、横移動、共有ファイル操作を同じ事案として見る設計が必要です。正規ツール利用だからこそ、前後の挙動を一緒に見る監視が効きます。

攻撃者はどの RMM 環境を狙いやすいのか

外から見える保守ポータルと、台帳から外れたエージェントが並ぶ環境です

攻撃者が好むのは、製品の知名度が高い環境そのものではなく、どこに管理ポータルがあり、どの端末へ常時接続でき、誰が責任者なのかが曖昧な環境です。保守ポータルが外から見え、そこへ入る経路が複数あり、さらに使っていないはずのエージェントが社内端末に残っていると、「どこへ入れば深い権限へ届くか」を短時間で推測しやすくなります。

実務では、「今は使っていないがアンインストールしていない agent」「委託先切り替え後も残った旧ベンダー用の接続先」「一度障害対応で開けた保守 URL」が同時に残りやすく、ここが真っ先に狙われます。RMM 悪用は派手な exploit の話というより、資産台帳からこぼれた保守面の再利用です。

委託先の例外権限が長生きするほど、実行可能な操作が増えます

保守運用では、「この委託先だけは 24 時間入れる」「この端末だけは無人接続を許す」「この共有 ID だけは MFA を外す」といった例外が積み上がりやすくなります。攻撃者はツール名よりも、こうした長生きした例外条件を利用します。とくに本番系サーバ、店舗端末、工場端末、病院端末のように、止めづらいシステムに例外が残ると、侵害後の価値が高くなります。

つまり、RMM 悪用を防ぐうえで先に見るべきは「どの製品を入れているか」より「誰がどの条件で入れるか」です。ベンダー交代や契約更新のたびに、例外権限を棚卸ししない限り、同じ導線が別の攻撃者に繰り返し使われます。

現場で誤判定しやすい兆候と、その切り分け方

「いつもの保守」に見える時ほど、申請情報と突き合わせる必要があります

RMM 悪用が厄介なのは、接続先ドメインも実行ファイル名も、一見すると通常業務に見えることです。そこで切り分けの起点になるのが、保守申請、変更票、当番表、委託先作業連絡といった業務側の証跡です。「深夜に本当に作業予定があったか」「その端末は申請対象だったか」「その委託先はまだ契約中か」を先に確認すると、正規通信に見える接続でもかなりの精度で異常を絞れます。

逆に、監視チームがネットワークログと端末ログだけで判断し、運用チームが申請情報だけで判断すると、どちらも「あり得そう」に見えて止め損ねます。RMM 悪用は技術ログだけで閉じず、保守作業の業務文脈を同じ事案へ寄せて判断するのが実務的です。

接続成功だけでなく、その直後の操作列まで見て初めて異常が分かります

異常判定で見るべきなのは、接続成功そのものよりも、その後に何が続いたかです。RMM 接続直後に新しい管理者アカウント作成、PowerShell や圧縮ツール実行、共有フォルダ探索、EDR 停止、ブラウザ保存資格情報の読み出しが並ぶなら、通常保守より侵害後活動の可能性が高まります。ここはLiving off the Land攻撃や認証情報悪用とつながる地点です。

さらに、RMM 接続が終わった後も、別ホストへの管理共有アクセスや横方向の認証失敗が増えているなら、単独端末の保守ではありません。RMM 悪用は「入ったかどうか」より「入った後に何を拡げたか」を追うことで、はじめて異常が見えてきます。

平時に整えるべき台帳・権限・監査設計

RMM 台帳は「製品名」よりも「責任線」と「停止条件」を持つべきです

台帳で最低限必要なのは、製品名やホスト名だけではありません。用途、対象端末、管理者、委託先名、契約終了日、接続元制限、無人接続の可否、最終確認日、停止条件まで持っていないと、異常時に「今すぐ止めてよい導線か」が判断できません。RMM は便利な分、責任線が曖昧なまま残りやすいため、止める基準が台帳に書かれていることが重要です。

ここが弱い組織では、事案発生時に「このポータルを落とすと誰が困るか」「この agent を消すと業務影響があるか」を個人の記憶で判断することになります。そうなると封じ込めが遅れ、侵害者に時間を与えます。台帳は資産把握ではなく、封じ込め判断を速くするための道具です。

監査は月次で十分ではなく、変更イベントのたびに差分確認が必要です

RMM 関連の事故を減らすには、月次点検に加えて、ベンダー追加、契約変更、障害対応、拠点新設、端末更改のようなイベントごとに差分確認を入れる必要があります。新しい委託先へ権限を渡した時、旧委託先の ID と接続元制限を同じ日に落とせているかまで見ないと、例外は増える一方です。

監査観点としては、「許可済み RMM 製品一覧」「例外アカウント一覧」「停止済みはずのポータル」「残置 agent」「高権限端末への無人接続」の5点を固定し、差分が出たら必ず担当者レビューを通すのが現実的です。ここまで整うと、RMM 悪用はツール固有の問題ではなく、例外運用の統制問題として扱えるようになります。

部門横断で決めるべき責任分担と例外管理

情報システム部門だけでは、保守導線の全体像を持ちきれません

RMM 悪用を減らすには、情報システム部門だけで完結させないことが重要です。実際には、委託先契約を持つ調達部門、現場保守の事情を知る運用部門、端末更改を管理する資産管理部門、incident 時の封じ込めを担うセキュリティ部門が、それぞれ別の情報を持っています。どこか一部門だけで保守導線を管理しようとすると、「契約は終わっているが接続は残っている」「現場は使っていないと思っているが agent が残っている」といったズレが必ず起こります。

そのため、RMM 台帳には技術項目だけでなく、契約終了日、利用部門、現場責任者、委託先担当窓口、緊急停止の承認者まで持たせる方が実務に合います。事案が起きてから関係者を探すのでは遅く、平時の時点で「誰が止める権限を持つか」を明確にしておく必要があります。

例外を承認するなら、終了確認までを一つの運用にします

保守例外が必要な場面は現実にあります。だからこそ、例外を許す時には、開始理由、対象端末、委託先名、接続元、利用時間、終了条件、終了確認者を一つの票にまとめるべきです。ここまで書かれていれば、異常な接続が出た時に「その例外は今も有効か」を即座に判断できます。逆に、開始時の承認だけで終わり、終了確認が無い例外は、ほぼ確実に残置導線になります。

さらに、月次点検では「新しい例外が何件増えたか」だけでなく、「期限切れなのに残っている例外が何件あるか」を見なければ意味がありません。RMM 悪用は、個別製品の危険性より、例外が終わらない組織文化に支えられて起きやすいからです。例外の件数、平均残存日数、停止済み確認率まで見える化すると、管理レベルをかなり引き上げられます。

事後レビューで残すべき論点

RMM 悪用の事後レビューでは、ツール名や接続元だけを残しても不十分です。どの例外権限が使われたか、台帳に無い導線がどこにあったか、申請情報と一致しなかった点は何か、停止判断に何分かかったかまで残すと、次回の封じ込め速度を上げやすくなります。

また、レビュー項目に「委託先アカウント整理完了日」「残置 agent 削除完了日」「停止済みポータル外部到達不可確認日」を持たせると、再発防止が技術調査で終わらず、運用の締め直しまで進みます。RMM 悪用は incident 後の管理項目まで設計して初めて改善が定着します。

さらに、次回の監査に向けて「誰がどの例外をまだ保有しているか」を一覧で残しておくと、改善が個人の記憶に戻りません。RMM 悪用は一度の封じ込めより、例外を持ち越さない管理に切り替えられるかどうかで差が付きます。

事後レビューを次の月次点検や委託先更新手続きへ接続できれば、RMM 悪用は単発の incident ではなく、継続改善のテーマとして扱えます。ここまで回り始めると、保守導線は「便利だから残すもの」から「説明できるものだけ残すもの」へ変わっていきます。

この転換ができる組織ほど、RMM 悪用の再発率は下がります。製品名よりも、例外を残さない管理の質が最後に効いてきます。

だから最終的な評価軸も、「何製品を使っているか」ではなく、「契約終了後の導線が残っていないか」「停止条件のない例外が残っていないか」「緊急時に誰が止めるか決まっているか」に置く方が実務では役立ちます。

古い保守導線や委託先接続の棚卸しなら ASM診断 PRO

ASM診断 PRO は RMM を制御する製品ではありませんが、外から見える保守ポータル、古いログイン画面、委託先向け導線、停止したはずの保守 URL を洗い出す入口として使いやすい構成です。

RMM悪用は、見えているリモートアクセスソフトだけでなく、その周囲にある古い公開導線や例外運用から広がります。公開面の棚卸しを先に進めると、「誰の導線をどこから閉じるか」を整理しやすくなります。

とくに、RMM そのものは社内台帳で把握していても、「保守会社向けの古いサブドメイン」「一時的に公開したまま戻していないログイン画面」「委託先切り替え後も残った接続先」までは見落としがちです。ASM診断 PRO で外から見える実際の状態を確認すると、運用台帳の中だけでは見えない公開導線を補完できます。

また、RMM 悪用の実務対策は、ツールの可否判断より先に「例外をどこまで棚卸しできるか」にかかっています。保守ポータル、管理 URL、残置サブドメイン、古い認証面を先に整理しておくと、事案時に止める順番を決めやすくなり、委託先や運用チームとの会話も具体的になります。

つまり ASM診断 PRO は、RMM を直接制御する製品ではなくても、RMM 悪用の前段になる公開面の整流化に効きます。社内で「どの保守導線がまだ外から見えているのか」「契約や用途の説明が付くのか」を確認する起点として使うと、運用設計と incident 対応の両方に接続しやすくなります。

よくある質問

まとめ

RMM悪用の本質は、正規ツールが危険というより、正規導線として残した例外運用が侵害者にとって便利な橋になることです。AnyDesk や ScreenConnect のような製品名だけではなく、共有アカウント、常時接続エージェント、委託先接続、停止済み保守導線まで含めて見直す必要があります。

守る側は、allowlist だけに頼らず、高リスク領域から承認制・時間制限・端末制限へ戻し、接続ログと端末挙動を相関できる状態を作ることが重要です。