【三井不動産の情報漏えい5.5万件】漏えい項目からMicrosoft Graphと攻撃経路を考える

Posted at 2026-09-03

注記: 本記事における企業名・サービス名の記述は、公開情報および報道に基づく技術的考察であり、事実の断定ではありません。侵害経路・原因・責任所在について、記事執筆時点で関係各社から詳細は公表されていません。事実については関係各社の公式発表をご確認ください。

被害の概要

2026年9月1日、三井不動産から情報漏えいに関する発表があった。

【お知らせ】不正アクセスによる情報漏えいの可能性について（PDF:419KB）

発表によると、一部システムの資格情報が不正に利用され、不正アクセスが発生。社内外の個人情報が最大5.5万件漏えいした可能性があるとのこと。

漏えいした可能性がある個人情報は以下の通り。

対象	内容	件数
当社および当社グループ会社の役職員等	氏名、メールアドレス、部署、役職	最大19,000件
社外関係者	メールアドレス、メールの表示名	最大36,000件

現時点では、業務情報（メール、チャット、ファイル等）やパスワードの漏えいは確認されていないという。

この記事では、この「何が漏れたか」から、どのようなシステム・データフローが関係していた可能性があるのかを考えてみる。

最初に結論を書いておくと、公開情報だけで侵害経路を特定することはできない。ただし、漏えいしたフィールドからバックエンドのデータフローを逆算していくと、Microsoft Graphとの興味深い一致が見えてくる。

漏えいしたデータが少し不思議

まず気になったのが、漏えいしたデータの組み合わせである。

社内の情報だけなら、人事管理システムや社員名簿などを最初に疑う。

氏名
メールアドレス
部署
役職

これはごく普通の社員Directoryである。ところが、今回は社外関係者3.6万人も含まれている。しかも、

メールアドレス
メールの表示名

だけ。

取引先管理やCRMのデータにしては属性が極端に少ない。普通なら会社名、部署、役職、電話番号など、もう少し情報を持っていてもよさそうだ。逆に「メールアドレス＋メール表示名」だけ大量に存在するシステムとは何だろう？

例えば、

メールなどから社内外の人物の「接点」を抽出し、関係グラフを作るシステム

であれば、このようなデータが存在しても不思議ではない。そこで三井不動産が実際にどのようなシステムを使っているのかを調べてみた。

Sansanと「人脈の可視化」

三井不動産では2014年12月にSansanを導入している。2015年8月には全社導入し、将来的にはグループ全社へ展開したいとSansanの導入事例で紹介されている。

導入事例には、次のような記述がある。

他部署の社員からこういう人を紹介してほしいという相談が増えました。私は仕事柄、社外の方と会う機会が多いのですが、その中にはこれまで三井不動産の社員が会ってきた方々とは全く異なる業界に身を置く方が非常に多くいらっしゃいます。
そういった新しいつながりが会社の中でしっかりと可視化されたことで、紹介してほしいという案件が増え、会社全体の人脈の広がりにも貢献しています。

つまり三井不動産では、少なくとも2014〜2015年の時点で「社内の誰が社外の誰とつながっているか」という人脈の可視化を積極的に利用していたことが分かる。

当時のSansanでは、基本的に「名刺交換」が関係グラフのEdgeになる。

社員A ── 名刺交換 ── 社外人物X
社員B ── 名刺交換 ── 社外人物Y
社員C ── 名刺交換 ── 社外人物X

全社員の名刺を集約すれば、

社外人物X
   │
   ├── 社員A
   └── 社員C

という関係を可視化できる。ここまでは2014年当時から存在したSansanの基本的な価値である。

2023年の「スマート接点管理」

その後、Sansanは2023年6月に「スマート接点管理」を発表している。

Sansan、メールでの接点を自動で蓄積・可視化する「スマート接点管理」機能を提供開始

何が新しいかというと、関係グラフのEdgeを名刺だけではなく、メールから自動生成できるようになった点である。

「スマート接点管理」機能は、Google Workspace Gmail™ やMicrosoft 365 Exchangeなどユーザが使用しているメールサーバーとSansanを連携することで、自動でメールでの接点を取り込むことができます。それにより、Sansan上で閲覧できる取引先の会社詳細や組織ツリーに日々のメールでのやりとりの量が接点数として表示されるようになります。

つまり、

従来

社員A ── 名刺交換 ── 社外人物X

だったものが、

社員A
  │
  ├── 名刺交換 ─────── 社外人物X
  ├── メール × 37 ──── 社外人物Y
  └── メール × 5 ───── 社外人物Z

となる。

