Qubole顧客に対するサプライチェーン攻撃

盗まれたベンダーキー1つで、全顧客のデータが流出：Quboleサプライチェーン攻撃の内部

サードパーティの侵害が複数の組織への侵入経路となり、Sentraが24時間以内にそれをどのように発見したか。

Sagy Drucker、Asaf Rozali、Riva Kranzとの共著

Sentraは最近、組織から組織へと広がる、非常に大規模なサプライチェーン攻撃を発見しました。数十社のQubole顧客が影響を受けました。攻撃者はビッグデータプラットフォームであるQuboleの認証情報を入手し、各社がかつてQuboleに付与したアクセス権限を利用して、静かにデータを引き出しました。これらの企業に直接侵入したわけではありません。攻撃者は、それらすべてが信頼していたベンダーを通じて侵入したのです。

［画像: 画像］

この種のリスクは見落としがちです。あなたのクラウドには、人間ではない多数のIDが存在します：ベンダー連携、自動化エージェント、AIエージェントなど、それぞれがデータへの常時アクセス権を持っています。ほとんどの日、それらは同じ場所から、同じスケジュールで、同じことを行います。危険なのは、そのうちの1つが何か別のことをし始めた日であり、それを監視しているチームは非常に少ないのです。

これらのうち最もリスクが高いのは、あなたが忘れてしまったものです。あなたがクラウドに接続したことのあるすべてのベンダーは、裏口を残しています。それらの裏口のほとんどはまだ存在し、信頼され、めったに監視されず、しばしば最も機密性の高いデータにアクセスできます。

Sentraはこのキャンペーンを検知し、Wizに報告しました。WizはSentraおよびMandiantと協力して調査を行いました。Wizは完全な調査結果を公開しています：Trusted by Default: Qubole Cross-Account Access Abused in the Wild。

この記事は、単一の企業の話ではありません。攻撃者がどのように侵入し、どのように移動し、何を狙い、最終的に何が露呈したのか、私たちが攻撃全体で目にしたことを記述します。

攻撃の概要

• 1回の攻撃で1ダース以上の組織がハッキングされた。すべて、かつてQuboleに付与したアクセスを通じて行われた。
• 各Qubole信頼ロールを引き受けるのに約1秒しかかからなかったため、攻撃者はほぼ瞬時に企業から企業へと移動できた。
• 約100のパスワードとキーが7分間で読み取られた。それらは3つの異なる場所に保存されており、さらに攻撃者がダウンロードしたファイル内には数千件の認証情報レコードが含まれていた。
• 書き込みアクションは0回。何も変更または削除されず、盗まれただけだったため、検知が困難だった。

忘れられたベンダーの信頼

攻撃者が使用した裏口は古いものでした。企業がQuboleの使用を停止した後もQuboleのロールは残っており、それらのロールは攻撃者が狙ったほぼすべてのデータにアクセス可能でした。

Quboleのロールは春以降、休眠状態でした。それから再び活動を始めました。Sentraはこのリスクを予見していました。攻撃に先立ち、Quboleのロールの1つが数ヶ月間未使用であるにもかかわらず機密データにアクセス可能であることを既に警告していました。

有効な認証情報、不正なネットワーク

この攻撃を受けた組織は不注意だったわけではありません。AWSの推奨通りにQubole連携を設定しており、追加のチェックとしてExternalId（ベンダーがアクセスする前に提示する必要があるコード）も含まれていました。すべてのQuboleロールにはそれが設定されており、攻撃者は毎回正しいコードを提示しました。AWSから見れば、攻撃者はQuboleそのものでした。

活動はQubole自身のネットワークからは一切行われていませんでした。すべてOVHサーバーとMullvad VPNから行われており、その期間中に通常のQuboleの活動は一切ありませんでした。すべてのセッションが攻撃者によるものでした。

それがサプライチェーン攻撃の危険な点です。信頼されたベンダーが侵害された場合、ベストプラクティスに従うだけでは不十分です。なぜなら、攻撃者のアクセスは本物であり、すべてのログで正当に見えるからです。それを阻止できるのは2つのことだけです。ゼロトラストは、各ベンダーを本当に必要なデータのみに制限するため、盗まれたキーは可能な限り少ない範囲しか開けません。そして、データ検出・応答（DDR）は、すべてのIDが実際にどのようにデータを使用しているかを監視し、信頼されたIDが攻撃者のように振る舞い始めた瞬間にフラグを立てます。この攻撃では、アクセスは有効に見えましたが、行動はそうではありませんでした。

静かにテストし、その後一掃

攻撃者はゆっくりと開始しました。彼らは、低価値のQuboleロールで盗んだ認証情報をテストし、静かに調査を行い、最初に数千件の顧客プロファイルファイルを盗みました。その後、急速に展開しました。数分以内に、すべてのQubole信頼ロールに侵入し、数日間にわたってバックグラウンドで実行されるバルクダウンロードを開始しました。最後のパスでは、異なるVPNアドレスから、本番データベースのバックアップを取得しました。

