亚马逊的邮件服务本是为企业设计的合规工具，现在却成了攻击者的"免死金牌"。
安全公司卡巴斯基最近发出警告：攻击者正在大规模劫持亚马逊简单邮件服务（SES）的凭证，发送海量钓鱼邮件。这些邮件能轻松通过企业邮箱的所有安全认证，直接钻进收件箱。
攻击链条：从GitHub到企业收件箱
整个攻击的起点，是散落在代码仓库里的AWS密钥。
攻击者使用TruffleHog这类扫描工具，在GitHub仓库、.ENV配置文件、Docker镜像、备份文件和公开可访问的S3存储桶中批量搜寻亚马逊云服务的登录凭证。一旦发现有效密钥，他们会先验证权限和邮件发送配额，确认能"大规模群发"后，立即启动钓鱼攻势。
卡巴斯基在报告中描述了这一流程：「验证密钥权限和邮件发送限制后，攻击者就具备了传播海量钓鱼信息的能力。」
这些邮件经过精心设计——自定义HTML模板模仿正规服务，登录流程高度逼真。主题从伪造的DocuSign文档到商业邮件诈骗（BEC）应有尽有。
为什么传统防御全部失效
问题的核心在于亚马逊SES本身的"合法性"。
作为亚马逊官方的邮件发送服务，SES天然拥有可信的发送基础设施。攻击者劫持凭证后发出的邮件，能顺利通过SPF（发件人策略框架）、DKIM（域名密钥识别邮件）和DMARC（基于域的消息认证、报告和一致性）三重认证检查。
这意味着什么？企业邮箱系统会把这些邮件标记为"安全"，直接送入收件箱，而非垃圾邮件文件夹。
更棘手的是IP封锁策略的彻底失效。安全团队无法通过封禁IP来拦截攻击，因为那样会阻断所有来自亚马逊SES的邮件——包括大量完全合法的企业通信。
卡巴斯基指出：「通过武器化这项服务，攻击者避免了从零搭建可疑域名和邮件基础设施的麻烦。他们直接劫持现有访问密钥，获得批量发送数千封钓鱼邮件的能力。」
从偶发到趋势：攻击规模正在升级
卡巴斯基用了一个值得注意的表述：「我们最近观察到利用亚马逊SES的钓鱼攻击出现上升势头。」
他们将这种变化定性为"从孤立事件转向稳定趋势"。这不是技术漏洞被利用的个案，而是一种正在成形的攻击范式——攻击者发现了一条成本极低、效果极佳的钓鱼通道。
对企业安全团队来说，这构成了双重困境。一方面，邮件认证体系（SPF/DKIM/DMARC）的设计初衷就是区分合法与非法发件人，现在这套体系被"合法"的发件人身份绕过；另一方面，阻断攻击源头的传统手段（IP封锁）在此场景下会产生巨大的误伤成本。
防御建议：从密钥管理入手
卡巴斯基给出的缓解方案聚焦于身份与访问管理（IAM）的加固。
具体包括：实施最小权限原则配置IAM访问；将IAM访问密钥替换为角色（Roles）进行AWS配置；启用多因素认证；配置基于IP的访问限制；实现密钥自动轮换；使用亚马逊密钥管理服务（KMS）集中加密数据和管理密钥。
这些建议的共同点在于——攻击的入口是暴露的凭证，防御的重点也应回到凭证的生命周期管理。
但这里存在一个结构性难题：GitHub等代码托管平台上的密钥泄露，往往发生在开发者的个人仓库或历史提交中，企业安全团队难以实现全覆盖的监控和清理。而攻击者的扫描工具（如TruffleHog）是自动化的、持续的、大规模的。
当防御方的清理速度追不上攻击方的扫描速度，这种不对称性就会持续产生可被利用的窗口期。
亚马逊SES钓鱼攻击的蔓延，暴露出云原生安全的一个深层张力：当基础设施即服务（IaaS）的便利性被攻击者逆向利用，传统的边界防御和认证体系会出现系统性盲区。企业邮箱的安全假设——"通过认证即可信"——在云服务被劫持的场景下需要重新校准。如果攻击者持续偏好这种低投入高产出的攻击路径，安全行业是否需要一套专门针对云服务凭证泄露的实时响应机制，而非依赖事后的密钥轮换建议？
热门跟贴