QRコードを悪用したフィッシングメール（413号）

2025年6月に、いわゆるバーコード決済のシステムを悪用したフィッシングメールが出てきました。

　PayPayで一瞬にして73万円を騙し取られた話（Applis氏のnoteより）
　https://note.com/appliss/n/n419dcf130240

キャッシュレス決済の信用にもつながる話ですので、PayPay側も数日で対応を行うなど、迅速な対応を取っており、同じ手口では被害を受けないようになっていますが、騙そうとする側もいろいろと研究を重ねていますから、油断は禁物です。


1. 事件の概要

今回の事件は「請求額の確定」というフィッシングメールから始まります。

Applis氏（上記の引用記事の作者さん）はその金額を不思議に思い、「詳細を確認する」ボタンを押したところ、何の説明もなくQRコードが表示されます。「ログインに必要なのかな？」と２枚のQRコードをPayPayのアプリ内で取り込んだそうです。

数分もすると、PayPayに登録してある銀行から、次々とPayPayにチャージされ、Winticketなるサービスに使われていきます。

Winticketというサービスに全く覚えのないApplis氏は、急遽銀行とPayPayの連携を解除したものの、その時点で既に70万円を越える被害を受けていたとのことです。

Applis氏は、PayPayアプリ内でQRコードをスキャンしただけだというのに、一体何が起きていたのでしょうか？


2. インターネットでの通信

この事件の仕組みのお話の前に、少し前提となるお話をします。

まずは、インターネット上での「通信」というのが何か？というお話です。

インターネット上では、皆さんもよくご存知のように通信販売での購入、銀行での振込みなど、おカネの流れを含む様々なことができます。

これらには、https(昔ならhttp)という通信手順（プロトコル）が使われています。

例えば、Googleにアクセスする時にはこんなURL（Unified Resource Locator）を使います。
　https://www.google.co.jp/

httpsというのは、ChromeやSafariといったブラウザを使う時、いわゆるインターネット利用時に必ず使われる通信手順のことですが、httpsは別にブラウザ専用ではありません。

ネットを利用する通信販売、ネットバンキング、チャットアプリ、LINEなどのSNS、どれもがhttpsを使っています。
実は、アプリが実現しているのは画面やデザインの表示だけで、チャットでの通信内容はもちろん、決済処理なども、裏側ではhttpsを用いています。


3. 決済時もhttpsを使う

とはいえ、口座番号さえ知っていれば、誰でも誰にでも送金できるなんて、あったら困りますし、それではネットを安心して利用できません。

だからこそ、ログインや多要素認証といった手段を使って、本人確認をするわけです。
そして、本人がログインした後に「決済してね」という依頼をする時には、必ず本人であることを確認してから、決済をするわけです。

ですが、実のところ、httpsという通信手順はステートレスといって、前回までの通信内容は全く知らない状態での通信を行います。

つまり、利用者から見るとちゃんとID/パスワードで認証して、ログインしているわけですが、httpsの通信上は、ログインという概念もなく、毎回新鮮な気持ちで全く前提知識なしで通信をしています。

もちろん、本当に何もなしだと上で書いたように誰でも送金できることになりかねません。

なので、ログインをすると、セッションIDとかセッショントークンといった長ーい番号を発行し、以降の通信ではその番号を毎回送り続けることで利用者を識別しています。（ここで登場するのがクッキーだったりする）

ですから、決済処理についても、決済に要する全ての情報を詰め込んだ１回のリクエストで全てを解決する仕組みとなっています。（データの渡し方は厳密にはいろいろあるのですが、ここでは省略します）

ですので、仮にセッションIDを詐称できれば、（技術的には）正しい決済依頼(URL)が発共できます。そして、それは有効なリクエスト（依頼）です。

有効なリクエストが来たら、それを処理するのがサーバの仕事です。

もし、それが不正な手順で得られたURLであったとしても、それが有効で（技術的に）正しいリクエストなら、それを受け入れて処理するのがサーバの仕事なのです。

残念ながら、悪意があるけど技術的に正しいリクエストは除外できないのです。


