
CVE-2025-11492、CVE-2025-11493 の解説とコード - Adversary-in-the-Middle 経由の ConnctWise Automate RMM の RCE
ペネトレーションテストの一環として、ConnectWise Automate Remote Monitoring and Management (RMM) エージェントに複数の脆弱性を発見しました。 ConnectWise は多くのマネージドサービスプロバイダー (MSP) がクライアントデバイスの管理・監視に利用しています。 これらの脆弱性により、攻撃者がネットワーク上で中間者攻撃 (Adversary-in-the-Middle) を確立できる場合にリモートコード実行が可能となり、また攻撃者が ConnectWise Automate エージェントが動作するデバイス上でコード実行または物理アクセスを得た場合には、ローカル権限昇格やステルス的な永続化として悪用される可能性があります。
これらの脆弱性は 2025 年 8 月 20 日に ConnectWise へ報告されました。ConnectWise は CVE ID を割り当て、2025 年 10 月 16 日にバージョン 2025.9 でパッチをリリースしました。
ConnectWise セキュリティ情報:
CVE ID:
2025.9 をリリースし、セキュリティ情報と CVE を公開。ConnectWise の迅速な対応と、修正に向けた協力的な姿勢、分類や修正の最適な方法について議論する姿勢には感謝しています。
これらの脆弱性の分類は興味深い課題でした。HTTPS への切り替えによってこの報告書のほぼすべてのシナリオが解決されるものの、そもそも HTTP をサポートする設計はエージェントとサーバ間の通信の信頼性を向上させるための選択であったことが明らかでした。暗号化スキームは中間者攻撃のリスクを部分的に認識・緩和しようとしているように見えましたが、一貫して適用されていませんでした。これを掘り下げる中で、脆弱性が「HTTP そのもの」なのか、「HTTP 上での暗号化の欠如」なのか、あるいはリプレイ防止やプラグイン検証などをそれぞれ別の脆弱性として分類すべきか、という検討が必要でした。ある時点で ConnectWise は脆弱性の様々な側面について 5 つ以上の別々の CVE を検討していました。
さらに、攻撃の範囲と攻撃ベクトルは、脆弱性を中間者攻撃(例:コーヒーショップの Wi-Fi)の観点から見るか、LPE/物理アクセスの観点から見るかで異なりました。別のアプローチとしては、各シナリオ(例:AiTM RCE、LPE、永続化の乗っ取りなど)を個別の脆弱性として扱うことも考えられます。
最後の学びとして、2025 年になってもファイル共有には依然として困難が伴うという点です(電子メールのセキュリティが .dll ファイルやそれらを含む .zip ファイルの添付を許可しませんでした)。
本レポートは、ConnectWise によるパッチリリースと CVE 公開、およびそのような開示が利用者に害を及ぼさないという ConnectWise の同意を得た上で公開されています。また、これらの脆弱性とその緩和策を公表することで、他のベンダーやセキュリティ専門家が ConnectWise Automate や他の RMM システムにおけるリスクをよりよく理解し、緩和する助けになると考えています。
本コンテンツは、正当かつ許可されたセキュリティ研究および教育目的のみを意図しています。この情報を不正に使用してシステム、ネットワーク、データを侵害することは違法かつ非倫理的です。本コンテンツは「現状のまま」提供され、いかなる種類の保証もありません。著者は、本情報の使用または誤用に起因するいかなる損害についても一切の責任を負いません。
このコードや情報をさらなる研究に使用する場合は、発見した脆弱性を影響を受けるベンダーに報告することで、責任ある開示を実践してください。
以下のレポートに加えて、このリポジトリには脆弱性を実証する PoC コードが含まれています。偽サーバの実装と使用手順の詳細については automate_server/README.md を参照してください。
このコードは、ConnectWise Automate に対するさらなる(倫理的な)セキュリティ研究にも使用できます。
以下のレポート(またはそれに近いバージョン)と、このリポジトリ内の PoC Python コードは、推奨される緩和策とともに ConnectWise に提供されました。
削除された緩和策のセクションには、Automate エージェントをこれらの脆弱性に対して複数の方法で堅牢化するために可能な変更の詳細が含まれています。
これらの変更の一部はまだ ConnectWise で検討中であるため、そのセクションは今回の公開から削除されています。
ConnectWise Automate Remote Monitoring and Management (RMM) エージェント(2025 年 8 月時点の最新バージョン、バージョン文字列 250.252 でテスト)は、特定の構成においてネットワークベースのリモートコード実行に対して脆弱です。エージェントが Server Address に暗号化されていない HTTP トランスポート(主要なものかフォールバックとして)を使用するように構成され、攻撃者が中間者攻撃 (AiTM) を実行できる場合、SYSTEM としてリモートでコードを実行できます。この構成は、複数のマネージドサービスプロバイダー (MSP) から実際に観測されています。
攻撃者がデバイスに非管理者として物理アクセスを得た場合、またはデバイスを攻撃者が制御するネットワークに接続できる場合(つまり、この脆弱性はローカル権限昇格としても使用可能)にも悪用が可能です。Automate はほとんどの RMM コマンドを暗号化および検証するための暗号化システムを採用していますが、そのプラグインシステムは十分な保護がなく、リモートコード実行に対して脆弱なままです。
Automate の制御サーバを模倣したカスタムサーバを実装することで、Automate エージェントに悪意のあるプラグインをダウンロードおよび実行させることができます。
侵害されたエージェントは、魅力的な永続化の形態としても機能します。RCE を使用してエージェントの対称暗号鍵を抽出すると、カスタムサーバは標準の RMM チャネルを使用してエージェントに任意のコマンドを送信できます。AiTM シナリオでは、攻撃者はファイル抽出、資格情報ダンプ、コマンド実行、構成変更など、任意の RMM コマンドを実行できます。また、攻撃者は RMM の Server Address を自身のサーバに変更することで、AiTM 後でもステルス的な永続化を実現できます。あるいは、RCE を利用してシステムレベルのコマンドを直接実行することも可能です。
http:// エンドポイントを含む Server Address を使用している。脆弱な構成は 2 つの異なる MSP から観測されている(実際の MSP ドメインと IP は置き換え):
https://automate.msp-one.com|http://automate.msp-one.comhttps://msp.msp-two.com|http://msp.msp-two.com|http://12.346.6.78http:// エンドポイントは https:// 接続が失敗した場合のフォールバックとして使用されるが、攻撃者は https をブロックすることでこれをシミュレートできる。Automate エージェントは、サーバアドレスとして http:// URL を使用するように構成できます。この構成はインストーラスクリプト/パッケージによって設定される可能性が高いですが、レジストリキー HKLM\SOFTWARE\LabTech\Service\Server Address を確認することで検証できます。

