Klue SaaS供应链OAuth令牌劫持实战复盘 企业云集成安全防御配置清单

一、事件全貌：9家安全厂商集体中招的供应链黑天鹅

6月12号暗网泄露站出现的一份名单，直接炸穿了海外安全圈。

Icarus勒索团伙公示了9家企业的受害证明，全是业内头部安全厂商——Recorded Future、HackerOne、Snyk、Huntress悉数在列。更讽刺的是，这些厂商的核心系统没被攻破，账号密码没泄露，MFA全程正常运行，攻击者只是偷了他们授权给第三方SaaS Klue的OAuth令牌，就直接堂而皇之进入了他们的Salesforce CRM。

这不是第一起SaaS供应链劫持事件，但第一次让这么多安全厂商同时栽在同一个环节。过去大家聊供应链安全，总盯着开源组件、云服务商底层，很少有人把“第三方应用OAuth授权”当成致命风险点。这次事件直接把这个盲区摆到台面上：你花几百万搭的身份安全体系，可能抵不过上游一个集成商的后台遗留账号。

整个事件的时间窗口非常短，前后不到48小时。

1. 6月11日凌晨，攻击者通过Klue内部遗留的集成后台账号，登入其后端服务节点。这个账号属于早期项目遗留，两年没人登录过，权限没回收，也没纳入常态化审计。攻击者拿到权限后没有直接动业务数据，先在服务器里植入了一段令牌采集脚本，定向扫描存储OAuth凭证的数据库表。当天白天，脚本跑完了全量客户数据，导出了所有生效的Salesforce OAuth访问令牌与刷新令牌。
2. 6月11日晚间到12日凌晨，攻击者用自动化脚本批量调用Salesforce API，遍历所有受害客户的CRM数据，按对象导出全量记录。单租户平均调用API次数超过1200次，全程没有触发任何一方的告警。
3. 6月12日上午，Icarus在暗网发布受害企业名单，同时向每家企业发送勒索邮件，要求支付比特币换取数据不公开。
4. 6月12日下午，Klue才通过内部异常流量监控发现入侵，紧急下线所有第三方集成，批量撤销所有OAuth令牌。此时数据窃取已经全部完成。
   后续陆续有更多企业披露受影响，除了9家安全厂商，还包括密码管理工具LastPass、保险科技公司Insurity等十余家企业。

Icarus是2026年4月才浮出水面的勒索团伙，和传统勒索软件团伙完全不同。他们不搞终端加密，不投病毒，专打SaaS供应链。

他们的作案逻辑非常清晰：找企业普遍在用的中间层SaaS服务商，拿下服务商后端，偷客户的OAuth令牌，直接拉取客户业务数据，然后勒索。全程走合法API通道，不留下门，不破坏系统，检测难度极高。

过去两个月他们已经攻击过3家中小型销售SaaS，只是客户名气不大，没引发行业关注。这次挑中Klue，就是因为Klue的客户群集中在科技、安全行业，企业付费能力强，数据敏感度高，勒索成功率高。

目前没有证据显示他们和其他知名勒索团伙有关联，技术风格偏轻量化，核心成员不超过5人，擅长云原生环境下的凭证窃取与API利用。

二、攻击链路拆解：一枚OAuth令牌如何绕开所有登录防护

图1 Klue OAuth令牌劫持攻击全链路流程图
（图示说明：完整呈现5个攻击节点——遗留凭证入侵后端→令牌库批量导出→刷新令牌换取访问凭证→Salesforce API批量拉取数据→暗网公示勒索，用不同颜色区分合法业务路径与攻击路径，标注每个环节的风险点）

整个攻击没有用到任何0day漏洞，全程走的都是合法业务路径。

第一步拿初始权限，靠的是Klue的内部管理疏漏。那个遗留后台账号用普通用户名密码登录，没有MFA，权限却能直接访问生产数据库。攻击者从暗网买到的账号信息，来源大概率是之前的员工泄露或者第三方外包商数据流出。

拿到后端权限后，攻击者没有碰业务前台，直接定位令牌存储库。SaaS集成商一般会把客户的OAuth令牌存在专门的数据库表中，和客户ID、授权范围绑定。Klue没有对令牌做字段级加密，只是做了基础的数据库访问控制。攻击者拿到数据库权限后，直接整表导出，前后花了不到20分钟。

