サイバー犯罪データ取引フォーラムで公開されたデータ漏洩により、659件の加盟店アカウントに紐づくStripeの実稼働用APIクレデンシャルと、顧客・決済関連データ約35GBが流出しました。
今回の流出は、42カ国の加盟店にまたがる推定68万8363件の顧客記録に影響していますが、これまでに得られている証拠によれば、Stripe自体のインフラが侵害されたわけではないとみられています。
このデータセットは2026年8月18日、「Satanic」と名乗るフォーラム出品者によって投稿され、販売ではなく無料ダウンロードという形で公開されました。
Ransomnewsは公開前にこの資料をオフラインで確認し、Stripeに通知した上で調査結果を公表したとしています。
独自の取材でも、今回のキャンペーンはStripeのプラットフォーム自体が侵害されたのではなく、加盟店側の機密情報が流出した事案であると説明されています。
流出したデータは1万7654個のファイルにまたがり、顧客、料金請求、支払いインテント、Checkoutセッション、請求書、支払い、残高取引、返金、異議申し立て、サブスクリプション、商品、価格情報など、StripeのAPIエンドポイント経由でエクスポートされたデータが含まれています。
データセット内の記録は2022年1月4日から2026年6月1日までの範囲に及ぶとされています。
フォーラムの出品情報には、Stripe自体がハッキングされたかのような誤解を招く記載がありました。しかし、報告されている証拠は、Stripeを決済処理に利用している個々の事業者に属するクレデンシャルが盗まれた、あるいは流出したことを示しています。
データセットのメタデータによると、573件のアカウントが決済の受け取りが可能であり、531件が支払い出金が可能で、519件は両方が可能だったとされています。
Stripeのシークレットキーは、加盟店アカウントへのプログラムによるアクセスを提供するため、影響の大きいクレデンシャルです。
有効化されている権限やAPIバージョンによっては、攻撃者が顧客データを列挙したり、取引記録を取得したり、料金請求を作成したり、返金を発行したり、決済ワークフローを改変したり、場合によっては出金先を変更したりできる可能性があります。
セキュリティ研究者は、リポジトリやCI/CDのログ設定ファイルに残されたキーが、決済詐欺やアカウント悪用に直結しかねないと繰り返し警告してきました。
セキュリティコンサルティングサービス
影響を受けた加盟店のうち最も多かったのは米国で212件、次いで英国が81件、フランスが57件、カナダが38件、ブラジルが30件、オーストラリアが27件だったとされています。
Ransomnewsは、流出したキーを使ってStripeへの認証を行ったり、加盟店のシステムにアクセスしたり、個々の顧客記録を閲覧したりはしていないとしています。代わりに、データセットの内部構造を評価したとのことです。
出品者「Satanic」は、投稿数779件、評価スコアは2,000近くという、フォーラム内で実績のあるアカウントです。
Ransomnewsの研究者らによれば、掲載された659件のクレデンシャルのうち、650件はsk_live接頭辞で始まる実稼働用のシークレットキーであり、残る9件は制限付きキーだったとされています。収集者が作成したインデックスでは、収集時点で全キーが有効であるとマークされていました。
Stripe加盟店のAPIキー659件
これらのファイルには、実稼働用APIの出力と一致するStripeオブジェクト識別子が含まれていたとされ、cus_接頭辞の顧客ID、ch_接頭辞の料金請求ID、pi_接頭辞の支払いインテントID、acct_接頭辞のアカウントID、cs_live_で始まる実稼働用CheckoutセッションIDなどが確認されています。
決済方法設定用のpmc_、請求書明細項目用のil_、異議申し立て用のdu_、Setup Intent用のseti_といった、より稀な識別子も含まれていたとされています。
注目すべき点として、このダンプにはクレジットカード番号全体は含まれていないようです。カードオブジェクトには、ブランド、下4桁、有効期限、資金源の種類、発行国、支払いフィンガープリントといった、Stripe APIが通常返すトークン化されたメタデータが含まれていました。
これにより、影響を受けた顧客のプライバシーおよび詐欺リスクは軽減されるものの、完全になくなるわけではありません。
このデータセットからは、659件のクレデンシャルがどのように入手されたのかは特定されていません。考えられる経路としては、開発者のデバイスから収集された情報窃取マルウェアのログ、公開リポジトリにコミットされたAPIキー、露出した.envファイル、設定ミスのあるクラウドストレージ、コンテナイメージ、CI/CDのログ、安全性の低いバックアップなどが挙げられます。
今回の事案は、公開されたAPIキーと、フル権限を持つシークレットキーとの運用上の違いを浮き彫りにしています。ソースコードから流出したキーは大規模に有効性を検証でき、その後、API経由でアクセス可能なデータを組織的に抽出するために使われる可能性があります。
この問題に関するより広範な報道では、公開コードリポジトリ、GitHub Actionsのログ、設定ミスのあるWebサーバーが、Stripeのシークレット情報が流出する典型的な経路として指摘されています。
影響を受けた事業者の多くは、自社のキーが流出したことにまだ気づいていない可能性があります。加盟店は、すべての実稼働用シークレットキーを直ちにローテーションし、Stripeダッシュボードのセキュリティおよびアクセスログを確認し、出金設定やリンクされている銀行口座情報に不正な変更がないか点検する必要があります。
セキュリティコンサルティングサービス
組織はまた、可能な限り、権限を広く持つシークレットキーの使用を、スコープを絞った制限付きキーに置き換えるべきです。
シークレット情報はサーバー側にのみ保持し、フロントエンドのコードに埋め込むことは絶対に避け、Gitの履歴、ビルドログ、コンテナのレイヤー、ドキュメントからも削除しなければなりません。
制限付きキーは、権限をその連携機能が本当に必要とするAPI操作のみに限定できるため、被害を抑える上で役立ちます。
セキュリティチームにとって優先すべきは、クレデンシャルの発見です。リポジトリ、CI/CDパイプライン、環境変数ファイル、クラウドストレージ、エンドポイントのテレメトリ、情報窃取マルウェアの流出情報フィードをスキャンしてStripeのクレデンシャルを洗い出し、流出が確認されたキーはすべて失効させて再発行してください。
[ライブウェビナー] Elastic社とUnderDefense社が開催するこのセッションでは、小規模なセキュリティチームがAIの可視性とエージェント型対応を一つの運用モデルに統合する方法を紹介します。 -> 今すぐ登録
翻訳元: https://gbhackers.com/659-stripe-merchant-api-keys/
