Microsoft 365のアプリ認証情報から不正アクセス？AI攻撃でSharePoint・OneDriveも標的に｜Entra IDの確認方法

Microsoft 365やAzureを管理する企業は、一般ユーザーのパスワードだけでなく、アプリケーションの認証情報も確認してください。 Microsoft Threat Intelligenceは2026年11月5日、AIエージェント型の攻撃ツール「ARTEX」によって、公開GitHubで見つけた認証情報が悪用され、AzureやMicrosoft 365のデータにアクセスされた事例を公表しました。

一部の事例では、GitHubでの探索開始からAzure Key Vaultのデータ持ち出しまで約5分。 これはMicrosoftが観測した個別事例であり、すべての攻撃が5分で成功したという意味ではありません。

対象になり得るのは、Entra IDに登録した自社アプリ、外部SaaSとの連携アプリ、サービスプリンシパルに強い権限を与えている組織などです。本件について日本国内の特定企業が侵害されたという発表は確認できていません。 本記事は2026年11月7日時点のMicrosoft公式情報に基づき、管理者が確認できる項目を整理します。

まず結論｜Microsoft 365管理者は何を確認する？

確認対象	今すること
Entra IDのサインインログ	「サービスプリンシパルのサインイン」を確認。10月28日以降の不審なアクセスを、保存期間内で調査
エンタープライズアプリケーション	見覚えのないアプリ、過剰なMicrosoft Graph権限、付与済み管理者同意を見直す
アプリの登録	不要なクライアントシークレット、追加された証明書、フェデレーション資格情報を確認
SharePoint・OneDrive・メール	不審なダウンロードやメール項目アクセスがないか、利用可能な監査ログで調べる
GitHubなどの公開コード	公開されたシークレットは削除だけで終わらせず、失効・再発行する

「Microsoft 365を利用しているだけで、全テナントが侵害された」という話ではありません。アプリ認証情報がどこかで露出していないか、露出していた場合に何へアクセスできるかが問題です。

何が起きた？ARTEXが公開GitHubの秘密情報を悪用

Microsoftは2026年8月以降、攻撃者がAIエージェント型の攻撃フレームワークを使い、GitHub上で大量の検索を実施する動きを観測していました。対象はログイン用パスワードだけでなく、アプリのクライアントシークレット、クラウドAPIキー、AIサービスのキーなどです。

10月28日には、漏えい・窃取した有効なアプリ認証情報を使ったMicrosoft Entra IDへのサインインが観測されています。複数テナントにまたがるサービスプリンシパルのサインイン後、クラウド資源の列挙、Azure Key Vault・Storageへのアクセス、SharePoint・OneDriveのファイルダウンロードやメール項目へのアクセスが確認されました。

項目	Microsoft公式で確認された内容
公表日	2026年11月5日
探索の観測開始	2026年8月以降
認証情報悪用の観測	2026年10月28日以降
使われた技術	AIエージェント型フレームワーク「ARTEX」
実際の影響	複数テナントでサービスプリンシパルのサインインと、クラウドデータへの不正なアクセス
国内の被害	この発表から国内企業の個別被害は確認できない

攻撃の流れを図解

攻撃者は最初から管理者アカウントのパスワードを知っている必要はありません。既に権限を付与されたアプリの認証情報を入手できれば、そのアプリに許可された範囲でAPIを実行できる点が重要です。Microsoftは、API呼び出しに失敗すると短時間でパラメーターを変更して再試行する動きも観測しました。

なぜ多要素認証（MFA）やパスワード変更だけでは防げない？

Microsoft 365では、人がサインインするユーザーアカウントとは別に、プログラムが自動処理のために使用するサービスプリンシパル（アプリケーションの実行主体）があります。代表例はバックアップアプリ、社内システム連携、ファイル自動処理です。

比較項目	通常のユーザーサインイン	サービスプリンシパル
認証の主体	社員などの利用者	アプリ・自動処理
代表的な認証方法	パスワード、パスキー、MFAなど	クライアントシークレット、証明書、フェデレーション資格情報など
権限の仕組み	ユーザー権限や委任された権限	アプリに付与されたAPI権限やAzure RBAC
今回の注意点	ユーザーのパスワード変更だけでは対処できない場合がある	有効なアプリ認証情報が漏れると、ユーザー操作なしで利用される可能性

アプリケーション権限を付与されたサービスプリンシパルへのアクセスには、通常の利用者向けMFAをそのまま適用できません。利用者のMFAは重要な対策ですが、アプリの認証情報の保護・権限縮小・サインイン監査も必要です。

確認方法① Entra IDでサービスプリンシパルのサインインを調べる

1. Microsoft Entra管理センターを開き、調査に必要な閲覧権限のあるアカウントでサインインします。
2. 「Entra ID」→「監視と正常性（Monitoring & health）」→「サインインログ（Sign-in logs）」を開きます。
3. ログの種別から「サービスプリンシパルのサインイン（Service principal sign-ins）」を選びます。ユーザーの対話型サインインとは別のログです。
4. 10月28日以降の保存されている期間について、送信元IP、アプリID、成功・失敗、アクセス先リソース、時刻を調べます。
5. 不審な記録があれば、同じアプリIDの権限、証明書・シークレットの変更履歴、AzureとMicrosoft 365の操作履歴を照合します。

