なぜMSの検知クエリは「4つ中3つ」しか書かれていないのか──2,250社試行・実被害173社のConnectWise侵害でMFAを素通りした「2段階攻撃」と4つの監査死角

2026年10月27日 02:55

【訂正と補足（2026年11月2日）】

Microsoftの原文で確かめ直したところ、この記事の次の点が誤っていました。お詫びして訂正します。

・「毎分2,900回」の数字の使い方が誤りでした。Microsoftの記事で毎分2,900回の失敗は、10月10〜14日に8組織（327アカウント）へ行われたパスワードスプレーのピーク（10月11日）の数字です。ConnectWise侵害後の2,250超のテナントへのサインイン試行の回数ではありません。

・本文の「さらにその直後の10月15日から17日には、毎分最大…」の数字は、10月15日から17日の出来事ではなく、10月10〜14日のパスワードスプレーという別の出来事の数字です。

・「狙われたアカウントの約98%をロックアウト」は、原文では「やり取りの約98%がロックアウト応答」で、アカウントの98%ではありません。

「マイクロソフトの公式ブログに掲載されていた検知用の検索クエリ（KQL）をそのままコピーして社内ログを調べましたが、1件もヒットしませんでした。うちの会社は完全に無傷です！」

もし社内のセキュリティ担当者や委託先の運用チームからこんな報告が上がってきたら、「よくやってくれた、それで安心だ」と胸をなでおろしてしまわないでしょうか。

しかし、2026年10月15日から17日にかけて世界中を震撼させた、自律型AIペネトレーションテスト基盤「ARTEX（アルテックス）」とIT管理・バックアップ大手「ConnectWise Cloud Backup（旧称：SkyKick）」をめぐるサプライチェーン侵害事案において、最も危険な落とし穴こそがこの「公式クエリの丸写しによる安心」でした。

最初にこの記事の結論をお伝えします。

2026年10月21日にマイクロソフトの脅威インテリジェンス部門（Microsoft Threat Intelligence）が公表した公式レポートと、最前線でインシデント対応にあたったHuntress、Todyl、Kudelski Security、Zscaler、Expel、ConnectWise、CrowdStrike、AhnLab ASEC、そしてGMOサイバーセキュリティ byイエラエの一次記録を1行ずつ突き合わせてファクトチェックした結果、公式発表の表面だけをなぞっていては絶対に気づけない「3つの重大な死角」が浮かび上がりました。

死角1（本文「4つ」対クエリ「3つ」の欠落）：マイクロソフト公式ブログの対策本文には「4つのアプリケーションIDをすべて棚卸しせよ（Inventory all four application IDs）」と明記されているにもかかわらず、同じ記事のKQL検知クエリと侵害指標（IoC）の表には「3つのID」しか記載されておらず、メールや社内ファイルを扱う第4のExchange / SharePoint用バックアップモジュール（さらに10月17日にConnectWiseが一括無効化した計7つの関連アプリIDの残り）が検索条件から抜け落ちていること。
死角2（10月15日の「第1波」と「第2波」の二段階構造と2028年合鍵）：「2,250社以上へのサインイン試行」という大きな数字の裏で、実際に鍵穴が合って侵入された「162社から173社」の被害現場では、外部IP（144.172.64[.]128 等）からPythonスクリプトでテナント番号順に総当たりした「第2波（06:13 UTC〜）」の数時間前に、正規の通信部品名（kiota-dotnet）とMicrosoft Azure内部IPv6を使った「第1波（01:58 UTC〜・03:44 UTC〜）」が静かに実行されていたこと。この第1波では、約50社でアプリ自身に「Exchange管理者」ロールが付与され（翌10月16日に攻撃者自身がロールを削除して証拠隠滅）、さらにわずか5分間で「社内のまったく別の正規アプリ2つ」に2028年まで使える新しい合鍵（クライアントシークレット）が埋め込まれていたこと。
死角3（人間用MFAの素通りと15分間のKey Vault一括窃取・7日間のログ寿命）：人間向けの多要素認証（MFA）やユーザー向け条件付きアクセスをどれだけ強化しても、機械同士が直接通信する「OAuth 2.0 クライアント認証情報フロー（App-Only認証）」では最初からMFAが呼ばれないこと。さらに侵入後わずか15分間で3つ以上のAzure Key Vaultから20件以上の秘密鍵がごっそり抜き取られ、無料版（Entra ID Free）の環境ではわずか7日間でサインインログ自体が消滅してしまうこと。

この記事は、次のような方に向けて書いています。

企業の情シス・セキュリティ運用（SOC / CSIRT）・クラウドインフラ管理に携わり、Microsoft 365（Entra ID）の外部連携アプリやサービスプリンシパルを棚卸ししたい方
ベンダーから配布された検知クエリやIoC（侵害指標）をそのまま回すだけでなく、「ログに映らない死角」をどう塞ぐかという実践的なフォレンジック（デジタル鑑識）の視点を知りたい方
自律型AI「ARTEX」を使った攻撃について、「日本企業80社や韓国の金融機関を狙った攻撃もすべて同じ国家グループ（Storm-0940）の仕業だ」という世間の短絡的な解説に違和感を覚え、一次資料に基づく正確な事実関係を確認したい方