拿到令牌之后的步骤最关键。很多人以为OAuth令牌有有效期，偷了也没用。但SaaS集成场景下，厂商为了保证服务不中断，几乎都会申请offline_access权限，拿到永久有效的刷新令牌。只要有刷新令牌，就能随时换出新的访问令牌，权限和最初授权的完全一致。

攻击者写了一套Python脚本，先拿刷新令牌换访问令牌，再调用Salesforce的REST API，先枚举所有可访问的sObject对象，再按对象批量查询数据。查询的都是标准接口，请求头里带的是合法的Klue应用令牌，IP地址用的是海外住宅代理，Salesforce的风控系统根本识别不出来。

整个数据窃取过程，攻击者不需要知道任何企业员工的账号密码，不需要绕过MFA，不需要碰企业的防火墙。他们拿的是企业主动授予第三方的合法身份，走的是企业主动开放的API通道。

这也是这次事件最打脸的地方。很多企业花大价钱做身份安全，给所有员工账号开MFA，做异地登录检测，堵死了账号被盗的所有路径。结果转头给第三方SaaS开了个直通CRM的后门，还把钥匙全交给对方保管。

三、底层逻辑：SaaS OAuth集成为什么成了重灾区

图2 第三方SaaS OAuth 2.0授权架构与劫持对比图
（图示说明：左侧为正常授权流程：企业管理员授权→Klue获取令牌→Klue调用API同步数据；右侧为劫持流程：攻击者窃取Klue存储的令牌→攻击者直接调用API→绕过所有企业侧登录防护，标注两种模式下的权限控制点差异）

很多人对OAuth的认知停留在“用微信登录第三方网站”，觉得这是个安全的登录方案。但企业级SaaS集成里的OAuth，和消费级场景完全不是一回事。

消费级OAuth授权的是用户个人身份，有效期短，权限有限。企业级SaaS集成里，管理员授权的是整个租户的访问权限，权限范围极大，而且为了保证数据同步不间断，基本都会申请长期有效的刷新令牌。

正常的流程是这样的：企业管理员在Salesforce里安装Klue的连接应用，勾选需要授权的数据范围，点击确认。Salesforce会给Klue返回授权码，Klue用授权码换回访问令牌和刷新令牌，存在自己的服务器里。之后Klue每次要同步数据，就拿刷新令牌换新的访问令牌，调用API读写数据。
这个流程本身没有设计缺陷，问题出在落地环节。

第一个问题是令牌集中存储。

所有客户的令牌都存在Klue自己的数据库里，相当于把上千家企业的CRM钥匙串都挂在自己腰上。Klue自己安全做得好就没事，一旦被攻破，所有客户集体失守。这就是典型的供应链单点风险。

第二个问题是权限过度授权。

绝大多数企业管理员安装集成应用的时候，不会仔细看权限范围，直接点全量授权。Klue本来只需要读取客户的竞争情报相关字段，实际拿到了整个CRM的读写权限。攻击者拿到令牌之后，能拉走所有数据，连合同附件都能下载。

第三个问题是令牌生命周期缺失。

大部分SaaS集成的刷新令牌是永久有效的，企业不主动撤销，令牌就一直能用。Klue自己也不会主动轮换客户令牌，很多令牌从客户安装集成那天起就没换过，用了三四年的都有。

第四个问题是API访问风控缺失。

不管是Klue还是Salesforce，都没有针对单应用的异常访问做基线检测。正常情况下Klue每天只会在固定时间同步一次数据，单租户API调用量不超过100次。攻击者半夜拉数据，单租户调用上千次，全程没有触发任何告警。

这四个问题凑到一起，就酿成了这次大规模供应链事件。而且这不是Klue一家的问题，是整个SaaS集成行业的通病。你随便去查任何一家做CRM集成的SaaS厂商，十家有八家都是这么干的。

四、受害厂商泄露详情：到底丢了哪些核心数据

这次公布的9家安全厂商，受损程度不一，核心业务数据基本都没碰，丢的全是CRM里的销售和客户数据。