4. QRコードはURLを持つ

QRコードには通常１つのURLが含まれます。
「それぐらいは知ってるよ」という方が多いでしょう。

ですが上で書いたように、「利用者登録も、決済依頼も、振込依頼も、どれも１つのURLで完結している」と言われるとどうでしょうか？

QRコードをうかつにクリックすることの恐さを感じないでしょうか。

もちろん、各サービス会社はそんな不正な処理が起きないように、細心の注意を払って設計を行うわけですが、利便性と安全性の「はざま」では、往々にして利便性を求める声が通ってしまいがちです。


5. 何があったのか？

Applis氏がログイン手続きだと思ってアクセスしたのは、もちろんPayPayのログインURLなどではありません。
これは、とあるサービスの支払い方法をPayPayとする申込みのURLでした。

とあるサービスというのはWinticketという競輪投票システムです。
このサービスでは支払いにPayPayが選べるようになっていました。（事故発生から数日で停止されたようです）

今回の問題は２点あります。

ひとつは、PayPayでの申込みを行う際に、利用者への確認が全くないという画面設計上の問題です。
これでは、今回のように利用者側からはだまされたことを知る術がありません。
例えば、「お客様のPayPay口座とWinticketのアカウント（ｘｘｘｘｘ）を連携しますか？」などとワンクッションがあれば、「はい」を選択することはまずなかったはずです。

もう一つは、WinTicket側で高額な投票券（馬券ならぬ車券と呼ぶらしい）を購入するときに、PayPayに連携している銀行口座から自動チャージできるオプションを用意していた点です。これが今回の被害を大巾に拡げた主因です。

後講釈ですが、いずれも利用者の利便性向上の狙いが裏目に出て被害を大きくしています。

さて、この２点を最大限活用しようとすると、犯罪者はこんな準備をするはずです。
　1. WinTicketでアカウントを作る
　2. PayPayを支払い口座とする申込みQRコードをゲット
　3. にせサイトを作って、QRコードを置いておく

この状態で3のにせサイトに誘導するフィッシングメールを送るわけです。
騙されてアクセスした人は、ホントはWinticketとの連携用QRコードなんて知る由もなく、PayPayアプリで読み込んでしまうわけですね。
すると、（何のメッセージもなく）PayPayとWinticketが連携されてしまいます。

犯罪者側は連携されたことを確認すれば、WinTicketで次々と車券を買って勝った分を現金化することができます。（チャージした分をそのまま現金にはできないため）

今回はPayPayとWinticketの双方の設計者が利便性を重視しすぎた結果と思われます。
考慮不足といえばそれまでですが、もう少し配慮していれば防げたのにと思うと、もったいない話です。


6. まとめ（今日からできること）

2025年6月にPayPayと外部サービスの連携を利用した非常に巧妙なフィッシングメールが登場しました。

QRコードの危険性は今までも言われていましたが、今回はその被害が大きい点もさることながら、利用者側でのガードが極めて難しいものでした。

現在は、PayPay側もシステム改修も含めて対応を行ったようですので、同じ事故は起きないでしょうが、同様の事例は今後、たくさん出てくるのではないかと思われます。

複数サービスの連携事業では、事業者側には手続きをカンタンにしたいという（主に営業サイドによる）圧力が働きます。そのため、安全性が軽視されやすい環境がありますから、PayPayに限らず、様々な形で同様の事故が増えるのではないかと思います。

「石川や　浜の真砂は尽きるとも　世に盗人の種は尽きまじ」
石川五右衛門の辞世の句だそうですが、当たっているのがなんともはや。

今回は、QRコードを用いたフィッシング詐欺のお話でした。
次回もお楽しみに。

今日からできること。
　・フィッシングメールは無視する
　　→「わからない場合はアクセスしない」が基本
　　→それでも不安なら、公式ページからログインして確認
　・アプリ上で出所の不明なQRコードを読ませない
　　→出所が不明な時点で毒まんじゅうと考えよう

（本稿は 2025年6月に作成しました）