この記事を読むことで、明日から現場でそのまま使える「3つの実務的な持ち帰り」が得られます。

持ち帰り1：マイクロソフトの公式KQLクエリに含まれていない「第4〜第7の関連アプリID」や、10月15日深夜の「第1波（Azure内部IPv6 × 正規 kiota-dotnet）」、そして「別アプリに植え付けられた2028年期限の合鍵」を漏れなく洗い出すための具体的な点検手順とKQLクエリが手に入ります。
持ち帰り2：「不審なアプリをパニックで削除（Delete）して証拠を消してしまう罠」「ユーザータブだけを見てサービスプリンシパルタブを見落とす罠」「Graph APIの読み取りログが既定で残らず、無料版は7日でログが消える罠」という4つの鑑識の落とし穴を回避できます。
持ち帰り3：「2,250社試行」と「実被害173社」の漏斗（ファネル）構造や、オープンソースの自律型AI「ARTEX」をめぐる犯人特定（アトリビューション）の鉄則を、経営層や社内メンバーへ専門用語なしでクリアに説明できるようになります。

この記事の元になった動画（1920×1080 フル解説本編）は、こちらからご視聴いただけます：https://youtu.be/nymRsTHk91Y

こんにちは、限界コンサルおじです。普段は企業のシステム設計や業務改革、セキュリティ運用の泥臭い現場を走り回りながら、海外の一次レポートを徹底的に検証する番組と記事をお届けしています。初めて読んでくださる方は、ぜひこちらの自己紹介記事もあわせてご覧ください：限界コンサルおじの自己紹介とチャンネルのご案内

図1：なぜマイクロソフトの検知クエリには「4つ中3つ」しか書かれていないのか？（Slide 01）

序章：予備知識ゼロでわかる「3つの基本用語」と今回の全体像

本編の検証に入る前に、今回の事件を耳と目でスッキリ理解するための「3つの基本用語」だけを、オフィスビルの入退館にたとえて整理しておきましょう。

図2：予備知識ゼロでわかる「3つの言葉」と全4章のロードマップ（Slide 02）

用語1：サービスプリンシパル（Service Principal）＝「外部の自動プログラムが出入りするための機械専用の業務用名札」

人間の社員がビルに入るときは、顔写真付きの社員証をかざし、スマホに届くワンタイムパスワード（多要素認証：MFA）を入力します。しかし、夜中に自動でデータをバックアップする外部ソフト（今回のConnectWiseなど）は、いちいち人間がスマホを押すわけにいきません。そこで「アプリ番号（client_id）」と「秘密の合鍵文字列（client_secret）」だけを提示して、24時間いつでも裏の搬入口から直接出入りできる「機械専用の業務用名札」を登録します。これがサービスプリンシパルです。

用語2：テナントGUID（Tenant GUID）＝「クラウド上の会社ごとの部屋番号」

Microsoft 365やEntra IDを契約している企業ごとに割り振られた、数字とアルファベット（0〜9、a〜f）からなる世界に1つだけの「会社の部屋番号」です。

用語3：KQL（Kusto Query Language）＝「膨大な入退館記録から怪しい通信を探し出す検索式」

何百万件もあるログのなかから、「特定のアプリ番号や怪しいIPアドレスからの通信だけ」を一瞬で抽出するための検索プログラムの式です。

この3つを押さえたうえで、以下の4つの章で一次資料のファクトチェックを進めていきます。

第1章：攻撃グループ「Storm-0940」の豹変と自律型AI「ARTEX」の正体、そして「ツールが同じ＝犯人も同じ」と決めつけてはいけない理由
第2章：「2,250社試行」と「実被害173社」の10倍以上の数字ギャップの正体と、マイクロソフト公式クエリから消えた「第4のアプリID」
第3章：10月15日に起きた「第1波（01:58・03:44 UTC）」と「第2波（06:13 UTC）」という、まるで別人のような2段階攻撃のミステリー
第4章・結論：なぜMFAは素通りされ、15分でKey Vaultの秘密鍵が抜かれたのか。「4つのフォレンジックの罠」と明日から使える監査クエリ・チェックリスト

第1章：Storm-0940の豹変と自律型AI「ARTEX」──なぜ「ツールの一致」で犯人を決めつけてはいけないのか

まずは第1章として、今回のサプライチェーン侵害を引き起こしたとされる脅威アクター「Storm-0940（ストーム・ゼロキューヨンゼロ）」と、攻撃の自動化に使われたオープンソースの自律型AI基盤「ARTEX（アルテックス）」の事実関係を、一次資料から正確にたどります。

図3：Storm-0940の豹変と自律型AI「ARTEX」の正体・アトリビューションの罠（Slide 03）

1-1. 「1日1回の忍び足」から「毎分2,900回・3時間未満の猛攻」への豹変

マイクロソフトが2026年10月21日に公開した公式脅威インテリジェンス報告、および2024年10月31日の過年度背景レポートを照合すると、Storm-0940の行動様式が2026年9月を境に劇的に変化したことがわかります。