Recorded Future是受影响最严重的一家。他们的CRM里存了全量客户信息、销售线索、合同报价，还有部分威胁情报的客户需求记录。攻击者拉走了过去三年的所有客户对象数据，大概十几万条记录。Recorded Future已经发了正式通知，告知所有客户信息泄露风险，同时安排了免费的信用监控服务。

HackerOne的泄露范围集中在企业客户侧。他们的白帽用户数据存在独立系统，没有接入Salesforce，所以没受影响。泄露的主要是企业付费客户的联系方式、合同信息、漏洞赏金项目合作记录。HackerOne已经撤销了所有Klue的授权，正在审计API访问日志确认具体泄露范围。

Snyk的情况类似，泄露的是销售端的客户数据，开源漏洞库、产品核心数据完全没碰。他们在公告里特意强调，客户的代码仓库信息、漏洞扫描数据都存在独立系统，和CRM物理隔离，没有泄露风险。

Huntress、Tanium、Jamf三家终端安全厂商的受损范围基本一致，都是客户联系方式、销售工单、合同信息。三家都在事件爆发后12小时内断开了Klue集成，完成了令牌轮换。

OneTrust作为数据合规厂商，这次中招格外尴尬。他们的CRM里存了大量客户的合规项目信息，包括部分企业的数据泄露事件处置记录。目前他们正在逐一通知受影响客户，同时接受监管机构的问询。

Gong和Sprout Social不属于纯安全厂商，但也都是科技行业知名SaaS服务商，泄露的同样是销售侧客户数据。

除了名单上的9家，LastPass的波及最受关注。很多人第一反应是密码库泄露了，其实没有。LastPass明确说明，用户的密码库、主密钥、所有加密存储的数据都存在独立的零知识架构系统里，和CRM完全隔离。这次泄露的只有销售和客服部门的工单数据、客户联系方式，不涉及任何用户密码信息。

目前所有受害厂商都没有公开支付赎金的消息，Icarus也还没有公开泄露具体数据内容。

五、企业应急实操：发现集成Klue后的处置步骤与检测脚本

如果你们公司也在用Klue或者同类第三方集成SaaS，现在立刻做四件事，别等官方通知。

1. 第一步，先去你的SaaS后台，找到已授权的第三方应用列表，直接撤销Klue的所有授权。不管有没有泄露，先断通路。令牌一旦泄露，只要没撤销，攻击者随时都能回来再拉数据。
2. 第二步，拉取过去7天的第三方应用API访问日志，重点查非工作时间的批量查询请求、单小时API调用量超过日常基线3倍以上的记录。只要有异常，基本就是数据被拉过了。
3. 第三步，盘点授权给Klue的权限范围，评估可能泄露的数据字段。如果只授权了只读的联系人对象，泄露范围就很小；如果授权了全对象读写，就要做好全量客户数据泄露的预案。
4. 第四步，通知相关客户和监管部门，按数据泄露合规要求走流程。不要存侥幸心理，勒索团伙说有数据，基本就是拿到了，早通报比被动曝光好。

Salesforce全量OAuth授权查询脚本

下面这段SOQL可以直接在Salesforce Developer Console里执行，查出当前租户所有已授权的第三方连接应用、授权时间、权限范围、最后访问时间。

SELECT Id, ConnectedApplication.Name, ConnectedApplication.DeveloperName, User.Name, Profile.Name, Scope, CreatedDate, LastUsedDate, IsRevoked FROM OAuthToken WHERE IsRevoked = false ORDER BY LastUsedDate DESC

执行后先筛LastUsedDate超过90天没访问的应用，直接撤销。再逐个核对每个应用的Scope字段，只要出现full、api之外的多余权限，立刻去收窄。

API异常访问批量检测脚本

这段Python脚本可以批量拉取过去7天的REST API访问日志，自动统计每个连接应用的调用次数、访问IP、操作对象，标记异常调用。