その後、活動は停止しました。信頼関係は依然として存在していたため、攻撃者はアクセスを失うことなく静かに潜伏しました。

攻撃者が認証情報を盗んだ方法

データの窃取だけでは十分ではありませんでした。私たちは、攻撃者がさらに多くのドアを開ける可能性のある認証情報を盗むために、いくつかの異なる技術を使用したのを目撃しました：

• Secrets Managerからシークレットを一括で取得： ソースコード、IDプロバイダー、CIおよびデータベースの認証情報、さらにはベンダー自身のトークンやExternalId。
• SSM Parameter Storeから復号化されたパラメータを読み取り： モニタリングおよびスキャナーエージェントキーを含む。
• Lambda環境変数を収集： 最初のアプローチがブロックされた際に、2番目のルートに切り替え。
• EC2ユーザーデータをスクレイピング： トークンやパスワードが隠されていることが多い起動スクリプト。

追跡方法

最初の作業は、漏洩したサンプルをSentraが既にスキャンしたデータと照合することでした。ファイル名だけでなく、ファイルの内容を比較しました。なぜなら、ファイル名は簡単に変更できますが、内容はそうはいかないからです。

数時間以内に、私たちはS3バケットの数個に絞り込みました。それらがソースであり、問題はより狭まりました：誰がそれらを読み取ることができたのか？

各ソースバケットには、サービスロール、管理者、シングルサインオンユーザー、自動化など、数百のIDがアクセス可能でした。1日でそれらすべてを追跡するのは現実的ではありませんでした。そこで、私たちは外部ID、つまり企業環境外からアクセスを信頼されているベンダー、ツール、パートナーなどに絞り込みました。次に、それらのうちどれが最も多くのソースバケットを読み取ることができたかをチェックしました。1つが際立っていました：Qubole。

データにアクセスできることが、実際にアクセスしたことを意味するわけではありません。そのため、各外部IDについて、そのアクティビティを自身の履歴と比較しました：いつ使用されたか、頻度、どのIPアドレスから、そして何を行ったか。すべてのベンダーは正常に見えましたが、1つを除いては。

少人数のチームが作業を分担し、それぞれがAIを使用して迅速化しました。私たちはすべての発見を1つのルールに当てはめました：証明されたか、または仮定されたか。そのルールは何度も私たちを救いました。初期の有力な手がかりは、書類上は強力に見えましたが、アクティビティログは、そのIDが一度も使用されていないことを示していたため、私たちはそれを却下しました。

何が盗まれたかの証明

攻撃者がデータにアクセスできることを知るだけでは十分ではありませんでした。影響を受けた各企業は、実際に何が盗まれたのかを知る必要がありましたが、これは証明するのが難しいことです。なぜなら、ほとんどのクラウドストレージはデフォルトで各ファイルの読み取りを記録しないからです。そのため、私たちは3つの場所から状況を把握しました。

1つ目は暗号化です。暗号化されたファイルがダウンロードされるたびに、クラウドはそのファイルを解除する必要があり、各解除はファイル名とともに記録されます。それらの記録を攻撃者のセッションと照合することで、どのファイルが持ち出されたかを確認できました。デフォルトの暗号化のみを使用するファイルはこのような痕跡を残さないため、実際の数はさらに多い可能性があります。

2つ目はシークレットそのものです。攻撃者が読み取ったすべてのパスワードとキーは、それ自身の記録を残し、変更すべきものの正確なリストを提供しました。

3つ目はファイルアクセスログです。有効になっていた場所では、攻撃者がダウンロードしたすべてのファイルを、IPアドレスとセッションとともに記録していました。ある企業の複数アカウントにわたるログは数百万ファイルに及び、暗号化されたバケットでは、ログは暗号化記録と正確に一致しました。

ここで、エージェント型のデータセキュリティプラットフォームが違いを生み出します。Sentraは、クラウド、SaaS、データウェアハウス、オンプレミス環境、AIシステム全体で機密データを継続的に発見・分類します。また、すべての従業員、サービスアカウント、AIエージェントと、それぞれがアクセスできるデータとのマッピングを行います。侵害後、時計は動き始めます：侵害通知の期限は72時間と短い場合があり、何が盗まれたかを解明するのに費やす1時間ごとに、封じ込めに費やせる時間が失われます。ログはどのファイルが触られたかを示すことはできますが、その中身までは示しません。Sentraは既に顧客のデータを発見・分類していたため、調査が始まる前に、個人情報、財務情報、認証情報が含まれる場所を把握していました。「何を失ったのか？」という問いは、数週間かかる可能性のあるものから、その日のうちに回答できるものへと変わりました。

その日のうちに実行すべき5つのアクション

その日の終わりまでに、私たちは各影響を受けた顧客に、証拠に裏付けられた5つの明確なアクションを提供できました：

