ハクソク

世界を動かす技術を、日本語で。

HNに聞く: PayPalの異議申し立てでスパム攻撃を受けているスタートアップ、どうすればよいですか？

356日前

概要

  • PayPal Commerce Platform を利用したマーケットプレイスでの不正購入・チャージバック被害の相談
  • 攻撃者は 自動化ブラウザ・IP変更・未検証アカウント を使用
  • PayPalサポートの対応が不十分 で、根本的な解決が困難
  • 動機・目的が不明 で、対策に苦慮
  • 類似事例や 追加対策・アドバイス を求めている状況

PayPal Multiparty APIを悪用した自動化不正購入・チャージバック事例

  • 攻撃者の特徴 ・常に同じ2つのドメインからの 新規メールアドレス 使用 ・ 未認証PayPalアカウント による決済 ・ 少額・デジタル商品 に対する購入 ・購入後 数時間以内に全て異議申し立て （チャージバック）

  • 攻撃の手法 ・API経由ではなく、 ブラウザ経由で自動化 ・ IPアドレスを都度変更 し、検知回避 ・アクセスログからも 高頻度なボットトラフィック を確認 ・ 変動を加えつつ繰り返し購入、検知を回避

  • PayPalサポートの問題点 ・ サポート対応が遅く、定型文中心 ・Multiparty APIに対する 理解不足 ・ 電話サポートはアカウント関連性を認識せず対応不可 ・ 各出品者ごとに個別対応を求められ、全体像が伝わらない

攻撃者の動機・狙いの考察

  • 単なる嫌がらせ行為 の可能性
  • チャージバック詐欺 によるPayPalや出品者の信用低下狙い
  • システムの脆弱性調査や自動化ツールのテスト
  • 競合他社による妨害行為 の可能性も

追加で検討すべき対策・アドバイス

  • フロントエンド・フォームの追加防御策 ・ reCAPTCHA や hCaptcha の導入で自動化防止 ・ JavaScript難読化・動的トークン でボット対策 ・ メールドメインのブラックリスト化、同一ドメインからの連続購入制限 ・ 未認証PayPalアカウントからの購入制限 （PayPal設定で可能か要確認）

  • ネットワーク・ログ監視強化 ・ 異常なIP・UAパターンの自動ブロック ・ アクセス頻度やパターンをリアルタイム監視 し、即時遮断

  • PayPal側への働きかけ ・ ビジネスアカウント担当者 へ直接エスカレーション ・ APIログ・被害状況をまとめたレポート を提出し、再調査依頼 ・ 複数の被害者で共同して要望書提出 も有効

  • 法的措置・第三者相談 ・ サイバー犯罪対策窓口 や 弁護士相談 でアドバイス取得 ・ 業界団体やセキュリティコミュニティ で類似事例の共有・情報収集

  • ユーザー・出品者への注意喚起 ・ チャージバック被害の説明・注意喚起 ・ 不審な取引パターンの共有 と協力要請

類似事例・参考情報

  • 海外フォーラムやGitHub上でも同様のMultiparty API悪用事例 報告あり
  • PayPal Commerce Platform はマーケットプレイス型でチャージバックリスクが高いとの指摘多数
  • サードパーティの不正検知サービス （例：Sift, Riskified, Signifyd等）導入で被害減少の事例

まとめ・推奨アクション

  • 多層的なボット・不正対策 の強化が必須
  • PayPalへのエスカレーションと記録保存 を継続
  • 業界内の情報共有 と 第三者の専門家相談 も検討
  • 根本的な動機特定は困難 だが、被害最小化と再発防止策の徹底が重要

Hackerたちの意見

おそらく、盗まれた/ハッキングされたPayPalアカウントをテストしてるんだと思う。オーナーが何かおかしいとは気づかないように、まずは小さなトランザクションで争いを起こしてるんじゃないかな。残念ながら、PayPalではアカウントの所有権を確認する方法がないんだよね（3DSみたいな）。以前、私たちも似たようなことがあって、PayPayサポートと1年以上も誰が費用を負担するかで揉めた結果、結局PayPalの支払いを停止したよ。もっといい方法があればいいんだけど、ごめんね。

