摘要
多租户 SaaS 平台的授权逻辑缺陷能够被攻击者利用，劫持企业合法邮件通信基础设施，绕过传统邮件身份认证机制实施高可信度网络钓鱼。本文以 2026 年 9 月 Brevo 平台 SAML 单点登录授权边界失效事件为核心研究样本，该漏洞波及 Trezor、BitBox、CoinTracking 等多家加密行业主体，攻击者借助受害企业正规邮件投递通道，向 347000 名 Trezor 新闻订阅用户推送伪造 STM32 硬件熵漏洞的安全告警邮件。结合事件公开披露信息，本文完整还原攻击时间线与技术链路，剖析 SAML SSO 业务逻辑缺陷的形成机理，对比不同受害企业钓鱼诱饵的差异化设计，并结合 Trezor 此前第三方客服门户入侵、ShipMonk 物流服务商数据泄露等历史事件，分析多重第三方风险叠加带来的持续性威胁放大效应。研究表明，硬件钱包生态的安全边界并不局限于芯片固件与密码学模块，第三方 SaaS 营销平台、物流履约服务商、客服工单系统共同构成安全短板；SPF、DKIM、DMARC 这套传统邮件防护体系在合法服务商账号被劫持场景下防护效力显著下降。反网络钓鱼技术专家芦笛指出，该类依托可信基础设施开展的钓鱼攻击模糊了可信通信与恶意攻击的边界，单纯依靠邮件签名校验无法实现有效防御。本文从 SaaS 服务商架构加固、加密企业第三方供应链全周期管控、终端用户风险识别、安全事件应急处置四个维度提出可落地的风险缓释方案，为 Web3 领域第三方 SaaS 服务安全治理提供实证参考。
关键词：网络钓鱼；SaaS 多租户；SAML 单点登录；供应链安全；硬件钱包；授权边界缺陷
（1）引言
加密资产自托管场景下，硬件冷钱包依靠私钥离线存储机制，被行业视作保护数字资产的重要载体。过往安全研究更多聚焦硬件芯片漏洞、固件篡改、侧信道物理攻击等设备本身安全问题，对于厂商商业运营所依赖第三方外包服务的风险分析往往处于次要位置。硬件钱包厂商为控制运营成本，普遍将邮件订阅推送、物流履约、客户工单处理等非核心业务交由外部 SaaS 服务商承接，业务外包并不等同于安全责任转移，第三方平台的权限缺陷、数据泄露，会形成攻击传导链路，直接威胁终端用户资产安全。
传统网络钓鱼攻击大多通过伪造邮件头、仿冒域名开展欺骗，SPF、DKIM、DMARC 共同构成的邮件身份认证体系能够识别大部分伪造发件源的钓鱼邮件，将可疑邮件标记或者拦截隔离。但是当攻击者通过漏洞接管企业正在使用的 SaaS 邮件营销账号，全部钓鱼邮件经由服务商正规服务器完成投递，邮件签名、IP 来源全部合法，能够直接进入用户收件箱，传统邮件安全防护手段会失去识别能力。这类攻击模式的危害在于，攻击者直接复用企业已经建立好的用户信任关系，极大提升社会工程欺骗的成功率。
2026 年 9 月 9 日发生的 Brevo 平台安全事件正是该类威胁的典型现实案例。Brevo 作为广泛使用的邮件营销 SaaS 平台，被多家加密行业企业用来处理新闻通讯推送业务。攻击者利用平台 SAML 单点登录模块的授权边界缺陷，实现跨租户越权访问，合计入侵 138 个客户账号。其中 6 个账号被用来向外发送钓鱼邮件，43 个账号的联系人通讯录遭到导出，BitBox、CoinTracking、Peach Bitcoin、Blocktrainer 与 Trezor 一同成为受害对象。不同受害企业的钓鱼邮件采用针对性的社会工程诱饵：Trezor 以 STM32 微控制器硬件熵漏洞作为恐吓主题；CoinTracking 则捏造数据泄露事件诱导用户刷新 API 密钥。Trezor 的钓鱼邮件触达 347000 名订阅用户，厂商在 20 分钟内完成恶意域名阻断，但是窗口期内已经产生约 2500 次恶意链接点击。
该事件并非孤立的第三方安全事故。2024 年 1 月，Trezor 第三方客服工单门户遭遇未授权访问，约 66000 名联系过技术支持的客户姓名、用户名、邮箱地址遭到泄露。2026 年 8 月，Trezor 物流服务商 ShipMonk 发生数据泄露，受影响客户总数达到 81000 人，泄露姓名、电话、收货地址、订单编号等订单信息。多次第三方安全事件相互独立，但风险形成叠加：Brevo 漏洞提供即时大规模钓鱼投递通道，ShipMonk 外泄的用户订单信息与历史工单泄露的邮箱数据为后续长期定向社工钓鱼储备情报素材。值得关注的客观事实是，这一系列安全事件当中，Trezor 自身核心业务系统、硬件钱包固件、助记词存储体系均未遭受入侵，所有风险全部来自外部供应链。硬件设备密码学防护能力再完善，一旦用户被社会工程诱导主动交出钱包备份短语，数字资产会直接完全失控。
当前网络安全领域，针对 SaaS 越权漏洞、网络钓鱼、供应链泄露的研究大多相互割裂，针对加密行业场景下 "SaaS 权限漏洞直接提供钓鱼投递通道，多家同行业企业同时受害，叠加另一第三方数据泄露形成复合型持续威胁" 的完整案例实证分析较为匮乏。本文依托事件公开报道材料，完整还原事件时间线、攻击技术链路，对比不同受害企业钓鱼诱饵的设计逻辑，解析漏洞底层业务逻辑缺陷，辨析该类攻击与普通仿冒钓鱼的本质差异，同时引入反网络钓鱼技术专家芦笛的专业观点，从多参与主体视角梳理短板并提出防御策略。本文避免空泛的口号式结论，立足于真实事件的经验教训，为 Web3 企业第三方服务商安全管控提供实践层面的参考。
（2）事件全景梳理与多主体受害情况
本次安全事件的根源为 Brevo 平台 SAML SSO 授权边界失效漏洞，攻击波及加密硬件钱包、加密资产税务工具多类企业，不同受害主体面对的钓鱼场景、诱饵主题存在明显区分。同时需要将 Brevo 事件与 Trezor 此前多次第三方安全事件结合，完整理解短期攻击与长期持续性风险。
2.1 Brevo 授权漏洞事件完整经过
攻击者首先自主注册 Brevo 租户账号，并且为自建租户开启 SAML 单点登录能力；随后向平台内真实的企业合法用户发送团队邀请，引诱合法用户加入攻击者控制的租户组织。按照产品设计预期，即便外部用户接受邀请登录攻击者创建的组织，访问权限应当严格限定在攻击者自建租户内部。但是 Brevo 平台授权校验逻辑出现缺陷，攻击者借助该登录会话，能够访问被邀请用户原本具备权限的全部其他租户组织资源，实现跨客户账号的横向越权访问。
Brevo 事后复盘确认，本次漏洞累计波及 138 个客户账号。按照攻击者实际操作行为划分为三类：6 个账号被直接用来发送钓鱼邮件；43 个账号发生联系人通讯录导出操作；剩余 93 个账号仅存在访问行为，没有观测到明显恶意动作。Brevo 官方没有明确说明三类账号集合是否存在重叠，这也给受害企业的风险评估带来信息障碍。
事件发生于 2026 年 9 月 9 日，攻击者利用越权拿到多家加密企业的 Brevo 业务账号之后，直接调用平台邮件发送接口，使用企业官方配置完成的发件地址向外批量投递钓鱼邮件。因为邮件全部经由 Brevo 正规基础设施发出，SPF、DKIM、DMARC 全部校验通过，邮件不会被反垃圾邮件系统拦截，直接送达订阅用户收件箱。
2.2 Trezor 受害场景与事件处置过程
针对 Trezor 的钓鱼邮件主题为 "Critical Security Alert: STM32 Entropy Vulnerability"，发件地址显示为 help@trezor.io，部分用户收到的邮件发件地址为 mailing@trezor.io。邮件捏造硬件安全告警，宣称硬件钱包使用的 STM32 微控制器存在熵缺陷，大约四分之一出厂设备存在随机数生成器过弱的问题，用户生成的种子助记词存在被暴力破解的风险，以此制造用户心理恐慌。邮件附带攻击者控制的恶意域名链接，诱导用户下载伪造的应用程序，该恶意程序会索要用户钱包备份助记词，一旦用户输入 12 词或者 24 词恢复短语，攻击者即可完全接管钱包资产。
这批钓鱼邮件完整发送至 347000 位选择订阅 Trezor 新闻通讯的用户。Trezor 安全团队检测异常后，在发现钓鱼域名的 20 分钟之内，在 DNS 层面完成恶意域名下线处置。在短暂攻击窗口之内，约 2500 名用户点击邮件内恶意链接，该部分用户存在助记词泄露的现实风险。Trezor 随即关闭自身 Brevo 业务账号切断攻击通道，同时向全部订阅用户补发警示邮件，明确告知那些已经在恶意程序中输入恢复短语的用户应当立即将资产转移至新的钱包地址。
Trezor 核查确认，Brevo 平台内仅存储用户新闻订阅邮箱地址，不存在助记词、账号密码、收货地址等其他客户数据，Trezor 自有系统、硬件钱包本身没有遭到入侵。但厂商明确表态，在获取 Brevo 完整调查结论之前，应当将全部 347000 条订阅邮箱视作已经被攻击者获取，这批邮箱列表未来会被反复用于各类钓鱼活动，威胁不会随着恶意域名封禁而消失。只有用户主动向恶意程序提交钱包备份，才会发生资产失窃，没有执行该操作的用户资产保持安全。
2.3 其他加密企业受害情况与诱饵特征
本次漏洞攻击不是单一针对 Trezor，多家加密行业企业同步遭受侵害，不同攻击者账号采用适配自身业务场景的钓鱼诱饵，体现攻击者具备针对不同业务主体定制社会工程话术的能力。
同为硬件钱包厂商的 BitBox，Brevo 账号遭到越权访问之后，攻击者向其新闻通讯订阅用户发送伪造告警邮件。BitBox 安全团队及时响应，联系服务商、向订阅用户发布风险警告并且上报钓鱼域名。BitBox 事后调查，Brevo 平台中只保存用户邮箱地址以及语言偏好设置，没有存储其他敏感客户信息；事件之后没有收到用户资金被盗、恢复短语泄露的相关报告。
CoinTracking 作为加密资产投资组合与税务报告工具，其 Brevo 账号被攻陷之后发送的钓鱼邮件主题为 "Data Breach Notice: Please refresh API Keys as soon as possible"。诱饵利用税务工具业务特征，捏造平台发生数据泄露，要求用户尽快刷新 API 密钥，诱导用户点击外部恶意链接，目的是窃取用户的 API 访问凭证，一旦凭证泄露，攻击者就可以读取用户加密资产持仓数据，进一步开展后续诈骗活动。
除上述三家之外，Peach Bitcoin、Blocktrainer 等加密行业机构也在 Brevo 事件后向用户发布钓鱼风险警告。Solana Mobile 同样提醒用户注意 Brevo 漏洞可能带来的钓鱼威胁。对比各家受害主体可以看出攻击者的社工设计逻辑：面向硬件钱包用户，利用芯片硬件安全漏洞制造恐慌，目标窃取钱包助记词；面向资产税务统计平台，则以数据泄露、密钥过期为借口，目标窃取业务 API 凭证。攻击者并非使用统一模板邮件，而是结合受害企业业务属性定制欺骗内容，进一步提升钓鱼邮件的迷惑性。
2.4 历史第三方安全事件带来的叠加风险
将时间线向前延伸，Trezor 在近两年内已经连续发生多起第三方服务商安全事故，这些事件虽然相互独立，但泄露的数据集合互相补充，共同放大终端用户面临的钓鱼风险。
2024 年 1 月，Trezor 披露第三方客服工单门户遭遇未授权访问，自 2021 年 12 月起联系过官方技术支持的约 66000 客户的姓名、用户名、邮箱地址遭到泄露。该次事件中 Trezor 自身系统同样未被入侵，风险完全来自外包客服平台。
2026 年 8 月 13 日，Trezor 披露物流履约服务商 ShipMonk 发生数据泄露事件。最初披露受影响客户规模为 13689 人，涉及 2026 年 5 月 10 日至 8 月 8 日期间下单的美国、英国、瑞典、哥伦比亚、巴西、意大利、葡萄牙客户。后续复盘发现服务商没有按照合同约定删除过期历史订单数据，2019 年 11 月至 2021 年 8 月的美国客户订单记录同样遭到窃取，整体受影响规模扩大至 81000 人。泄露字段包含姓名、电子邮箱、联系电话、收货地址、订单编号等物流订单信息。ShipMonk 方面确认，入侵源于其部署的 Metabase 数据分析平台存在未授权远程代码执行漏洞，攻击者利用该漏洞获取系统访问权限并抽取客户数据。
该批数据不包含私钥、助记词，不会直接造成资产被盗，但是具备很高的情报价值。攻击者可以将 ShipMonk 获取的订单信息，和 Brevo 事件拿到的大规模邮箱列表、2024 年工单门户泄露的用户信息进行匹配整合，后续可以制作高度定制化钓鱼邮件、短信甚至纸质钓鱼信件。公开报道显示，2026 年早些时候已经出现面向硬件钱包用户的纸质伪造信件攻击，信件内置钓鱼二维码，以身份核验为借口骗取恢复短语。ShipMonk 泄露的收货地址数据，会让这类线下社工攻击成为现实威胁。Brevo 事件提供短期爆发式的邮件钓鱼攻击窗口，ShipMonk 的数据泄露与历史工单门户泄露则为数月乃至数年持续性定向社会工程攻击储备情报素材，多重风险叠加放大整体安全威胁。
（3）Brevo 授权边界缺陷的技术逻辑与攻击链路解析
本次事件根源不属于缓冲区溢出、SQL 注入这类底层代码漏洞，属于 SaaS 多租户产品的业务授权逻辑缺陷。需要区分身份认证与授权访问两个基础安全概念：身份认证用于确认访问者是谁；授权访问管控已经通过身份核验的主体能够访问哪些业务资源。Brevo 平台 SAML SSO 流程完成了身份认证，但是会话与租户绑定的授权校验缺失，直接引发大规模跨租户越权访问。
3.1 SAML SSO 跨租户越权漏洞运行机理
SAML 即安全断言标记语言，是单点登录场景中身份提供商与服务提供商之间交换认证数据的标准协议。SAML SSO 允许用户使用一组身份凭证登录多个关联服务，在企业 SaaS 场景中被广泛用于员工统一身份管理。当 SAML 实现存在缺陷时，可能引发权限提升或者未授权访问多个资源的问题。
现代 SaaS 平台普遍支持单点登录，同时支持一个自然人账号加入多个不同企业租户，满足外包顾问、集团管理人员跨组织工作的业务需求。从安全设计角度，即便用户本身具备多个租户的访问权限，当用户经由 A 租户的 SSO 配置完成登录，生成的会话凭证必须严格限定于 A 租户资源；访问 B 租户业务资源，需要完成租户上下文切换，重新校验该会话是否具备 B 租户访问权限，会话凭证不能跨租户组织生效。
Brevo 平台缺失该层关键约束。攻击者操作流程可以拆解为完整业务交互链条。第一步攻击者自行注册全新 Brevo 租户，开启 SAML SSO 单点登录配置；第二步以该租户管理员身份，向平台内真实存在的其他企业合法用户发出团队成员邀请；第三步合法用户接受邀请加入攻击者创建的租户组织；第四步攻击者使用自己控制的身份提供商完成 SAML SSO 登录。系统完成身份认证之后，没有将本次会话的权限范围锁定在攻击者自建租户之内，错误允许该会话调用被邀请用户全部原有租户的操作权限。
漏洞触发需要一套完整前置业务交互流程：注册账号、开启 SSO、发送团队邀请、目标用户接受邀请。该类条件触发式业务逻辑缺陷很难被通用自动化漏洞扫描器捕获，更多依靠业务逻辑安全审计才能够被识别。漏洞本身不会直接导出通讯录或者发送邮件，越权登录成功之后，攻击者再手动执行读取联系人、发起批量邮件推送等业务操作，完成后续攻击行为。
3.2 完整攻击链路：权限劫持、合法投递、社会工程收割
漏洞越权登录只是攻击的起始环节，完整攻击链路分为三层。第一层，攻击者利用授权边界失效实现横向移动，获取多家加密行业企业 Brevo 租户管理权限；第二层，针对受害企业账号，读取已经收集完毕的订阅联系人列表，调用 Brevo 邮件发送能力，复用企业已经配置好的发件域名、DKIM 签名密钥，发起大规模邮件推送；第三层，依靠定制化社会工程诱饵制造紧急场景，引导用户访问外部恶意链接，下载伪造程序，诱导受害者提交高敏感凭证，对于硬件钱包用户目标是种子助记词，对于 CoinTracking 这类平台目标是 API 密钥。
本次攻击与普通邮件伪造钓鱼存在本质区别。普通钓鱼攻击者自建邮件服务器篡改邮件头部发件人字段，SPF 校验会判定 IP 地址与发件域名不匹配，DKIM 不存在合法签名，DMARC 策略会直接拒收或者隔离邮件。本次攻击全部邮件经由 Brevo 官方服务器发出，签名全部有效，邮件安全协议全部返回可信判定结果。反网络钓鱼技术专家芦笛强调，劫持正规服务商通信信道的钓鱼攻击，其本质是滥用邮件安全体系本身的信任模型；传统防护手段依赖 IP 地址、数字签名判断邮件可信度，当攻击者掌握合法服务商发送能力，上述防护维度全部失效，威胁隐蔽性大幅提升。防护思路不能仅仅停留在邮件流量层面，需要向前延伸到上游 SaaS 服务商的权限安全管控。
3.3 攻击链路末端的社会工程学分析
攻击者针对不同业务主体定制诱饵，充分利用用户的心理弱点开展欺骗。针对 Trezor 用户，STM32 芯片属于行业广泛使用的硬件钱包主控芯片，加密社区用户对于芯片随机数熵漏洞具备认知基础，攻击者借用真实存在的硬件芯片型号虚构漏洞，构建 "资产即刻面临暴力破解风险" 的紧急场景，压迫用户快速做出操作决策。在恐慌情绪之下，用户会跳过独立核验官方公告的步骤，直接点击邮件内链接。厂商 20 分钟阻断窗口期就出现 2500 次点击，能够印证这套社工话术的欺骗效力。
针对 CoinTracking 用户，攻击者抓住工具使用者对 API 密钥安全的焦虑，捏造数据泄露事件，以 "尽快刷新密钥规避风险" 作为驱动点，诱导用户访问恶意链接。两类诱饵拥有共同的设计逻辑：制造紧急风险，要求用户立刻执行操作，剥夺用户冷静核验信息来源的时间。这也是供应链劫持类钓鱼攻击成功率较高的重要原因，邮件来自看上去完全可信的官方发件地址，进一步放大心理暗示效果。
3.4 漏洞影响边界的客观辨析
对事件影响边界的客观研判，是受害企业开展风险处置的前提。138 个被访问账号不等于 138 家企业全部发生数据泄露。部分账号只是存在登录访问，没有执行联系人导出或者发送钓鱼邮件；6 个发送钓鱼邮件账号与 43 个导出通讯录账号集合是否重叠，Brevo 并未对外明确披露。企业开展内部风险评估，不能够简单以是否账号被访问作为唯一判断标准，需要回溯平台操作日志，区分单纯登录、通讯录导出、发送外发邮件等不同行为，以此划分风险等级。
同时应当区分两种风险层级：第一，即时攻击风险，攻击者利用账号发送钓鱼邮件，在很短时间窗口内完成攻击投递；第二，数据外泄遗留风险，通讯录被导出之后，邮箱数据永久留存攻击者手中，会转化为长期威胁，即便服务商漏洞修复、账号关停，后续钓鱼风险依旧持续存在。Trezor 并没有收到明确证据证明 347000 条邮箱全部被导出，但出于安全考量，将全部订阅地址视作已经泄露，该处置思路符合网络安全事件的保守研判原则。
（4）事件所揭示多维度安全短板
复盘整个事件链条，安全缺陷分布在 SaaS 服务商 Brevo、加密企业厂商、物流外包服务商 ShipMonk、终端用户多个参与主体，并非单一主体的责任，多方短板叠加，促成事件实际危害。
4.1 Brevo 即 SaaS 服务商侧存在的安全短板
首先是核心授权逻辑设计缺陷。完成 SAML SSO 身份认证之后，缺少会话与租户上下文的强绑定校验，登录会话没有被限制在发起 SSO 配置的租户组织内，身份认证完成之后，每一次资源访问没有再次校验会话允许访问的租户范围，依靠登录阶段一次性身份校验替代持续授权校验，造成跨租户越权。
其次，高危业务行为异常检测能力不足。平台内部出现跨大量不同租户组织的账号登录行为、大批量联系人导出操作、突发超大批量邮件推送，这类属于高风险操作，平台没有及时触发安全告警。本次事件是受害企业自身观测到异常钓鱼邮件之后，事件才得以暴露，平台端没有第一时间感知攻击行为。面向邮件营销类 SaaS，大规模批量邮件发送属于高危动作，除身份认证之外，缺少额外确认机制，账号一旦被越权接管，攻击者可以直接发起数万级别邮件投递。
第三，事件后信息披露颗粒度不足。仅对外公布三类账号的统计数字，没有说明集合之间是否重叠，缺少对客户企业风险评估的支撑信息，增加受害方研判难度。
4.2 加密企业厂商层面暴露的安全短板
第一，第三方服务商全周期安全管控存在不足。硬件钱包厂商业务高度依赖多家第三方服务商，Brevo 负责新闻邮件推送，ShipMonk 负责物流履约，还有独立第三方工单门户承接客户支持业务，多家第三方先后爆出安全事件，反映出外包供应商上线之后缺少周期性持续安全审计。很多企业将安全评估集中在采购准入阶段，服务商正式投入业务运行之后，安全核查趋于弱化。
第二，对于第三方服务商的数据生命周期管控，过度依赖合同文本约束。ShipMonk 事件中，合同条款明确约定过期历史订单数据需要完成删除，厂商也收到服务商已经删除的确认，但是实际系统中依旧长期留存数年的客户订单记录。仅依靠合同与服务商的自我承诺，缺少技术层面核验手段，无法保障数据销毁条款落地执行。
第三，面向用户的风险信息沟通仍有优化空间。发生第三方安全事件，需要清晰向用户区分两层事实：企业自有核心系统是否被入侵；第三方发生何种故障，用户面临怎样的风险。同时持续向用户明确官方行为边界，硬件钱包厂商永远不会通过邮件、外部应用索要助记词，避免用户混淆风险概念。本次事件发生之前，加密领域已经出现谷歌广告仿冒网站、纸质伪造信件等多种针对 Trezor 用户的钓鱼攻击，也说明厂商面向用户的常态化安全科普工作需要持续强化。
4.3 ShipMonk 物流服务商安全短板
ShipMonk 遭受攻击的直接诱因是 Metabase 平台的高危漏洞。BI 分析平台部署在互联网可访问环境，内部存储大量客户订单隐私数据，网络暴露面过大，没有落实网络访问限制。服务商漏洞管理流程存在缺陷，高危漏洞出现之后没有及时完成防护处置。其次没有落实数据生命周期管理，超期客户订单数据长期保存，扩大泄露数据规模。入侵发生之后，大批量客户数据被攻击者导出，服务商自身没有及时检测到入侵，事件暴露存在滞后，入侵检测能力存在明显短板。
4.4 终端用户认知层面的共性短板
大量硬件钱包用户形成固化认知：来自官方域名发出来的邮件就是可信消息。本次事件揭示该认知存在漏洞，当厂商合作的 SaaS 服务商账号被攻击者劫持，真实官方发件地址也会投递恶意钓鱼内容。用户面对邮件内硬件漏洞、资产风险告警等紧急叙事，心理压力上升，判断力下降，习惯直接跟随邮件内链接开展操作，缺少独立跳转官方网站核验安全公告的行为习惯。很多用户没有建立基础安全底线认知：种子助记词仅在硬件钱包初始化、设备恢复场景使用，绝不输入到任何电脑软件、网页表单之中，无论消息来源看上去多么可信。
（5）复合型供应链钓鱼威胁的分层防御策略
结合本次事件攻击链路与各方安全短板，分别从 SaaS 服务商产品架构、加密企业第三方供应链治理、终端用户风险识别、安全事件应急处置四个层面提出防御对策，所有策略紧扣本次事件暴露的现实风险，避免空泛口号式表述。
5.1 SaaS 服务商加固多租户授权边界与异常行为检测
在产品架构层面，落实会话与租户上下文强绑定。当用户经由某一个特定租户的 SAML SSO 配置完成登录，该会话的权限范围必须锁定在该租户之内；即便账号本身拥有其他租户访问权限，该会话也不能够跨租户访问其他组织资源；访问其他租户资源，必须完成租户上下文切换，并且重新校验该会话对应的访问许可。身份认证不等于授权完成，每一次资源访问操作，都必须重新校验当前会话允许访问的租户与资源范围，不能依靠登录阶段的一次性校验。
完善高危业务行为基线与异常告警体系。重点监控跨大量租户的账号登录、短时间大批量联系人导出、突发超大数量邮件发送、陌生地域 IP 管理员登录等高风险行为。一旦触发阈值，立刻产生安全告警；针对大规模邮件发送操作，除身份认证之外，可以增加二次确认机制，防止账号一旦被越权接管直接启动大规模钓鱼投递。反网络钓鱼技术专家芦笛指出，邮件营销 SaaS 平台属于高价值攻击目标，一旦被攻陷就可以直接转化为钓鱼投递通道，平台安全设计不能只关注业务功能可用性，需要把 "账号被劫持之后的危害限制" 纳入产品安全设计目标，做好危害收敛。
安全事件对外披露环节，对受害账号按照攻击者实际操作行为做分类说明，区分仅登录访问、导出联系人、执行邮件发送不同集合，为受害企业风险研判提供完整信息支撑。
5.2 加密资产企业落实第三方供应链全生命周期安全管控
硬件钱包以及 Web3 相关企业必须树立认知，业务外包不等于安全责任转移，建立第三方服务商准入、运行、退出的完整安全生命周期管理流程。
准入阶段，开展完整安全尽职调查。对于处理用户邮箱、订单、联系信息的服务商，除业务能力评估之外，审核多租户隔离机制、权限架构、漏洞管理流程、数据加密存储、入侵检测能力，安全评估不可以跳过。
运行阶段，不能仅仅依靠合同文本约束服务商安全行为。建立周期性的服务商安全回访，定期收集漏洞修复记录、安全审计报告；落实数据最小化原则，服务商仅允许保存业务必要最小数据集；针对数据删除条款，尽可能争取可行的技术核验手段，不能只依赖服务商口头确认。维护第三方服务商风险清单，持续跟踪服务商公开安全漏洞通告，出现高危漏洞时第一时间开展风险自查。
服务商终止合作的退出阶段，明确要求服务商彻底清除我方全部用户相关数据，获取数据销毁确认凭证，消除服务商侧残留数据集带来的泄露风险。
面向终端用户开展常态化安全科普，反复传递明确安全边界：官方包括合作服务商在内，任何渠道永远不会向用户索要钱包种子助记词。发生安全事件对外公告时，客观区分自有系统安全状态和第三方故障，清晰告知用户短期攻击风险与长期遗留钓鱼风险，避免模糊表述造成用户误判。
5.3 强化终端用户风险识别能力
终端用户需要破除 "官方发件域名等同于邮件内容可信" 的固有认知。遇到邮件提及硬件漏洞、账户风险，要求下载外部软件、提交钱包备份、刷新 API 密钥时，禁止直接点击邮件附带链接。应当手动在浏览器输入官方域名，前往官方公告板块核对安全事件的真实性。
硬件钱包使用者需要固化一条操作底线：种子助记词仅仅用于硬件钱包初始化与设备恢复操作，永远不要把助记词输入电脑软件、网页表单，无论信息宣称来自厂商或者合作服务商。当收到紧急安全告警，产生恐慌情绪的时候，正是钓鱼攻击成功率最高的阶段，应当暂停所有操作，独立核验信息来源，不要在焦虑状态下执行下载、提交敏感凭证的动作。
5.4 优化安全事件应急处置流程
从本次事件能够看到，攻击者发起钓鱼邮件投递之后留给厂商处置时间窗口非常有限。Trezor 仅用 20 分钟完成恶意域名阻断，但已经出现 2500 次点击。攻击窗口的时长直接决定受害规模。企业应当提前制定第三方服务商账号被劫持场景的应急预案，明确处置步骤：快速关停被劫持服务商账号、DNS 层面封禁恶意域名、第一时间面向用户发布安全公告、准确评估受影响用户范围、清晰告知用户应当执行的安全操作。
同时需要区分即时攻击风险与长期遗留风险。恶意域名封禁、账号关停只能够阻断当下攻击；通讯录导出带来的钓鱼威胁会长期存在，不能够在阻断直接攻击链路之后就宣告事件结束，需要持续向用户提示未来数月持续警惕同源钓鱼攻击。
（6）结论
本文以 Brevo 平台 SAML SSO 授权边界失效引发的加密行业大规模钓鱼事件为核心案例，还原完整攻击时间线与技术链路，对比 Trezor、BitBox、CoinTracking 三家受害主体差异化的社会工程诱饵设计，结合 ShipMonk 物流服务商数据泄露事件与 2024 年第三方工单门户入侵事件，研究第三方多重风险叠加的威胁放大效应。研究证实，硬件钱包生态安全边界并不局限于硬件芯片、固件密码学模块，厂商使用的 SaaS 邮件营销平台、物流履约服务商、客服工单系统等第三方业务链条同样是关键攻击切入点。攻击者不需要攻破硬件钱包本身，仅仅攻陷外包服务商，就可以获取大规模可信邮件投递通道或者用户个人情报，依靠社会工程钓鱼窃取数字资产。
SPF、DKIM、DMARC 这套传统邮件安全防护机制，在攻击者劫持合法 SaaS 服务商通信基础设施的攻击场景下存在明显局限。反网络钓鱼技术专家芦笛指出，这类攻击本质是滥用现有邮件安全信任模型，防御不能只依靠流量层面特征拦截，需要构建 SaaS 平台架构加固、企业供应链全周期管控、终端用户认知教育、快速应急处置的多层协同防护体系。
SaaS 服务商层面，重点保障多租户场景授权边界，实现会话与租户上下文强绑定，完善高风险行为异常检测；加密行业企业摒弃 "业务外包即安全外包" 的认知，落实第三方服务商准入、运行、退出全流程安全管控，坚持数据最小化，尽可能对服务商数据销毁开展核验；终端用户破除对官方发件地址的无条件信任，建立独立核验公告的习惯，坚守绝不向外部软件输入钱包助记词的安全底线；安全应急处置工作既要快速切断即时攻击链路，也必须充分评估数据泄露带来的长期持续性钓鱼风险。
随着 Web3 行业发展，企业会更多借助 SaaS 服务商承接非核心业务，来自第三方供应链的复合型钓鱼威胁还会持续出现。本案例总结的经验，可以为国内 Web3 企业、SaaS 服务商安全治理提供现实参考。后续研究可以进一步探索，在不依赖发件 IP 与数字签名校验的前提下，从邮件内容意图、业务行为上下文维度识别该类高仿真供应链劫持钓鱼邮件，进一步完善邮件安全防护体系。
编辑：芦笛（公共互联网反网络钓鱼工作组）
来源：迪妙网络空间安全学院