従来の行動様式（2021年〜2024年頃）：中国国家背景とされるStorm-0940は、家庭用の古いルーター（SOHOルーター）などを乗っ取ったボットネット「CovertNetwork-1658（別名：Quad7 / 7777ボットネット）」を踏み台にしていました。当時の最大の特徴は、警備システムのロックアウトやアラートを避けるために、全体の約80パーセントのケースで「1つのアカウントに対して1日にたった1回だけパスワードを試す」という、極めて遅くて目立たない「ロー・アンド・スロー（Low-and-Slow）」攻撃でした。
2026年9月以降の豹変（ARTEXによる超高速化）：ところが2026年9月以降、Storm-0940は自律型AIペネトレーションテスト基盤「ARTEX」を悪用して攻撃工程を自動化し、世界数百の組織を標的にしました。複数の事例において、「最初に標的を定めてからクラウド環境の特権アクセスを奪取するまでわずか3時間未満」という驚異的なスピードを記録しています。
10月10日〜14日の15万1,000回パスワードスプレー：その乱暴なまでの速度変化を象徴するのが、サプライチェーン侵害の直前にあたる2026年10月10日から14日の記録です。攻撃者は「144.172.64[.]99」という単一のIPアドレスから、8つの組織の327個のアカウントに対して、合計15万1,000回を超えるパスワード総当たり攻撃（失敗）を浴びせました。特にピークとなった10月11日の1日だけで11万1,000回以上も失敗を繰り返し、標的アカウントの約98パーセントをアカウントロックアウト（締め出し状態）に追い込んでいます。さらに続く10月15日から17日には、毎分最大2,900回というマシンガンのような速度でサインインを試行しました。

1-2. オープンソース「ARTEX」の出自、10月8日の閉鎖宣言、そして消えないフォーク

では、ここで悪用された「ARTEX」とは一体どのようなツールなのでしょうか。GitHub上に残された設計記録・複製リポジトリおよび韓国のセキュリティ企業AhnLab（アンラボ）のASEC分析チームが2026年10月14日に公表した隔離実験レポートから、以下の確定事実が確認できます。

開発者と競技会での実績：ARTEXは、中国のセキュリティ技術者である「Autumn-27」氏が開発したオープンソース（AGPL-3.0ライセンス）の自律型AI脆弱性診断・ペネトレーションテスト基盤です。中国の検索大手・百度（Baidu）が主催したセキュリティ競技会「Agent+」で優勝した実績を持ち、2026年8月20日にバージョン0.3.2が公開された後、わずか1か月後の9月24日にはバージョン0.3.14まで猛烈なペースで機能拡張が重ねられました。
AhnLab ASECによる隔離実験と世界900個の公開IP：アンラボが隔離された実験環境でこのARTEXを動作させたところ、人間の指示を一切介さずに、標的Webサーバーのファイルアップロード脆弱性を見つけてWebシェル（裏口プログラム）を設置し、さらに内部のメッセージ管理ミドルウェア「Apache ActiveMQ」の脆弱性を突いて、社内ネットワークにある4台のホスト（PC・サーバー）を次々と自動で乗っ取る（ラテラルムーブメント）挙動が実証されました。アンラボは2026年10月14日時点で、ARTEXに関連する公開サーバーのIPアドレスを世界で約900個特定しており、詳細分析した600個のうち90.2パーセントが米国、中国、香港、シンガポールに集中していました。
2026年10月8日の公式閉鎖宣言とフォークの残存：実は、開発者のAutumn-27氏自身は、マイクロソフトがレポートを出す2週間近く前の2026年10月8日に、「オープンソースのツールが違法なサイバー攻撃に悪用されるリスクを防ぐため、今後はソースコードを非公開（クローズドソース化）にし、厳格な審査を通過した法人（B2B）のみに提供する」という安全声明を発表し、本家リポジトリの公開を停止していました。しかし、一度インターネット上に公開されたコードは消えません。GitHub上には RuoJi6/ARTEX、BaaRai/ARTEX、trhhubsd/ARTEX といった複製（フォーク）が現在も残存しており、攻撃者が自由に取得・改変できる状態が続いています。

1-3. ファクトチェックの重要論点：「ARTEXを使った攻撃＝すべてStorm-0940」という誤解を解く

ここで、今回の横断検証で最も強調しておきたい「犯人特定（アトリビューション）の罠」があります。2026年10月には、ARTEXや類似の自律型AIツールを使った攻撃レポートが複数の調査機関から相次いで発表されました。

CrowdStrikeの韓国金融機関標的レポート（2026年10月7日公開）：CrowdStrikeの報告によると、2026年9月下旬から10月上旬にかけて韓国の金融機関を狙った攻撃者は、香港のサーバーとARTEX稼働サーバー（38.244.50[.]120）を組み合わせ、複数の大規模言語モデル（DeepSeek v4.1-flash、GLM-5.3、Grok 4.6など）を開発補助ツールやARTEXに接続して攻撃を遂行し、さらには「盗み出した韓国企業のデータをTelegramのどこで売ればいいか」までAIに相談していました。
GMOサイバーセキュリティ byイエラエの日本企業80社標的レポート（2026年10月19日公開・10月21日更新）：GMOサイバーセキュリティ byイエラエの報告によると、日本企業約20社（うち9社は同一業種）を標的にしたARTEXのログイン画面と攻撃サーバーが確認されたほか、デジタルギフト・小売、保険・金融、物流、ECなど業種別に分かれた合計7台のAI攻撃基盤が日本の約80社を標的にしており、うち少なくとも8社が9月以降に被害や情報漏えいを公表しています。
NorForgeの「Cairn」調査レポート（2026年10月公開）：NorForgeの報告でも、ARTEXとは別のオープンソース自律型AI攻撃ツール「Cairn（ケアーン）」の公開パネルが20台以上見つかり、1,100件以上の自動攻撃プロジェクト（成功率約10パーセント）が米国・日本・オーストラリアの組織に対して稼働していたことが判明しています。

