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

发布时间：2026/6/26 20:22:26

一、事件全貌9家安全厂商集体中招的供应链黑天鹅6月12号暗网泄露站出现的一份名单直接炸穿了海外安全圈。Icarus勒索团伙公示了9家企业的受害证明全是业内头部安全厂商——Recorded Future、HackerOne、Snyk、Huntress悉数在列。更讽刺的是这些厂商的核心系统没被攻破账号密码没泄露MFA全程正常运行攻击者只是偷了他们授权给第三方SaaS Klue的OAuth令牌就直接堂而皇之进入了他们的Salesforce CRM。这不是第一起SaaS供应链劫持事件但第一次让这么多安全厂商同时栽在同一个环节。过去大家聊供应链安全总盯着开源组件、云服务商底层很少有人把“第三方应用OAuth授权”当成致命风险点。这次事件直接把这个盲区摆到台面上你花几百万搭的身份安全体系可能抵不过上游一个集成商的后台遗留账号。整个事件的时间窗口非常短前后不到48小时。6月11日凌晨攻击者通过Klue内部遗留的集成后台账号登入其后端服务节点。这个账号属于早期项目遗留两年没人登录过权限没回收也没纳入常态化审计。攻击者拿到权限后没有直接动业务数据先在服务器里植入了一段令牌采集脚本定向扫描存储OAuth凭证的数据库表。当天白天脚本跑完了全量客户数据导出了所有生效的Salesforce OAuth访问令牌与刷新令牌。6月11日晚间到12日凌晨攻击者用自动化脚本批量调用Salesforce API遍历所有受害客户的CRM数据按对象导出全量记录。单租户平均调用API次数超过1200次全程没有触发任何一方的告警。6月12日上午Icarus在暗网发布受害企业名单同时向每家企业发送勒索邮件要求支付比特币换取数据不公开。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现在立刻做四件事别等官方通知。第一步先去你的SaaS后台找到已授权的第三方应用列表直接撤销Klue的所有授权。不管有没有泄露先断通路。令牌一旦泄露只要没撤销攻击者随时都能回来再拉数据。第二步拉取过去7天的第三方应用API访问日志重点查非工作时间的批量查询请求、单小时API调用量超过日常基线3倍以上的记录。只要有异常基本就是数据被拉过了。第三步盘点授权给Klue的权限范围评估可能泄露的数据字段。如果只授权了只读的联系人对象泄露范围就很小如果授权了全对象读写就要做好全量客户数据泄露的预案。第四步通知相关客户和监管部门按数据泄露合规要求走流程。不要存侥幸心理勒索团伙说有数据基本就是拿到了早通报比被动曝光好。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_URLhttps://your-domain.my.salesforce.comSF_ACCESS_TOKENyour-access-tokenSF_API_VERSIONv59.0defget_api_event_logs(days7):sfSalesforce(instance_urlSF_INSTANCE_URL,session_idSF_ACCESS_TOKEN,versionSF_API_VERSION)start_time(datetime.now()-timedelta(daysdays)).strftime(%Y-%m-%dT%H:%M:%SZ)soqlf SELECT EventDate, ConnectedAppName, UserId, User.Name, ClientIp, Operation, EntityName, RowsProcessed, RequestUri FROM EventLogFile WHERE EventType API AND EventDate {start_time}ORDER BY EventDate DESC resultsf.query_all(soql)returnresult[records]defanalyze_anomaly(logs):app_statsdefaultdict(lambda:{call_count:0,ips:set(),entities:set(),off_hour_calls:0})forloginlogs:app_namelog.get(ConnectedAppName,Unknown)ifnotapp_name:continuestatsapp_stats[app_name]stats[call_count]1stats[ips].add(log.get(ClientIp))stats[entities].add(log.get(EntityName))event_hourdatetime.strptime(log[EventDate],%Y-%m-%dT%H:%M:%S.%fZ).hourifevent_hour6orevent_hour22:stats[off_hour_calls]1anomaly_apps[]forapp,statsinapp_stats.items():is_anomalyFalsereason[]ifstats[call_count]500:is_anomalyTruereason.append(f7天调用量{stats[call_count]}次超出基线)ifstats[call_count]0andstats[off_hour_calls]/stats[call_count]0.3:is_anomalyTruereason.append(f非工作时间调用占比{round(stats[off_hour_calls]/stats[call_count]*100,1)}%)iflen(stats[ips])5:is_anomalyTruereason.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__:logsget_api_event_logs(days7)anomaliesanalyze_anomaly(logs)print(f共检测到{len(anomalies)}个存在异常的第三方应用)foriteminanomalies:print(f-{item[app_name]}:{item[reason]})withopen(salesforce_oauth_anomaly_report.csv,w,newline)asf:writercsv.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_URLhttps://your-domain.my.salesforce.comSF_ACCESS_TOKENyour-access-tokenSF_API_VERSIONv59.0# 替换为目标应用的开发者名称TARGET_APP_DEV_NAMEKlue_Battlecardsdefrevoke_app_tokens():sfSalesforce(instance_urlSF_INSTANCE_URL,session_idSF_ACCESS_TOKEN,versionSF_API_VERSION)soqlf SELECT Id, UserId FROM OAuthToken WHERE ConnectedApplication.DeveloperName {TARGET_APP_DEV_NAME} AND IsRevoked false tokenssf.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):batchtoken_ids[i:i200]batch_requests[{method:DELETE,url:fservices/data/v{SF_API_VERSION}/tooling/sobjects/OAuthToken/{tid}}fortidinbatch]sf.restful(tooling/composite/batch,methodPOST,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有行为检测有离职回收。第三方应用的令牌挂在那里几年没人管权限还特别大。未来的企业身份安全必须把第三方应用身份和员工身份放在同等重要的位置。统一授权、统一审计、统一管控做到授权必审批、访问必留痕、异常必告警、闲置必回收。不然下一次供应链事件爆发中招的可能就是你。你们公司做过全量第三方OAuth应用盘点吗目前有多少个活跃的第三方集成授权你认为SaaS服务商是否应该为OAuth令牌泄露事件承担主要责任