└

PayPal以外で、これらの問題がないサービスに切り替えたのは何？

└

手数料で「保証」(またはブロック)してくれるサービスってあるの？とにかく、これは支払いサービスの主な責任だよね！！商人に簡単に負担を押し付けるなんて、ちょっとおかしいよ。

└

アカウントの所有権を確認する方法がない（3DSのように） 3DSは2FAで、PayPalには確実にあるけど、顧客を保護するために2FAに関係なく対応してるんだよね。

└

数年前からオンライン決済に関わってないから、参考程度に聞いてほしいけど、同意するよ。PayPalは店舗にとって最悪の決済ソリューションかもしれない。サポートはひどいし、全然役に立たないし、アカウント管理は他の決済ソリューションと比べて非常に複雑だった。PayPalに関する私たちのルールは、毎日PayPalアカウントから全てを移動させること。彼らに資金を保持させないようにしよう。いつかアクセスをブロックされるから。彼らが触れることができる金額を最小限に抑えることも大事だよ。あと、小額の支払いにはPayPalを使わないように。これで、盗まれたアカウントの確認源として利用されるのを防げるから。私が関わった中で、同じレベルの無能さを持っていたのはKlarnaだけだった。Klarnaは当時、詐欺の概念を理解していなかった。スウェーデンだから、スウェーデンではほとんど詐欺を防いでいたからね。一度人々がそのシステムを突破して、Klarnaがスウェーデン以外に拡大したら、彼らは諦めて、私たちに請求しようとした。契約には彼らが支払いを回収する責任があると明記されていたのにね。

└

投稿を読んで最初に思ったのは「PayPalは使わない方がいい」ってこと。オンラインマーケットプレイスや複数の売り手、クレジットカードの取引とか…もう十分大変なのに、扱いがひどい業者に依存しちゃダメだよ。

自動チャージバックの悪用みたいだね。カードテストか、単に支払い/争いの仕組みを利用しようとしてるのかも。私たちも似たようなことに対処したことがあるよ。役立ったことをいくつか挙げると、 – ブラウザフィンガープリンティング（FingerprintJSとか、基本的なユーザーエージェント＋行動トラッキング） – フルヘッダーとTLSフィンガープリントをログに残す — IPは回転するけど、他のパターンが漏れることもある – 支払いフローに少しの摩擦を加える（軽いCAPTCHAやJSチャレンジなど） – タイミングパターンを見てみる — 自動化は厳密な間隔で動くことが多い PayPalのサポートは、型にはまったもの以外は遅いことで有名だから、merchanttechsupport@paypal.comにメールしてみて。エスカレーションされたケースでは、彼らの方が役に立つことが多いよ。こういうことは思っているよりも一般的で、特にデジタル商品を売っているプラットフォームではよくあることだよ。

ここにいる他のコメント者たちも、合理的な対策を提案してるね。一つアドバイスをすると、PayPalはリスクがあると見なした商人アカウントを容赦なくバンするから、早めに解決するか、別のPSPにすぐ切り替えられるように計画しておいた方がいいよ。たとえビジネスがバンされなくても、マルチパーティベンダー（適切な用語があれば教えて）も影響を受けるかもしれないから。

最近、似たようなことがあったよ。一部のIPアドレスはプロキシやデータセンターだったけど、そうじゃないのも多くて、ボットネットかもしれないと思った。ユーザーエージェントも一般的なものだったから、簡単にはバンできなかった。フィンガープリンティングとレートリミティングを追加したら、問題は解決したみたい。彼らは大量のアカウントやクレジットカード番号をテストしようとしてるから、最善の戦略は彼らを遅らせて、規模的に見合わないようにすることだね。

└

「住宅プロキシ」にアクセスを売ってる会社がたくさんあるよね。

