摘要
SaaS 第三方服务商安全漏洞引发的供应链钓鱼攻击已经成为针对加密货币用户的重要威胁。2026 年 9 月邮件营销服务商 Brevo 因 SAML SSO 实现缺陷遭到攻击者利用，攻击者横向越权访问 138 家客户账号，借助合法邮件基础设施向硬件钱包、加密资产跟踪平台的订阅用户投放高度仿真钓鱼邮件，部分账号的联系人数据遭到批量导出，形成即时攻击与后续持续性威胁叠加的安全局面。本次攻击区别于传统仿冒域名钓鱼，邮件经由企业真实域名发出，常规邮件身份校验机制无法识别威胁，社会工程学文案结合加密行业专业技术叙事放大用户恐慌心理，显著提升攻击成功率。本文以 Brevo 安全事件作为研究样本，梳理攻击完整链路，剖析 SaaS 多租户架构身份授权边界缺陷、加密行业第三方外包服务安全治理短板、合法源钓鱼的检测困境、加密用户安全认知误区等多层问题。结合事件复盘结果，从 SaaS 服务商、加密行业机构、终端用户、安全技术能力四个维度，提出可落地的闭环防御思路。反网络钓鱼技术专家芦笛指出，供应链钓鱼攻击的本质不是单一漏洞问题，而是信任传递链条出现断裂，第三方服务商的安全缺陷会沿着业务合作关系传导至终端用户，传统边界防护手段对此类攻击存在明显防护盲区。研究对加密资产行业第三方 SaaS 供应链安全治理、定向钓鱼威胁处置具有现实参考价值。
关键词：供应链钓鱼；SaaS 多租户；SAML SSO；加密货币安全；网络钓鱼防御
1 引言
加密货币硬件钱包、链上资产统计平台的用户持有高价值数字资产，历来是网络攻击重点目标。传统攻击模式大多集中于恶意仿冒官方网站、伪造相似域名、恶意软件窃取私钥等路径，安全行业针对该类威胁已经积累较多检测与处置经验。伴随数字化业务发展，大量加密企业将邮件营销、客户通知、订阅管理等业务外包给第三方 SaaS 服务商，企业不再自主运维邮件发送系统，客户联系人名单、订阅用户邮箱全部存储在第三方多租户 SaaS 平台之上。业务外包能够降低企业运维成本，同时也引入全新的供应链安全风险：第三方服务商一旦发生安全故障，威胁会顺着合作链路直达终端客户，企业自身安全防护体系难以阻断来自上游服务商传导过来的攻击流量腾讯云开发...。
2026 年 9 月爆发的 Brevo 安全事件充分暴露这一类风险。攻击者没有直接入侵 Trezor、BitBox、CoinTracking 等加密企业的自有服务器，而是利用邮件营销服务商 Brevo 的 SAML SSO 授权实现漏洞，越权访问多家加密企业在 Brevo 平台内的租户账号，直接调用服务商邮件发送接口，使用企业真实域名向外发送钓鱼邮件。由于邮件从合法服务商基础设施发出，SPF、DKIM、DMARC 这类常规邮件身份验证全部校验通过，邮件能够直接进入收件箱，不会被垃圾邮件网关标记拦截。攻击者针对不同企业定制高度专业化社会工程内容，以硬件芯片重大漏洞、API 密钥必须紧急更新为叙事，制造紧迫的安全焦虑，诱导受害者下载恶意应用、提交钱包助记词、备份密钥等核心敏感信息。除了即时发起钓鱼投递，攻击者还从 43 个租户账号导出全部联系人数据集，这批数据可以被用于后续多轮持续性定向欺诈活动，威胁具备长尾效应。
当前网络安全研究领域，针对钓鱼攻击的研究多聚焦仿冒域名、终端恶意程序，针对 SaaS 供应链传导型钓鱼的深度案例分析相对有限，尤其缺少面向加密货币高价值用户场景下的完整攻防链路拆解。本次事件具备典型样本价值：攻击入口为身份认证协议实现缺陷，攻击载体是合法可信的邮件基础设施，攻击目标是资产敏感度极高的加密货币用户，威胁同时包含即时攻击和数据泄露带来的远期风险。本文立足于该事件完整事实，还原攻击全流程，逐层挖掘技术、管理、用户认知层面的安全短板，构建覆盖服务商、机构、用户的多层防御框架，不追求空泛的口号式对策，重点探讨如何截断 SaaS 平台向终端用户传导威胁的信任断裂环节。文中所有分析均基于事件公开披露信息展开，不做无依据推演。
2 Brevo 供应链钓鱼攻击事件全景还原
2.1 事件时间线与基础统计数据
事件发生于 2026 年 9 月，UTC 时间 9 月 10 日 06:30，Brevo 平台内部监测系统识别到异常安全事件，平台存在 SAML SSO 协议实现层面的授权边界缺陷。攻击者利用该缺陷完成跨租户越权访问。事件初期 Brevo 对外披露有 120 个客户账号遭到访问，事后完整事故复盘报告修正统计结果，一共有 138 个租户账号被攻击者非法获取访问权限。在全部被入侵账号当中，仅有 6 个账号被攻击者直接用来向外批量发送钓鱼邮件；43 个账号的联系人客户列表遭到攻击者导出下载；剩余 93 个账号没有观测到攻击者执行读取、导出、发送邮件等有实际危害的操作行为。
Brevo 在 CEST 时间 9 月 10 日上午 11 点 30 分完成漏洞封堵，切断攻击者访问路径，强制全部受影响会话下线。平台启动对受影响客户一对一通知流程，同步在状态页面对外发布安全通告。受到波及的加密企业包含硬件钱包厂商 Trezor、BitBox，链上资产统计服务 CoinTracking。其中 Trezor 受影响规模最大，总计 347000 名新闻通讯订阅用户收到伪造官方钓鱼邮件。攻击者发送的恶意链接在被关停之前，已经有两千多名用户完成访问操作。企业原有业务系统、钱包固件、后端数据库没有被直接入侵，威胁完全来源于第三方邮件服务商的安全故障。
2.2 攻击技术路径：SAML SSO 多租户授权边界失效
SAML SSO 是行业广泛使用的单点登录协议，作用是允许用户借助一套身份凭证访问多个不同业务系统，降低多平台账号密码管理负担。协议本身标准设计不存在安全缺陷，本次事故根源是 Brevo 平台在多租户架构下对 SAML 断言的权限范围实现存在逻辑错误，属于产品实现层面的漏洞，并非协议本身存在固有安全缺陷。
攻击者首先自行注册 Brevo 平台账号，在自建租户环境内部配置攻击者完全掌控的 SAML 身份提供商。之后攻击者向平台内真实合法用户发送组织邀请，诱导目标用户加入攻击者创建的恶意租户环境。正常设计逻辑下，用户通过攻击者管控的身份源完成 SSO 登录之后，权限应当严格限定在攻击者创建的租户空间，不允许跨越组织边界访问用户原本所属的其他租户资源。但是 Brevo 平台授权校验环节存在边界管控疏漏，登录会话没有被限制在当前恶意租户内部，会话获得了该用户原本具备全部访问权限，实现跨租户横向移动。依靠该逻辑缺陷，攻击者就能够访问到该用户关联的其他租户账号，最终获取到 138 家不同客户的 Brevo 租户操作权限。
拿到租户账号权限之后攻击者拥有两项核心能力：第一，调用平台邮件发送 API，使用企业真实域名、真实发件地址向该租户存储的全部联系人发送邮件；第二，导出租户内部保存的全部订阅用户邮箱数据集。这两个能力分别对应两类威胁：即时定向钓鱼投递，以及联系人数据外泄带来的长期风险。整个攻击流程当中，攻击者不需要破解用户密码，不需要绕过传统邮件网关，直接复用 SaaS 服务商合法发送链路，传统安全设备很难识别该类攻击行为。
2.3 针对加密行业的社会工程内容设计
攻击者针对不同加密企业，定制差异化高仿真钓鱼邮件文案，文案大量使用加密行业专业术语，提升内容可信度，同时刻意制造紧急、危机氛围，逼迫接收人快速行动，降低用户理性核验的可能性。
针对 Trezor 硬件钱包用户的钓鱼邮件标题为 “Critical Security Alert: STM32 Entropy Bug Identified”，副标题标注硬件微控制器存在紧急漏洞。邮件正文声称工程团队发现 Trezor 设备使用的 STM32 芯片存在硬件出厂缺陷，四分之一设备会在生成助记词时随机熵值不足，助记词种子可以被暴力破解，部分设备种子熵仅有 40 比特，同时提示部分 2023 年之前初始化设备以及少量新设备均受影响。邮件嵌入恶意链接，诱导收件人下载外部应用程序，并且在应用当中填写钱包助记词备份。硬件钱包核心安全逻辑就是助记词离线保存，一旦受害者按照提示提交备份，攻击者就能够远程窃取全部加密资产。
面向 CoinTracking 用户的钓鱼邮件主题为 “Data Breach Notice: Please refresh API Keys as soon as possible”，以数据泄露告警作为切入点，要求用户立刻更新 API 密钥，邮件附带恶意链接诱导跳转伪造页面。CoinTracking 业务依赖用户导入交易所 API 密钥读取资产数据，用户对 API 密钥安全告警具备天然的敏感性，社会工程攻击充分利用业务场景特征，进一步提升欺骗成功率。
值得注意，所有邮件发送源是企业真实域名，发件地址与日常官方通讯完全一致。普通用户通过查看发件人信息无法分辨真伪，传统的仿冒域名钓鱼识别手段全部失效。很多用户的安全习惯仅仅是核对发件人名称，在本次攻击场景下这套判别逻辑完全失效。
2.4 攻击带来双重威胁：即时欺诈与长期数据泄露风险
本次安全事件的危害分为两个层次，第一层是即时钓鱼攻击，6 个被入侵账号直接发送钓鱼邮件，接收人收到高仿真告警邮件，一旦点击链接下载恶意程序、提交助记词或者 API 密钥，数字资产会直接面临被盗风险。第二层风险来自 43 个账号联系人数据被批量导出，即便这部分账号没有被用来发送钓鱼邮件，订阅用户邮箱地址已经流出。攻击者掌握这批高质量目标数据集之后，可以在未来发起多轮钓鱼、邮件欺诈、垃圾推送等持续性攻击，威胁不会随着漏洞修补立刻消失，存在显著长尾效应。
事件当中加密企业自有核心业务系统没有遭到攻破，但是终端用户依旧遭受严重威胁，直观体现 SaaS 供应链安全传导效应。企业核心系统安全不等于客户安全，第三方外包服务的安全缺陷可以绕开企业边界防护，直接触达终端客户。
3 事件折射出的多维度安全问题剖析
3.1 SaaS 多租户架构下身份授权边界的治理缺陷
多租户 SaaS 平台将大量客户业务数据集中部署在同一套底层系统，租户之间逻辑隔离，物理层面共享基础设施。身份认证与授权模块是多租户安全隔离的核心基石。SSO 单点登录功能提升业务便捷度的同时，也放大权限管理风险。一旦会话的权限作用范围没有做好严格隔离，攻击者就可以借助一次身份登录实现跨租户越权访问，形成一破多损的后果。
从 Brevo 事件可以看出，部分 SaaS 服务商在产品开发阶段，对 SSO 跨组织邀请场景的权限边界测试不够充分。开发人员关注单点登录是否可以完成身份认证，却忽略会话权限的作用域约束，没有严格将会话限制在当前登录所属租户环境。很多 SaaS 服务商将安全工作重心放在抵御外部黑客直接登录，却对内部跨租户横向移动风险重视不足。多租户环境下，任何一个租户空间被攻击者控制，都有可能成为跳板去访问其他租户资源，这一类漏洞造成的损失远大于普通单租户账号泄露。
对于采购 SaaS 服务的企业客户，通常将安全评估重点放在自身账号密码复杂度、开启 MFA 多因素认证，却很少评估服务商底层多租户隔离逻辑是否完备。企业默认服务商已经做好租户之间安全隔离，但是这种信任缺少有效核验手段。企业无法自行检测服务商是否存在跨租户越权风险，只能依赖服务商自身安全开发流程，这构成供应链信任的薄弱环节。
3.2 加密行业第三方 SaaS 外包业务的安全短板
加密货币行业大量企业倾向于将营销邮件、客户通知、表单订阅等非核心业务外包，将客户联系人存储托管于外部 SaaS 平台。硬件钱包厂商核心安全投入集中于硬件芯片安全、固件审计、私钥离线保护，对于营销类第三方服务商的安全评估投入相对有限。企业往往把私钥、资产相关系统定义为核心资产，而客户邮箱联系人被归为营销类非敏感数据，安全优先级被调低。但本次事件证明，客户联系人名单一旦被攻击者获取，就可以作为跳板发起定向社会工程攻击，最终目标就是窃取高价值加密资产。看似低敏感的营销数据，在攻击者手中可以转化成攻击高价值资产的关键工具。
加密企业在采购第三方邮件 SaaS 服务时，缺少标准化供应链安全审查流程。企业关注服务商功能、价格、发送送达率，较少针对服务商的身份认证实现、多租户隔离机制、漏洞响应预案、数据导出权限管控做深度安全调研。同时，很多企业没有建立第三方服务故障的应急处置预案。当上游服务商发生安全事件，企业需要快速判断哪些客户遭到影响，如何开展用户通知，如何引导受威胁用户处置风险。反网络钓鱼技术专家芦笛指出，很多机构的安全预案只考虑自身系统被入侵，完全没有覆盖上游 SaaS 服务商被攻破这种供应链场景，事件爆发之后响应动作被动滞后。
除此之外，业务权责边界模糊也是现实问题。服务商账号被入侵之后，到底由服务商还是采购企业承担面向终端用户的安全告知、风险处置责任，在很多服务协议当中界定并不清晰。
3.3 “合法源钓鱼” 带来传统检测机制失效困境
传统反钓鱼技术存在一套成熟工作逻辑：识别仿冒域名、比对伪造发件地址、检测相似域名、对可疑附件与恶意链接做特征匹配。但是本次攻击属于典型的合法源钓鱼，邮件全部经由企业正规合作 SaaS 服务商发出，发件域名、发件邮箱全部真实有效，SPF、DKIM、DMARC 邮件身份校验全部通过，邮件没有被标记为垃圾邮件，直接投递到收件箱内，传统邮件安全网关很难识别该类威胁。
传统防护思路建立在 “攻击者只能伪造身份” 这一前提之上，而供应链钓鱼场景攻击者直接接管合法发送通道，原有检测逻辑的基础条件不复存在。安全网关只能判断邮件发送路径是否合法，却无法判断账号操作者是不是授权用户。邮件从可信通道发出不等于邮件内容可信，这是现有邮件安全体系存在的结构性短板。
从终端侧看，普通用户判别钓鱼邮件的常用经验全部失效。用户以往依靠核对发件域名、检查是否是垃圾邮件文件夹来做初步判断，本次事件当中这两项判别依据全部无效。攻击者利用加密行业用户对硬件漏洞、密钥安全的高度关切，使用专业技术叙事，制造紧急氛围，利用用户恐惧心理促使受害者跳过核验步骤直接执行操作。很多安全培训告知用户不要相信陌生发件人，却很少覆盖 “来自真实官方渠道的恶意消息” 这种复杂场景。
3.4 加密货币终端用户的安全认知误区
硬件钱包的核心安全理念就是助记词离线保存，绝不向任何线上应用、网页、邮件当中提交备份信息。但是在本次事件中，依然出现大量用户点击恶意链接访问钓鱼页面。从用户角度复盘，可以总结出几类典型认知误区。
第一，过度信任邮件来源。只要邮件显示为自己订阅的企业官方通讯，就默认内容全部可信，缺少二次核验习惯。用户没有建立独立渠道核验的意识，直接以邮件本身作为权威信息源。
第二，面对 “硬件致命漏洞” 这类紧急安全告警产生恐慌心理，情绪主导操作，放弃安全流程。攻击者文案刻意渲染危机，暗示设备资产随时面临被盗，诱导用户立刻执行操作，不要等待、不要去官网慢慢查阅公告。
第三，分不清 “第三方服务商被攻破” 和 “产品本身被攻破”。部分用户无法理解，硬件钱包产品本身没有漏洞，但是营销邮件服务商被入侵，依旧会收到官方域名发出的欺诈消息。用户固有的认知模型是产品被攻破才会收到欺诈通知，很难理解供应链传导的攻击路径。
第四，缺少标准化应急处置知识。很多用户不清楚正规加密硬件钱包服务商永远不会通过邮件索要助记词、种子备份，正规机构不会通过邮件链接引导用户下载外部程序输入钱包备份。这类基础安全常识的普及依旧存在缺口。
3.5 事件暴露出的威胁长尾处置难题
43 个账号联系人数据被导出，代表大量邮箱地址泄露。这部分数据外泄并不伴随当下的钓鱼邮件发送，属于静默式的数据泄露。企业很难知道这批数据流向何方，攻击者何时会再次利用这批数据集发起攻击。用户本身也无法知晓自己邮箱已经被导出，没有触发任何告警。传统安全事件处置，大多聚焦当下已经爆发的攻击行为，对于 “数据已经被导出但是尚未被利用” 这类长尾威胁，行业缺少成熟处置范式。企业很难针对每一位被导出的联系人进行通知，大规模通知又容易造成用户恐慌，甚至造成告警疲劳。如何平衡风险告知与避免过度恐慌，是供应链数据泄露场景下的现实难题。
4 面向 SaaS 供应链钓鱼攻击的多层闭环防御体系构建
针对 Brevo 事件暴露出的各类风险，不能依靠单一技术或者单一主体完成防护，需要 SaaS 服务商、采购 SaaS 的加密行业机构、安全技术能力、终端用户四个层面协同，构建闭环防御，切断威胁沿着供应链从服务商传导到终端用户的完整链路。
4.1 SaaS 服务商层面：加固多租户身份授权与权限管控
SaaS 服务商作为供应链攻击入口，是第一道关键防线。首先，在产品开发阶段针对 SSO 单点登录、跨租户组织邀请功能开展专项安全测试，重点验证会话权限作用域边界。任何通过外部身份源登录产生的会话，权限必须严格约束在当前租户空间，杜绝会话越权访问其他租户资源。多租户架构下的权限边界不能依赖业务逻辑的隐性假设，需要做显式权限隔离校验，把跨租户访问作为高危场景重点审计。
其次，完善账号异常行为检测体系。对于批量导出联系人、短时间内向数十万联系人批量发送邮件这类高风险操作，建立行为基线，一旦观测到租户账号发生超出历史习惯的数据导出、大规模邮件发送，立刻触发高等级告警，自动触发二次身份核验，必要时临时阻断操作。即便攻击者拿到账号登录权限，异常行为也会被实时识别，降低攻击成功概率。同时完整留存审计日志，记录账号登录来源、身份登录方式、数据导出记录、邮件批量发送记录，事故发生之后可以快速完成影响范围统计与复盘。
再者，完善漏洞应急响应机制。一旦确认发生越权入侵，第一时间切断攻击者会话，强制全部关联账号重新认证，快速完成漏洞修补。同时建立高效的客户通知通道，第一时间告知受影响客户，明确告知哪些账号被访问，哪些账号发生邮件发送，哪些账号发生数据导出，提供准确完整的统计数据，不能只给出模糊笼统的通告。最后，做好安全开发流程管控，将多租户隔离、SSO 权限校验纳入安全编码强制检查项，避免出现授权逻辑缺陷。
4.2 加密行业机构层面：完善第三方 SaaS 供应链安全治理
采购 SaaS 服务的加密企业，需要改变 “非核心业务服务商安全优先级偏低” 的思维。营销联系人名单虽然不属于私钥、资产数据库，但是一旦泄露就可以转化为针对高价值用户的攻击素材，应当纳入供应链安全管理范畴。
第一，建立第三方服务商安全准入评估流程。在采购邮件营销类 SaaS 产品之前，开展供应链安全调研。重点核查服务商多租户隔离安全控制、SSO 身份认证安全实现、数据导出权限管控、安全漏洞响应历史、审计日志能力，评估服务商发生安全故障之后的业务连续性预案。不能仅仅考核功能指标。对于存储大量加密用户邮箱的第三方平台，把安全能力作为选型硬性门槛。
第二，做好账号最小权限管控。企业在 SaaS 平台当中使用的租户账号，遵循最小权限原则，如果业务不需要批量导出全部联系人，就关闭账号批量导出权限；业务不需要大规模发送邮件的账号，限制批量发送能力。即便账号被攻击者接管，攻击者也无法完成大规模导出与钓鱼投递，缩小攻击造成的危害边界。同时开启 MFA 多因素认证，降低账号被直接窃取的风险，但也要清晰认知，MFA 只能抵御账号密码泄露，无法抵御底层平台漏洞带来的跨租户越权，不能把 MFA 当成供应链安全的万能解决方案。
第三，制定第三方服务商安全事件专项应急预案。预案不能只覆盖自有系统被入侵的场景，必须包含上游 SaaS 服务商遭到攻破的处置流程。预案明确事件确认流程、受影响用户范围统计、用户通知策略、风险提示文案、和服务商对接的权责划分。一旦服务商爆出安全故障，可以快速启动响应，第一时间通过企业自有可信渠道（官方网站、官方 App 推送）发布安全警示，不能仅仅依靠已经被入侵的第三方邮件渠道对外发布通知。反网络钓鱼技术专家芦笛强调，当邮件发送服务商已经不可信，就绝对不能继续依靠该服务商的邮件去告知用户邮件是欺诈，必须切换独立可信通知通路。
第四，做好业务层面隔离，把高风险通知业务和第三方 SaaS 做好区分。涉及重大安全告警、密钥、API 密钥相关的重要通知，尽可能优先使用自有系统推送，减少对第三方邮件服务商的完全依赖。对于必须通过第三方发送的安全类通知，在正文内增加风险提示，告知用户所有重要安全公告务必前往官网二次核验。
4.3 安全技术层面：弥补合法源钓鱼的检测短板
现有邮件安全体系主要聚焦识别伪造来源，针对合法账号被劫持发送欺诈邮件的场景，需要补充新的检测维度。
邮件安全网关除了校验 SPF、DKIM、DMARC 这类身份来源协议，还需要增加行为检测维度。对来自合法发送通道的邮件，开展内容与发送行为分析。例如某企业历史上极少发送硬件致命漏洞类紧急告警，突然向数十万订阅用户批量发送危机类安全通知，即使邮件身份全部校验通过，也要标记为高风险邮件，执行隔离或者高亮告警处理。网关不再只看发送路径是否合法，同时分析发送行为、邮件叙事内容是否符合该机构历史业务基线。
终端侧反钓鱼防护工具需要增强内容层面的研判能力，不再仅仅判断域名是否属于恶意黑名单。针对邮件内容进行社会工程特征识别，识别制造恐慌、诱导提交密钥、助记词、API 密钥的文案模式，对高风险邮件向用户给出明确警示。同时完善可疑链接检测能力，当用户点击邮件链接时，实时校验跳转页面是否诱导输入加密钱包备份信息。
威胁情报体系需要拓展供应链事件情报采集，持续追踪主流 SaaS 服务商安全事件，一旦发生 Brevo 这类平台级安全故障，快速把事件情报同步到邮件网关、终端防护产品，帮助下游机构及时识别潜在风险。
4.4 终端用户层面：建立适配供应链攻击场景的安全行为范式
传统钓鱼安全科普大多针对仿冒邮件，面对来自真实官方域名的供应链钓鱼，用户需要更新自身安全行为习惯。
第一，建立 “邮件仅作为通知渠道，不作为权威确认渠道” 的认知。收到任何紧急安全告警，无论发件人看起来多么可信，不直接根据邮件内链接操作。主动打开浏览器手动输入官方网址，或者打开官方 App，在企业自有官方渠道核对是否存在这条安全公告。无论邮件来源多么可信，关键操作永远走独立访问官方渠道完成，不点击邮件内部链接处理安全告警。
第二，牢牢记住加密行业基础安全底线：正规硬件钱包厂商、资产跟踪服务商永远不会通过邮件、外部网页、下载的第三方应用索要钱包助记词、种子备份。任何邮件要求填写恢复短语、钱包备份，无论内容描述多么紧急，都直接判定为欺诈行为。
第三，区分 “服务商被攻破” 和 “产品本身出现漏洞”。收到官方域名发出的可疑安全告警，不要立刻恐慌，先独立核验，不要被邮件渲染的紧急氛围裹挟而仓促操作。
第四，事故场景下的处置动作。一旦不慎点击邮件当中链接，并且输入过钱包备份信息，按照厂商指引，立刻将全部资产迁移到全新生成的钱包当中，旧钱包直接废弃。不要抱有侥幸心理。对于收到可疑钓鱼邮件但是没有点击链接的用户，保持持续关注官方公告，留意后续会不会出现更多定向欺诈邮件。
4.5 针对数据导出带来长尾威胁的处置策略
针对联系人数据被批量导出这种没有立刻爆发攻击的风险，需要兼顾风险告知与避免告警疲劳。企业首先需要明确区分两类受影响人群：一类是收到钓鱼邮件的用户，这类用户风险最高，需要第一时间充分告知；另一类仅仅是联系人被导出，没有收到钓鱼邮件。针对后者，不适合做大规模恐慌式推送，但需要在官网、社区公告当中明确披露该情况，告知相关邮箱有可能在未来收到定向钓鱼，提醒全体订阅用户提高警惕。同时企业可以建议用户做好邮箱别名、不同业务场景使用不同邮箱地址，降低单一邮箱泄露带来的影响。安全厂商持续跟踪泄露数据集在黑产圈流转情况，及时捕获基于这批数据发起的后续钓鱼活动。
5 事件带来的启示与行业思考
Brevo 供应链钓鱼攻击事件不是一次孤立安全事故，代表一类正在快速增长的威胁模式。攻击者不再执着于直接攻破目标企业自身防护体系，转而寻找企业依赖的第三方 SaaS 服务商作为突破口。只要找到供应链链条上的薄弱环节，攻击者就能够借助服务商的可信身份，绕开企业构建全部边界防御，直接触达海量终端客户。对于加密货币行业，该威胁模式具备极高的现实危害性：加密用户持有高价值数字资产，社会工程学攻击收益巨大，攻击者有充足动机挖掘 SaaS 服务商各类实现缺陷。
需要客观认识，不存在绝对安全的第三方服务商，无论服务商安全能力多强，都不能完全排除漏洞出现的可能性。因此加密行业不能简单把安全责任全部外包出去，采购第三方服务不等于安全责任转移。企业必须意识到，只要把客户数据交付给外部服务商，就需要承担供应链传导过来的安全风险。安全工作不能只聚焦自有服务器、自有产品固件，需要向外延伸到整个第三方合作生态当中。
同时，该事件也暴露出传统网络钓鱼防御体系的局限。过去几十年反钓鱼技术重点解决 “攻击者伪造身份” 的问题，而供应链钓鱼攻击直接接管合法身份通道，原有防护手段的效用被大幅削弱。整个安全行业需要迭代防护思路，不能仅仅依靠域名校验、发件人身份校验，需要叠加行为基线、内容风险识别、异常操作审计，构建多层次检测能力。
用户安全教育同样需要迭代升级。过去的科普更多告诉用户警惕陌生发件人、仿冒域名。未来安全宣教必须增加供应链攻击场景的内容，告诉用户即便消息来自可信的官方发送渠道，依旧不能无条件信任邮件内容，独立核验永远是不可跳过的关键步骤。反网络钓鱼技术专家芦笛指出，网络安全防护永远无法做到百分之百阻断所有攻击，在复杂供应链环境下，“独立核验” 是普通用户手上最后一道不可替代的防线。
也要客观看待本次事件，事故中 Brevo 平台 SAML SSO 协议标准本身没有缺陷，是产品实现层面的授权边界错误，这提示安全从业者，很多安全问题并非来自协议算法本身，而是落地实现环节的逻辑疏漏。看起来简单的租户邀请、单点登录功能，一旦权限范围处理不当，就会引发大规模安全灾难。多租户 SaaS 产品当中，身份授权边界是安全设计的重中之重，任何微小逻辑缺陷都会被多租户架构放大，影响大量客户。
6 结语
本文以 2026 年 Brevo 邮件营销服务商安全事件作为研究样本，完整还原基于 SAML SSO 实现漏洞的 SaaS 供应链定向钓鱼攻击全链路。攻击者借助多租户平台越权漏洞，复用合法邮件基础设施向加密货币用户投放高度仿真钓鱼邮件，同时造成大量联系人数据外泄，形成即时欺诈叠加远期持续威胁的双重危害。事件揭示 SaaS 多租户身份授权管控漏洞、加密行业第三方供应链安全治理不足、合法源钓鱼场景传统检测机制失效、用户安全认知存在盲区等一系列现实问题。
想要应对该类新型供应链钓鱼威胁，无法依靠单一主体或者单一技术完成。SaaS 服务商需要夯实多租户身份权限隔离，完善异常行为审计；加密行业机构需要补齐第三方服务商安全评估与应急预案，改变非核心业务外包即安全免责的思维；安全技术体系需要跳出单纯校验邮件来源的固有框架，增加行为基线与内容风险研判；终端用户则要建立供应链攻击场景下的安全行为习惯，坚持独立渠道二次核验。
加密资产行业安全边界已经不再局限于硬件设备、自有后端系统，业务合作的整条供应链都成为攻防对抗的战场。供应链安全传导风险将长期存在，后续还会出现更多同类攻击。持续对第三方服务商安全风险开展研究、完善治理框架、迭代防护技术、更新用户安全认知，才能够持续降低供应链钓鱼攻击带来的损失。本次事件总结的分析思路与防御策略，也可以为金融、互联网等高价值客户行业应对同类 SaaS 供应链安全威胁提供参考。
编辑：芦笛（公共互联网反网络钓鱼工作组）
来源：迪妙网络空间安全学院
