ハッカーがConnectWise Cloud Backupの認証情報を悪用、AI駆動のMicrosoft 365攻撃を展開

ハッカーは、侵害したConnectWise Cloud Backupのアプリケーション認証情報を悪用してMicrosoft 365環境にアクセスし、権限を昇格させたうえで、永続化用の認証情報を仕込みました。

Ethicalhacking tools

Microsoftは、このキャンペーンを中国政府と連携する脅威アクター「Storm-0940」の仕業だと断定しています。同グループはオープンソースのエージェント型AIフレームワーク「ARTEX」を使い、2,250を超えるテナントへの後続攻撃を加速させたとされています。

ただし、認証に成功したからといって、データが盗まれたとは限りません。

Huntressは2026年10月16日に、この認証情報の悪用を最初に公表しました。その後の調査はMicrosoftの見解を裏付けていますが、ARTEXの関与までは独自に確認できていません。

研究者は、テレメトリのみに基づく場合、LLMの関与について確度は「低〜中」と評価しています。Microsoftの帰属分析も考慮すると、確度は「中〜高」に上がります。

認証マテリアルを手にした攻撃者は、対話的なユーザーサインインやMFAのプロンプトを経ることなく、顧客テナント内で既に付与されている権限を使ってMicrosoft Graphのトークンを要求できました。

10月15日、Huntressは144.172.64[.]128からのアクティビティを約1,000のテナントで観測しました。このうち300以上でサインインに成功しています。

この数字はHuntressが監視している範囲に限った数であり、Microsoftが示したより広範な標的数と矛盾するものではありません。

Huntressによると、旧SkyKickのConnectWise Cloud Backupは、顧客のメールボックス、ファイル、Teamsのコンテンツ、ディレクトリ情報を保護するためにアプリケーション権限を使用しています。

ConnectWise Cloud Backup

調査した2つのテナントでは、侵害後の活動として、特権ロールの変更と認証情報の仕込みが確認されました。

Microsoft Teams向けのConnectWise Cloud Managementアプリケーションは、自らにグローバル管理者ロールを割り当てました。さらに、テナント固有のHuntressアプリケーションを含む他のアプリケーションにシークレットを追加しています。

これらの認証情報があれば、元のベンダーアプリケーションを封じ込めた後もアクセスを維持できてしまいます。

Huntressは10月15日の活動から、3つの運用パターンを特定しました。スクリプトによる列挙、オペレーターによる調整、そして標的が消えた後も動き続けたバックグラウンドツールです。

ある列挙シーケンスでは、Python-urllib/3.12を使い、テナントを識別子の昇順に処理していました。

別のバーストでは、10秒間に約100件のトークン要求の失敗が発生しています。これは、モデルが要求ごとに判断していたというより、並列のワーカースレッドによる動きと一致します。

適応的なオーケストレーションを強く示唆するのは、認証情報の操作時の挙動です。証明書のアップロードがサムプリントの不一致で失敗した後、55秒後に別の実行が行われました。その際には、以前の実行にはなかったリトライ処理が加わっていました。以降の待機時間は、3.5秒から7.1秒へとほぼ倍増しています。

研究者は「まず試験的に実行し、その後バッチ処理する」という挙動が繰り返されていることも確認しました。1つのテナントで動作を試してから、対象を拡大していたのです。

こうしたパターンは、オペレーターが実行の合間にツールを修正したと考えれば説明がつきます。ただし、人間なのか、チャットボットの支援を受けたオペレーターなのか、自律型エージェントなのかは、決定的には判別できません。

MicrosoftはARTEXを、発見した資産や弱点をマッピングし、並列の攻撃経路を追求するマルチエージェント型フレームワークだと説明しています。Storm-0940の複数の作戦では、3時間以内に特権的なクラウドアクセスに到達しました。

一方で、完全自律型とする解釈に疑問を投げかける証拠もあります。Teamsのサービスプリンシパルが削除された後も、リクエストは調整されないまま、4〜8秒おきに22分間続きました。

Huntressは、調査対象の被害組織からMicrosoft Graphのアクティビティログを入手できませんでした。そのため、リクエストの内容や、データへのアクセスがあった可能性を把握できていません。アプリケーション専用のディレクトリ監査イベントにも、送信元IPアドレスが記録されていませんでした。

したがって、監査証跡が不完全であることも、トークンの発行に成功したことも、情報が外部に持ち出されたかどうかを裏付けるものではありません。

管理者は、証拠を削除せずに、影響を受けたアプリケーションの接続を無効化してください。あわせて、サービスプリンシパルのサインインを調査し、不正な認証情報とロール割り当てを削除する必要があります。

ベンダーの認証情報をローテーションするだけでは、別途仕込まれたバックドアは排除できません。

アプリケーションが自らを特権ロールに割り当てる動き、予期しない認証情報の追加、通常のベンダーの挙動からの逸脱については、優先してアラートを設定してください。

サポートされている環境では、Microsoft Graphのアクティビティログを有効にし、テナントをまたいで相関分析を行うことも重要です。なお、リクエストの間隔だけでは、AIの関与を確実に見分けられません。

侵害指標（IoC）

注: IPアドレスとドメインは、誤って名前解決されたりハイパーリンク化されたりするのを防ぐため、意図的に無害化（例: [.]）しています。無害化の解除は、MISP、VirusTotal、SIEMなど、管理された脅威インテリジェンスプラットフォーム内に限って行ってください。

MTTRを21分短縮し、被害が出る前にサイバー脅威を阻止。ANYRUNのサンドボックスをSOCに導入。

AuditSecurity