└

今、ボットネットと戦ってるところなんだけど、彼らは自動的に適応して、呼び出しを信じられないほど多くのIPに分散させて、すべてCloudflareで良いJA4フィンガープリントを持ってたんだ（侵害されたか育成された「ユーザー」）。ブロックするものが何もなかったよ。高カウントのJA4をターゲットにして、一時的にそれをブロックし始めたんだ。これで、彼らは自動的に止まることが多かった。非常に洗練されたLLM対応のレンタルマフィアボットネットだった。攻撃のアプローチをいろいろ工夫して、こちらが圧力をかけると、彼らもそれに応じてきた。最終的には、認証フロー全体を再構築することになった。過去の誤った製品や管理の決定から、たくさんの匿名エンドポイントやカード番号を検証するエンドポイントがあったからね。最終的には、時々多くの正当なトラフィックをブロックしなきゃいけなかった。ユーザーの摩擦を減らすことは、スケールされたボット攻撃の摩擦も減らすから。

└

「サービス料」を設定すれば解決するんじゃない？取引するための返金不可の金額を。

これはマネーロンダリングの手口で、ドメインごとにどこまで行けるか試してるんだ。PayPalのAPIのバグも悪用していて、SDKがexample.comとwww.example.comを区別しないんだよね。もしあなたのようなウェブショップが悪用されてマネーロンダリングに使われたら、これらの2つのサブドメインからのトランザクションが混ざることになる。PayPalのサポートは、各ケースをきちんと扱わないほど頭が悪くて、後で他のソーシャルメディアサービス（例えば、アイテムを贈れるTikTokやSnapchatのストリーム）を通じてトランザクションを混ぜることもある。PayPalサポートのワークフローは、すべてのトランザクションを手動で識別しなきゃいけないから、人間が何週間も忙しくなるんだよ。本気で言ってる。こういう詐欺師がこういう手口で勝ち続ける理由だよ。通常、これをエスカレーションする方法もないし、ビジネス顧客でもPayPalのサポートオフィスの組織構造のせいで無理なんだ。対策としては、こういうことをすることが知られているホスティングのASNをブロックして、ウェブショップのバージョンを既知の脆弱性や修正のためにダブルチェックすることをお勧めするよ。もしまだDockerを使っていないなら、今すぐウェブショップソフトウェアを仮想化し始めて。これがどれだけ重要か、強調しておきたい。サービスに使っているユーザーやパスワード、VPSのファイルシステムのインジケーターもダブルチェックして。SSHパスワードを無効にして、VPSではSSHキー認証だけを使うようにしてね。これがまだ行われていない場合は特に。これを書いているのは、通常こういう手口はサーバーがすでに侵害された後に始まるからで、例えばSSHパスワードのブルートフォーススキャナーが成功したり、ウェブのエクスプロイト/持続性エクスプロイトが成功した後なんだ。もしボットネットに関連するネットワークをブロックするための出発点が必要なら、私はまさにこれを行うファイアウォールと詐欺データベースプロジェクトを始めたよ：[1] https://github.com/cookiengineer/antispam [2] https://github.com/tholian-network/firewall

└

初心者の質問でごめんだけど、Dockerってどうやってこの状況を改善できるの？今、DevOpsについて勉強中なんだ。

└

ここでのマネーロンダリングの部分を説明してくれる？

└

これはマネーロンダリングじゃないよ。MLだったら、なんで彼らが異議を唱えるの？