これらのニュースが同時期に出たことで、SNSや一部の解説記事には「韓国の銀行や日本企業80社を襲っているのも、すべてマイクロソフトが発表した中国の国家グループStorm-0940の仕業だ！」と一括りにする言説があふれました。

しかし、一次資料を正確に読めば、この短絡的な結びつけは明確な誤りです。

CrowdStrike自身も、韓国金融事案の攻撃主体を「未知の脅威アクター（Unknown Threat Actor）」と明記しており、Storm-0940とは一切断定していません（盗んだデータの売り先をチャットで相談するような行動は、国家背景の精鋭部隊よりも金銭目的の犯罪グループの特徴を強く帯びています）。
そしてGMOサイバーセキュリティ byイエラエも、2026年10月21日の追記において、「オープンソースの開発者が中国のエンジニアであることと、日本企業を攻撃している主体が誰であるかは一切関係がない」と明確に釘を刺しています。

誰でも無料でコピーできた公開ツールだったからこそ、国家背景のグループも、金銭目的のサイバー犯罪者も、同じ「ARTEX」という道具を使っているのです。道具が同じだからといって犯人まで同じだと決めつけると、守るべきポイントを見誤ります。

第2章：2,250社試行 vs 実被害173社の漏斗と、MS公式クエリから消えた「第4のアプリID」

続いて第2章では、2026年10月15日から17日にかけて発生した「ConnectWise Cloud Backup（旧称：SkyKick）」のサプライチェーン侵害について、各社の発表数値の食い違いと、マイクロソフト公式レポートの「4つ対3つの矛盾」を検証します。

図4：2,250社試行 vs 実被害173社の漏斗と「第4のアプリID」欠落（Slide 04）

2-1. なぜ「2,250社」と「173社」で数字が10倍以上違うのか？（攻撃ファネルの解明）

今回の事件では、調査会社ごとに発表している「被害の数字」が一見バラバラに見えます。まずは各社の一次資料の数字を並べてみましょう。

Microsoft（2026年10月21日）：「2,250以上のテナント（企業環境）に対してサインインが試行された（attempted sign-in to more than 2,250 tenants）」
Huntress（2026年10月16日公開・19日更新）：「自社の監視範囲で約1,000のEntraテナントにサインイン試行があり、そのうち300件以上（Over 300）のサインインが成功した」
ConnectWise公式アドバイザリ（10月15日初版・20日更新）およびKudelski Security：「実際に影響を受けた顧客テナントは162社から173社である」

「マイクロソフトは2,250社と言っているのに、コネクトワイズは173社と言っている。誰かが被害を小さく見せようとしているのではないか？」と疑いたくなるかもしれませんが、フォレンジックの仕組みを知れば理由は極めて明快です。これは「泥棒がドアノブをガチャガチャ回した部屋の数（試行）」と、「実際に鍵穴が合ってドアが開いてしまった部屋の数（成立）」の違いです。

1. 第1段階（ドアノブ回し：2,250社以上のテナントGUID）：攻撃者は、ConnectWise Cloud Backup（旧SkyKick）の廃止・失効したはずの古いアプリケーション認証情報（マスターキー）と、何らかの経路で入手した2,250社以上のテナントGUID（部屋番号リスト）を使って、片っ端からサインインを試みました。

2. 第2段階（門前払い：2,000社以上での未登録エラー）：しかし、狙われた企業が過去に一度もConnectWiseやSkyKickのバックアップ製品を導入していなければ、その企業のEntra ID（ビルの受付）にはそもそもその機械用名札（サービスプリンシパル）が登録されていません。そのため、「そんなアプリケーションはうちのテナントに存在しません（AADSTS700016: Application with identifier was not found in the directory 等）」というエラーが出て、入り口で門前払いになります。

3. 第3段階（鍵穴一致・侵入成立：162社〜173社 / Huntress観測で300件超の成功イベント）：2,250社以上のうち、過去または現在に実際にこのバックアップ製品を導入しており、テナント内にサービスプリンシパルの同意（Consent）が残っていたために鍵穴がピタリと合い、内部への侵入を許してしまった企業が「162社から173社」（1社あたり複数回のログインを含むHuntressのイベント観測数で「300件以上」）だったのです。

2-2. 最大の発見：マイクロソフト公式ブログの「本文4つ」対「クエリ3つ」の矛盾

そしてここからが、今回のファクトチェックで明らかになった実務上の最重要ポイントです。

マイクロソフトの2026年10月21日の公式ブログ記事の対策セクション（Mitigation / Hunting guidance）を原文で読むと、本文には明確にこう書かれています。

"Inventory all four application IDs"（4つのアプリケーションIDをすべて棚卸しせよ）

ところが、そのすぐ下に掲載されている、現場の管理者がコピー＆ペーストして使うためのKQL検知クエリおよび侵害指標（IoC）の表を見ると、なんとアプリケーションIDが「3つ」しか書かれていないのです。

