TL;DR
- 01何が起きたか
2026 年 10 月、ConnectWise の Cloud Backup（旧 SkyKick）などのアプリの資格情報が悪用され、顧客の Microsoft 365 テナントに不正にサインインされた。Huntress の調査では、攻撃元の IP からのサインイン活動が約 1,000 テナントにあり、300 超で成功した。同じ日、2 つの顧客テナントでは、別の ConnectWise 系アプリの ID が自らを Global Administrator にしていた（Huntress は、サインインと同じ攻撃者の操作とは結びつけていない）。資格情報の露出経路は未解明で、インシデントは継続中である。
- 02なぜ見分けられないか
攻撃者は顧客のパスワードを使わず、顧客の管理者が同意したアプリとして認証した。正規のアプリの操作と、資格情報を持つ別の主体の操作は、認証の時点では区別がつかない。
- 03欠けていた層
ConnectWise は 10 月 14 日に不正アクセスを発見していたが、アプリ ID を無効化した 17 日までの間の 15 日に、管理者権限の自己付与は通った。効かなかったのは、同意済みのアプリ ID の操作を、実行の前に「ベンダーが意図した操作か」独立に確かめる層である。
何が起きたか
- 対象
- ConnectWise の Cloud Backup（旧 SkyKick）と Cloud Management 系の Microsoft 365 アプリ。MSP（マネージドサービスプロバイダ）とその顧客のテナントで、管理者が同意して導入している。
- 資格情報の悪用
- Cloud Backup のアプリ ID の資格情報で、顧客テナントにサインインされた（Huntress）。顧客のパスワードは要らず、アプリとしてトークンを得る形である。
- 規模
- Huntress は 10 月 17 日、攻撃元 IP のサインイン活動が約 1,000 テナントにあり、300 超で成功したと報告した（16 日時点の確認は 162 テナント）。資格情報はアプリに同意した全テナントで通るため、影響はさらに広い可能性がある。
- 管理者権限の自己付与
- 10 月 15 日、2 つの顧客テナントで、Cloud Management の Microsoft Teams 用アプリの ID が自らを Global Administrator にし、他のアプリに資格情報を追加した。
- ConnectWise の対応
- 10 月 17 日に 7 つのアプリ ID を無効化し、関連する証明書を失効させ、Cloud Backup など 3 サービスを停止した。無効化は既に行われた変更を元に戻さず、発行済みのトークンは失効するまで使える可能性がある（同社 advisory）。
- 侵入の経路
- 資格情報がどこから渡ったかは未解明。製品の脆弱性の寄与は「確認されていない」（ConnectWise）。
用語メモ
テナント — Microsoft 365（Entra ID）で、組織ごとに分けられた利用環境。利用者、アプリ、権限はテナントごとに管理される。
アプリ ID（サービスプリンシパル） — 人ではなくアプリがテナントにサインインするための ID。管理者が同意した権限を持ち、資格情報を持つ者はその権限で動ける。
トークン — 認証の後に発行される、一定時間有効な通行証。アプリを止めても、発行済みのものは失効するまで使えることがある。
③ と ④ は別のアプリの操作で、Huntress は同じ攻撃者のものとは結びつけていない。どちらも ① の同意を根拠に、確かめられないまま通った。
MSP とその顧客のテナントで導入。
経路は未解明。
2 つの顧客テナントで、他のアプリに資格情報を追加。
トークンを得る。
時系列 — 公表と対応
- ConnectWise が不正アクセスを発見（同社 advisory）。
- 03:44（UTC）ごろ、ある顧客テナントで Cloud Management の Teams 用アプリが自らを Global Administrator にし、2 つのアプリに資格情報を追加。06:13〜08:34（UTC）に、攻撃元の IP が Cloud Backup のアプリとして認証した。
- Huntress が公表（162 テナント）。ConnectWise が advisory を公開。
- ConnectWise が 7 つのアプリ ID を無効化し、Cloud Backup を停止。Microsoft Threat Intelligence が X で注意を呼びかけ。Huntress が約 1,000 テナントの活動を報告。
- Huntress が、同じ手順の管理者権限の自己付与を 2 つ目の顧客テナントで確認。10-20 にかけて更新が続き、10 月 20 日 00:45（UTC）の時点で、3 つのサービスは停止したまま。
事実は Huntress（調査主体の自己公表）と ConnectWise の公式 advisory に拠る。資格情報の露出経路、製品の脆弱性の寄与、管理者権限の自己付与とサインインが同じ攻撃者かは未確認である。Huntress は被害テナントを監視する当事者でもあり、自社のアプリも標的にされた。
公表後の対応
- Huntress: アプリの無効化と、資格情報・ロール・監査ログの確認を推奨した。
- Todyl: アプリを無効化しても、発行済みのトークンは最長 90 分有効なままになりうると報告した。
なぜ止まらなかったか
この事案の失敗は、顧客のパスワードの弱さでも、操作の誤りでもない。アプリ ID の資格情報は持つ者にそのアプリの権限をそのまま与え、ロールの付与や資格情報の追加も、実行の前に「ベンダーが意図した操作か」を確かめられないまま通った。
導入のときに一度与えた同意が、その後の管理操作の根拠として、実行のたびに確かめられないまま使われた。
証明は操作が実行される前に働き、検出は異常が表に出た後に働く。その間、アプリ ID の操作は同意どおりの正規の操作として扱われる。
アプリ ID はまだ有効
検出は働いた。Huntress は、アプリが自らを昇格させた操作を、通信の特徴（User-Agent）の違いなども手がかりに見分けている。ただ、気づくのは操作の後で、無効化までの間に権限の付与は通った。「アプリに同意した」と「この操作はベンダーが意図した操作である」は別々の事実で、前者は導入の時点で記録され、後者は実行のたびに確かめなければならない。この隔たりが検出と証明の落差であり、構造的な欠落である。
同じ構造は、Vercel/Context.ai（AI ツールへの「全許可」の OAuth が入口）と Salesloft Drift（盗まれた OAuth トークンで 700 超の Salesforce 環境を参照）にも現れている。
対策するには
ベンダーのアプリの資格情報が渡っても、顧客の側で通る操作を狭めることはできる。露出経路が分からなくても、アプリ ID に許す操作を導入のときに絞り、ロールの付与や資格情報の追加のように権限を変える操作は、実行の前に止めて確かめる。止めた操作と通した操作は、アプリとは別の場所に残す。
注意したい業界・業務
- 業界調達・サプライチェーン
- MSP と、Microsoft 365 のバックアップや管理を外部のサービスに任せる組織。バックアップや管理の SaaS は、テナント全体に及ぶ権限を求めることが多い。
- 業務アカウント・権限の管理
- テナントに導入したアプリと、アプリが持つ権限の管理。今回の操作は、利用者ではなく、同意済みのアプリ ID から行われた。
いまの対策で埋まるか
| 対策 | 今回 | 理由 |
|---|---|---|
| 利用者の多要素認証（MFA） | 関係しない | 攻撃者は利用者のパスワードを使わず、アプリとして認証してトークンを得た。 |
| 導入時の同意の審査 | 一部 | アプリに与える権限の広さは絞れる。与えた権限の範囲内の操作は、資格情報を持つ者なら誰が実行しても通る。 |
| サインインと監査ログの監視 | 一部 | Huntress は通信の特徴（User-Agent）の違いを手がかりにしたが、それだけでは決め手にならない。気づくのは操作の後で、ディレクトリの読み取りは監査記録に残らない。 |
| ベンダーによるアプリ ID の無効化 | 一部 | 以後の認証は止まる。既に行われた変更は戻らず、発行済みのトークンは失効するまで使える可能性がある。 |
- アプリ ID に許す操作を、導入のときに決める。バックアップの読み取りは可、ディレクトリロールの自己付与と他のアプリへの資格情報の追加は不可、のように操作の種類で決める。同意した権限の広さだけでは、この区別はつかない。
- 権限を変える操作は、実行の前に止めて確かめる。アプリ ID からのロールの付与や資格情報の追加は、決めた範囲に入るかを照合し、入らなければ通さない。登録された実行環境から来たかも、資格情報とは別に確かめる。
- どの許可でどの操作をしたかを、アプリとは別に残す。止めた操作と通した操作を、後から第三者に示せる形、つまり証明として残す。
テナントに同意したアプリについて、組織で確かめる 3 項目
- 使っていないアプリや、必要より広い権限が残っていないかを、定期的に見直しているか。
- アプリ ID が自らにロールを付けたり、他のアプリに資格情報を足したりしたとき、誰に知らせが届くか。
- ベンダーが侵害を公表したとき、そのアプリを止め、発行済みのトークン、追加された資格情報、付与されたロールを確かめる手順と担当が決まっているか。
注：正規の実行環境そのものが侵害された場合や、決めた範囲の中の操作が悪用された場合は、この仕組みでも通ってしまう。許す範囲の決め方が緩ければ、緩いまま通る。また、権限を変える操作を止めて確かめる運用にすると、ベンダーの正規の操作も遅れる。資格情報の露出経路はまだ公表されていない。続報で判明すれば、この Brief を改訂する。
Sources
- 一次・企業公式ConnectWise「Cloud Backup (formerly known as SkyKick) Service Interruption」
- 一次・X の投稿Microsoft Threat Intelligence ConnectWise Cloud Backup の OAuth アプリの侵害についての投稿
- 一次・調査主体の自己公表Huntress「Vendor credential enables unauthorized access」
報道・解析 3 件
- 独立報道The Hacker News「Hackers Use Compromised ConnectWise Credential to Sign In to 173 Microsoft 365 Tenants」
- 独立報道The Hacker News「ConnectWise Suspends Cloud Backup After Attackers Compromise Microsoft 365 Tenants」
- 独立解析Todyl「Investigation: Unauthorized Access Through the ConnectWise Cloud Backup Microsoft 365 App」
参照: 事後の検知が証明にならない論点は「AI時代のサイバー防衛に残された、最後の層」。