警惕新型 AWS S3 存储桶勒索攻击：超千个密钥遭滥用，云安全面临严峻挑战

一、攻击事件概述

2025 年 4 月，一场针对亚马逊云服务（AWS）S3 存储桶的大规模勒索软件攻击被曝光。安全研究人员发现，攻击者利用超过 1200 个独特的 AWS 访问密钥，对暴露的 S3 存储桶进行加密，并索要比特币赎金。这场攻击不仅展现了云环境下密钥泄露的巨大风险，也揭示了勒索软件在云基础设施中的新型攻击模式。

二、攻击技术细节

（一）密钥滥用与数据加密

攻击者通过非法渠道收集到1.58 亿条 AWS 密钥记录，从中筛选出1229 个独特密钥对（包含 Access Key ID 和 Secret Access Key）。尽管部分密钥已被轮换，但仍有大量有效密钥被用于入侵 S3 存储桶。
攻击手法利用 AWS 原生的 ** 服务器端加密（SSE-C）** 功能，攻击者生成自己的 AES-256 加密密钥，对存储桶内的数据进行加密。这种方式无需与存储桶所有者交互，受害者往往在数据加密后仍毫无察觉，形成 “静默入侵”。

（二）勒索流程与隐蔽性

加密完成后，攻击者在每个存储桶中留下名为warning.txt的勒索文件，要求支付 0.3 BTC（约 2.5 万美元） 赎金，并提供联系邮箱。
攻击具备高度自动化特征，且不删除文件或修改存储桶结构，仅通过加密锁定数据。更危险的是，部分受害者的 AWS 环境仍在正常运行，尤其当存储桶用于备份或低频访问场景时，用户可能长期未发现异常。
攻击者甚至警告受害者 “不要更换密钥”，并通过允许恢复测试文件来展示 “解密能力”，以此迫使受害者支付赎金。

三、密钥泄露的潜在途径

尽管攻击者收集密钥的具体手段尚未完全确认，但以下途径被列为高风险可能：

公共代码仓库泄露：开发人员误将 AWS 密钥提交到 GitHub、Bitbucket 等平台，攻击者通过 TruffleHog、Gitleaks 等工具扫描抓取。
CI/CD 工具配置漏洞：Jenkins、GitLab runners 等持续集成工具因配置不当或弱认证，导致密钥暴露。
应用配置文件缺陷：Web 应用的.env、config.php 或 JSON 配置文件未妥善保护，因服务器 misconfiguration 被公开访问。
IAM 用户管理疏忽：长期未轮换的老旧密钥、未及时停用的离职员工账号，成为攻击者的 “静默目标”。
第三方工具与黑市交易：开发者工具、云管理面板或密码管理器遭破解，密钥通过地下市场流通。

四、攻击影响与风险分析

数据恢复困境：由于使用 AWS 原生加密，若未备份加密密钥，数据几乎无法通过技术手段解密，受害者被迫面临 “赎金支付或数据永久丢失” 的抉择。
业务连续性威胁：被加密的存储桶若包含生产环境数据或关键备份，可能导致服务中断。攻击者甚至通过设置 “7 天数据删除策略” 施压，进一步加剧恢复紧迫性。
云安全信任危机：攻击利用 AWS 自身加密机制对抗用户，凸显云服务权限管理的脆弱性，可能引发企业对云安全架构的重新审视。

五、防御与缓解措施

为应对此类威胁，企业需从密钥管理、访问控制和监控审计多维度强化云安全：

（一）密钥与权限治理
- 立即审计 IAM 凭证：禁用所有未使用的密钥，对活跃密钥进行强制轮换，遵循 “最小权限原则” 分配 IAM 角色。
- 缩短密钥生命周期：使用临时令牌（如 AWS STS）替代长期密钥，避免在代码或配置文件中硬编码凭证。
（二）自动化监控与检测
- 启用 AWS GuardDuty 与 Config：利用云原生工具实时监控异常访问模式，记录配置变更，及时发现密钥滥用迹象。
- 扫描公共资源泄露：通过 SonarQube、Snyk 等工具扫描代码仓库和开源项目，阻止密钥意外提交。
（三）加密与日志管理
- 限制 SSE-C 使用：仅在必要场景启用客户提供的加密密钥，并配置严格的访问策略。
- 增强日志审计：开启 S3 存储桶的详细访问日志，监控 warning.txt 等异常文件的创建和修改。
（四）应急响应准备
- 定期备份数据：确保关键数据在外部存储或多云环境中具备可靠备份，降低对赎金的依赖。
- 制定响应预案：明确密钥泄露后的处置流程，包括密钥轮换、漏洞修复和执法机构通报。

六：行业启示与总结

此次攻击标志着云勒索软件进入 “低技术门槛、高自动化” 阶段 —— 攻击者无需复杂漏洞利用，仅依赖泄露的密钥即可实施大规模攻击。这一趋势凸显了云环境中 “身份即安全边界” 的核心挑战：企业必须将密钥管理视为云安全的基石，而非次要环节。