fromsimple_salesforceimportSalesforcefromcollectionsimportdefaultdictfromdatetimeimportdatetime,timedeltaimportcsv# 配置Salesforce连接信息，建议使用只读权限的集成用户SF_INSTANCE_URL="https://your-domain.my.salesforce.com"SF_ACCESS_TOKEN="your-access-token"SF_API_VERSION="v59.0"defget_api_event_logs(days=7):sf=Salesforce(instance_url=SF_INSTANCE_URL,session_id=SF_ACCESS_TOKEN,version=SF_API_VERSION)start_time=(datetime.now()-timedelta(days=days)).strftime("%Y-%m-%dT%H:%M:%SZ")soql=f""" SELECT EventDate, ConnectedAppName, UserId, User.Name, ClientIp, Operation, EntityName, RowsProcessed, RequestUri FROM EventLogFile WHERE EventType = 'API' AND EventDate >={start_time}ORDER BY EventDate DESC """result=sf.query_all(soql)returnresult['records']defanalyze_anomaly(logs):app_stats=defaultdict(lambda:{"call_count":0,"ips":set(),"entities":set(),"off_hour_calls":0})forloginlogs:app_name=log.get('ConnectedAppName','Unknown')ifnotapp_name:continuestats=app_stats[app_name]stats['call_count']+=1stats['ips'].add(log.get('ClientIp'))stats['entities'].add(log.get('EntityName'))event_hour=datetime.strptime(log['EventDate'],"%Y-%m-%dT%H:%M:%S.%fZ").hourifevent_hour<6orevent_hour>22:stats['off_hour_calls']+=1anomaly_apps=[]forapp,statsinapp_stats.items():is_anomaly=Falsereason=[]ifstats['call_count']>500:is_anomaly=Truereason.append(f"7天调用量{stats['call_count']}次，超出基线")ifstats['call_count']>0andstats['off_hour_calls']/stats['call_count']>0.3:is_anomaly=Truereason.append(f"非工作时间调用占比{round(stats['off_hour_calls']/stats['call_count']*100,1)}%")iflen(stats['ips'])>5:is_anomaly=Truereason.append(f"访问IP数量{len(stats['ips'])}个，存在分散访问特征")ifis_anomaly:anomaly_apps.append({"app_name":app,"call_count":stats['call_count'],"ip_count":len(stats['ips']),"reason":"; ".join(reason)})returnanomaly_appsif__name__=="__main__":logs=get_api_event_logs(days=7)anomalies=analyze_anomaly(logs)print(f"共检测到{len(anomalies)}个存在异常的第三方应用：")foriteminanomalies:print(f"-{item['app_name']}:{item['reason']}")withopen('salesforce_oauth_anomaly_report.csv','w',newline='')asf:writer=csv.DictWriter(f,fieldnames=['app_name','call_count','ip_count','reason'])writer.writeheader()writer.writerows(anomalies)print("异常报告已导出为 salesforce_oauth_anomaly_report.csv")

使用前先安装依赖：pip install simple-salesforce，替换配置里的实例地址和访问令牌。建议用只读权限的集成用户运行，避免额外权限风险。

批量撤销可疑应用令牌脚本

如果确认某个应用的令牌泄露，用下面这段脚本批量撤销该应用所有已发放的令牌，比手动删效率高很多。

fromsimple_salesforceimportSalesforce SF_INSTANCE_URL="https://your-domain.my.salesforce.com"SF_ACCESS_TOKEN="your-access-token"SF_API_VERSION="v59.0"# 替换为目标应用的开发者名称TARGET_APP_DEV_NAME="Klue_Battlecards"defrevoke_app_tokens():sf=Salesforce(instance_url=SF_INSTANCE_URL,session_id=SF_ACCESS_TOKEN,version=SF_API_VERSION)soql=f""" SELECT Id, UserId FROM OAuthToken WHERE ConnectedApplication.DeveloperName = '{TARGET_APP_DEV_NAME}' AND IsRevoked = false """tokens=sf.query_all(soql)token_ids=[t['Id']fortintokens['records']]ifnottoken_ids:print("未找到该应用的有效令牌")returnprint(f"找到{len(token_ids)}个有效令牌，开始批量撤销...")# Salesforce单批操作最多200条，分批处理foriinrange(0,len(token_ids),200):batch=token_ids[i:i+200]batch_requests=[{"method":"DELETE","url":f"services/data/v{SF_API_VERSION}/tooling/sobjects/OAuthToken/{tid}"}fortidinbatch]sf.restful('tooling/composite/batch',method='POST',data={"batchRequests":batch_requests})print(f"已完成{len(token_ids)}个令牌的撤销操作")if__name__=="__main__":revoke_app_tokens()