ここで重要なのは、今回の事件にSansanが関係していると言いたいわけではないということだ。三井不動産がスマート接点管理を利用していることを示す公開情報も、私が調べた範囲では確認できなかった。

Sansanの例から分かるのは、

「メールから社外人物との接点を抽出し、関係グラフを構築する」というシステムが実際に存在する

ということだ。

そして、ここからMicrosoft側を調べると興味深い一致が出てくる。

Microsoft Graphとの一致

三井不動産がMicrosoft 365（M365）やAzureを広く利用していることは、複数の公開情報から確認できる。

素晴らしいチャレンジである。

さらに、社員名簿システム「FACE WALL」などの公開事例から、Azure AD（現在のMicrosoft EntraID）やMicrosoft Graph APIを利用したシステム構成が実際に存在することも確認できる。

Microsoft 365のExchange Onlineからメール情報をAPI経由で取得する代表的な方法の一つが、Microsoft Graphである。

例えばMessage resourceには、

from
sender
toRecipients
ccRecipients
bccRecipients
replyTo

などの情報が含まれる。

その中で使われるemailAddress resourceは、非常にシンプルである。

{
  "address": "string",
  "name": "string"
}

addressはメールアドレス、nameは表示名である。

今回公表された社外関係者の漏えい情報と並べてみる。

三井不動産が公表した情報	Microsoft Graph `emailAddress`
メールアドレス	`address`
メールの表示名	`name`

ほぼそのままである。

もちろん、これだけで「Microsoft Graphから漏れた」と断定することはできない。メールを扱うシステムなら似たデータモデルを持つことは十分にあり得る。ただし、Microsoft Graph由来のデータだったとしても全く不思議ではない構造である。

社内1.9万人の情報もGraphと対応する

一方、Microsoft Graphのuser resourceには、

displayName
mail
department
jobTitle

などの属性がある。今回公表された社内情報と並べると、

三井不動産が公表した情報	Microsoft Graph `user`
氏名	`displayName`
メールアドレス	`mail`
部署	`department`
役職	`jobTitle`

こちらもかなり綺麗に対応する。

例えばGraphなら、

GET /v1.0/users?$select=displayName,mail,department,jobTitle

のような形で必要な属性を取得できる。ただし、携帯電話番号などを攻撃者があえて外す理由はないので、たぶん、そういう情報は単純に入っていなかったと思われる。

整理すると、

Microsoft Entra ID
       │
       │ user
       │ displayName / mail
       │ department / jobTitle
       │
       ▼
 Microsoft Graph
       ▲
       │
       │ message
       │ emailAddress
       │ name / address
       │
Exchange Online

というデータモデルが、

社内 19,000件
 ├── 氏名
 ├── メール
 ├── 部署
 └── 役職

社外 36,000件
 ├── メール表示名
 └── メール

という今回の漏えい項目とかなりよく一致する。

ここまでをまとめると、

Microsoft Graph経由で取得・加工されたデータを保持する何らかのシステムが関係していた

というのは、考えられる仮説の一つだと思う。ただし、ここから先はさらに推測の度合いが上がる。

では、どうやってGraphへアクセスするのか

仮にMicrosoft Graphが関係していたとしても、それだけでは侵入経路は分からない。

例えば、

通常のCredential Phishing
AiTM（Adversary-in-the-Middle）によるSession/Token窃取
OAuth Consent Phishing
Access Token / Refresh Tokenの窃取
Graph連携アプリのClient Secret窃取
Service Principalの侵害
連携SaaS側のCredential侵害

など、いくつもの経路が考えられる。

三井不動産の発表も、

一部システムの資格情報が不正に利用された

としているだけで、資格情報が何だったのかは公表していない。そのため、ここから侵入経路を特定することはできない。ただ、2026年に入ってからMicrosoft 365界隈で大規模に観測されている攻撃の一つに、Device Code Phishingがある。

Mimecastによれば、2026年3月以降、5万件以上の悪意あるDevice Code Phishingキャンペーンが観測されているという。

もし今回の侵害がユーザ起点のOAuth Token窃取だったと仮定すれば、Device Code Phishingは技術的に成立する侵入経路の一つである。

ここからは今回の事件そのものではなく、「仮にDevice Code Phishingだったら」という話として、この攻撃を見てみる。

Device Code Phishingとは

Device Code Flow

Device Code Flowとは、キーボードやブラウザを持たないデバイスなどを認証するためのOAuthの仕組みである。

例えば、テレビ上のアプリからMicrosoftアカウントへログインするケースを考える。

