Betterment 数据泄露事件导致 140 万客户个人信息泄露。

2026-02-06 10:09:44 2 525

Betterment 披露了一起由社交工程驱动的数据泄露事件,该事件泄露了约 140 万个客户帐户的个人信息,显著扩大了 2026 年 1 月与欺诈性加密货币诈骗信息相关的安全事件的影响。



Betterment 披露了一起由社交工程驱动的数据泄露事件,该事件泄露了约 140 万个客户帐户的个人信息,显著扩大了 2026 年 1 月与欺诈性加密货币诈骗信息相关的安全事件的影响。

2026 年 1 月初,领先的自动化投资和智能投顾平台 Betterment 检测到对用于客户沟通和运营的系统存在未经授权的访问。

攻击者利用社会工程攻击攻击第三方平台帐户,诱骗员工分享凭据,而不是利用 Betterment 核心基础设施中的直接技术漏洞。

凭借这种访问权限,威胁行为者发送了与加密货币相关的欺诈性消息,这些消息伪装成 Betterment 的官方促销活动,承诺如果用户将资金(最高可达约 10,000 美元的加密货币)发送到攻击者控制的钱包,加密货币的价值将“翻三倍”。

Betterment当天撤销了未经授权的访问权限,通知受影响的客户忽略这些消息,并启动了由外部网络安全支持进行的取证调查。

违规范围
后续分析和 Have I Been Pwned索引显示,此次事件导致 1,435,174 个 Betterment 帐户的数据泄露。

虽然 Betterment 最初没有披露受影响的总人数,但泄露监控服务后来证实,至少有 140 万条唯一记录受到影响。

Betterment及其调查人员强调,此次事件中客户的投资账户并未遭到访问。该公司表示,没有证据表明在1月9日的攻击中密码、身份验证令牌或其他登录凭证遭到泄露。

泄露的数据集主要包含个人身份信息和联系人元数据,而非金融账户凭证。已确认泄露的字段包括:


  • 姓名。
  • 电子邮件地址。
  • 地理位置数据和雇主所在地。
  • 实际地址。
  • 电话号码。
  • 出生日期。
  • 职位名称。
  • 与客户互动相关的设备信息。

标识符和联系属性的这种组合,为有针对性的网络钓鱼、商业电子邮件入侵和身份关联诈骗创建了丰富的画像,尤其是在与其他经纪数据集交叉引用时。

Betterment于2026年1月9日至10日期间检测并阻止了此次攻击,并迅速向客户发出关于欺诈性加密货币信息的警告。在随后的公开更新中,该公司确认了个人数据泄露的范围,并重申账户凭证仍然安全。

2026 年 2 月 5 日,该事件以“Betterment”为名被添加到重大公共泄露通知服务中,反映了 140 万个受影响的账户,并正式确立了其作为大规模客户个人信息泄露事件的地位。

关于作者

socsoc110篇文章125篇回复

评论2次

要评论?请先  登录  或  注册
  • 2楼
    2026-2-10 11:28

    ### 结论 本次事件核心源于 **第三方权限被社会工程攻击突破**,导致攻击者通过合法渠道向客户发送欺诈性信息并获取高价值PII(个人身份信息)。关键问题包括: - 第三方xi统接口的访问权限未遵循最小化原则; - 缺乏对第三方账户异常行为的实时监控; - 数据分类不完善,PII与敏感操作(如消息发送)权限未充分隔离。 --- ### 分析路径 #### **L1 攻击面识别** 1. **源点(Source)**: - 第三方平台账户的员工凭证(攻击入口); - 客户数据库中的PII字段(泄露源)。 2. ** Sink(漏洞利用路径)**: - 攻击者通过控制的第三方账户向客户发送欺诈性消息(Sink为消息发送接口); - 数据导出接口可能被滥用(如批量导出PII)。 #### **L2 假设与验证** **假设1**:第三方平台的员工凭证复用其他xi统权限。 验证方法: - 检查攻击者控制的第三方账户是否被用于访问其他内部xi统(如客户数据库)。 **假设2**:员工缺乏社会工程攻击防御培训。 验证方法: - 审计员工账户的异常登录行为(如异地登录、非工作时间访问); - 检查员工是否参与过针对钓鱼攻击的模拟测试。 #### **L3 边界/异常场景** - **横向移动**:攻击者能否通过第三方账户访问核心xi统? 验证:检查第三方账户权限边界,是否具备直接访问投资账户或交易数据的权限。 - **数据流监控**:是否存在PII数据被批量导出或传输的记录? 验证:检查日志中是否存在异常的API调用(如高频率数据导出请求)。 #### **L4 防御反推与修复** **防御逻辑漏洞**: - 缺乏对第三方账户的 **MFA强制要求** 和 **权限隔离**; - 消息发送接口未设置 **二次验证机制**(如人工审核欺诈性内容)。 --- ### 验证步骤 1. **权限审查**: - 列出所有第三方平台账户的访问权限列表,确认其是否遵循最小权限原则。 2. **日志审计**: - 检查2026年1月9日前后第三方账户的登录记录、API调用日志,定位异常行为(如非授权IP登录、高频数据请求)。 3. **数据分类验证**: - 确认PII字段是否存储在与第三方接口隔离的数据库中,或是否通过加密/脱敏技术隔离。 4. **攻击链复现测试**: - 模拟攻击者通过第三方账户权限访问消息发送接口,验证是否触发告警或自动阻断机制。 --- ### 修复建议 1. **第三方权限加固**: - 强制第三方账户启用 **MFA**,并限制权限到最小必要范围(如只读或特定模块访问); - 实施 **时间窗口限制**(如仅允许工作时间登录)。 2. **行为监控与告警**: - 部署 **用户行为分析(UEBA)**,监控第三方账户的异常行为(如批量发送消息、数据导出); - 对敏感操作(如消息发送)添加 **二次验证**(如短信验证码或管理员审批)。 3. **数据流控制**: - 采用 **零信任架构**,要求所有数据导出请求需通过多因素授权; - 对PII字段实施 **动态脱敏**,确保第三方接口仅暴露必要信息。 4. **员工安全意识强化**: - 定期进行 **社会工程模拟攻击测试**,重点演练钓鱼邮件和凭证泄露场景; - 建立 **内部报告机制**,鼓励员工上报可疑请求。 --- ### 关键结论 事件暴露了 **第三方xi统权限管理与内部监控的双重失效**。防御需从“凭证安全”转向“权限最小化+实时监控+数据流控制”,并结合人员培训形成闭环。

  • 1楼
    2026-2-7 15:27

    它这个 泄露了约 140 万个客户帐户的个人信息,那牵扯了400多万人啊,影响也不小了啊