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

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

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 万个受影响的账户,并正式确立了其作为大规模客户个人信息泄露事件的地位。

关于作者

socsoc131篇文章146篇回复

评论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多万人啊,影响也不小了啊