テレビ上のアプリがMicrosoftのDevice Authorization Endpointへ要求する
Microsoftからdevice_codeとuser_codeが返される
テレビは「PC/スマホでこのURLにアクセスし、ABCD-EFGHのようなコードを入力してください」と表示する
ユーザはPC/スマホから正規Microsoftサイトへアクセスし、ログインしてuser_codeを入力する
テレビ上のアプリは、保持しているdevice_codeを使ってToken EndpointをPollingする
ユーザの認証・承認が完了すると、テレビ側へAccess Tokenが発行される

概念的には、

テレビ
 │
 │ Device Authorization
 ▼
Microsoft
 │
 ├── device_code ─────→ テレビが保持
 │
 └── user_code ───────→ 人間に表示
                           │
                           ▼
                       PC / スマホ
                           │
                     正規Microsoftで
                      認証・承認
                           │
                           ▼
                       Microsoft
                           │
                           │ Access Token
                           ▼
                         テレビ

という仕組みである。

Device Code Phishing

この仕組みで重要なのが、

認証するデバイス（PC/スマホ）とAccess Tokenを受け取るクライアント（テレビ）が別物

という点である。Device Code Phishingでは、攻撃者がこの「テレビ役」になる。

攻撃者
 │
 │ Device Authorization
 ▼
Microsoft
 │
 ├── device_code ─────→ 攻撃者が保持
 │
 └── user_code
        │
        ▼
   フィッシングメール
   Teamsメッセージ等
        │
        ▼
      被害者
        │
        ▼
正規Microsoftサイト
        │
  正規アカウントで
   MFA / Passkey
        │
        ▼
    Microsoft
        │
        │ Access Token
        ▼
      攻撃者

例えば攻撃者は、

「Teams会議へのアクセスを承認するため、このコードを入力してください」

などと被害者を誘導する。いわゆるソーシャルエンジニアリングである。重要なのは、攻撃者が偽Microsoftサイトを用意する必要がないことだ。被害者がアクセスするのは、本物のMicrosoftの認証画面で構わない。

そのため、

「リンク先のURLが正しいか確認しましょう」

という従来型のフィッシング教育だけでは防げない。

MFAやPasskeyでも防げない理由

MFAもPasskeyも非常に重要なセキュリティ対策である。特にPasskeyは、Credentialを正規ドメインにBindingすることで、偽ドメインへのCredential Phishingに対して非常に強い。

しかしDevice Code Phishingでは、そもそも被害者がアクセスしているのが正規Microsoftサイトである。Passkeyから見れば、正常なAuthenticationである。

攻撃者はuser_codeに対応するdevice_codeを保持し、「このDevice Authorizationは完了したか？」とMicrosoftのToken Endpointへ定期的に問い合わせている。

被害者が正規Microsoftサイトで認証・承認を完了すると、そのAuthorizationは攻撃者が開始したDevice Code Flowと結び付く。

つまり、

「Authenticationを破る」のではなく、「正規のAuthenticationを利用してAuthorizationを奪う」。

という攻撃である。

Microsoftから見れば、正規ユーザによって認証・承認されたOAuth Access Tokenなので、そのTokenに与えられた権限の範囲では正規アクセスとして扱われる。なので、

「MFAを入れているからCredential Phishingは大丈夫」

は通用しない。

ただし、これはMFAやPasskeyが無意味という意味ではない。Device Code Phishingが、それらとは異なるレイヤーを狙っているという話である。

Device Code Phishingへの対策

手口を見ると、Device Code Phishingをユーザ教育だけで防ぐのは難しい。教育するなら、

「URLが正しいか確認する」ではなく、「自分が開始していない認証・承認を完了しない」

くらいだろうか？しかし、本命はEntra側での制御だろう。

Device Code Flowを原則Block

Microsoft Entra Conditional Accessでは、Authentication FlowとしてDevice Code Flowを指定してBlockできる。Microsoft自身も、Device Code Flowは顧客による利用頻度が低い一方で攻撃に利用されることがあるとして、可能な限りBlockすることを推奨している。ただし、いきなりBlockすると、

Teams Rooms
Teams Android Devices
Shared Teams Devices
Azure CLI
Developer CLI Tools
一部のLegacy CLI

などに影響する可能性がある。そのため実務上は、

Sign-in Logsで利用状況を確認
        ↓
Conditional AccessをReport-only
        ↓
     影響を確認
        ↓
必要な用途だけ例外化
        ↓
Device Code FlowをBlock

という順番が安全だろう。

OAuth / アプリ権限を最小化する

Device Code FlowをBlockすれば全て解決するわけではない。Device Code Phishingで攻撃者が取得するのはOAuthのAccess Tokenであり、Microsoft Graphだけが攻撃対象になるわけではない。攻撃者が何にアクセスできるかは、そのTokenに与えられたScopeや権限によって決まる。

