ConnectWise Cloud Backupアプリの鍵でM365テナントに侵入

概要

• ConnectWise Cloud Backup は、MSP（IT運用を請け負う事業者）が顧客の Microsoft 365 や Google Workspace のデータをバックアップするためのクラウドサービス。仕事の性質上、導入された各テナントで、メールボックス、OneDrive、SharePoint、Teams、ディレクトリのデータへの広い権限を与えられている（Huntress、The Hacker News）。
• 10月15日、このアプリの認証情報が、ConnectWise とは関係のないホスティング事業者のIPアドレス 144.172.64[.]128 から使われ、顧客テナントで Microsoft Graph のアクセストークンが取得された。テナントはGUIDの昇順に数秒〜数分おきに巡回されており、標的のリストを順に処理するスクリプトとみられる（Huntress、Todyl）。
• Huntress は10月16日 19:00 UTC の時点で162テナントでの不正なサインインを確認した（The Hacker Newsは173テナントと報じた）。10月17日の追記では、このIPアドレスからのサインイン活動があった Entra テナントを約1,000、そのうち成功したものを300超としている（Huntress、The Hacker News）。
• 1つのテナントでは、別のアプリ「ConnectWise Cloud Management - MS Teams」が自分をグローバル管理者に加え、MSPの管理ツールと Huntress 自身のアプリに新しいクライアントシークレットを足していた（Huntress）。
• ConnectWise は「Cloud Backup 環境のアプリケーションIDへの不正アクセス」を認め、サービスを停止した。保管しているバックアップのアーカイブにアクセスされた証拠はないとしている。攻撃者が認証情報をどう手に入れたかは公表されていない（ConnectWise、BleepingComputer）。

この記事では、ベンダー・公的機関・研究者・報道で確認できた内容を「事実」、筆者の推測や意見を「考察」として分けて書いています。

何が起きたか（時系列）

日本時間は筆者がUTCから換算した。

技術的な問題点（根本原因）

事実（Huntress、Todyl、ConnectWise、BleepingComputer）

• Cloud Backup は、複数の組織にまたがって使われる「マルチテナント」のアプリである。各テナントの管理者が同意すると、そのテナントにアプリの代理（サービスプリンシパル）ができ、利用者がサインインしていなくてもデータを読める「アプリケーション権限」が与えられる（Todyl、BleepingComputer）。
• アプリが自分を証明するための認証情報（シークレットや証明書）は発行元のベンダーのテナントにあり、同意したすべてのテナントで同じものが通る。Entra の記録では、使われた資格情報の種類は「client assertion」だった。Huntress は「顧客が自分の環境で何をしても、これを生むことはできない」と書いている（Huntress、Todyl）。
• 攻撃者は OAuth 2.0 のクライアント資格情報フローで、アプリとして直接トークンを取った。利用者がいないため、MFA も利用者向けの条件付きアクセスもかからない。Todyl の記録では条件付きアクセスの状態は notApplied だった（Todyl）。
• 得られる権限は、各テナントでアプリに与えられていたものそのまま。Todyl の確認では、メールと添付ファイルの読み書き（Exchange Web Services 経由のメールボックス全体へのアクセスを含む）、OneDrive と SharePoint のファイル、Teams のチャット、データの復元だった。Microsoft は、Directory.ReadWrite.All を含む既存の権限が悪用された可能性が高いとみている（Todyl、BleepingComputer）。
• 利用者のセッションを取り消してもこのアクセスは終わらない。テナントでアプリを無効化すると新しいトークンは出なくなるが、発行済みのトークンは最大90分有効なまま残る（Todyl）。
• 攻撃者が認証情報をどこから得たのかは、公表されているどの資料にも書かれていない（BleepingComputer）。

考察

利用者のアカウントを守る仕組み（MFA、条件付きアクセス、セッションの取り消し）は、どれも「人がサインインする」ことを前提にしている。アプリケーション権限で動くアプリは、その前提の外にいる。しかもマルチテナントのアプリでは、鍵を持つのは顧客ではなくベンダーで、1本の鍵が同意したすべてのテナントの扉を開ける。顧客から見れば、自分の環境で何も間違えていないのに、他社の鍵1本の管理に、自社のメールとファイルの安全がかかっていたことになる。バックアップは「読む」だけでなく「書き戻す」ためにも権限を必要とするので、与えられる権限はもともと広い。

攻撃・侵入経路