1. Quboleを信頼しているすべてのロールから削除する。
2. 読み取られたすべてのシークレットをローテーションする。私たちは各シークレットの名前とログ内の場所を共有しましたが、値そのものは決して見ませんでした。
3. 攻撃者のIPアドレスをブロックする。
4. ログが期限切れになる前に保存する。
5. Quboleに通知する。

1つのベンダー、多数の標的

私たちが目撃したのは、特定の企業に固有のものではありませんでした。攻撃者はQuboleの認証情報を保持しており、それらの認証情報はQuboleをまだ信頼しているすべての組織へのドアを開きました。これは広範なキャンペーンであり、企業から企業へと移動し、数十社のQubole顧客に影響を与えました。

Sentraはどの組織が同じベンダーを信頼しているかを確認できるため、約1時間でQubole接続を持つすべてのSentra顧客をチェックしました。顧客環境全体で同様のアクティビティが確認されました。長らく使用されていなかったQuboleロールが、同じ時間枠で突然活動を再開し、私たちは影響を受けた各顧客に直接警告しました。

その後、私たちはこのキャンペーンをWizに報告し、WizとMandiantとの共同調査につながりました。彼らの調査は、同じ攻撃者が被害者環境を次々と迅速にスキャンしていることを示しています。

忘れたドアを閉める

一部のベンダーは、他のベンダーよりもはるかに機密性の高いデータにアクセスできます。それらが攻撃者の標的となります。それらのうちの1つが侵害されれば、それにアクセスできるすべてが失われます。まずそれらを見つけることから始めましょう：どの外部IDが顧客記録、財務データ、認証情報にアクセスでき、それぞれがどれだけアクセスできるか。

次に、ゼロトラストアプローチでそのアクセスを縮小します：各ベンダーは、今日の業務に必要なデータのみを受け取り、それ以上のものはありません。使用しなくなった連携については、完全に信頼を削除してください。なぜなら、休眠状態の特権を持つ外部ロールは、監視されるのではなく削除されるべきだからです。残りのロールについては、ベンダーが文書化した内容に権限を制限し、各ロールをベンダーの公開ネットワークアドレスに限定してください。このケースでは、漏洩したすべてのシークレットは、Quboleが全く必要としなかった権限から来ており、ネットワーク制限だけでも私たちが確認したすべてのログインをブロックできたはずです。

Sentraが行っているのはまさにこれです。どのベンダー、サービスアカウント、AIエージェントが最も機密性の高いデータにアクセスできるかを示し、過剰または未使用のアクセスにフラグを立て、攻撃者が悪用する前にそれを削減するのに役立ちます。そして、アクセスは常に変化するため、Sentraは監視を続け、突然異なる振る舞いを始めたベンダーは早期に検知されます。

Sentraが1ヶ月を1日に変えた方法

私たちはゼロから始める必要はありませんでした。だからこそ、調査は1ヶ月ではなく1日で済みました。Sentraは既に顧客の機密データを発見・分類していたため、盗まれたサンプルを数時間以内にそのソースにまで追跡できました。また、ベンダーを含む誰がそのデータにアクセスでき、それぞれがどれだけのことができるかをマッピングしていたため、数百の可能性のある容疑者が短いリストに絞られました。

Sentraは、何も起こる前にリスクをフラグ付けしていました：数ヶ月間使用されていなかったが、機密データにアクセスできるQuboleロール。そして、Sentraは各IDの通常の振る舞いを把握していたため、静かなベンダーロールが異なる振る舞いを始めた瞬間に攻撃者が際立ちました。

データが何であるかを知っていたため、各顧客に、データが存在する場所だけでなく、どのような種類の機密情報が公開されたかを伝えることができました。そして、Sentraはどの組織が同じベンダーを信頼しているかを知っているため、1人の顧客のインシデントは、リスクのある他のすべての顧客にとって早期警告となりました。

私たちはその後、この方法を再利用可能な調査スキルに変えたため、次のケースは空白のページからではなく、プレイブックから始まります。

サプライチェーン侵害を防止・軽減するための実行可能なコントロール

• 継続的な機密データ発見： すべてのクラウド、SaaS、データウェアハウス、AI環境全体で機密データを自動的に特定・分類します。
• IDとデータのマッピング： すべての従業員、ベンダー、サービスアカウント、AIエージェントと、それぞれがアクセスできる特定のデータ資産をマッピングします。
• 休眠アクセスの一掃： 攻撃者が悪用する前に、未使用、過剰、または忘れられたサードパーティ連携にフラグを立て、取り消します。
• リアルタイム異常検出（DDR）： アクセスパターンを監視し、異常なサードパーティの振る舞いを即座に検知してアラートを発します。
• 迅速なインシデント封じ込め： 事前に分類されたデータコンテキストを使用して、数週間ではなく数時間で侵害の影響を判断します。

完全な技術的詳細と侵害の兆候については、Wizの調査をお読みください。

今日、どの外部IDがあなたの機密データにアクセスできるかを確認したいですか？ 今すぐデモを予約してください。