マイクロソフトのクエリと表に記載されている「3つのID」は以下の通りです。

記載ID 1：506e08f9-6e9a-4da4-942b-a099a03644ae（ConnectWise Cloud Backup — SkyKick Platform Sync / Migrator）
記載ID 2：24205314-2b89-4e07-a2a4-579e898a5640（ConnectWise Cloud Management）
記載ID 3：0de14c77-b9b0-4137-9360-34878a929827（SkyKick Backup — ConnectWise Cloud Backup Master）

では、本文で「4つすべてを調べろ」と言っていた残りの「4つ目のアプリID」はどこへ消えてしまったのでしょうか。

Huntress、Todyl、Kudelski Security、そしてConnectWiseの公式アドバイザリを突き合わせると、SkyKick（ConnectWise Cloud Backup）の製品はバックアップ対象や機能ごとに複数のエンタープライズアプリに分かれており、上記の3つに加えて、メールや社内ポータルデータを扱う第4のモジュール「ExchangeおよびSharePoint用バックアップモジュール（SkyKick Cloud Backup for Exchange/SharePoint 等）」が存在します。

さらに、Expelの調査報告およびHuntressの記録によれば、ConnectWiseは2026年10月17日に、これらに関連する「合計7つのアプリケーションID」を一括で無効化・ローテーションしています。

もし企業のセキュリティ担当者が、マイクロソフト公式ブログのKQLクエリだけをそのままコピーして「3つのAppId」しか検索しなかったらどうなるでしょうか。残りの第4〜第7の関連モジュール、特にメール（Exchange）やファイル（SharePoint / OneDrive）に直結するバックアップモジュールに対する不審なサインインや権限操作を、丸ごと見落とすことになります。だからこそ、3つのIDの丸写しで終わらせず、テナント内にあるすべての「ConnectWise」および「SkyKick」名義のエンタープライズアプリケーションを名前と権限で総ざらいする必要があるのです。

第3章：10月15日の「2段階攻撃」ミステリー──01:58・03:44 UTCの第1波 vs 06:13 UTCの第2波

では第3章として、実際に鍵が開いてしまった162社から173社のテナントの中で、2026年10月15日に何が起きたのかを秒・分単位のタイムラインで解剖します。TodylとHuntress、Kudelski Securityのフォレンジック記録を時系列に並べると、背筋が凍るような「2段階の攻撃構造（第1波と第2波）」が浮かび上がってきます。

図5：10月15日の「2段階攻撃」の謎──第1波 vs 第2波の完全対比（Slide 05）

多くの解説では「外部の怪しいIPアドレス（144.172.64[.]128 など）から、Pythonなどの自動スクリプトで一斉に攻撃してきた」とだけ語られています。確かにそれは事実ですが、それは10月15日の朝6時13分（UTC）以降に始まった「第2波（フェーズB）」の姿にすぎません。実はその数時間前、深夜01時58分から03時49分（UTC）にかけて、まったく手口の異なる「第1波（フェーズA）」が静かに実行されていたのです。

3-1. 第1波（フェーズA：01:58〜03:49 UTC）──正規名札 kiota-dotnet とAzure内部IPv6による特権付与と2028年合鍵工作、そして翌日の証拠隠滅

まず、第1波の時計の針を正確に追いましょう。

10月15日 01:58 UTC頃（Todyl観測：約50社での特権ロール自己付与）：乗っ取られたConnectWise Cloud Managementアプリ（AppId: 24205314-2b89-4e07-a2a4-579e898a5640）が、約50社の顧客テナントにおいて、自分自身にメール環境を掌握できる特権ロール「Exchange管理者（Exchange Administrator）」を勝手に付与しました。さらに1社から2社のテナントでは、会社の最高権限である「グローバル管理者（Global Administrator）」を自分自身に付与しました。
10月15日 03:44〜03:49 UTCの5分間（Huntress観測：別アプリ2つへの2028年合鍵追加）：グローバル管理者を奪ったその管理アプリが、わずか5分間のうちに、テナント内にある「まったく別の2つの既存アプリ」（そのうちの1つは、なんとセキュリティ監視会社であるHuntress自身の正規連携アプリでした）に対して合計9回の編集操作（Update application）を実行し、有効期限が2028年まである新しいクライアントシークレット（2年間使える裏口の合鍵）を勝手に追加しました。
鑑識チームを震撼させた通信元とUser-Agent（名札）：この第1波（01:58 UTCからの特権ロール付与）で使われていたプログラムのUser-Agent（名札）は、普段ConnectWiseの正規システムが使っているのと同じマイクロソフト公式の.NET用通信ライブラリkiota-dotnet/1.9.0 (.NET Runtime 8.0.20)であり、通信元のIPアドレスもMicrosoft Azureのデータセンター内部のIPv6アドレスでした（※別アプリに追加した合鍵でのアクセスには Python-urllib/3.12 が使用されました）。
翌10月16日の「証拠隠滅（ロール自己削除）」：さらに驚くべきことに、翌日の2026年10月16日になると、攻撃者は再びアクセスし、前日に自分自身へ付与した「Exchange管理者」のロールを自ら削除（Remove member from role）し、「最初から何もなかったかのように」足跡を消して回ったのです。