flowchart TD
    A[ConnectWise Cloud Backupアプリの<br/>認証情報が攻撃者の手に<br/>入手経路は未公表] --> B[144.172.64.128から<br/>クライアント資格情報フローでサインイン]
    B --> C{そのテナントに<br/>アプリへの同意があるか}
    C -->|ない| X[失敗]
    C -->|ある| D[アプリとしてGraphのトークンを取得<br/>MFAも条件付きアクセスもかからない]
    D --> E[メール・ファイル・Teams・ディレクトリを<br/>アプリの権限の範囲で読める]
    F[別のConnectWiseアプリ<br/>Cloud Management - MS Teams] --> G[自分をグローバル管理者に追加]
    G --> H[MSP管理ツールとセキュリティ製品のアプリに<br/>新しいシークレットを追加]
    H --> I[ベンダーの鍵を止めても残る<br/>別の入口]
    I --> J[MSP管理ツール経由で<br/>他の顧客テナントへ広がるおそれ]

事実（Huntress、Todyl、BleepingComputer）

• 巡回：テナントはGUIDの昇順に処理された。Huntress は数秒おき、Todyl は1〜6分おきで、途中に43分の空白があったと記録している。Todyl は「アプリが有効なテナントはすべて侵害されたと考えてよい」と書いている（Huntress、Todyl）。
• 偵察段階のアクセス：Todyl が調べた9テナントでは、サインインのほかに、アカウントの作成、権限の追加、パスワードの変更、居座りの仕掛けは見つからなかった。バックアップを契約していないテナントでは、トークン取得後のメールやファイルの読み取りの記録はなかった（Todyl）。
• 居座り：Huntress が見た1テナントでは、約5分の間に「Cloud Management - MS Teams」が 03:44 と 03:48 の2回グローバル管理者に加わり、他の2つのアプリに9回の変更を加えた（6回成功、3回失敗）。証明書の追加は拇印の不一致で拒否され、その後のシークレットの追加は成功した。足されたシークレットで Huntress のアプリに7回続けてサインインされた。Huntress は、この段階と 144.172.64[.]128 からのサインインが同じ攻撃者かどうかは確かめられていないとしている（Huntress）。
• Microsoft も、サービスプリンシパルでのサインインに成功したあと、Graph APIでの偵察と、認証情報を追加しようとする動きを観測したとしている（BleepingComputer）。
• 攻撃者を見分ける手がかり：正規の Cloud Backup は Azure 内部のプライベートIPv6（fd00:: の範囲）から接続する。不正なサインインは単一の商用VPSのIPv4、Python の User-Agent（Python-urllib/3.12、python-requests/2.31 など）、1テナント1回のトークン取得という点で、いずれも正規の動きと違っていた。ただし、グローバル管理者への追加と認証情報の追加は Azure 内部のプライベートIPv6から来ており、正規の ConnectWise の通信も同じ範囲から来るため、アドレスだけでは操作者を特定できない（Todyl、Huntress）。

なぜ防げなかったか・構造的要因の考察

1. 「アプリとしてのサインイン」には、人向けの防御が効かない。 不正なサインインには MFA の要求も、利用者向けの条件付きアクセスもかからなかった。Microsoft の「ワークロードID向けの条件付きアクセス」は、テナントに登録された単一テナントのアプリが対象で、他社のマルチテナントのアプリには使えない（Todyl、ConnectWise）。顧客の側に残る手段は、同意する権限を絞ることと、使わないアプリを外すことくらいしかない（考察）。
2. 見えない読み取りがある。 Huntress は、Graph を使ったディレクトリの読み取りは監査の記録に残らないとし、「トークンは出たが、取られたものは見えない」が現状だと書いている。バックアップを契約しているテナントでは、攻撃者の読み取りと正規のバックアップの読み取りが同じアプリの名前で記録され、送信元のIPもMicrosoftの基盤のものになる。要求ごとの送信元を残す Microsoft Graph アクティビティログは P1/P2 が必要で、さかのぼって有効にはできない（Huntress、Todyl）。「痕跡がない」ことが「何もされていない」ことを意味しない（考察）。
3. ベンダーのアプリが、自分で自分の権限を上げられた。 約50テナントで Cloud Management 系のアプリが自分に Exchange 管理者などのロールを付け、1テナントではグローバル管理者にまでなった。ロールを割り当てられるアプリは、管理者そのものと同じ扱いが要る（Huntress）。ある Reddit の利用者は、何年も使っていない SkyKick のアプリが自分を Exchange 管理者にしたという通知を受け取ったと書いている（BleepingComputer）。
4. ベンダーの鍵を止めても、足された鍵は残る。 グローバル管理者になったアプリは、他のアプリへの認証情報の追加、新しいアプリの作成と権限付与、利用者のパスワードや認証方法のリセット、条件付きアクセスの変更ができる。どれもベンダーの鍵に頼らない新しい入口になる。Huntress は「ベンダーの認証情報の再発行は必要だが、それだけでは足りない」と書いている（Huntress）。
5. MSPの構造が被害を広げうる。 MSPの管理ツールは多くの顧客テナントに同意されていることが多く、そこに鍵が足されれば、1つのテナントから他の顧客へ広がる道ができる。Huntress は、実際に広がったところはまだ見ていないとしたうえで、MSPには管理ツールとセキュリティ製品のアプリから点検するよう求めている（Huntress）。セキュリティ製品のアプリに鍵が足されたことは、守る側の道具が、そのまま攻撃者の道具になりうることを示している（考察）。