取引が人間から来ていると仮定すると、悪意のある行動を軽減しようとする期待がある場合、オートメーションよりも人に指示する方が安上がりなことが多いよ。悪意のある行動を防ぐために、一時的にサービスを停止する覚悟を持とう。本物の顧客がサービスを使い続けられるように、手動での作業をする必要がある。例えば、手動でアカウント承認を求めるとかね。これらのチャージバック取引は、ビジネスの運営能力に対するリスクとして扱うべきだよ。許可するたびに、ビジネスに対する永久的なダメージのリスクが増すから。PayPalのアカウントマネージャーに連絡してみて。これはフロントラインサポートを通すべきことじゃないよ。自分のアカウントを知っている人と話す必要がある。もしアカウントマネージャーがいないなら、作ってもらおう。もし作れないなら、PayPalと提携している不正防止の会社を探してみて。彼らがあなたの代わりにPayPalに直接連絡できるかもしれないよ。今後のために、サービスプロバイダーに依存しているなら、常に直接連絡できる人を持っておくべきだよ。プロバイダーがそれを提供しないなら、別のプロバイダーを探そう。特に金融サービスはリスクを嫌うから、ちょっとでも怪しい匂いがしたらアカウントを凍結することもある。たとえ防ごうとしたとしてもね。その回復にかかるコストは、今のうちに取るどんな対策よりも大きくなるよ。PayPalのアカウントを失うのは、数日間購入をオフにするよりも悪いから。

アカウントを未確認のバイヤーを拒否するように設定できるよ。https://www.paypal.com/us/cshelp/article/what-are-payment-re...

└

なんでこれがトップの回答じゃないの？

└

+1。サイドで言及されたように、これがコンバージョン率に悪影響を与えるよ。でも、永遠にそれを続ける必要はないし、少しの余裕を得るために使えるよ。攻撃者は、一時的にブロックされると興味を失ったり、もっと実りのあるターゲットに移るかもしれない。これはオンライン詐欺の「クマより速く逃げる必要はない」っていうダイナミクスだね。無限のターゲットがあって、攻撃者を完全に排除する必要はないから、彼らにとってROIが魅力的でなくなるようにすればいい。私のシナリオに関する考えは、1. チャージバックは単なる財政的な問題じゃない。マーケットプレイスだから、売り手の信頼を取り戻すために支払う金額はないし、決済プロバイダーとの条件を変えることもできない。2. メールが同じドメインから来るなら、そのドメインをブロックできる？使い捨てドメインはたくさんあるけど、攻撃者がそれを切り替えるのも手間だよ。3. CAPTCHAは、キャプチャ解決サービスやマルチモーダルAIの登場でますます効果が薄れてる。最近のいくつかの攻撃では、hCaptchaがTurnstileやreCAPTCHAよりも少し良いって聞いたよ。4. シャドウバンは、攻撃者の時間を無駄にするのに良い手段で、彼らのROIを殺すためには本当に重要だよ。ただし、実際の良い顧客を怒らせないように、誤検知率を低く保つ必要がある。5. 君のシナリオ（APIなし、ブラウザ必須、ボット活動が期待されない）は、適切に実装されたデバイスフィンガープリンティングに非常に適してる。私はStytchの詐欺とセキュリティのPMで、デバイスフィンガープリンティング製品もあるよ。オープンソースのものより試すのが難しいけど、攻撃者が実装を検査して回避することができないという利点がある。もっと話してみたい？今のコントロールを見て、デバイスフィンガープリンティングを試す価値があるかどうか、一緒に確認するのもいいよ。メールを送ってね（私のユーザー名の最初の文字）+（私のユーザー名の最後の4文字）@stytch.com。

ここでのスレッドは面白そうだったね。「アカウントを未確認のバイヤーを拒否するように設定できる」って。これに加えて、PayPal（またはAmazon）に依存する長期的なビジネスは築けないよ。ドメインに攻撃を仕掛けるのもいいかも。弁護士からの強い言葉のメールや、2つのドメインについてICANNに不正を報告することも考えてみて。

こういう注文は「保留」として扱って、最終的な支払いページにアクセスするためにSMSコードを要求するのもいいかも。こういう追加のステップがあれば、もし攻撃者の目的が特定のあなたを攻撃することじゃなければ、彼らを思いとどまらせるかもしれないよ。別の簡単なターゲットに移るだろうし。

