「ハッカーではなく、“ボット”がお金を稼ぐ構造」

リワード・クーポン自動化悪用対策

「イベント参加者がこんなに多いはずがないのですが？」

新規顧客獲得のため、ある飲食アプリでは出席イベントやクーポンキャンペーンを実施しました。

開始初週、社内ダッシュボードは華やかな数字を表示していました。

• イベント参加数が急増
• クーポン利用率が急上昇
• DAU・MAUが増加

しかし1か月後、数字は別の事実を示し始めました。

• 売上は変化なし
• マーケティング費用だけ増加
• 正常ユーザーのクーポン利用率は低下

イベントを利用していたのは顧客ではありません。

ボットでした。

なぜリワード・クーポン自動化は危険なのか

この攻撃の最大の問題は、

「ハッキングに見えないこと」

です。

リワード自動化の特徴

• 正常ユーザーの行動とほぼ同じ
• サーバーリクエストも正常に見える
• 決済・ログインエラーが発生しない

つまり、セキュリティ事故に見えないままビジネスを破壊する行為です。

実際の事例：エミュレーターファームが作った偽ユーザー

会員制飲食アプリで実際に発生したケースです。

発見された異常

• 特定時間帯に出席チェックが急増
• 新規アカウント作成パターンが繰り返される
• 数百アカウントで同じ操作フローが同時発生

調査結果

• 数十台のエミュレーターを同時実行
• マクロによる自動クリック
• 出席 → ミッション → クーポン発行 → ポイント獲得
• 一部は中古マーケットでクーポン販売

人間ではなく、

自動化された環境がイベント報酬を獲得していました。

攻撃方法の流れ

1）複数エミュレーター実行

• 実際のAndroid端末のように偽装
• 端末ID・OS情報をランダム化

2）マクロ・自動入力

• 出席ボタンを自動クリック
• イベント参加を自動化
• 繰り返しアカウント作成

3）サーバーはすべて正常処理

• ログイン成功
• イベント参加成功
• クーポン発行成功

サーバーから見ると、

「正常ユーザーによる正常リクエスト」

でした。

セキュリティ問題はどこにあったのか

問題は明確でした。

「アプリが実行される環境と、入力している主体を検証していなかった」

具体的なセキュリティ不足

• エミュレーター実行制御なし
• 自動入力・異常タッチ検知なし
• 同一行動パターンへのクライアント検証なし
• アプリ完全性・信頼度による制限なし

つまり、

「人間がボタンを押した」という前提を信頼したこと

が問題でした。

LIAPPはどのように防御したのか

リワード自動化はサーバーより先にアプリレベルで防ぐ必要があります。

• エミュレーター環境検知
• ルート・仮想化・フッキング環境検知
• 異常環境でのアプリ実行制限
• 同一座標への繰り返しタッチ検知
• 非現実的な反応速度検知

適用後、どのような変化があったのか

セキュリティ適用後、

• エミュレーターによる参加はほぼゼロへ
• クーポン悪用停止
• マーケティング費用正常化
• 本当のユーザーへのメリット向上

最も重要な変化は、

「リワードはコストではなく、信頼に基づく報酬である」という認識

でした。

飲食アプリが学ぶべき教訓

リワードやクーポンは顧客への特典ですが、プラットフォームにとっては現金と同じ価値を持つ資産です。

そして、この資産はサーバーより先に守る必要があります。

• 実行されるアプリ
• 入力する手
• 表示される画面

飲食アプリへの最終的な教訓

デリバリー・会員アプリの事故はサーバーから始まりません。

始まりは、

注文を作るアプリ、
操作する手、
表示される画面。

この3つは選択肢ではなく、飲食アプリ運営における基本防御ラインです。

#飲食アプリセキュリティ #配達アプリセキュリティ #リワード悪用 #クーポン自動化 #マクロ攻撃 #エミュレーター #マーケティング費用 #ポイントセキュリティ #会員アプリ #モバイルセキュリティ #アプリ完全性 #自動化対策 #LIAPP #LISS #LIKEY