運用者向けの具体的な対策と検知ポイント

対策（事実に基づくもの）

• 7つのアプリを、各テナントで無効化する（削除しない）。ConnectWise が全認証情報の再発行と復旧の手順を示すまで戻さない。無効化の間はバックアップが止まるので、最後に取れた復元ポイントを確かめておく（Huntress、ConnectWise）。
• MSPは、自社のテナントと管理しているすべての顧客テナントで点検する。使われていない古い SkyKick の接続が残るテナントも含める（ConnectWise）。
• 10月13日以降（記録があれば10月1日以降）を対象に、アプリの認証情報（シークレット、証明書、フェデレーション資格情報）、ディレクトリロール、所有者、同意、条件付きアクセスや信頼できる場所の変更を確かめる。心当たりのないものは、証拠を残してから外す（ConnectWise、Huntress、Todyl）。
• Exchange で、外部への自動転送、受信トレイのルール（隠しルールを含む）、トランスポートルール、メールボックスへの代理アクセスの追加がないか確かめる（ConnectWise）。
• 条件付きアクセスでこれらのアプリを除外しているポリシーがあれば、アプリを無効化したうえで見直す（Huntress）。
• Microsoft Graph アクティビティログを有効にする（さかのぼっては効かない）（Todyl）。

検知ポイント（事実に基づくもの）

• Entra のサインインログは、既定の「ユーザーのサインイン」ではなく「サービス プリンシパルのサインイン」のタブで、上のアプリケーションIDに絞って見る。144.172.64[.]128（AS14956、RouterHosting）と、Microsoft／Azure 以外のアドレスに注目する（ConnectWise、Huntress）。
• 監査ログの「Add member to role」「Update application」「Add service principal credentials」。サービスプリンシパルが自分をロールに加える、あるいは他のアプリを変更する動きは、多くのテナントでそれだけで調べる価値がある（Huntress）。
• User-Agent の組み合わせ。ベンダーのアプリは kiota-dotnet、不正な操作では Python-urllib/3.12、python-requests/2.31、python-requests/2.34.2、パスワードスプレーでは curl/7.88.1 が見られた。どれも単独では弱く、アプリとIPと組み合わせて使う（Huntress、BleepingComputer）。
• アプリの所有元テナントID 3f9cd7a0-127a-4ed4-bf06-2f830d5616b7（ConnectWise S-K LLC）。SkyKick のアプリはすべてここから発行されている（Huntress、Todyl）。

考察（運用上の工夫）

• 他社のアプリに同意するときは、「そのベンダーの鍵が漏れたら、自社の何が読まれ、何が書き換えられるか」を確かめる項目に加えたい。バックアップ、メール保護、管理ツールのように広い権限が要るアプリほど、台帳に載せ、使わなくなったら外す運用が要る。
• アプリの登録でシークレットを禁止したり有効期間を短くしたりできるアプリケーション管理ポリシーや、アプリ管理者ロールを持つ人を絞ることは、足された鍵を使いにくくする（Huntressの指摘）。自社の管理ツールやセキュリティ製品のアプリにも、ロールの割り当てと認証情報の追加を監視する警報を設けておくとよい。
• 今回の点検項目は、ConnectWise の製品を使っていない組織にとっても、「ベンダーのアプリを経由した侵入」への備えとしてそのまま使える。

参考リンク

• ConnectWise (SkyKick) Vendor Credentials Abused in M365 Attacks（Huntress、2026年10月16日、17日更新）
• Investigation: Unauthorized Access Through the ConnectWise Cloud Backup Microsoft 365 App（Todyl、2026年10月16日）
• Cloud Backup (formerly known as SkyKick) Service Interruption（ConnectWise Trust Center、10月18日 01:00 UTC 更新）
• Hackers breach Microsoft 365 tenants via ConnectWise supply-chain attack（BleepingComputer）
• Hackers Use Compromised ConnectWise Credential to Sign In to 173 Microsoft 365 Tenants（The Hacker News）