六、长效防御配置清单：从根源堵死OAuth供应链风险

应急只是止损，真正要防住这类攻击，得从流程和配置上把漏洞堵上。下面这套配置清单，直接套用到Salesforce、微软365、飞书、企业微信所有支持OAuth集成的平台都能用。

令牌生命周期管理

很多SaaS平台默认刷新令牌是永久有效的，一定要手动改。Salesforce里可以在连接应用设置里调整刷新令牌策略，把刷新令牌有效期设为30天，过期必须重新授权。访问令牌有效期保持1-2小时，不要延长。

不要允许offline_access权限之外的长期令牌申请。所有第三方应用申请令牌的时候，必须校验权限范围，没有特殊需求的一律不给刷新令牌权限。能走实时授权的就不要用长期令牌。

建立令牌自动轮换机制。核心业务系统的第三方集成令牌，每15天自动轮换一次，不用等过期。轮换过程不用中断业务，旧令牌保留24小时过渡期，保证同步任务不报错。

权限最小化裁剪

这一步能把泄露后的损失降到最低。

绝对不要给第三方应用全量API权限。安装集成的时候，逐字段核对授权范围，只给应用实际需要的对象和字段。比如竞争情报工具只需要客户公司名称和行业字段，就别给联系方式、合同金额这些敏感字段。

能用只读权限就绝对不给读写权限。大部分集成工具只需要读取数据，不需要修改，直接锁死只读权限。就算令牌被偷，攻击者也只能看数据，不能篡改或者删数据。

按数据分级做授权。核心敏感数据对象，比如合同、财务、员工信息，禁止任何第三方应用访问，单独做接口白名单。普通业务数据可以开放给集成工具，敏感数据走单独的审批流程。

日志审计与异常检测

这是最后一道防线。

所有第三方应用的API访问日志必须全量采集，保留至少90天。日志里必须包含应用名称、操作人、IP地址、操作对象、请求行数、请求时间这些字段。

设三条基础告警规则，直接就能拦住90%的批量窃取：

单应用单小时API调用量超过日常基线3倍，触发告警。正常集成工具的调用量非常稳定，突然飙升基本就是有人在批量拉数据。

非工作时间出现第三方应用的批量查询操作，触发告警。大部分企业的同步任务都在工作时间跑，半夜拉数据大概率有问题。

第三方应用出现从未使用过的IP段，触发告警。集成工具的服务器IP都是固定的，突然出现住宅IP、机房代理IP，基本就是令牌泄露了。

不要依赖SaaS厂商的自带风控，他们的告警阈值设得非常松，等他们发现的时候数据早就被拉完了。自己搭一套日志检测规则，比什么都靠谱。

第三方SaaS准入审计

从源头筛掉风险高的厂商。

新接入第三方SaaS之前，必须做安全评估，重点查三个点：令牌怎么存、有没有加密、会不会定期轮换。

要求厂商提供令牌存储方案，必须是字段级加密，密钥单独管理，不能和业务数据存在同一个库。不能提供的直接pass，不管产品多好用。

要求厂商支持令牌自主轮换，企业可以随时主动轮换令牌，不需要厂商配合。不支持的直接pass。

要求厂商有完善的内部权限管控，后台账号必须有MFA、有生命周期管理、有操作审计。拿不出证明的直接pass。

不要觉得这是小题大做，你给对方开的是核心业务系统的访问权限，和把办公室钥匙交给外人没区别。准入的时候严一点，比出事之后救火强得多。

僵尸凭证常态化清理

堵死最容易被忽略的入口。

每个季度做一次全量第三方应用盘点，把超过90天没访问的应用直接撤销授权。很多公司装了一堆集成工具，用了两次就不用了，授权一直挂着，全是风险点。

同步清理内部的集成后台账号、服务账号。这类账号最容易被遗忘，权限又高，是攻击者最喜欢的入口。所有服务账号必须纳入统一身份管理，定期轮换密码，开启MFA，设置自动过期。