（別の決済会社で働いてたけど、私はその会社を代表して話してるわけじゃないよ。）攻撃者の動機や意図を探るのが難しいね。私が考える最も可能性が高いのは、カードや認証情報のテストをしてるってこと。彼らは大量の盗まれた認証情報を盗んだり購入したりしてるんだ。それらの認証情報は、機能することが知られていれば個別に価値が高くなる。彼らは、何かを売ってるインターネット上のビジネスを使って、「ごめん、アカウント/カード/etc.に請求できなかったから、それは売れないよ。他のカードはある？」って言って、キャンセルされてない認証情報の山を素早く絞り込むんだ。別の攻撃のバリエーションとしては、「範囲内のすべてのカードを列挙して、実際に存在するカードを絞り込む」ってのもある。より価値のあるカードを見つけたら、それを別の攻撃者に高い値段で売ったり、実際にお金を得るためにカードや認証情報を攻撃する同僚に渡したりする。デジタルアイテムは、売る側が高い利益率を持っていて、詐欺に対する防御が低いから便利なんだ。安いもの、特に値段を自分で決められる安いものは、カードホルダーやその銀行の注意を引きにくいから便利。これが、チャリティが頻繁に悪用される理由の一つでもあるんだ。彼らは、たとえ最低の決済処理コストよりも価値が低い1ドル以下の寄付でも喜んで受け入れるからね。悪党たちは目立ちたくないんだ。なぜなら、実際の盗難は未来に起こるから。私が昔運営してた会社も、PayPalを使ってて、かなりイライラしたことがあった。私は、いくつかのヒューリスティックを追加して、それに合うユーザーには無料で商品を提供することで解決したんだ。成功した売上の場合に送られる通常のメッセージも一緒にね。これで、彼らが使おうとしている目的には、あなたのウェブサイトがすぐに役に立たなくなる。悪党たちは、混乱と後悔の30秒を経験した後、次のサイトに移動するんだ。昔は、悪党たちはブラウザのインスタンスを普通のユーザーのように見せるのがすごく下手だったから、データアクセスのパターンとかでね。少しでも役に立つことを願ってるよ。頑張って！最終的にはPayPalの注意を引くことができるかもしれないし、カードや認証情報のテスト攻撃を受けている場合には、選択肢があるかもしれない。でも、そうじゃないかもしれない。私自身は、問題を解決する前に成功しなかった。将来的にこの問題が起こる前に、モニタリングを構築することをお勧めするよ。紛争が起こる前に、これが起こっていることを知るためにね。紛争は、彼らから来ることもあれば、正当なユーザーから来ることもあるから、彼らが盗んだ認証情報によっては、まだすべての不正請求をキャッチしていないかもしれない。（「すべての請求」が争われたと言ってたから、言及しておくよ。）もし私が君なら、もっと広いネットを張って、予防的に返金したり、広いネットの中で見直したりすることを試みるよ。正しいことをするためでもあるし、例えば人々が月次明細を受け取るときに、もっと多くの紛争を未然に防げるかもしれないから。

└

ストライプでも同じ問題（盗まれたクレジットカード番号をテストする人たち）があって、特定のクレジットカード会社から切断されそうになったことがある。キャプチャを実装して、メールアドレスを検証するツール（emaillistverify）を使ったら、問題が解決したよ。

└

同意だね。こういう攻撃に対処するには、専用のセキュリティチームが必要だよ。実際の顧客に過度な負担をかけないようにしながら、攻撃を分類して対策を講じるのは簡単じゃないしね。支払い処理業者がこういう詐欺の最前線になるのも本来の役割じゃないし。ユーザーをリスクのバケットに分類するための指紋認証みたいな方法を見つける必要があるよ。で、そのバケットに応じて扱いを変えるんだ。例えば、ブラックホール、高負荷の確認、そしておそらく安全なユーザーの3つのバケットが妥当だと思う。Cloudflareにはボットを特定するためのツールがあって、かなりの部分を彼らに任せられるよ。