最近の不正アクセスを追っていて、一つ考え方が変わってきた。
これまで私は、
脆弱性を探す → サーバーへ入る → 認証情報を探す → 権限を上げる → データへ進む
という順番を強く意識していた。
しかし最近の事案を見ると、もっと安い攻撃が成立しているように見える。
最初に「鍵」がある。
その鍵を使う「鍵穴」が見える。
さらに、使い方を示す「地図」まである。
攻撃者は一番強い鍵ではなく、鍵・鍵穴・地図が揃った、すぐ使える場所を探しているのではないか。
例えばSendGridのAPIキーが漏れたとする。
これは使いやすい。
APIのURL、認証方法、request形式。全部公開されている。
つまり、
鍵を拾う → ドキュメントを見る → 正規APIを呼ぶ
までが簡単につながる。
一方、自社独自APIの強力なキーを拾っても、
それが分からなければ、すぐには使えない。
鍵の強さだけでは足りない。
鍵穴と、その使い方が必要になる。
先日、旭化成セラピューティクスの「Pharma DIGITAL」を調べたとき、静的フロントとAPIの境界がはっきり見えた。
静的サイトが危険という話ではない。
ブラウザがAPIを呼ぶ以上、endpoint、認証方式、parameter、request、responseといった構造は、外側からある程度観察できる。
つまり自社独自APIでも、フロントが鍵穴と、その使い方を教えてくれる。
鍵を持っていれば、そこから正規ルートをたどれる可能性が出てくる。
ここでWebだけを見ていてはいけなかった。
スマホアプリだ。
10月7日に公開されたマクニカ セキュリティ研究センターの記事では、伊藤忠サイバー＆インテリジェンス、セキュアスカイ・テクノロジーから提供された情報も含め、最近相次ぐWebシステム侵害の傾向が整理されている。
その事案対応やログ分析に基づく情報の中には、スマホアプリを解析してAPIキーを取り出し、正規アクセスに見える形でAPIを呼び出すケースも観測されている。
スマホアプリはサービスを利用するためにAPIへ接続する。
だから、誰でもアプリを入手して通常の操作をすれば、どの操作で、どのAPIへ、どんなrequestが飛ぶのかという正常系の通信パターンが見える場合がある。
さらに解析すれば、API endpoint、認証方式、API key、client ID、設定値などが分かることもある。
もちろん、アプリ内にあるAPI keyがすべて秘密情報という意味ではない。
重要なのは、その値を、どこで、どう使うのかまで一緒に分かること。
スマホアプリは場合によって、鍵穴と地図をまとめて見せ、さらに鍵まで持っていることがある。
10月8日、JPCERT/CCも、直近で相次ぐ国内組織への不正アクセスについて注意喚起を出した。
複数の報告を受けているAPI経由の攻撃手法として、
を挙げている。
つまり、
という攻撃が、実際に報告されている。
一方、JPCERT/CCは別のケースとして、さまざまな既知の脆弱性や管理不備を探索する中で、環境設定ファイルやバックアップファイルの窃取などを試みている可能性があるともしている。
これも、設定ファイルを鍵束と地図の両方として見る考え方と矛盾しない。
今でもWebサーバーには、.env、.git、設定ファイル、バックアップ、debug情報を探すスキャンが大量に来る。
そこには、DB credential、API key、mail service key、cloud tokenなどがあるかもしれない。
しかし.envに入るのは鍵だけではない。
DBホスト、API URL、サービス名、環境名、接続先。
つまり.envは場合によって、鍵束であると同時に地図でもある。
しかも今のシステムは、一社だけで開発・運用されているとは限らない。
鍵や設定情報が存在する場所は増えている。
本番そのものを破らなくても、一番弱い場所から拾えばいい。
JPCERT/CCも、他システムへの侵害で窃取したAPIキーが使われるケースを挙げている。
ここまでを整理すると、攻撃者が利用するものは、大きく三つに分けられる。
これは、すべての攻撃を説明する公式ではない。
マクニカが整理している最近の事案には、匿名ユーザーでも会員向け機能へ到達できたり、APIが必要以上の情報を返したりするなど、そもそも強い鍵を必要としないものもある。
つまり、鍵穴と地図だけで成立する攻撃もある。
ただ、使える鍵があり、鍵穴が見え、正常な使い方まで分かる。
そこまで揃えば、攻撃コストはさらに下がる。
重要なのは、攻撃者がゼロからAPIの仕様を考える必要がないことだ。
Webフロントがある。
スマホアプリがある。
そこには、正常にサービスを使うための処理が実装されている。
つまり、正常系のお手本が配られている。
少なくとも、入口を理解するコストは大きく下がる。
しかし攻撃は、画面から見える機能だけで終わるとは限らない。
JPCERT/CCは、本来画面操作では実行できない内部APIに対する攻撃も報告されているとしている。
具体的には、
などだ。
つまり、地図は入口にすぎない。
正常系からシステムの構造を理解した後、その先に画面には見えない扉がないかを探るケースもある。
ここでもう一つ、従来のOS中心の攻撃との違いが見えてくる。
もちろん、OSを侵害し、権限昇格し、横展開する攻撃は今もある。
ランサムウェアなら、
侵入 → OS権限昇格 → EDR回避 → 横展開 → 暗号化
という流れは今も重要だ。
しかし、アプリ側のデータを取ることが目的なら事情が違う。
アプリには正常に動き続けてもらった方がいい。
壊してしまえば、自分が使いたい経路まで止まる。
だから、壊して支配するより、正常な動きを維持したまま、アプリの中で権限を広げる方が合理的な場合がある。
rootやAdministratorを取らなくても、アプリが持つ権限だけで目的を達成できることもある。
セイコーマートの事案では、約57万のユーザーIDが不正アクセスを受けた可能性があり、その発覚の端緒となったのは1件の不正な退会処理だった。
その退会が技術的にどの経路で実行されたのかは公表されていない。
ただ、退会そのものはサービスに存在する通常の処理だ。
ここで気になるのは、誰が、誰に対して、その処理を実行できたのかという認可の境界だ。
アプリを狙う攻撃を見るとき、
だけでは足りない。
一件一件は正常な処理に見えても、主体や対象が違えば不正利用になる。
そして、量が増えたり、退会や通知などの副作用が出たりすれば、そこで発覚する。
マクニカの記事でも、高負荷や顧客への通知など、さまざまな痕跡を残す「荒っぽい」動きが見られ、それが被害発覚につながっている可能性が指摘されている。
つまり、正規ルートを使うことと、検知されないことは同じではない。
では、なぜアプリを狙う価値があるのか。
昔なら、企業の重要データはSoR、System of Recordにあると考えるのが普通だった。
顧客マスタ、契約、取引、口座、会計。企業の本丸だ。
しかし今は、その外側にも重要な情報がある。
問い合わせ、CRM、会員管理、チャット、サポート、スマホアプリ。
顧客を識別し、通知し、サービスを提供するために、会員ID、氏名、メールアドレス、電話番号といったIdentityに近い情報を、外側のアプリでも扱う。
焼肉きんぐとMrMaxでは、
という4項目が共通して漏えい対象となった。
これらは契約、取引、決済といった本丸側のデータとは少し違う。
しかし、その人が誰なのかを識別し、通知し、認証や本人確認の周辺で使われる情報でもある。
焼肉きんぐは公式スマホアプリを提供している。
アプリを配布する以上、第三者も正規利用者と同じアプリを入手できる。
通常の操作から通信を見るだけでも、どの機能がどのAPIを呼び、どんな形式でデータをやり取りするのかという正常系のパターンが見える場合がある。
だからといって、今回の侵害がアプリ解析やAPIキー取得から始まったとは言えない。
原因は公表されていない。
重要なのは、外側からアプリの正常な使い方を理解するコストは、それほど高くないということだ。
攻撃者が最初からこの4項目を狙っていたのかも分からない。
むしろ、
アプリへ到達した。そこに、そのデータがあった。
という可能性も考える必要がある。
マクニカの記事でも、最近の事案では、直接金銭化しやすい情報ではなく、単体では悪用しづらい情報だけが漏えいするケースも少なくないと指摘されている。
その目的についてマクニカは断定していない。
その上で、集めた情報を組み合わせ、次の詐欺などに利用する意図がある可能性も一つの仮説として挙げている。
「単体では弱い情報」だから価値がない、とは言い切れない。
大和証券の事案はさらに分かりやすい。
侵害されたのは証券取引システムではなく、問い合わせを扱う外部システムだった。
それでも、対象情報には口座番号まで含まれていた。
その口座番号が自動的に連携されたのか、顧客自身が問い合わせ時に入力したのかは外からは分からない。
一方、大和証券の問い合わせは、口座を持つ顧客と、それ以外の利用者で導線が分かれている。
口座を持つ顧客がログインした上で問い合わせる仕組みなら、少なくとも問い合わせを顧客と結びつける識別情報は必要になる。
つまり問い合わせ側には、誰からの問い合わせなのかというIdentityと、何を問い合わせたのかという文脈が結びつく。
さらに備考欄や自由文には、本来は本丸側にありそうな情報まで流れ込み、溜まることがある。
マクニカも、備考欄などに想定していなかった情報が保存されていないかを見直す必要性を指摘している。
SoEは、もう単なる受付窓口ではない。
スカラコミュニケーションズのi-askでは、管理サイトへの不正ログイン後、不正プログラムが設置され、同一サーバー上で稼働していた最大5社のシステム環境のデータベースから、問い合わせ情報を取得された可能性があると公表された。
さらに同社は、被害拡大防止として、アップロードされたファイルをプログラムとして実行できないよう設定変更を実施した。
今後は管理者認証の強化や環境間の分離も行うとしている。
ここから先は推測になる。
最初の認証がどう成立したのかは分からない。
不正プログラムが、具体的にどの機能を使って設置されたのかも公表されていない。
ただ少なくとも、
不正ログイン → 不正プログラム設置 → 複数企業の問い合わせデータを取得した可能性
という順番が公表されている。
重要なのは、最初の入口だけではない。
一つの入口を取られた後、そのアプリの中でどこまで進めるのかという問題だ。
ここまでをつなぐと、攻撃側から見た魅力が分かる。
鍵がなくても成立する攻撃はある。
しかし、
ならば攻撃コストはさらに下がる。
しかも、その先のアプリだけでも十分価値がある。
ならば、わざわざOS全体を支配し、本丸まで進む必要がない場合もある。
アプリを壊さず、正常に動かしたまま使う。
攻撃者が探しているのは、必ずしも最強の鍵ではない。
Webフロントは地図になる。
スマホアプリなら、地図だけでなく鍵まで含んでいる場合がある。
.envなら、鍵と接続先が同時に見つかることもある。
そして、その先にあるのはもう「周辺だから価値が低いデータ」とは限らない。
Identity、問い合わせ、会話、顧客との接点。
攻撃者は本丸を狙わなくなったのではない。本丸に近いデータが、外側へ出てきた。
本丸まで行かなくても、外側のアプリだけで目的を達成できる場合がある。
だから、「APIを隠せばいい」という話にはならない。
ブラウザがAPIを使うなら、その存在を完全には隠せない。
スマホアプリも、配布する以上は解析される前提で考える必要がある。
JPCERT/CCが推奨している対策も、この考え方とよく合う。
つまり企業側が見るべきなのは、
だと思う。
鍵は守る。
しかし、鍵は漏れる可能性がある。
地図も完全には隠せない。
ならば、鍵を取られても、開く扉を限定する。
そして、一つの扉を開けても、次の扉まで開かないようにする。
攻撃者が探しているのは、最強の鍵ではない。
鍵・鍵穴・地図が揃い、その先のアプリだけでも価値がある場所。
最近相次いでいる不正アクセスは、そういう場所から攻められているのではないかと思う。
Aikido Community Japan
公開日: 2026/10/8
最終更新: 2026/10/8
セキュリティの最新情報をお届けします。