离职员工、外包人员的账号，离职当天必须全量回收，包括所有第三方系统的账号权限。很多遗留账号都是这么来的。

以下是可直接落地的OAuth安全配置基线模板：

# 企业第三方OAuth集成安全配置基线 v1.0# 适用平台：Salesforce / Microsoft 365 / 飞书 / 企业微信token_lifecycle:access_token_ttl_hours:2# 访问令牌有效期，最长不超过2小时refresh_token_ttl_days:30# 刷新令牌有效期，最长不超过30天auto_rotation_days:15# 自动轮换周期，核心系统不超过15天allow_offline_access:true# 是否允许离线访问，按需开启permanent_token_forbidden:true# 禁止永久有效令牌permission_control:default_permission:read_only# 默认权限为只读full_access_approval_required:true# 全量读写权限必须走审批sensitive_object_whitelist:# 敏感对象白名单，默认禁止第三方访问-Contract-Opportunity.Amount-User.Phone-User.Emailfield_level_security:true# 启用字段级权限控制logging_and_detection:log_retention_days:90# 日志保留天数baseline_call_alarm_threshold:3# 调用量超基线倍数触发告警off_hour_alarm_enabled:true# 启用非工作时间告警new_ip_alarm_enabled:true# 启用陌生IP告警log_export_enabled:true# 日志全量导出到SIEMvendor_access:token_encryption_required:true# 要求厂商字段级加密存储令牌mfa_for_vendor_admin:true# 厂商后台管理员必须开启MFAvendor_audit_cycle_months:6# 厂商安全审计周期idle_app_revoke_days:90# 闲置应用自动撤销天数

这套基线可以直接导入到你们的IAM系统或者SaaS管理平台里，作为所有第三方集成的统一准入标准。

七、行业前瞻：OAuth供应链攻击的演化方向

这次Klue事件不是孤立事件，是SaaS供应链攻击演化的必然结果。

过去三年，勒索团伙的攻击路径一直在变。最开始直接打企业终端，加密硬盘。后来打企业邮箱，偷数据勒索。现在开始往上走，打中间层SaaS服务商，一次攻击就能拿下几十上百家企业。

成本越来越低，收益越来越高，检测难度越来越大。

接下来这类攻击会往三个方向演化。

第一个方向是覆盖更多平台。

现在主要打Salesforce生态，接下来微软365、Google Workspace、国内的飞书企业微信都会成为目标。这些平台的第三方应用生态更庞大，授权更不规范，很多企业连自己装了多少应用都不知道。

第二个方向是瞄准AI Agent集成。

现在企业都在接各种AI助手、AI销售、AI客服，给这些AI应用开的权限都特别大，很多直接授权了全邮箱、全CRM读写权限。这些AI服务商的安全能力参差不齐，一旦被攻破，后果比这次严重得多。

第三个方向是攻击链更隐蔽。

现在攻击者还是直接批量拉数据，容易被发现。以后他们会做低频慢速窃取，每天拉一点数据，拉长攻击周期，完全融入正常业务流量里，更难检测。

对于国内企业来说，不要觉得这是海外的事，和自己没关系。国内SaaS行业的令牌管理水平比海外还差，很多厂商连令牌加密都做不到。只是现在攻击者还没盯上国内市场，一旦盯上，爆出来的事件只会更严重。

现在很多企业聊零信任，都在讲员工身份、终端安全，很少有人把第三方应用身份纳入零信任体系。实际上第三方应用的风险比员工账号高得多。员工账号有MFA，有行为检测，有离职回收。第三方应用的令牌挂在那里几年没人管，权限还特别大。

未来的企业身份安全，必须把第三方应用身份和员工身份放在同等重要的位置。统一授权、统一审计、统一管控，做到授权必审批、访问必留痕、异常必告警、闲置必回收。

不然下一次供应链事件爆发，中招的可能就是你。

1. 你们公司做过全量第三方OAuth应用盘点吗？目前有多少个活跃的第三方集成授权？
2. 你认为SaaS服务商是否应该为OAuth令牌泄露事件承担主要责任？