そのため、

OAuth Clientが要求するScope
ユーザがアプリにConsentできる権限
Delegated Permissions
Application Permissions
登録されているOAuthアプリやService Principal

などを棚卸しし、必要最小限にする。

Microsoft EntraIDを利用している場合であれば、Enterprise ApplicationsやApp registrationsを確認する。Microsoft Graphについても、Mail.*、Directory.*、Files.*、Contacts.*など、広範囲なデータへアクセスできる権限を持つアプリは特に確認した方がよい。

重要なのはGraphそのものではなく、

「誰が、どのOAuth Clientを通じて、どのResourceに、どのScopeでアクセスできるのか」

を把握し、Tokenを奪われた場合の被害が及ぶ範囲を小さくしておくことである。

Tokenの不正利用を監視する

Device Code Phishingを完全に防げなかった場合も考える必要がある。Microsoft EntraIDであればSign-in LogsなどからDevice Code Flowの利用状況を確認し、通常とは異なるIPアドレスや地域、アプリケーション、認証フローなどを監視する。

Device Code Phishingに限らず、OAuth Tokenが奪われた後のアクセスを検知するという意味でも重要である。

Microsoftだけの問題ではない

Device Code FlowはMicrosoft独自の仕組みではない。OAuth 2.0 Device Authorization GrantはRFC 8628で標準化されており、例えば、

Google
GitHub
Okta
AWS系（Amazon Cognito）

などでもDevice Authorization Flowが利用できる。

GoogleはDevice Code Flowで利用可能なScopeを限定している。

GitHubはDevice Flowがフィッシングに悪用される可能性を明記し、必要がなければ有効にしないことを推奨している。

現在、大規模に観測されているDevice Code PhishingはMicrosoft 365を狙ったものに偏っているが、問題の本質はMicrosoft固有ではない。

一般化すると、

会社で使っているIdP/SaaSについてDevice Authorization Grantが有効になっていないかを確認し、不要なら無効化する。

全部。いますぐ。

まとめ

今回の三井不動産の発表から分かっているのは、

「一部システムの資格情報が不正に利用され、社内外最大5.5万件の個人情報が漏えいした可能性がある」

というところまでである。侵害されたシステムも、Credentialの種類も、具体的な侵入経路も公表されていない。

一方、漏えいした情報をデータ構造として見ると、

社内
氏名 / メール / 部署 / 役職

        ↓

Microsoft Graph user
displayName / mail / department / jobTitle


社外
メール表示名 / メール

        ↓

Microsoft Graph emailAddress
name / address

というかなり興味深い一致がある。

さらに三井不動産では、Microsoft 365やAzureの利用に加え、社員名簿システム「FACE WALL」の公開されたシステム構成図から、Azure AD（現Microsoft EntraID）およびMicrosoft Graph APIを利用するシステムが実際に存在することも確認できる。

したがって、

Microsoft Graph経由で取得・加工されたデータを保持する何らかのシステムが関係していた

という仮説は成立する。

ただし、

Graphが関係していたことと、Device Code Phishingで侵入されたことは別の話である。

後者を裏付ける情報は現時点ではない。Credential Phishing、AiTM、Token窃取、OAuth Consent Phishing、Client Secret窃取、Service Principal侵害など、同じ結果を生む攻撃経路はいくつも存在する。

Device Code Phishingは、その中でも2026年に急増しており、MFAやPasskeyを導入していても成立し得る興味深い攻撃手法なので、今回の仮説から派生して取り上げた。

答え合わせはたぶんできない。ただ、こうやって「何が漏れたか」からデータフローを逆算し、そこから考えられる侵入経路をThreat Modelingしておくことは、守る側として意味があると思う。

セキュリティ担当として、ここ数週間、ちょっとモードが変わったかな？と感じている。攻撃が多岐にわたり、痛いところを突いてくるようになった感覚がある。

私は守るべきアセットを軸に、侵入・伝播経路を考慮して、日々モニタリングをしているが、最近は、これまで想定していなかった侵入経路が発見されたり、ぶっちゃけてんやわんやである。

ベトナムは5連休だったのだけど、セキュリティ対策に費やしてしまった。

攻撃面としてサービスそのものを攻めるより、ユーザを攻める方が安い。特に今回取り上げたようなOAuth/SaaS Hijackは、とてつもなく厄介である。CVEだけ見ていてもダメだし、対策も面倒。予算は付かず、上からのあたりは強く、周りには理解されづらい。

そしてセキュリティ予算が付かなければ、技術的なチャレンジも停滞してしまう。

何卒、予算を！何卒〜！！笑

（おわり）

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up