3-2. 第2波（フェーズB：06:13〜08:34 UTC）──外部IPからテナント番号（0〜f）の昇順で2,250社をなめる絨毯爆撃

そして、この精密な第1波が終わった約2時間半後の10月15日 06時13分から08時34分（UTC）にかけて、今度はまるで別人のような「第2波（フェーズB：テナント番号順の総当たり絨毯爆撃）」が始まります。

通信元IPアドレスの変化：通信元はAzure内部IPv6ではなく、144.172.64[.]128、144.172.64[.]99、144.172.64[.]60（クラウドサーバー事業者Cloudie LimitedやStark Industries関連とされる外部IPv4アドレス）に切り替わりました。
User-Agent（名札）の変化：正規の kiota-dotnet ではなく、Python-urllib/3.12、python-requests/2.31.0、python-requests/2.34.2、curl/7.88.1、azure-toolkit/1.0 といった剥き出しのスクリプトや自律型AIツール群の名札に変わりました。
テナントGUIDの「0からfまで昇順」の機械的スイープ：Huntressの分析で判明した決定的な事実として、この第2波が各企業のテナントへアクセスした順番が、なんと「テナントGUID（部屋番号の16進数文字列）のアルファベット・数字の昇順（0 から始まり 9、a から f へ進む順番）」で機械的に並んでいました。06時13分に「0」で始まるテナントからスタートし、08時34分に「f」で始まるテナントで終わるまで、約2時間20分かけて2,250社以上のリストを上から順番になめていったのです。

3-3. なぜ第1波と第2波でこれほど手口が違うのか？

なぜ第1波は正規の kiota-dotnet とAzure内部通信で静かに約50社へ裏口を作り、第2波は外部IPからPythonスクリプトで番号順に総当たりしたのでしょうか。技術的な仮説としては次の2つが考えられます。

仮説A（ベンダー環境内部での標的型工作 → 外部AI基盤での一括スイープ）：攻撃者がまずConnectWiseのAzure環境そのもの（あるいは正規のビルド・実行基盤）に侵入し、第1波としてめぼしい約50社に正規ツール経由で特権と2028年合鍵を仕込んだあと、外に持ち出した認証情報と顧客テナントリストを自律型AI「ARTEX」に読み込ませて第2波の絨毯爆撃を走らせたという見方。
仮説B（初期侵入チームから自動化実行部隊への引き継ぎ）：初期侵入を果たした精鋭チームが第1波で確実に裏口を確保したうえで、奪った鍵を別の実行部隊や自動化ボットに引き渡したという見方。

いずれにせよ、実務上の教訓は明確です。「144.172.64.x の外部IPアドレスとPythonのUser-Agentだけ」を検索している企業は、Azure内部のIPv6と正規の kiota-dotnet で実行された「第1波の特権付与と翌日の証拠隠滅」を完全に見逃してしまいます。

第4章：【私なりの解釈】なぜMFAは素通りされたのか？Key Vault一括窃取と「4つのフォレンジックの罠」

ここからは、一次資料の事実を踏まえた【私なりの解釈】として、なぜ「全社員にMFA（多要素認証）を義務付けている企業」までがわずか5分で最高権限を奪われ、15分で金庫の鍵を抜かれてしまったのか、その構造的な死角と、現場の管理者が今まさにハマっている「4つのフォレンジック（鑑識）の罠」を解剖します。

図6：【私なりの解釈①】なぜMFAと条件付きアクセスは無力化され、Key Vaultが15分で抜かれたのか（Slide 06）

4-1. 人間用の改札（MFA）をどれだけ固めても、機械専用の搬入口（Client Credentials Flow）は素通りされる

まず1つ目の構造的核心は、「人間用の改札口と、機械専用の搬入口はまったく別の仕組みで動いている」という点です。

今回悪用されたのは、OAuth 2.0の「クライアント認証情報フロー（Client Credentials Flow）」、いわゆる「アプリ単独認証（App-Only Authentication）」です。これは人間の社員がブラウザ画面からログインするのではなく、バックアップソフトなどの機械が、自分のアプリ番号（client_id）と秘密の合鍵（client_secret）だけをマイクロソフトの認証サーバーに直接提示して、「私はConnectWiseの自動プログラムです」とアクセストークンを受け取る通信です。

多くの企業が導入している多要素認証（MFA）や、社外からのアクセスを制限する「ユーザー向けの条件付きアクセス（User Conditional Access）」は、あくまで「人間の社員がログインする正面改札口」にしかかかっていません。機械用のサービスプリンシパルが合鍵を使って裏の搬入口から入ってくるとき、人間用のMFAは最初から1回も呼ばれないのです。

別途ライセンスが必要な「ワークロードアイデンティティ向けの条件付きアクセス（Workload Identities Conditional Access）」を使って「ConnectWiseの正規サーバーIP以外からのトークン要求を遮断する」という網を張っていない限り、合鍵さえ本物であれば、海外の怪しいサーバーから毎分2,900回アクセスが来ても、クラウドの門番は「はい、正規の機械ですね、どうぞ」とすべて通してしまいます。

4-2. わずか15分間で3つ以上の「Azure Key Vault」から20件超の秘密鍵をごっそり抜く自律連鎖

