2025年8月8日から18日ごろにかけて、営業支援サービス Salesloft の Drift を Salesforce に連携していた多数の会社から、データが持ち出された。攻撃者が使ったのは、Drift が預かっていた OAuth トークンだった。Salesloft と Salesforce が Drift の有効なトークンをすべて失効させたのは2025年8月20日で、攻撃開始から12日かかった。
2026年6月12日には、競合分析サービスの Klue が、連携の仕組みで不正な動きを見つけた。ここでも Klue を外部サービスにつなぐ OAuth トークンが使われ、Salesforce を含む外部サービス上で、複数の顧客の環境のデータにアクセスされた。どちらも海外の事件だが、SaaS に外部サービスをつなぐ使い方は日本でも一般的で、守り方はそのまま使える。
自社に穴が無くても、合鍵で正面から入られる
Salesforce のような業務用の SaaS には、営業支援、チャット、競合分析などの外部サービスを「連携」でつなぐ。連携は OAuth という仕組みで、外部サービスに合鍵（トークン）を渡す形になる。この合鍵は、渡した先の会社が保管している。
渡した先が侵入されると、パスワードも多要素認証も通さずに、合鍵で自社の SaaS に正面から入られる。自社の設定に穴が無くても起きる。
Drift と Klue で何をされたか
Salesloft Drift（2025年8月）
Google Threat Intelligence Group（GTIG）は2025年8月27日に報告を出し、8月28日に更新した。GTIG は攻撃者を UNC6395 として追跡しており、攻撃者は Drift の OAuth トークンを使って各社の Salesforce に入った。読み出された対象には、問い合わせ（Cases）、取引先（Accounts）、ユーザー（Users）、商談（Opportunities）がある。
GTIG assesses the primary intent of the threat actor is to harvest credentials.
攻撃者の主な目的は、認証情報を集めることだと GTIG はみている。
出典: Google Threat Intelligence Group「Widespread Data Theft Targets Salesforce Instances via Salesloft Drift」
Google によると、攻撃者は書き出したデータの中から、AWS のアクセスキー（AKIA で始まるもの）、パスワード、Snowflake のトークンを探していた。問い合わせの記録に社員や顧客が貼り付けた鍵が残っていれば、それが次の侵入の材料になる。攻撃者は実行した問い合わせの記録を消したが、ログは残っていた。
8月28日の更新で、被害は Salesforce との連携にとどまらないと分かった。「Drift Email」の OAuth トークンも盗まれ、8月9日には、Drift と連携していたごく少数の Google Workspace のアカウントでメールが読まれた。Google は、Drift に保存された、またはつながったすべての認証トークンを、漏れた可能性があるものとして扱うよう求めた。
攻撃の開始から全トークンの失効までの流れを、図1に並べた。
2025年8月20日の失効と同時に、Salesforce は Drift を AppExchange から外した。ただ、連携先や SaaS 側の失効を待たなくても、自社でトークンを取り消せば、自社の分の合鍵はその時点で使えなくなる。
Klue（2026年6月）
Klue は2026年6月18日の発表で、6月12日に連携の仕組みの一部で不正な動きを見つけたと明らかにした。CEO の Jason Smith は、原因をこう説明している。
Our investigation determined that an attacker gained access through a compromised legacy credential associated with an integration service.
調査の結果、攻撃者は連携サービスに紐づく、漏れた古い認証情報を使って入ったと判明した。
出典: Klue「An update on recent Klue security incident」
攻撃者はそこから、Klue を外部のサービスにつなぐための OAuth トークンを手に入れた。それを使い、Salesforce を含む外部サービス上で、複数の顧客の環境のデータにアクセスした。古い認証情報がいつ、誰に、何のために発行されたものかは未公表だ。
Klue の環境に保存されていた顧客のデータには、影響した証拠は無いと同社は説明している（調査の途中経過）。Klue は、認証情報とトークンの失効、不正なコードの削除、影響の可能性がある連携の停止を行った。CrowdStrike など外部の専門家に調査を依頼し、警察にも通報した。
BleepingComputer の報道によると、Huntress は自社の Salesforce が影響を受け、取引先の連絡先、営業のやりとり、価格の情報などが盗まれたと公表した。Recorded Future、Tanium、Jamf なども影響を認めた。恐喝集団 Icarus が犯行を主張しているが、Klue はこれを認めていない。
全組織が今日やること: つないでいる外部サービスを書き出す
対象は Salesforce、Google Workspace、Microsoft 365、Slack など、自社で使っているすべての SaaS だ。台帳を作る、使っていない連携を外す、止める手順を決める、の3段で進める。
1. 連携の台帳を作る
- SaaS ごとに、連携している外部サービスを全部書き出す。社員に聞いて回るのではなく、各 SaaS の管理画面で連携の一覧を見て書き出す。
- 1件ごとに、サービス名、連携した人、渡している権限の範囲、最後に使われた日の4項目を記録する。
- 台帳は表計算1枚でよい。上の4項目に「止めるときに開く画面」と「止める担当者」を足して、6列にする。
- 連携した人が退職・異動している連携には印を付け、次の手順で優先して見直す。
2. 使っていない連携を外す
- 試験導入で一度つないだままの連携や、最後に使われた日が古い連携から外す。
- Klue の件は「古い認証情報」が入口だった。使っていない連携ほど、誰も見ていない合鍵になる。
- 使っている部署が分からない連携は、全社に1週間の期限を切って問い合わせ、返事が無ければ外す。
- 外すときは、その SaaS の側でトークンも取り消す。Salesforce での手順は次の章に書いた。
3. 連携先の事件に備えて、止める手順を決める
- 連携先が事件を公表したら、その日のうちにトークンを失効させる。連携先や SaaS 側の対応は待たない。
- Drift では、Salesloft と Salesforce がすべてのトークンを失効させるまで、攻撃開始から12日かかった。
- Google が Drift の件で求めたとおり、その連携先に保存した、またはつないだすべての認証トークンを、漏れた可能性があるものとして扱う。Drift Email のように、Salesforce 以外につないだ分も対象にする。
- 公表を見落とさないよう、台帳の連携先ごとに、セキュリティのお知らせを載せるページと、先方の担当窓口を書いておく。
- 失効させたら、その連携先につないでいた SaaS ごとに、次の章の「見張る」と、その次の章の「記録を検索する」を行う。
Salesforce の管理者が今日やること
図2は、Google の推奨と Salesforce の文書をもとに、管理者が設定で確かめる項目を並べたチェックリストだ。合鍵を減らす、範囲を狭める、見張る、の順に並べてある。
トークンを確かめて取り消す
- 設定の「OAuth Connected Apps Usage」の画面を開く。つながっているアプリと、使っている人数が一覧で出る。
- 台帳に無いアプリや使っていないアプリは、この画面でトークンを取り消す。
- 特定のユーザーの分だけ取り消すときは、ユーザーの詳細画面の「OAuth Connected Apps」から取り消す。
- Salesforce の文書によると、リフレッシュトークンは既定では取り消すまで無期限に有効だ。しばらく使っていない連携も、取り消しの対象にする。
- 取り消した後で困る部署が出たら、その時点で、必要な範囲だけに絞ってつなぎ直す。
連携アプリに渡す権限を最小にする
- 連携アプリに渡しているスコープを見直し、full のような広い範囲は避ける（Google の推奨）。
- スコープを狭められない連携は、台帳に理由を書き、次に見直す日を決めておく。
- 台帳の「渡している権限の範囲」の欄を、見直した結果に合わせて更新する。
入れる場所を絞る
- 連携アプリの IP の設定を「Enforce IP restrictions」にする。IP の制限を緩める設定にはしない（Google の推奨）。
- プロファイルに「ログイン IP アドレスの範囲」を設定し、信頼できるネットワークからだけ入れるようにする。
API を使える人を絞る
- 先に、「API Enabled」が付いている人を一覧にし、連携や自動処理で API を実際に使っている人を確かめる。
- 「API Enabled」の権限をプロファイルから外す（Google の推奨）。
- API が必要な人にだけ、権限セットで付け直す。
セッションを短くする
- 設定のセッション設定で、セッションのタイムアウトを短くする（Google の推奨）。
- 盗まれたセッションが使える時間を縮めるための設定だ。
見張る
- Event Monitoring で、連携アプリの認証の記録を見る。
- 実行された検索の記録（UniqueQuery のイベント）を見る。
- ふだんの1日あたりの書き出し量と時間帯を控えておき、それと違う量や時間帯の書き出しがあれば調べる（Google の推奨）。
- Drift の件では、攻撃者が問い合わせの記録を消しても、ログは残っていた。消された形跡があっても、ログ側を必ず確かめる。
入られた後に: 記録に残った「鍵」を探して消す
Drift の攻撃者は、書き出したデータの中から鍵やパスワードを探していた。連携先が侵入されたと分かったら、持ち出された可能性のある記録に何が書かれていたかを、自社で確かめる。その手順を図3にまとめた。
記録を検索する
- 問い合わせ（Cases）や取引先（Accounts）などの記録を、次の文字列で検索する（Google の推奨）。
- AKIA（AWS の長期アクセスキー）
- snowflakecomputing.com、Snowflake
- password、secret、key
- 自社の VPN や SSO のログイン URL
- コードや記録に残った秘密を探す道具として、Google は TruffleHog を挙げている。
- 見つかった記録は、記録の番号と、見つかった文字列の種類を一覧にして、入れ替えの担当者に渡す。
見つかった鍵は入れ替える
- 見つかった鍵やパスワードは、すぐに無効化して入れ替える。
- 記録から消すだけでは足りない。すでに書き出されている可能性がある。
- 入れ替えた鍵の一覧を残し、古い鍵が使われた形跡がないかを、その鍵の発行元のログで確かめる。
問い合わせ窓口の運用を変える
- 顧客や社員に、問い合わせの本文へパスワードや鍵を書かせない。問い合わせフォームと返信の定型文に、その旨を書いておく。
- 書かれていたら、受け取った側で伏せる。
- 上の文字列での検索は一度で終わらせず、月に1回など日を決めて繰り返す。
出典
- Google Threat Intelligence Group「Widespread Data Theft Targets Salesforce Instances via Salesloft Drift」（2025年8月27日初報、8月28日更新）
- Klue「An update on recent Klue security incident」（2026年6月18日）
- BleepingComputer「Klue OAuth breach victim list grows as Icarus hackers claim attack」
- Salesforce Developers 文書（Packaging Guide）: 接続アプリケーションの OAuth アクセスの管理
