Microsoft 365へ外部サービスをつなぐと、バックアップや連携機能を便利に使える反面、「そのアプリが持つ権限」がもう一つの入口になります。Microsoftは10月21日、Storm-0940と呼ぶ活動者が、AI侵入テスト・フレームワークARTEXを使い、ConnectWiseのCloud Backupに関わるサプライチェーン侵害を広げたとする調査を公開しました。
注目したいのは、AIが攻撃を自動化したという見出しだけではありません。すでに許可済みのアプリケーションを経由すると、普段のユーザー名・パスワードによるサインインとは別の経路で、Microsoft 365の設定やデータに触れられる可能性があるからです。
Microsoft 365の運用担当者は、何を止め、何を消さず、どの記録を先に見るべきか。ARTEXの名前より先に、第三者アプリの信頼関係を点検する順番を見ていきます。
今回の入口は「AIを使った攻撃」ではなく、委任済みアプリの資格情報と権限です。
影響を急いで断定せず、対象アプリ、サービスプリンシパルのサインイン、権限・資格情報の変更を時間順に確かめることが出発点になります。
ARTEXを使った攻撃で、何が速くなったのか
Microsoft Securityの調査によると、Storm-0940は2026年9月以降、ARTEXを使って多業種の数百組織を標的にしました。Microsoftは同活動者を中国国家と連携する存在と評価しており、複数の事例で標的化から特権クラウドアクセスまでが3時間未満だったと説明しています。
ARTEXは、任意のAIモデルを使って侵入テストの作業を自動化できるオープンソース基盤です。Microsoftの説明では、偵察からデータ流出までを少ない人手で進めるマルチエージェント型の仕組みとして使われ得ます。ここで重要なのは、AIが新しい脆弱性を魔法のように作るという話ではなく、偵察、試行、見つけた情報の整理を同時並行にしやすくする点です。
速さが変わると、監視アラートの後に人が相談する時間も短くなります。
「不審なアラートが一件あった」ではなく、どのアプリの、どの権限で、何が続いたかを一続きで見る準備が必要です。
ConnectWise経由で問題になった「信頼済みアプリ」
Microsoftは、ConnectWiseのマルチテナントアプリケーションに対する侵害とStorm-0940を関連付けています。攻撃者は、すでに顧客テナントでアクセスを許可されていたアプリの資格情報を悪用し、通常の対話式サインインを経ずにMicrosoft 365環境へ認証したと報告されています。
その後の活動として、MicrosoftはMicrosoft Graphを介した偵察、アプリ資格情報の変更、権限を広げ得る変更を観測しました。Microsoftの公開情報には、ConnectWise関連アプリを使って2,250超のテナントにサインインを試みたことも記載されています。
ただし、ここで読み違えたくない点があります。Microsoftは、影響を受けたアプリが存在することや認証が成功したことだけでは、顧客データがアクセス・流出したことを意味しない、と明記しています。存在確認、サインイン、Graph操作、権限変更、データ操作を同じ重さで扱わず、記録をつないで判断します。
第三者アプリは、便利な連携のために権限を受け取ります。
だからこそ、アカウントのパスワード変更だけで完結させず、アプリ自身の資格情報、同意、サービスプリンシパルの履歴まで確認対象に入れる必要があります。
AIエージェントに渡す権限の境界を考えるなら、Open Agent Safety Platformの記事で扱った「必要な権限だけを渡し、外側から記録する」という視点も役立ちます。クラウド連携アプリでも、役割と範囲を後から説明できる状態を保ちたいところです。
まず止めることと、消さずに残すこと
ConnectWiseの公式アドバイザリーは、対象となるアプリ接続を、サービス別の正式な復旧案内が出るまで無効のままにするよう案内しています。復旧の見通しや再登録の手順は更新され得るため、メールの転送文ではなくTrust Centerの最新表示を確認するのが安全です。
一方で、Microsoftは最初の対応として、エンタープライズアプリをすぐ削除しないよう勧めています。削除を先にすると、設定や監査証跡が失われ、何が起きたかを追いにくくなるためです。接続の遮断、構成とログの保全、確認済みの不正な資格情報・権限の除去という順番を、組織のインシデント対応手順に沿って進めます。
「アプリを削除すれば安全」と急がないでください。
緊急の封じ込めを優先しつつ、サービスプリンシパルの設定、監査ログ、SIEMの記録を残してから、権限や資格情報の是正へ進むことがMicrosoftの案内です。
今回のように管理範囲が複数社にまたがるときは、PHP緊急更新の記事で触れたように、「誰がその実行環境や連携を管理しているか」を先に分けると連絡先を取り違えにくくなります。自社テナント、MSP、アプリ提供者のどこが次の操作を持つのかを整理しましょう。
サービスプリンシパルは、どこを見ればよい？
Microsoftは、影響を受けたConnectWiseアプリが現在または過去に導入・承認されていたすべてのMicrosoft 365テナントを確認し、表示名ではなくアプリケーションIDで探すよう案内しています。表示名は似たものや変更されたものがあり得るためです。
次に見るのは、サービスプリンシパルの成功・失敗サインイン、Microsoft Graphの操作、アプリ資格情報の追加、所有者・同意・アプリロール・特権ロールの変更です。Microsoftは少なくとも10月15日以降、可能なら10月1日以降まで記録を広げるよう推奨しています。公開済みのIPだけに絞らず、普段のベンダー基盤と異なる送信元や、予期しない大量アクセスも文脈と照合します。
見つけたアプリを「影響あり」と即断しないことも大切です。
アプリの存在 → 実際の認証 → Graph操作 → 権限・資格情報の変更 → リソースアクセス、という順に記録を結ぶと、調査と封じ込めを混同しにくくなります。
外部連携を、使い続けられる状態へ戻すために
AIを使う攻撃が注目を集めるほど、防御側も「AIだから特別」と考えたくなります。しかし今回の中心にあるのは、長く使われてきた外部アプリの信頼、資格情報、最小権限、そして監査ログです。AIはその既存の経路を速く、大きく試せるようにした要素として捉えるほうが、対策の場所を見失いません。
復旧後も、第三者アプリの棚卸しを一度きりで終わらせず、不要な同意を外し、強い権限を定期的に見直し、異常なアプリ専用アクセスを監視することが土台になります。外部サービスを止めることではなく、どのサービスに何を任せ、異常時に誰が止めて調べるかを決めておくことが、連携を安全に使い続ける条件になります。
次にMicrosoft 365の連携を棚卸しするときは、ユーザー一覧だけでなく「アプリに渡した権限と、そのアプリの操作履歴」を並べてみてください。
信頼済みの連携を見える化できれば、急なアラートにも、止める・残す・調べるの順で落ち着いて向き合えます。