さらに恐ろしいのが、Zscaler ThreatLabzの分析報告やマイクロソフトが記録した、侵入直後の「Azure Key Vault（アジュール・キー・ボールト）からの秘密鍵一括抜き取り」です。

攻撃者の自律型AIは、テナントに入るとまずMicrosoft Graph APIを通じて全社員の名簿、グループ、ディレクトリロール、アプリケーション一覧を高速で列挙します。そして、その企業がシステム全体のパスワードやAPIキー、暗号鍵を保管している金庫「Azure Key Vault」を見つけると、わずか「15分間」のうちに、3つ以上の異なるKey Vaultに対して合計20回以上の秘密情報読み取り（SecretGet）を連続実行し、社内のあらゆるシステムのマスターキーをごっそり持ち出していました。

実は私自身も昔、自分が管理していた検証用のクラウド環境で、これとそっくりな冷や汗モノの失敗をやらかしたことがあります。テスト用のバッチ連携プログラムに「いちいち権限エラーが出るのが面倒だから」と、うっかり金庫（Key Vault）の中身を全部読める強い権限をつけたまま放置してしまい、社内監査の模擬ペネトレーションテストで10分も経たないうちに全検証サーバーの接続キーを芋づる式に抜かれて真っ青になった苦い経験があります。人間が手でやっても10分で抜けるのですから、自律型AIなら15分で3つの金庫を空にするのも当然と言えます。

4-3. 現場の管理者がハマる「4つのフォレンジック（鑑識）の罠」

そのうえで、今回の一次資料を横断検証して浮かび上がった、現場の担当者が今まさに陥っている「4つのフォレンジックの罠」を整理します。

図7：【私なりの解釈②】現場がハマる「4つのフォレンジックの罠」と未確認事項の切り分け（Slide 07）

罠1：不審なアプリをパニックで「削除（Delete）」してしまい、証拠と犯行経路を自分で消してしまう罠

マイクロソフトの10月21日のレポートが最も強く警告しているのが、「不審なエンタープライズアプリをいきなり削除（Delete）するな、まずは無効化（Disable）せよ」という鉄則です。管理画面でサービスプリンシパルを完全に削除してしまうと、そのアプリに紐づいていた過去の権限同意（Consent）の状態や一部の関連メタデータが消えてしまい、「そもそもどの権限を使ってどのデータに触られたのか」を後から追跡できなくなります。まずはプロパティ設定で「ユーザーのサインインを有効にする：いいえ（無効化 / Disable）」に切り替えて出入りだけを止め、ログを完全に保全してから調査に入ってください。

罠2：大元のアプリを止めても「最大90分間」はトークンが生きており、「別アプリの2028年合鍵」は永遠に残り続ける罠

ConnectWiseが10月17日に大元の7つのアプリIDを停止しましたが、すでに発行されたアクセストークンは既定で60分から最大90分間は有効なまま動きます。それ以上に致命的なのは、第3章で見た通り、攻撃者がその5分間のうちに「社内のまったく別の正規アプリ（Huntressのアプリなど）」に2028年期限の新しいクライアントシークレットを追加していた場合です。大元のConnectWiseアプリをどれだけ無効化しても、別のアプリに植え付けられた合鍵は一切消えません。

罠3：「ユーザーのサインインログ」だけを見て安心し、「サービスプリンシパルのサインインタブ」を見落とす罠

Microsoft Entraの管理画面でサインインログを開いたとき、最初に表示される初期画面は「人間の社員のサインイン履歴（User sign-ins）」です。今回の攻撃はすべて機械用の名札で行われているため、初期画面をどれだけ検索しても1件も出てきません。必ず画面上部のタブを「サービスプリンシパルのサインイン（Service principal sign-ins）」に切り替えて検索する必要があります。

罠4：「ディレクトリ読み取りは既定で監査ログに残らない」うえに、「無料版は7日間でログが消える」という時間の壁

ExpelとTodylが指摘している通り、Microsoft Graphを通じた社員名簿や設定の「読み取り（GETリクエスト）」は、標準のEntra監査ログ（Audit Logs）には一切記録されません。何を読まれたかを知るには、有料の「Entra ID P1またはP2ライセンス」を保有したうえで、事前に「MicrosoftGraphActivityLogs」のDiagnostic設定（Log AnalyticsやSIEMへの転送）を有効にしておく必要があります。さらに、ライセンスがない無料版（Entra ID Free）のテナントでは、サインインログ自体の保存期間が「わずか7日間」しかありません。10月15日の攻撃から1週間以上が経過した現在、無料版の環境では10月15日の侵入記録そのものがすでに寿命で消え去っている可能性が高いのです。

4-4. 確定事実と「未確認事項」の厳格な切り分け

なお、今回のファクトチェックにおいて、公開されている一次資料だけでは裏付けが取れず「未確認」として断定から外した点が2つあります。

未確認事項1（ConnectWise内部での初期流出経路）：ConnectWiseの環境から具体的にどの経路で「廃止・失効済みのアプリ認証情報」と「顧客テナントGUIDリスト」が外部へ流出したのかという初期侵入の内部詳細（ConnectWiseおよびMandiantによるフォレンジック調査が継続中であり、現時点では外部公開されていません）。
未確認事項2（第1波と第2波の実行主体の内部関係）：10月15日の第1波（01:58 UTC〜・正規 kiota-dotnet 使用）と第2波（06:13 UTC〜・外部IPからPython等で昇順総当たり）が同一のオペレーターによる連続操作なのか、それとも初期侵入部隊から自動化実行部隊への引き継ぎなのかという内部オペレーションの分担。

