6日間の不正アクセス、判明はその6日後。 2026年10月2日（金）から7日（水）まで、第三者が日本のバーガーキング公式アプリの会員を管理するシステムにアクセスしていました。運営するビーケー・ジャパンは10月13日（火）、約1,118万件の会員情報が漏えいしたことを確認し、15日に公表しました。氏名、メールアドレス、電話番号、生年月日が含まれます。飲食チェーンのアプリから約1,100万件規模の会員情報が流出したのは、焼肉きんぐに続いて10日間で2件目です。
概要：この記事のために作成した図です。
以下では、ビーケー・ジャパンが公表した内容、日付から読めること、そして同社のインターネットに面したシステムを受動的な記録だけで採点したリスクカードを示します。攻撃者の役に立つ詳細は載せていません。
ビーケー・ジャパンが公表した内容
株式会社ビーケー・ジャパンは、日本でバーガーキングの店舗と公式アプリを運営しています。2026年10月15日にお知らせをPDFで公表しました。ビーケー・ジャパン：お知らせ（PDF）
- 10月2日（金）から10月7日（水）。 第三者が、公式アプリの会員情報を管理するシステムに不正アクセスしました。
- 10月13日（火）。 不正アクセスの可能性を調査した結果、会員情報の漏えいが判明しました。不正アクセスの事実を把握した後、直ちに通信元からのアクセスを遮断したとしています。
- 10月15日。 お知らせを公表しました。個人情報保護委員会への報告、対策本部の設置、暫定対策の実施は済んでおり、恒久対策、外部専門機関と連携した調査、対象の顧客へのメールでの案内を進めています。ITmedia Mobile · INTERNET Watch
| 項目 | 内容 |
|---|---|
| 件数 | 公式アプリ会員情報 約1,118万件。お知らせに正確な件数はありません |
| 漏えいした情報 | 会員ID、メールアドレス、登録種別、都道府県、性別、生年月日、氏名（漢字・カナ）、電話番号、モバイルオーダー履歴の有無、メールアドレス認証の有無 |
| 含まれないもの | クレジットカード番号。同社は保持していないとしています |
| パスワード | 「ログインパスワード情報の漏えいは現在確認されておりません」 |
| 原因 | 第三者による不正アクセス。不正アクセスが可能となった経緯は外部専門機関と調査中 |
| これまでの被害 | 不正利用などの二次被害は確認されていません |
確認したどの報道も、同じ件数と項目を伝えています。GAME Watch · サイバーセキュリティ.com · ITmedia ビジネスオンライン
日付と項目から読めること
6日間、さらに6日。 不正アクセスは暦の上で6日間続き、漏えいの判明はその終了から6日後でした。お知らせは、同社が最初に異変を疑った時期も、通信元を遮断した時期も書いていません。遮断が10月7日なら、何が取られたかの特定に6日かかったことになり、調査としては普通の長さです。遮断がそれより後なら、アクセスは別の理由で止まったことになります。いずれにしても、公表はアクセスが終わってから8日後でした。
「確認されていない」は「漏えいしていない」ではありません。 ビーケー・ジャパンは、ログインパスワード情報の漏えいは「現在確認されておりません」としています。これに対し焼肉きんぐのお知らせは、パスワードは漏えいした情報に含まれないとしていました（当サイトの分析）。アクセスされたシステムにパスワードが保存されていたか、どう保存されていたかを同社が示すまでは、アプリのパスワードは知られた可能性があるものとして扱ってください。
本人確認に使われる項目。 氏名、電話番号、生年月日の組み合わせは、多くのコールセンターが電話の相手を確認するのに使う情報です。性別と都道府県は偽の連絡をもっともらしくします。「モバイルオーダー履歴の有無」は、実際にアプリで注文している人、つまり注文や返金の連絡を待っていそうな人を攻撃者に教えます。「登録種別」が何を指すかは、お知らせに説明がありません。
約1,118万件は記録の数で、人数ではありません。 1人が複数のアカウントを持つことも、古いアカウントもあります。アプリに登録したことがある人は、対象外だと考えないでください。
10日間で2件目の飲食チェーンのアプリ
10月5日、物語コーポレーションは、会員管理システムへの不正アクセスにより焼肉きんぐアプリの会員情報10,788,963件が漏えいしたと公表しました。同社が不正アクセスを確認したのは10月2日で、ビーケー・ジャパンへのアクセスが始まった日です。物語コーポレーション
項目は異なります。焼肉きんぐで漏えいしたのは会員番号、氏名、メールアドレス、電話番号で、生年月日、性別、パスワードは含まれないとしていました。ビーケー・ジャパンでは生年月日と性別が含まれます。どちらの会社も原因やアプリの開発・運用会社を明らかにしておらず、2件を結びつける公開情報はありません。
ビーケー・ジャパンが漏えいを確認した10月13日、情報通信研究機構（NICT）は「A2B攻撃」について注意を呼びかけました。企業の公開アプリを解析し、その背後のサーバーを攻撃する手口です（当サイトの分析）。NICTはどの企業の被害もこの手口と結びつけておらず、ビーケー・ジャパンもアプリやAPIが侵入経路だったとは述べていません。
リスクカード：外から見たバーガーキング（日本）
リスクカードが答える問いは一つです。公開されている記録だけを読む人に、ビーケー・ジャパンのインターネットに面したシステムはどう見えるか。 漏えいの原因を説明するものでも、脆弱性診断でもありません。
作り方。 すべて、すでに存在する記録から作りました。お知らせのダウンロードを除き、ビーケー・ジャパンのシステムには何も送っていません。
- 証明書の透明性（CT）ログ：burgerking.co.jp配下の名前と、その証明書を提示するサーバー
- 商用のインターネットスキャンサービスが10月17日より前に収集していた既存の記録
- ドメインのメール認証に関する公開DNSレコード
- 米CISAの「悪用が確認された脆弱性」カタログ（KEV）
- ランサムウェアのリークサイトを追跡する公開サービス2つ：ransomware.liveとRansomLook
項目、重み、評価の基準は、評価する前に決めました。ホスト名、アドレス、ポート、製品名は意図的に載せていません。読者よりも攻撃者の役に立つ情報だからです。名前の分かる企業で現に悪用できる状態のものを見つけた場合は、公開せずJPCERT/CCに報告します。
図1：バーガーキング（日本）の外部から見たリスクカード（2026年10月17日）。本記事のためのオリジナル図版。
| 項目 | 重み | 評価（0〜3） | 確認したこと |
|---|---|---|---|
| ログイン画面・管理機能の露出 | 25 | 2、中程度 | 顧客向けアプリではない業務アプリケーションのログイン画面が、インターネットから到達できます。データベース、ファイル共有、リモート管理のサービスは見当たりません |
| 悪用が確認された脆弱性 | 20 | 0、確認されず | 識別できたソフトウェアに、CISAのカタログと一致するものはありません。1つのロードバランサーのアドレスでバージョン表示から推定された項目は数えていません。いずれもカタログにはなく、そのアドレスは他の顧客にも使われていたためです |
| サポート切れのソフトウェア | 20 | 0、確認されず | サポートが終了したソフトウェアは識別できませんでした |
| メールのなりすまし対策 | 15 | 3、弱い | DMARCポリシーは監視のみ（p=none）で、レポートも求めていません。SPFレコードは厳格です |
| インターネットに面した規模 | 10 | 1、小さい | 同社の証明書を提示するサーバーは十数台で、すべて1つのクラウド事業者にあります |
| ランサムウェアのリークサイト | 10 | 0、掲載なし | 10月17日時点で、どちらの追跡サービスにもビーケー・ジャパンへの犯行声明はありません |
| 総合 | 100 | 100点中35点：中 |
計算。 各項目を0〜3で評価し、スコアは「重み×評価÷3」の合計です。25×2÷3＋15×3÷3＋10×1÷3＝16.7＋15＋3.3＝35。区分は、34未満が低、34〜66が中、66超が高。高いほどリスクが大きいことを示します。
見えないもの。 サーバーの多くはクラウドのロードバランサーで、外からはロードバランサーが見えるだけで、その背後のソフトウェアは見えません。アプリの会員システムを動かしているものは外から見えないため、このカードはそれについて何も言えません。「確認されず」は「見える範囲になかった」という意味です。スキャンの記録はある時点のもので、数日前のこともあります。低いスコアは安全を意味せず、「中」は不注意を意味しません。
スコアを変えるもの。 35点のうち15点はメールの設定によるものです。DMARCポリシーをquarantineかrejectにし、集計レポートを受け取るようにすれば、スコアは20点で「低」になります。レコードは誰でもdig +short TXT _dmarc.burgerking.co.jpで確認できます。
メールの評価がこの事案で重要な理由
ビーケー・ジャパンのお知らせは、同社を装った不審なメール、SMS、電話に注意するよう顧客に求めています。正しい呼びかけです。1,118万件の氏名、メールアドレス、電話番号、生年月日は、もっともらしい偽の連絡に必要な材料そのものです。
DMARCは、自社ドメインを名乗りながら認証に失敗したメールをどう扱うかを、ドメインの所有者が受信側のメールサーバーに伝える仕組みです。10月17日時点で、burgerking.co.jpはv=DMARC1; p=none;を公開していました。規格上、p=noneはドメインの所有者が特別な処置を求めないことを意味します。ruaのアドレスがないため、同社のドメイン名でメールを送っている者についてのレポートも届きません。RFC 7489（DMARC）
大手のメールサービスは独自のなりすまし判定を行うため、偽のメールが止められることはあります。しかしビーケー・ジャパンは、拒否するよう求めていません。p=noneはGmailが一括送信者に求める最低限の水準を満たしますが、監視のための設定で、通常は強制に移る途中で使われます。Google：メール送信者のガイドライン DMARCは似たドメインには効かないため、いずれにしても受信側でのフィルタリングが必要です。
攻撃者の視点
レッドチームなら、このデータをどう使うか。MITRE ATT&CKに対応づけたモデルで、今回の攻撃の再現ではありません。
| 段階 | 想定される動き | ATT&CK |
|---|---|---|
| アプリを調べる | 公開アプリとその通信から、会員情報を返すエンドポイントと、呼び出し元の識別方法を読み取る | T1594 Search Victim-Owned Websites |
| 会員システムに到達する | 弱い認可、盗まれた認証情報、アプリの背後のシステムの欠陥 | T1190 Exploit Public-Facing Application |
| 数日かけて集める | リクエストを自動化し、6日間記録を集める | T1119 Automated Collection; T1213 Data from Information Repositories |
| ブランドの名前で送る | 監視のみのポリシーを当てにしてburgerking.co.jpを差出人にしたメール、または似たドメインからのメール | T1656 Impersonation; T1583.001 Acquire Infrastructure: Domains |
| 個人に合わせた誘い文句 | 会員の実名と生年月日を使った、クーポン、返金、「アカウント確認」のメールやSMS | T1566 Phishing; T1660 Phishing (Mobile) |
| 本人確認を通る | 氏名、電話番号、生年月日を使ってヘルプデスクに電話し、アカウントの再設定や支払先の変更をさせる | T1598 Phishing for Information; T1656 Impersonation |
防御側の視点
対応手順： APIデータ漏えい対応プレイブックは、アプリやAPIを通じて読み出されたデータの調査と復旧を扱います。ここでのリンクは、ビーケー・ジャパンで同じことが起きたことを意味しません。
1. 従業員や顧客がバーガーキングのアプリを使っているなら
- 連絡。 実名と生年月日を使った、バーガーキングのクーポン、注文、返金、アカウント確認をかたるメール、SMS、電話を想定してください。リンクはたどらず、アプリか公式サイトを自分で開いてください。お知らせにあるビーケー・ジャパンのカスタマーサービスは0120-945-630（平日10時〜17時）です。
- パスワード。 パスワードの漏えいは確認されていませんが、否定もされていません。アプリのパスワードと、同じパスワードを使ったアカウント（業務用を優先）を変更してください。
- 本人確認。 自社のコールセンターやヘルプデスクでは、これらの顧客の氏名、電話番号、生年月日は攻撃者に知られているものとして扱ってください。折り返し電話や、登録済みの端末に送るコードを使ってください。
2. メールのフィルタリングを運用しているなら
- 送信側のポリシーに頼らない。 ドメイン側が処置を求めていなくても、認証に失敗したburgerking.co.jpからのメールに自社のなりすまし対策が働くようにしてください。クエリ1は、すでに利用者に届いたものを探します。
- 他のドメインからの誘い文句。 クエリ2は、バーガーキングの名前を出しながら別のドメインから届いたメールを探します。偽物と確認したものは遮断し、次の従業員向け注意喚起に加えてください。
3. 会員アプリを運用しているなら
- 呼び出し元ごとの量で警報を出す。 6日間にわたって記録を返す会員システムなら、初日に量の警報が鳴るべきです。ソースネクストの分析に、呼び出し元が自身の通常量を大きく超えて読み出したことを探すクエリがあります。
- 返す量を減らす。 会員登録の後、アプリが生年月日を返す必要があるか見直してください。
- 通信元を遮断できる人と速さを、事前に決める。 「直ちに」に時刻が付くようにします。
- 必要になる前にDMARCを強制にする。 顧客に偽メールへの注意を呼びかける前に、レポート付きで
quarantineかrejectに移してください。
4. 対応すべきチーム
| チーム | 範囲 | 次の一手 | 必要な証跡 |
|---|---|---|---|
| メールセキュリティ | burgerking.co.jpを名乗るメールと、他のドメインからバーガーキングを名乗るメール | クエリ1と2を実行し、偽物を遮断し、なりすまし対策のポリシーを確認 | クエリ結果、遮断の記録 |
| SIEM / SOC | 10月2日以降のメールとサインインのログ | 両クエリを定期実行し、アプリを使う従業員のヘルプデスク経由の再設定を監視 | 実行計画、検出結果 |
| IT運用 | 自社の会員アプリとメールドメイン | 呼び出し元ごとの量の警報、レポート付きでDMARCを強制 | 設定、DMARCレポート |
| 法務・プライバシー | 従業員の情報と顧客対応の手順 | 従業員への周知の要否を判断し、生年月日に頼る本人確認を見直す | 判断の記録 |
| 委託先リスク | アプリを開発・運用する委託先 | 同じアプリ基盤を使う顧客と、その監視体制を確認 | 書面での回答 |
ハンティング
ビーケー・ジャパンの事案に固有の痕跡情報（IOC）は公表されていません。 以下のクエリは、その後に来るもの、つまりバーガーキングを名乗るメールを自社のログから探します。
どちらのクエリも例示であり、実データでは実行していません。テーブル名とフィールド名は、2026年10月17日（日本時間）にMicrosoftのドキュメントで確認しました。どちらもMicrosoft Defender for Office 365が必要です。
1. 差出人がburgerking.co.jpで、DMARCに合格しなかったメール。 Microsoft Defender XDRの高度なハンティング。
// Illustrative; not run against live data. Microsoft Defender XDR advanced hunting; needs Defender for Office 365.
// Inbound mail since 2 Oct 2026 whose visible From domain is Burger King Japan's but which did not pass DMARC.
// The domain's DMARC policy was p=none on 17 Oct 2026, so receiving servers are not asked to reject such mail.
// AuthenticationDetails holds verdicts such as {"SPF":"pass","DKIM":"pass","DMARC":"pass","CompAuth":"pass"};
// if DMARC comes back empty in your tenant, every message is kept, so check the column before trusting a quiet result.
let Since = datetime(2026-10-02T00:00:00Z);
let BrandDomain = @"(?i)(^|\.)burgerking\.co\.jp$";
let KnownForwarders = dynamic(["REPLACE_WITH_FORWARDING_RELAY_IP"]); // forwarding breaks SPF; list your own relays
EmailEvents
| where Timestamp > Since
| where EmailDirection == "Inbound"
| where SenderFromDomain matches regex BrandDomain
| where not(SenderIPv4 in (KnownForwarders))
| extend Auth = parse_json(AuthenticationDetails)
| extend DMARC = tostring(Auth.DMARC), SPF = tostring(Auth.SPF), DKIM = tostring(Auth.DKIM), CompAuth = tostring(Auth.CompAuth)
| where DMARC != "pass"
| summarize Messages = count(), Recipients = dcount(RecipientEmailAddress),
FirstSeen = min(Timestamp), LastSeen = max(Timestamp)
by SenderFromAddress, SenderMailFromDomain, SenderIPv4, DMARC, SPF, DKIM, CompAuth, DeliveryAction
| order by Messages desc
| take 500
2. バーガーキングの名前を出しながら、別のドメインから届いたメール。 Microsoft Defender XDRの高度なハンティング。
// Illustrative; not run against live data. Microsoft Defender XDR advanced hunting; needs Defender for Office 365.
// Inbound mail since 2 Oct 2026 that names Burger King or the Whopper but was not sent from its domain.
// BK Japan warns of fake mail, SMS and calls posing as the company. Expect news newsletters about the breach; list them as exceptions.
let Since = datetime(2026-10-02T00:00:00Z);
let LurePattern = @"(?i)burger\s*king|バーガーキング|whopper|ワッパー";
let OfficialDomains = @"(?i)(^|\.)(burgerking\.co\.jp|REPLACE_WITH_OTHER_VERIFIED_SENDER_DOMAIN)$";
EmailEvents
| where Timestamp > Since
| where EmailDirection == "Inbound"
| where Subject matches regex LurePattern or SenderDisplayName matches regex LurePattern
| where not(SenderFromDomain matches regex OfficialDomains)
| join kind=leftouter (
EmailUrlInfo
| where Timestamp > Since
| project NetworkMessageId, UrlDomain
) on NetworkMessageId
| summarize Recipients = dcount(RecipientEmailAddress), UrlDomains = make_set(UrlDomain, 10),
FirstSeen = min(Timestamp), LastSeen = max(Timestamp)
by SenderFromAddress, SenderFromDomain, Subject, DeliveryAction
| order by FirstSeen asc
| take 500
ダウンロード：なりすまし差出人のKQL · 誘い文句メールのKQL
結果がなくても、何も届いていない証明にはなりません。ビーケー・ジャパンが注意を呼びかけている他の経路、SMSと電話はメールのログには現れません。EmailEvents · EmailUrlInfo
コピーして使えるテンプレート
［ ］内をすべて置き換えてください。社外に出すものは、事前に法務またはプライバシー担当の確認を受けてください。
従業員への案内
件名：バーガーキングのアプリの情報漏えい――氏名や誕生日を知っている偽の連絡に注意してください
日本でバーガーキングを運営するビーケー・ジャパンは2026年10月15日、公式アプリの会員情報 約1,118万件が漏えいしたと発表しました。氏名、メールアドレス、電話番号、生年月日、性別、都道府県が含まれます。クレジットカード番号は保持されていませんでした。パスワードの漏えいは確認されていません。
- バーガーキングのクーポン、注文、返金、アカウント確認をかたるメール、SMS、電話に注意してください。実名や生年月日が書かれていることがあります。
- そうした連絡にあるリンクや電話番号は使わず、バーガーキングのアプリか公式サイトを自分で開いてください。
- アプリを使っている場合は、そのパスワードと、同じパスワードを使っている他のアカウント（業務用を優先）を変更してください。
- この件で［会社名］のIT部門がパスワードやコードを尋ねることはありません。
- 不審な連絡は［報告ボタンまたは宛先］に報告してください。
問い合わせ先：［セキュリティ担当の連絡先］
まだ分かっていないこと
- 侵入の方法： アプリのAPI、管理用の経路、盗まれた認証情報、委託先のいずれか。
- ビーケー・ジャパンが最初に疑った時期と、通信元を遮断した時期。
- **アクセスされたシステムにパスワードが保存されていたか、**保存されていたならどの方式か。
- 正確な件数と、それが何人分にあたるか。
- **誰が関与したか、**データが売りに出されるか。
- **アプリを開発・運用しているのは誰か、**同じ基盤を使う他社があるか。
出典と更新履歴
- ビーケー・ジャパン：不正アクセスによる公式アプリ会員情報漏えいに関するお詫びとお知らせ（PDF）、2026年10月15日
- ITmedia Mobile、2026年10月15日
- INTERNET Watch、2026年10月15日
- GAME Watch、2026年10月15日
- ITmedia ビジネスオンライン、2026年10月15日
- サイバーセキュリティ.com、2026年10月15日
- セキュリティ対策Lab、2026年10月15日
- 物語コーポレーション：焼肉きんぐアプリに関するお知らせ、2026年10月5日
- NICT：A2B攻撃に関する注意喚起、2026年10月13日
- RFC 7489（DMARC）
- CISA：Known Exploited Vulnerabilities カタログ
当サイトの関連記事：焼肉きんぐのアプリの情報漏えい · ソースネクストの会員API · skyticketとNICTのA2B攻撃の注意喚起 · フィッシング対応プレイブック
2026年10月17日： 初版を公開しました。ビーケー・ジャパンのお知らせは同社のウェブサイトで直接確認しました。報道は検索結果を通じて確認しました。調査環境からそれらのページを直接開くことはできませんでした。すべての数字を2つ以上の出典で確認しています。リスクカードは、10月17日（日本時間）に確認した証明書ログとDNSレコード、およびスキャンサービスがすでに収集していた記録に基づきます。スキャンもログインも行っていません。公開前の21時頃（日本時間）に、ログイン画面のスキャン記録、DMARCレコード、両方のリークサイト追跡サービスを再確認し、いずれも変化はありませんでした。