HTTPS エンドポイントと HTTP エンドポイントの両方をパイプ | で区切って使用することで、理論上 HTTPS 接続に問題が発生した場合、Automate エージェントは HTTP 接続にフォールバックすることを保証します。
攻撃者が Automate エージェントとサーバ間のネットワークトラフィックに対して中間者攻撃 (AiTM) アクセスを得た場合、HTTPS 接続を意図的に妨害し、HTTP へのフォールバックを引き起こすことができます。これにより、攻撃者はエージェントとサーバ間でやり取りされるトラフィックを傍受、監視、改変できます。攻撃者はその後、トラフィックを https://automate.msp-one.com にリバースプロキシすることで、エージェントの「通常の動作」を維持しつつ、データを盗聴できます。さらに、応答を注入または変更したり、Automate エージェントからの要求に応答する完全な偽の Automate サーバをセットアップしたりすることもできます。
これは、「悪意のある」Wi-Fi アクセスポイント (hostapd、dnsmasq、IP 転送 + NAT) をセットアップし、トラフィックリダイレクションのための iptables ルールとリバースプロキシ用の mitmproxy スクリプトを使用して実現されました。

その他、実行中のプログラム、完全なネットワーク構成、ドキュメントパスなど、より機密性の高いデータが Automate エージェントの応答で観測されることがありました。
iptables -t nat -A PREROUTING -i wlx90916440139a -p tcp --dport 80 -j REDIRECT --to-port 8080 iptables -A FORWARD -i wlx90916440139a -p tcp --dport 443 -j DROP
#### mitmproxy script:```python
# run with AiTMweb --mode transparent@8080 -s automate_AiTM.py
def request(flow: http.HTTPFlow):
if flow.request.pretty_host == 'automate.msp-one.com':
flow.request.url = 'https://automate.msp-one.com' + flow.request.path
ZTNAソリューションはこの傍受を多少複雑にすることができますが、mitmproxyスクリプトをさらに追加してZTNAを条件付きで検出・ブロックすることで確実に回避され、結果としてトンネル化されていないHTTPへのフォールバックが発生しました。