Microsoft Power Pages のミスコンフィグが原因：13 組織における約 2,700万件のレコードが露出？

Misconfigured Microsoft Power Pages Likely Exposed 27 Million Records to ExfilSquad

2026/08/17 gbhackers — Microsoft Power Pages のミスコンフィグとみられる問題により、13 組織において約 2,700 万件のレコードが露出した可能性がある。この問題が明らかになったのは、被害組織から取得したとされる 382.64 GB のデータが、データ恐喝グループ ExfilSquad により Torrent で公開された後のことである。公開データを分析した研究者たちは、外部から読み取り可能な Microsoft Dataverse テーブルが存在していた証拠を確認している。こうした状況は、ゼロデイ・エクスプロイトやランサムウェアの展開、従来型のネットワーク侵入によるものではないとみられている。

Fortra の Intelligence and Research Experts (FIRE) の調査担当者が今回確認したのは、公開されたデータセットの構造が、Dataverse をバックエンドとする Microsoft Dynamics 365 CRM／ERP 環境からのエクスポートに類似していることである。Microsoft Power Pages を使用する組織は、Dataverse に接続する外部公開 Web ポータルを構築でき、このサービスは、市民向けサービス／カスタマー・サポート／登録・申請フォームなどの正当な公開ワークフローをサポートするよう設計されているが、ポータルから Dataverse へのアクセスはテーブル権限と Web ロールの割り当てによって制御される。

この仕組みを踏まえると、最も有力な仮説は、影響を受けたポータルで Anonymous Users Web ロールが、公開読み取りアクセスを許可する Dataverse テーブル権限に割り当てられていたというものである。このような権限が機密性の高いテーブルに適用されていた場合、未認証の訪問者でもポータルの公開 API レイヤーを介してレコードを取得できるため、正規の公開機能が大量のデータ露出につながる可能性がある。

研究者によると、ExfilSquad によるデータへのアクセスについて、マルウェア／ラテラル・ムーブメント／クレデンシャル窃取／ソフトウェア脆弱性悪用などを用いた証拠は確認されておらず、従来型の侵入活動ではなく、公開状態にあったデータへのアクセスだった可能性が示されている。

運用上、この違いは重要であり、脆弱性を抱えるアプリケーションにはパッチ適用が必要である一方、ミスコンフィグされたポータルでは、アクセス制御の即時修正／データ露出状況の評価／認証情報またはアイデンティティに関するリスクへの対応が必要となる。このキャンペーンが示しているのは、クラウド・セキュリティで繰り返される現実であり、正規の SaaS 機能が過度に広範な匿名権限を持つよう設定されていると、インターネットからアクセス可能なデータ流出チャネルへ変わる可能性がある。

公開ポータルが設計上バックエンド・テーブルを公開している場合、エンドポイント環境がクリーンだからといって、データも保護されていると考えるべきではない。Fortra の評価では、382.64 GB のアーカイブは、13 組織と約 2,700 万件のレコードに関連付けられており、報告された被害者には政府機関や教育機関が含まれている。

公に言及されているデータセットに含まれるのは、City of Atlanta／UK Department for Education／District of Columbia Public Schools などの組織である。

Microsoft Power Pages のミスコンフィグ

潜在的な影響は、一般的な連絡先データだけにとどまらず、報告されたサンプルには個人識別情報／CRM レコード／サービスとサポートのデータなどが含まれており、教育関連のデータセットには生徒の氏名／生年月日／一意の生徒識別子も含まれていた。このような情報は、スピア・フィッシング／アイデンティティ詐欺／アカウント復旧攻撃／なりすまし／従業員／学生／市民／顧客／パートナーを狙った後続攻撃に悪用される可能性がある。

2026年7月下旬に出現したとされる ExfilSquad は、8月7日の時点で被害者のデータを公開し、これにより恐喝目的の主張が、広範な二次的プライバシー・リスクや詐欺リスクへと発展した。同グループの活動が示しているのは、クラウド上で露出したデータが大規模に収集される可能性である。ポータルが公開され、その API からレコードが返される状態になると、脅威アクターは内部ネットワークへ侵入することなく収集を自動化できる。

Power Pages を運用するセキュリティ・チームに求められるのは、匿名アクセスを許可している全ポータルに対する緊急の確認と、ビジネス・プロセスに必要な範囲を超えるテーブルの読み取り権限が付与されていないことの確認である。特に注意すべき対象は、連絡先／アカウント／リード／インシデント／注釈／商談／ケース・レコードや、個人情報／金融情報／従業員情報／運用データを含むカスタム・エンティティを格納するテーブルである。

管理者に求められるのは、公開データへのアクセスを明示的に必要としない全テーブル権限から Anonymous Users ロールを削除することである。匿名アクセスが必要な場合には、その権限を狭い範囲に限定し、API が有効なテーブルでは、ワイルドカード指定によるフィールド選択ではなく、明示的に必要なフィールドだけを公開する必要がある。

意図しない広範な情報露出を減らすために、Microsoft は特定のシステム・テーブルに対する匿名 Web API におけるワイルドカード設定も制限している。実践的な検証手順として防御側に推奨されるのは、自組織の外部から到達可能なポータルに未認証セッションでアクセスし、API ルートがレコード本体を返さないことを確認することである。

Dataverse データを含むレスポンスが正常に返された場合には、データが露出している可能性があると判断し、過去のアクセス状況の調査と速やかな修復を実施する必要がある。

このインシデントが改めて示しているのは、アイデンティティと認可の設定も組織の攻撃対象領域の一部であるという点である。Power Pages のデプロイメント環境で過度に寛容な Web ロールを 1 つ割り当てるだけでも、インターネット上の誰もが利用できる大量のデータをエクスポートできるインターフェイスへと、顧客向けポータルが変容する可能性がある。

外部公開向けポータルを構築する Microsoft Power Pages において、アクセスの制御に関するミスコンフィグが大きな問題となっています。本来は限定的な公開に留めるべきバックエンドの Dataverse システムにおける未認証での閲覧を許す権限構成となっているため、認証を経ない訪問者が API を経由して内部データを参照可能な状態に陥りました。これにより個人識別情報や取引情報などの重要データが外部へ流出し、スピア・フィッシング／アイデンティティ詐欺／なりすまし／二次的プライバシー侵害などの悪質な二次被害へ繋がる危険性が生じています。対応策としては Anonymous Users ロールにおける不要なテーブル権限の削除／アクセス可能フィールドの制限／未認証セッションを用いたレスポンス確認による露出状況の監査などが強く求められます。