これらは推測で断定せず、ログで確認された確定事実と明確に区別して扱います。

結論：明日から現場で実行する「3つの緊急監査アクション」と拡張ハンティングクエリ

最後に、明日会社のPCを開いたらすぐに実行してほしい「3つの緊急監査アクション」と、マイクロソフトの公式クエリの死角を補完した確認手順を1枚にまとめます。

アクション1：アプリ名義での総棚卸しと「無効化（証拠保全）」、および全アプリの2028年合鍵チェック（ログ消滅環境でも有効）

マイクロソフトのクエリにある3つのID（506e08f9-6e9a-4da4-942b-a099a03644ae、24205314-2b89-4e07-a2a4-579e898a5640、0de14c77-b9b0-4137-9360-34878a929827）だけでなく、第4のExchange / SharePoint用モジュールを含む「ConnectWise」および「SkyKick」名義の全アプリ（10月17日に無効化された計7つのIDすべて）をエンタープライズアプリケーション一覧から探してください。

見つかった場合は削除（Delete）ではなく必ず「無効化（Disable）」にしてログを保全します。そして、たとえ無料版で過去7日間のサインインログが消えてしまっていても、テナント内の「すべての既存アプリ」の設定を開き、2026年10月13日以降に見覚えのないクライアントシークレット（特に2028年期限のもの）や証明書が追加されていないか、また「Exchange管理者」や「グローバル管理者」のロールに見知らぬサービスプリンシパルが居座っていないかを「現在の設定状態」から直接確認してください。ログが消えていても、埋め込まれた合鍵は現在の設定画面に必ず残っています。

アクション2：サービスプリンシパルタブでの異常名札ハンティングと、Key Vault大量読み取りの監視

サインインログの「サービスプリンシパル」タブおよび監査ログ（30日間保存）で、以下の拡張KQLクエリを使って第1波と第2波の両方を調査してください。

// 1. サービスプリンシパルサインインの拡張ハンティング（MS公式3件＋名称一致＋異常User-Agent＋攻撃IP）
AADServicePrincipalSignInLogs
| where TimeGenerated >= datetime(2026-10-10)
| where AppId in (
    "506e08f9-6e9a-4da4-942b-a099a03644ae",
    "24205314-2b89-4e07-a2a4-579e898a5640",
    "0de14c77-b9b0-4137-9360-34878a929827"
  )
  or ServicePrincipalName has_any ("ConnectWise", "SkyKick")
  or IPAddress in ("144.172.64.128", "144.172.64.99", "144.172.64.60")
  or UserAgent has_any ("Python-urllib/3.12", "python-requests/2.31.0", "python-requests/2.34.2", "curl/7.88.1", "azure-toolkit/1.0")
| project TimeGenerated, ServicePrincipalName, AppId, IPAddress, UserAgent, ResultType, ResultDescription
| order by TimeGenerated asc

// 2. 第1波（01:58〜03:49 UTC）の特権ロール付与・翌16日の証拠隠滅・別アプリへの2028年合鍵追加の監査ログ検索
AuditLogs
| where TimeGenerated >= datetime(2026-10-13)
| where OperationName in (
    "Add member to role",
    "Remove member from role",
    "Update application",
    "Add service principal",
    "Add service principal credentials",
    "Update application – Certificates and secrets management"
  )
| project TimeGenerated, OperationName, InitiatedBy, TargetResources, IPAddress, Result
| order by TimeGenerated asc

// 3. Azure Key Vault における短時間での大量 SecretGet（15分間で3 Vault / 20回超）の検知
AzureDiagnostics
| where ResourceProvider == "MICROSOFT.KEYVAULT"
| where OperationName == "SecretGet"
| summarize SecretReadCount = count(), DistinctVaults = dcount(Resource) by CallerIPAddress, identity_claim_appid_g, bin(TimeGenerated, 15m)
| where SecretReadCount >= 10 or DistinctVaults >= 2

アクション3：機械用の名札（ワークロードアイデンティティ）に対するIP制限と、過剰な常設権限の廃止

人間の社員にMFAをかけるだけでなく、外部ベンダーの連携アプリに対しても「ワークロードアイデンティティ向けの条件付きアクセス（Workload Identities Conditional Access）」を適用し、ベンダーが公表している正規の送信元IPアドレス以外からのトークン要求を入り口で拒否してください。また、すでに解約したり移行が終わったりした古いバックアップソフトの同意（Consent）を放置せず、四半期ごとに棚卸しして無効化する仕組みを作ることが最大の防御になります。

あなたの会社のクラウド環境では、「人間ではなく外部の連携アプリが持っている特権や合鍵の有効期限」を、誰がどのくらいの頻度で点検していますか。ぜひYouTubeのコメント欄やnoteのコメントで現場の実態や悩みを教えてください。

参照した一次資料・検証レポート一覧（確認日：2026年10月26日）

#サイバーセキュリティ #情報セキュリティ #情シス #EntraID #AIエージェント #脆弱性対策 #生成AI