Microsoftが主に観測した送信元IPは199.19.77.84、199.19.77.18です。後者はTor出口ノードであり、無関係な通信が混じる可能性もMicrosoftが注意しています。IPの一致だけで侵害を断定せず、複数アプリへの短時間のアクセスや、その直後のファイル取得を合わせて確認します。

サインイン失敗コードAADSTS7000215（無効なシークレット）やAADSTS7000222（期限切れシークレット）も調査の手掛かりです。失敗が続いた後に成功へ変わった場合は特に注意が必要です。これらのエラー単体で侵害確定とは判断できません。

Business Basicなどではログの保存期間に注意

Microsoft Entra ID Freeの標準的なサインイン・監査ログ保存期間は7日間、Entra ID P1/P2は30日間です。2026年11月7日時点では、Free環境で10月28日の記録がすでに表示されない可能性があります。過去に外部保存していなければ復元できるとは限りません。なお、サインインログの閲覧自体にP1は必須ではありません。

参考：Microsoft Learn：サインインログ／ログ保存期間。

確認方法② エンタープライズアプリケーションの権限を見直す

1. Entra管理センターの「Entra ID」→「エンタープライズアプリケーション」→「すべてのアプリケーション」を開きます。
2. 見覚えのない名前だけでなく、利用開始日、アプリの所有元、アプリケーションID、実際の業務用途を確認します。
3. 個々のアプリの「アクセス許可（Permissions）」で「管理者の同意（Admin consent）」と「ユーザーの同意（User consent）」を確認します。
4. SharePoint・OneDrive・メールへ広範囲にアクセスできる権限が本当に必要か、管理者とシステム提供元で判断します。

例としてMicrosoft GraphのFiles.Read.All、Sites.Read.All、Mail.Readなどは、付与方式や同意の範囲によってアクセス可能なデータが変わります。権限名だけで危険なアプリと決めつけず、委任されたアクセス許可とアプリケーションのアクセス許可を区別して評価してください。正規のバックアップや連携アプリを一律削除すると、業務停止につながります。

公式手順：エンタープライズアプリのアクセス許可を確認・取り消す。

確認方法③ アプリの登録でシークレットと証明書を確認する

1. Entra管理センターで「Entra ID」→「アプリの登録（App registrations）」→「すべてのアプリケーション」を開きます。
2. 対象アプリの「証明書とシークレット（Certificates & secrets）」で、クライアントシークレット、証明書、フェデレーション資格情報を確認します。
3. 作成者と用途が不明な資格情報、想定外に追加された資格情報、有効期限が不自然に長いものを洗い出します。
4. 「APIのアクセス許可（API permissions）」も確認し、業務に不要なアクセス許可を削減する計画を立てます。

この画面で確認できるのは主に自社テナントのアプリ登録です。他社が所有するマルチテナントアプリの秘密鍵そのものは、自社のアプリ登録画面に現れない場合があります。 外部SaaSはエンタープライズアプリとベンダーからのセキュリティ通知も確認してください。

公開GitHubなどにアプリ認証情報が含まれていた場合は、投稿やファイルを削除するだけでは不十分です。履歴・複製から取り出せる可能性があるため、侵害された可能性のある認証情報を失効し、新しい資格情報に切り替えます。 業務アプリの停止を避けるため、必要に応じて新資格情報への切替と動作確認を先に行い、露出済みの旧資格情報は速やかに無効化してください。

公式手順：Microsoft Learn：アプリ認証情報の管理。

確認方法④ SharePoint・OneDrive・メールのアクセス履歴を調べる

サインインが成功していた場合、「どのファイルへアクセスしたか」まで調べることが重要です。利用中のライセンスと監査設定に応じてMicrosoft Purviewの監査検索、Azure Activity Log、Key Vault診断ログ、Storage診断ログを確認します。

• SharePoint・OneDrive：ファイルのアクセス・ダウンロード操作の有無、操作ユーザー・アプリ、アクセス元を確認
• Exchange Online：不審なメール項目アクセス、アクセス元、同じアプリによる操作がないかを確認
• Azure Key Vault：シークレットの一覧・読み取り、普段と異なるアプリによるアクセスがないかを確認
• Azure Storage：データ列挙やダウンロード、アクセスキー取得操作を確認

操作ログは製品・ライセンス・設定によって取得状況や保存期間が異なります。ログが見つからないことは、アクセスがなかったことの証明にはなりません。

不審な痕跡を見つけた場合の初動対応

