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