SMSポンピングは急速に拡大している不正攻撃の手口であり、特に金融サービス業界において、不正対策チームをしばしば不意打ちにします。
不正行為者は、オンボーディング時のOTPやSMSによる2要素認証（2FA）リクエストといった一般的なUXフローを悪用し、自分たちが管理するプレミアム料金番号宛てに何千通ものSMSを送信させます。一見すると新規顧客が急増しているように見えますが、実際には不正行為者が偽のトラフィックを送りつけて利益を得ており、その結果として通信費の請求を負わされるのはあなたの会社なのです。
こうした攻撃は高速かつ大規模に行われるため、たった一度のインシデントでも多大な損失を招く可能性があります。それにもかかわらず、リスク管理チームは見逃してしまいます。なぜなら、彼らのソリューションはプラットフォーム悪用ではなく、不正行為の検知に特化して調整されているからです。
そのため、SMSポンピングはフィンテック企業やマーケットプレイスにとって非常に危険な見落とし箇所となっています。幸い、適切なシグナルを用いれば、SMSポンピングは防ぐことができます。
SMSポンピングとは何ですか？
SMSポンピングとは、不正行為者がOTPや2要素認証（2FA）のSMS認証コード送信リクエストを悪用し、大量のSMSトラフィックを発生させ、その費用を企業側に負担させる攻撃です。 目的はアカウント乗っ取りや資金洗浄ではありません。彼らが管理するプレミアム料金番号（高額課金番号）にSMSを転送させ、その手数料の一部を不正に得ることです。一見すると無害に思えるかもしれませんが、この手口により、わずか数分で数万ドル規模の損失が発生する可能性があります。
この手口には、SMSトールフロード、不正に膨らませたトラフィック（AIT）、国際収益分配型不正（IRSF）、偽のOTP悪用、2FA課金詐欺などさまざまな呼び名がありますが、その仕組みはどれも非常によく似ています。
- 詐欺師は、レート制限やスロットリングが設定されていない公開されたSMSトリガーを見つける。
- 彼らは怪しげな通信事業者やSIMファームを通じて、プレミアムレート番号のまとまったブロックを取得します。
- ボットやスクリプトを使って何千件もの不正なリクエストが送信されます。これらは単純なフィルタを回避するために、プロキシやデバイスエミュレーター経由で分散されることが多く、OTP／2FA リクエストに対してリスクスコアリングを行っている企業はごくわずかです。
- 各リクエストはあなたのSMSアグリゲーターへのAPIコールを発生させ、アグリゲーターはそれを通常のトラフィックとして扱い、そのまま下流へルーティングします。
- メッセージはプレミアムレート番号に流し込まれます。実際にラックに並んだ本物のSIMに着信することもありますが、別の場合には、キャリアが配信確認を偽装しているだけのこともあります。
- 請求は上流へとさかのぼっていきます。あなたのプラットフォームがSMSプロバイダーに支払いを行い、そのプロバイダーが通信事業者に支払い、通信事業者が不正行為者と収益を分配するのです。
- あなたの側から見ると、テレメトリ上はすべて正常に見えます。OTP は「送信済み」となっており、ログイン失敗もなく、顧客からの苦情もありません。あなたに見えているのは、予期しない SMS 送信量の急増だけです。
SMSポンピング詐欺は誰に影響しますか？
SMSポンピング詐欺は、さまざまな関係者に影響を及ぼします。標的となる企業、トラフィックを配信するCPaaSプロバイダー、それを中継する通信事業者（テレコ）、そしてその責任を問われる不正対策・リスク管理チームが含まれます。
影響を受ける当事者 | 彼らへの影響 |
ビジネス | 偽のOTP請求書による直接的な金銭的損失や顧客からの苦情 |
CPaaS プロバイダー | 顧客離れと、より強力な不正防止対策を導入しなければならないというプレッシャー |
通信事業者 / キャリア | SMSへの信頼低下が長期的なトラフィック量を減少させる |
不正対策およびリスク管理チーム | SMSポンピングを検知するためのツールがない状態での社内の説明責任 |
エンドカスタマー | 攻撃中にOTPコードが失敗したりタイムアウトしたりして、ログインの問題やフラストレーションを招き、最悪の場合はユーザーが操作を途中で放棄してしまう可能性があります |
それはビジネスそのものから始まります。なぜなら、最終的に請求書を支払うのは彼らだからです。偽のOTPリクエストであっても、すべてSMSプロバイダーから請求されるため、そのコストはフィンテック企業やマーケットプレイスが直接負担することになります。
その痛みは次に CPaaS プロバイダーへと移っていきます。彼らはそのコストを転嫁することもできますが、顧客が何の前触れもなく数十万ドル規模の請求額の急増を見続ければ、反発が起こります。離脱する顧客もいれば、より強力な対策を求める顧客もいます。その結果、CPaaS ベンダーはメッセージごとの料金こそ支払わないかもしれませんが、顧客満足度と顧客維持という形で代償を払うことになるのです。
その圧力は最終的に通信事業者にも及びます。企業が通信キャリアからSMSを直接購入することはほとんどありませんが、チャネルとしてのSMSへの信頼が損なわれると、CPaaSプロバイダー経由で通信事業者に流れるトラフィック量は減少します。時間の経過とともに、それは通信業界の長期的な収益を危険にさらすことになります。
不正対策チームやリスク管理チームは板挟みの立場に置かれています。本来、SMSポンピングを検知することを前提に設計されていなかったにもかかわらず、なぜ既存のコントロールが不正を見逃したのか、その責任を問われてしまうのです。
最後に、これはお客様にも影響を及ぼす可能性があります。 攻撃の速度が十分に高い場合、OTP/2FA のフローが詰まり、本来のユーザーが OTP/2FA のステップアップを完了しようとした際に失敗やエラーメッセージを引き起こすことがあります。これは UX を悪化させるだけでなく、解約や離脱につながるおそれもあります。
SMSポンピング攻撃を検知する方法
ほとんどのリスク管理チームは、SMSポンピングが従来型の不正行為には見えないため、見逃してしまいます。
不正な取引に関する異議申し立てもなく、架空の本人情報もなく、ユーザーからの苦情もありません。OTP は「送信済み」となり、トラフィックはクリーンに見え、ダッシュボード上でも通常どおりのアクティビティが表示されます。一般的な不正検知ルールはアカウント乗っ取りや支払い悪用向けに最適化されており、通常の利用に見える中に紛れたインフラ悪用を検知するようには設計されていません。
誰かが「なぜSMSの請求額が急増したのか」と問い始める頃には、すでに被害は発生しています。そのうえ、OTP/2FAこそが必要なロジックのすべてだと考えているため、OTP/2FAのトリガーに対して意思決定ロジックを実装している企業はごくわずかです。
もし早期に察知したいのであれば、注目すべき兆候は次のとおりです。
速度の異常
実際のユーザーが、機械のような速度で連続してOTPエンドポイントにアクセスすることはありません。もし1つのデバイスやサブネットから数分のうちに何百件ものリクエストが送信されている場合、それはおそらくボット攻撃です。時間帯やセグメント、ユーザーの行動パターンに応じて変化するアダプティブなしきい値を設定しましょう。
ボットのシグネチャとボット主導のSMS攻撃検知
自動化を速度だけで推測してはいけません。正確に見極めましょう。Sardine は Selenium、Playwright、Stagehand を含む 17 以上の自動化フレームワークを検知できます。シグネチャのヒットに加え、リクエストのリズム、ヘッドレスフラグ、スクリプト可能なブラウザの特性を組み合わせて判定します。
デバイスとネットワークの兆候
一般的な顧客は、通常、自分の本当のIPアドレスや位置情報をわざわざ隠そうとはしません。住宅用プロキシの利用は、とくにボットやエミュレーターの使用といった他のシグナルと組み合わさると、不正の兆候になり得ます。不審なデバイス属性も、ほかのサインとして挙げられます。たとえば、タイムゾーンの国がデバイスのGPSデータと一致していなかったり、同じフィンガープリントが複数のユーザー間で使い回されている場合などです。
完了率
健全なファネルでは、送信は検証へとつながります。一方でポンピングが起きている場合、送信数だけが急増し、完了数は横ばいになります。プレフィックス、ルート、ジャーニーごとに、送信から検証まで、そして送信からセッション継続までを追跡しましょう。
宛先パターンとSMSプレミアムレート詐欺の検知
リクエストがどこに到達しているかに注意してください。高コストのプレフィックスや、ユーザー数が少ない地域（ジオ）にリクエストが集中している場合は、SMSコスト悪用攻撃の兆候です。MCC/MNC、番号帯、ルートの変化、そして認証済みユーザー1人あたりのコストを監視しましょう。
スロットリング
可能な限りOTP／2FA／SMSプロバイダーが提供するガードレールを利用するか、社内システムを用いてスロットリング技術を活用し、レート制限によって急激なAPIコールの増加を防ぐようにしてください。これは、DDoS攻撃に対して用いるのと同じ技術的な戦略です。
接続グラフ
詐欺行為者は、見かけ上は別々のアカウントに見えるように活動を分散させるのが一般的ですが、マッピングしてみると各種シグナルがつながっていることが分かります。共有されたIPやIPレンジはよくあるつながりであり、アカウント間で使い回されるデバイスフィンガープリントも同様です。リンクしたアカウント群の一つがOTPリクエストの不釣り合いに大きな割合を占めている場合、連携した攻撃を受けている可能性が高いと言えます。
すでに被害に遭ってしまった場合の対処法
SMSポンピングへの最善の対策は、被害が広がる前に食い止めることです。しかし、すでに組織が影響を受けてしまっている場合でも、被害を最小限に抑え、責任を上流に戻すのに役立ついくつかの手順があります。
- 料金に異議を申し立てる。通信事業者に連絡し、不正なトラフィックに対する料金の取り消しを依頼してください。多くの場合、これにより責任は通信事業者側に移ります。
- 番号を報告してください。 不審な番号をスクリプト経由で7726（SCAM）に転送し、特定・ブロックできるようにします。
- 必要に応じてエスカレーションしてください。大規模な攻撃が発生した場合、FCC（連邦通信委員会）が介入することがあり、多くの場合、通信事業者に責任を問うことになります。
- 報告を提出してください。組織が被害に遭った場合は、FTC に報告を行い、電話番号の停止手続きを開始してください。これにより、その番号が今後の攻撃で再利用されるのを防ぐことができます。
これらの対策は進行中の攻撃を止めることはできませんが、金銭的な被害を軽減することはできます。
なぜSardineは他のツールが見逃す不正を防げるのか
レガシーなシステムは、ブロックリストや静的なルールに過度に依存しているため、こうした攻撃を見逃してしまいます。既知のパターンは止められますが、新しい手口はそのまま通り抜けてしまいます。SMSポンピングは、その抜け穴を悪用する攻撃です。
Sardine はデータ中心のアプローチでこれを一新します：
- 私たちは徹底的に調査し、デバイスと行動のデータを活用して、他社が見逃してしまう微妙なシグナルをあぶり出します。
- 私たちは、独自の行動トラッキング技術を用いることで、この不正行為を助長するために使われているボットやスクリプト、エージェント型AIエージェントなどの自動化システムを素早く検知することができます。
- 私たちはサイロ化されたデータを解消し、顧客ジャーニー全体のあらゆるデータを一つの包括的なリスクビューに統合することで、フィンテックやマーケットプレイス環境におけるSMSポンピングをはるかに発見しやすくします。
- 統合されたシグナルにより、不審なつながりや連携した不正行為が可視化されます。
- 当社のアノマリーエンジンはライブトラフィックを監視し、異常なパターンが現れた瞬間に検知してフラグを立てます。
- その後、当社のAIが脅威を阻止するためのルール案を自動生成し、チームが対応するまでの時間を短縮します。
このアプローチにより、当社はマーケットプレイスのお客様の一社が不正グループの被害に遭った際に支援することができました。Sardine はその行為を高リスクとしてフラグし、250ミリ秒以内に判定しました。何百万件ものリスク判断のうち、人間の審査によって覆されたのはわずか0.068％に過ぎませんでした。
大規模なSMSポンピング詐欺の被害に直面している場合、私たちがビジネスへ影響が及ぶ前に攻撃を封じ込めるお手伝いをします。ぜひお問い合わせいただき、デモを予約してください。
よくある質問
SMSポンピング詐欺とは何ですか？
SMSポンピング詐欺（AIT＝Artificially Inflated Traffic／不正なトラフィック水増しとも呼ばれます）は、詐欺者が自分たちで管理している、または収益を分配している電話番号宛てに、何千通ものSMSワンタイムパスワード（OTP）メッセージを意図的に発生させる手口です。これにより、送信側のCPaaS予算を消耗させる一方で、受信側キャリアの収益を不正に膨らませます。
SMSポンピング詐欺は、SMSスパムとどう違うのですか？
スパムは受信者を狙いますが、SMSポンピングは送信者を狙います。スパムでは受信者はメッセージを求めていませんし、不正行為者は有料のOTP送信を発生させるために、収益分配スキームに組み込まれた電話番号宛てに、偽のアカウント作成やパスワードリセットを何千件も自動生成します。
どの業種がSMSポンピング詐欺の影響を最も受けやすいですか？
フィンテック、暗号資産取引所、ライドシェア、フードデリバリー、マーケットプレイス、そして大規模にSMSワンタイムパスワード（SMS OTP）を利用するあらゆるコンシューマー向けプロダクトが対象です。Twitterは、無料ユーザー向けのSMSによる2要素認証（SMS 2FA）を廃止する前の2023年に、SMSポンピング詐欺によって6,000万ドルの損失を被ったと公表しています。
なぜCPaaSベンダーのスパム対策ではSMSポンピングを防げないのですか？
CPaaS のスパム対策は通常、メッセージ内容と送信レート制限に基づいて行われます。一方で SMS ポンピングは、コンテンツフィルターをすり抜ける正規のアカウント作成フローを利用し、レート制限を回避するために数千ものアカウントに分散させ、正規に見えるキャリアのプレフィックス宛てにルーティングします。検知にはメッセージ内容ではなく、送信元デバイスや行動パターンに関するシグナルが必要になります。
SMSポンピングをいち早く検知する最速のシグナルは何ですか？
発信元セッションにおけるデバイスフィンガープリントと行動バイオメトリクスを組み合わせ、それらをSonarコンソーシアムが保有するSMSポンピングパターンと照合してスコアリングします。実際のユーザーは通常1回だけOTPを要求しますが、ポンピングボットは数千回ものリクエストを発行し、その際のデバイスや行動のわずかな一貫性が検出され、50ミリ秒以内にしきい値を超えるスコアとして判定されます。