1. 証跡を確保：関連するサインイン、アプリ監査、ファイル操作、Key Vault・Storageログを保存し、時刻とアプリIDを記録する。
2. 悪用経路を止める：影響アプリのシークレット、証明書、フェデレーション資格情報を失効・再発行し、必要ならサービスプリンシパルを無効化する。既発行トークンは有効期限まで利用可能な場合がある。
3. 二次被害を確認：影響アプリが参照できたKey Vault内のシークレット、文書内の資格情報、Azure DevOpsのPATなども交換対象に含める。
4. 権限を縮小：不要なAPI権限やAzure RBACロールを削除し、長期シークレットへの依存を減らす。
5. 社内外と連携：外部SaaS・MSPが関係する場合は提供元に確認。個人情報への影響があれば組織のインシデント対応手順に沿って判断する。

Microsoftは、対象のIPアドレス199.19.77.84/32を指定した条件付きアクセスによるブロックも推奨しています。ただし、ワークロードID向け条件付きアクセスにはWorkload ID Premiumのライセンスが必要で、対象も自テナント登録のシングルテナントアプリなどに制限があります。一般ユーザー向けEntra ID P1の条件付きアクセスと同じものではありません。IP遮断だけでは他の送信元を使う攻撃を防げないため、資格情報の交換と権限の見直しを優先してください。

予防策｜GitHubで公開した情報は削除だけでは不十分

• GitHubのSecret scanningや公開リポジトリ監視を利用し、組織が管理しない公開リポジトリへの流出も確認する。
• ソースコード、構成ファイル、CI/CD設定へ長期間有効なパスワードやシークレットを直接記載しない。
• 対応できるアプリはマネージドIDやワークロードIDフェデレーションなど、固定シークレットに依存しにくい方式へ移行する。
• アプリ登録権限や管理者同意の付与を必要最小限にし、利用していないエンタープライズアプリを定期的に棚卸しする。
• アプリ認証のサインインログを継続的に収集し、ライセンスによる保存期間を超える調査が必要なら事前に外部保管を検討する。

これまでのMicrosoft 365のIP制限やユーザー向けMFA対策も重要ですが、保護対象とできる通信は同じではありません。関連記事：Microsoft 365のIP制限はBusiness Basicだけでできる？Entra ID P1なしで実機検証。

11月6日の続報｜金融機関へのARTEX攻撃も公表

Microsoftは11月6日、別の調査として、金銭目的の攻撃グループStorm-3358がARTEXなどを利用して金融機関を標的にした活動を報告しました。主に東南アジアの金融組織などを対象とし、Webアプリの脆弱性悪用や遠隔操作ツールの設置が説明されています。

11月5日付のGitHub認証情報悪用事例と、11月6日付の金融機関への活動は、Microsoftが別々に説明した事象です。 同じ攻撃ツールに関係するものの、すべて同一の侵害事件・同一攻撃者と扱うことはできません。また国内組織への被害を示す情報ではありません。

よくある質問（FAQ）

Q. Microsoft 365を使っているだけで情報漏えいの対象ですか？

いいえ。今回の発表は特定のアプリ認証情報が悪用された攻撃の観測です。Microsoft 365利用者全員のデータが漏えいしたと公表されたわけではありません。自社テナントが影響を受けたかはログやアプリ認証情報の調査が必要です。

Q. 全社員のパスワード変更とMFAの有効化で解決しますか？

社員のアカウントが侵害されていれば必要な対策になり得ますが、今回の主要な問題はアプリ認証情報です。該当アプリのシークレット・証明書などを確認し、露出していた認証情報を失効させる必要があります。

Q. 管理センターにサービスプリンシパルのログが出てきません

サインインログの種別選択、調査期間、閲覧権限、ライセンスによる保存期間を確認してください。Entra ID Freeは標準7日間です。過去の記録は外部へ保存していない限り確認できないことがあります。

Q. IPアドレスが一致しなければ安心できますか？

いいえ。攻撃元は変わり得ます。特定IPの検索に加え、短時間に複数アプリでサインインが成功した記録、権限変更、ファイルダウンロードなどの行動を組み合わせて調べてください。

まとめ｜まずアプリ認証情報と権限を確認

今回の特徴は、攻撃者が人のパスワードではなく、アプリに与えられた信頼関係を入口にしたことです。AIエージェントで探索と後続の操作が高速化し、実際に数分で重要なクラウド資源へ到達した事例もありました。まずEntra IDのサービスプリンシパルのサインインログ、アプリの権限、公開コードに漏れたシークレットの有無を確認しましょう。

出典・更新履歴

• Microsoft Threat Intelligence・Microsoft Security Research（2026年11月5日）「Threat actors use agentic AI tooling to find and abuse exposed secrets」
• Microsoft Threat Intelligence（2026年11月6日）「ARTEX abuse expands as cybercriminals target financial sector」
• Microsoft Learn：Service principal sign-in logs
• Microsoft Learn：Review permissions granted to enterprise applications
• Microsoft Learn：Microsoft Entra data retention

情報確認：2026年11月7日（日本時間）。記事本文はMicrosoft公式発表と公式管理者ドキュメントを基に編集。管理画面の操作手順は実機での確認ではなく、公式手順を日本語化して整理したものです。