文章总结： 本文分析攻击者利用被盗AWS凭证滥用WorkMail服务绕过SES沙箱限制进行钓鱼攻击的手法。攻击者通过TruffleHog发现凭证，在权限提升后建立WorkMail组织与验证域名，借此对外发送大量钓鱼邮件，且SMTP方式发送不留日志。建议组织严格限制IAM权限、禁用未使用的WorkMail服务并加强凭证管理以防御此类云服务滥用。 综合评分： 91 文章分类： 云安全,威胁情报,应急响应
绕过SES沙箱：通过AWS WorkMail发起钓鱼攻击的新手法
Dubito Dubito
云原生安全指北
2026年1月29日 08:46 江苏
注：本文翻译自 Rapid7 的文章《Threat Actors Using AWS WorkMail in Phishing Campaigns》[1]，可点击文末“阅读原文”按钮查看英文原文。
全文如下：
一、引言
在 Rapid7，我们追踪了大量以云环境为目标的威胁，其中一种常见攻击目的是劫持受害者的基础设施，用于托管网络钓鱼或垃圾邮件活动。除了显而易见的安全风险外，这种方法还使攻击者能够将其运营成本转嫁给目标公司，通常会给受害者带来其从未打算使用的服务所产生的巨额意外账单。
Rapid7 近期调查了一起云滥用事件，其中攻击者利用被盗的 AWS 凭证，通过 AWS WorkMail 部署网络钓鱼和垃圾邮件基础设施，从而绕过了 AWS Simple Email Service (SES) 通常强制执行的反滥用控制。AWS SES 是一个通用型、API 驱动的电子邮件平台，旨在处理应用程序生成的邮件，例如交易通知和营销信息。这使得攻击者能够利用亚马逊的高发件人声誉来伪装成合法的商业实体，并能够直接从受害者拥有的 AWS 基础设施发送邮件。此类活动生成的服务属性遥测数据极少，使得攻击者的活动难以与常规操作区分开来。任何暴露了 AWS 凭证并配置了宽松的 身份与访问管理（IAM，Identity and Access Management）策略的组织都可能面临风险，尤其是那些未对 WorkMail 和 SES 配置设置防护措施或监控的组织。
在本文中，我们分析了 MDR 团队观察到的一起真实事件，其中攻击者滥用了 AWS 原生电子邮件服务，在被入侵的云环境中构建网络钓鱼和垃圾邮件基础设施。我们将重现攻击者的攻击路径，从凭证验证和 IAM 侦察，到通过横向移动至 AWS WorkMail 来绕过 Amazon SES 的安全防护。在此过程中，我们将重点说明攻击者如何利用合法的服务抽象来规避检测，审视由此产生的日志记录和归因差距，并概述防御者可用的实用检测与预防策略，以识别和中断类似的云原生滥用行为。
二、背景：AWS WorkMail 及其核心组件
AWS WorkMail 是一项完全托管的商业电子邮件和日历服务，它允许组织在无需部署或维护自有邮件服务器的情况下运营企业邮箱。它支持 IMAP 和 SMTP 等标准电子邮件协议，以及常见的桌面和移动客户端，对于已在 AWS 内运营的团队而言，这是一个轻量级、按需付费的替代方案。
为了理解攻击者在此事件中执行的活动，首先需要了解 AWS WorkMail 中的几个核心概念。
2.1 组织（Organization）
组织 是 WorkMail 中的顶层容器。它代表一个独立的电子邮件环境，容纳所有用户（Users）、组（Groups）和域（Domains）。每个 WorkMail 组织都是特定于区域的，并且独立运行。这使得攻击者能够以最小的设置创建一次性的、自包含的电子邮件基础设施。
2.2 用户（Users）
用户 代表 WorkMail 组织内具备邮件功能的个体身份。使用 workmail:CreateUser API 调用创建用户后，可以通过 workmail:RegisterToWorkMail API 调用为其分配邮箱。一旦注册成功，该用户就可以通过 AWS WorkMail Web 客户端进行身份验证，或通过标准电子邮件协议进行连接，并立即开始发送和接收邮件。
2.3 组（Groups）
组 是用户的集合，可以代表多个成员接收邮件。它们通常用于邮件分发列表或共享收件箱，可以简化 WorkMail 组织内的大批量邮件投递或内部协作。
2.4 域（Domains）
域 定义了 WorkMail 组织使用的电子邮件地址命名空间（例如 @example.com）。在使用一个域之前，必须验证其所有权。此验证过程利用了 Amazon Simple Email Service (SES) 的标准域名验证机制，通常通过 DNS 记录完成。一旦验证通过，该域就可以被主动用于发送和接收邮件，这使得攻击者能够从攻击者控制的（但看似合法的）域进行操作。
三、攻击分析
下图以图形化方式呈现了攻击者在整个攻击过程中执行的关键事件，从初始访问行动开始，经过权限提升，直至达成最终目标。
图1：攻击过程的可视化图示
注：该图翻译如下：
3.1 初始访问
此次入侵始于长期有效的 AWS 访问密钥被暴露。恶意活动的第一个迹象是一个 User-Agent 被设置为 “TruffleHog Firefox” 的 sts:GetCallerIdentity API 调用。这强烈暗示攻击者使用了 TruffleHog，这是一种攻击者常用的工具，用于发现和验证从 GitHub、GitLab 和公共 S3 存储桶等来源泄露的凭证。Rapid7 经常在活跃的攻击活动中观察到 TruffleHog 的使用，包括被归因于 Crimson Collective[2] （译文详见：针对AWS云环境的新威胁：Crimson Collective勒索攻击分析）等组织的行为。
在此初始凭证验证的几天后，我们观察到了涉及第二个 IAM 用户的可疑活动，该用户通过长期访问密钥进行身份验证。虽然我们无法最终证明这两个用户是由同一操作者访问的，但多个因素表明它们属于同一入侵活动。值得注意的是，两次身份验证都源自同一地理区域，这对于受害者的正常运营模式而言是异常的。在整个事件发生期间，对这两个账户的访问都是通过一组轮换的 IP 地址进行的，这些地址主要与亚马逊和 DigitalOcean 等云服务提供商相关联。这种基础设施选择与常见的攻击者手法一致，旨在混淆真实来源并融入合法的云对云流量中。
图2：显示 TruffleHog 发现 Google Cloud Platform (GCP) 凭证的示例输出
3.2 侦察阶段与权限提升
在获得初始访问权限后，攻击者使用第一个被入侵的用户，通过原生 AWS API 进行基本的环境侦察。这些尝试反复导致 AccessDenied 错误，表明暴露的凭证受到有限权限的约束。该活动是使用 AWS 命令行界面 (CLI) 进行的，这表明攻击者进行了手动、交互式的探索，而非自动化工具操作。
在遭遇这些限制后，对手将活动转移到了第二组被盗用的凭证上，这组凭证拥有更广泛的权限。利用此用户，枚举活动变得更有目的性和结构化。攻击者首先使用 iam:ListUsers API 调用来了解身份环境，然后采用了一种通过故意触发 API 错误来确认特定权限的技术，而无需进行持久性更改。
作为更广泛侦察行动的一部分，攻击者还查询了 Amazon SES，以评估其当前配置和可利用性。具体来说，他们执行了 ses:GetAccount 和 ses:ListIdentities。这些调用使攻击者能够快速映射账户内 SES 的运行状态。ses:ListIdentities API 调用用于确定是否存在任何已验证的身份（域名或电子邮件地址）可以立即用于发送邮件；当时并不存在。同时，ses:GetAccount 被用来识别该账户是否在 SES 沙箱中运行，沙箱会施加严格的发送限制，并且在启动大规模电子邮件活动之前需要额外步骤。
这种以 SES 为重点的侦察表明了攻击者早期就有滥用电子邮件发送功能的意图，并展示了攻击者如何仅使用少量低噪声的管理 API 调用就能有效评估服务就绪状态。
例如，攻击者试图创建一个已存在的 IAM 用户。由此产生的错误响应确认了他们拥有 iam:CreateUser 权限，但并未成功创建新实体：
{
"userAgent": "aws-cli/1.22.34 Python/3.10.12 Linux/5.15.0-113-generic botocore/1.23.34",
"errorCode": "EntityAlreadyExistsException",
"errorMessage": "User with name xxxx already exists."
}
清单 1：iam:CreateUser CloudTrail 日志片段
使用 iam:CreateLoginProfile 也进行了类似的验证。通过提供一个违反账户密码策略的密码，攻击者收到了一个 PasswordPolicyViolationException 异常，从而确认了他们有能力创建控制台登录配置文件：
{
"userAgent": "aws-cli/1.22.34 Python/3.10.12 Linux/5.15.0-113-generic botocore/1.23.34",
"errorCode": "PasswordPolicyViolationException",
"errorMessage": "Password should have at least one uppercase letter"
}
清单 2：iam:CreateLoginProfile CloudTrail 日志片段
在验证了其权限范围后，攻击者创建了一个新的 IAM 用户，附加了 AWS 托管策略 AdministratorAccess，并建立了一个登录配置文件以启用 AWS 管理控制台访问。这标志着攻击从基于 CLI 的侦察转向了完全的基于 GUI 的控制，提供了不受限制的访问权限，并为后续的操作活动奠定了基础。
3.3 达成目标：为滥用准备电子邮件基础设施
到侦察阶段结束时，攻击者已经确认了两个关键事实：
- 1. Amazon Simple Email Service (SES) 中不存在已验证的身份。
- 2. 该账户仍受 SES 沙箱限制。
SES 沙箱的明确设计目的是限制欺诈和滥用，其限制有效阻止了有实质影响的网络钓鱼或垃圾邮件活动。只要账户处于沙箱中，就适用以下控制措施：
- • 邮件只能发送给已验证的身份（电子邮件地址或域）或 SES 邮箱模拟器。
- • 每 24 小时 最多只能发送 200 条消息。
- • 最高发送速率为每秒 1 条消息。
这些限制使得 SES 不适合立即进行大规模滥用。但攻击者并未放弃该服务，而是启动了一个流程，试图使更大容量的邮件发送合法化。
首先，他们向 AWS 提交了一个支持工单，请求脱离 SES 沙箱。同时，他们使用 servicequotas:RequestServiceQuotaIncrease API 调用，请求将每日发送配额大幅提高到 每天 100,000 封邮件。
{
"requestParameters": {
"serviceCode": "ses",
"quotaCode": "L-XXXXXX",
"desiredValue": 100000
}
清单 3：RequestServiceQuotaIncrease API 调用中的请求参数
在这个等待期间，攻击者专注于持久化和隐蔽性。他们创建了多个 IAM 用户。这些用户名被故意设计成类似于区域性或服务范围的自动化账户，而不是人类操作者。为了在 IAM 审计期间进一步降低可疑度，攻击者为这些用户附加了范围狭窄、仅针对 SES 的策略，而不是宽泛的管理权限。这种方法使他们能够保留操作访问权限，同时最小化诸如权限过高的身份等明显的入侵指标。
至此，攻击者已为大规模电子邮件滥用有效地准备了账户，但他们并没有等待 AWS 的批准就继续行动了。
3.4 通过滥用 AWS WorkMail 绕过 SES 控制
攻击者没有在等待 SES 沙箱解除和配额增加期间保持空闲，而是转向了 AWS WorkMail。该服务提供了另一种电子邮件发送途径，且前期限制要少得多。
使用 workmail:CreateOrganization API，攻击者创建了多个 WorkMail 组织。随后，他们为一些设计得看起来合法且商务化的域名发起了域名验证流程，这些域名包括：
- •
cloth-prelove[.]me - •
ipad-service-london[.]com
域名验证是通过 ses:VerifyDomainIdentity 和 ses:VerifyDomainDkim 执行的，这些调用源自 workmail.amazonaws.com。这为防御者指出了一个重要的细微差别：虽然涉及 SES API，但该活动是由 WorkMail 配置驱动的，而非传统的 SES 电子邮件活动。
一旦域名验证完成，攻击者直接在 WorkMail 内创建了多个邮箱用户，例如：
- •
service@ipad-service-london[.]com - •
marketing@ipad-service-london[.]com
这些账户有两个作用。首先，它们在应用层建立了持久性，独立于 IAM。其次，它们为网络钓鱼和垃圾邮件操作提供了可信的发件人身份，看起来与合法的企业电子邮件地址非常相似。
CloudTrail 还记录了 AWS 目录服务事件，显示利用受害者的目录租户为新发件人域创建了新别名：
CreateAlias
AuthorizeApplication
这种横向移动之所以影响重大，是因为 AWS WorkMail 没有实施类似 SES 的沙箱模型。邮件可以立即发送给外部、未经验证的收件人。此外，WorkMail 支持的发送量远高于 SES 沙箱限制。虽然 Rapid7 尚未通过实验验证最大吞吐量，但 AWS 文档引用的默认上限是 每个组织每天 100,000 个外部收件人，所有用户的发送量汇总计算。
3.4.1 邮件发送方法与日志记录的盲点
攻击者有两种可行的选项通过 WorkMail 发送邮件：
1. Web界面
通过 AWS WorkMail Web 客户端发送的邮件，可能会以 ses:SendRawEmail 事件的形式间接出现在 CloudTrail 中。产生这些事件是因为 WorkMail 使用 Amazon Simple Email Service (SES) 作为其底层邮件传输服务，即使邮件完全是通过 WorkMail 应用编写和发送的。
虽然这些事件不归因于某个 IAM 主体，但它们确实在 requestParameters 字段中暴露了多个有价值的元数据——最值得注意的是发件人的电子邮件地址和关联的 SES 身份。这使得防御者即使在没有传统的应用级或邮件级日志的情况下，也能将外发邮件活动与特定的 WorkMail 用户以及最近验证的域名联系起来。
这些 ses:SendRawEmail 事件的一个显著限制是缺少真正的客户端源 IP 地址。因为通过 WorkMail Web 界面发送的邮件是由 AWS 托管服务代表邮箱用户执行的，所以 CloudTrail 记录的 sourceIPAddress 是 workmail.<region>.amazonaws.com，而不是攻击者浏览器会话的原始 IP 地址。这有效地掩盖了攻击者的真实网络来源，使防御者无法将邮件发送活动与可疑 IP 范围、TOR 出口节点或先前观察到的入侵基础设施相关联。
{
"eventVersion": "1.11",
"userIdentity": {
"type": "AWSService",
"invokedBy": "workmail.us-east-1.amazonaws.com"
},
"eventTime": "2025-12-20T11:26:59Z",
"eventSource": "ses.amazonaws.com",
"eventName": "SendRawEmail",
"awsRegion": "us-east-1",
"sourceIPAddress": "workmail.us-east-1.amazonaws.com",
"userAgent": "workmail.us-east-1.amazonaws.com",
"requestParameters": {
"sourceArn": "arn:aws:ses:us-east-1:123456789012:identity/malicious-organiation[.]com",
"destinations": [
"HIDDEN_DUE_TO_SECURITY_REASONS"
],
"source": "=?UTF-8?Q?Malicious_User?= <marketing@malicious-organiation[.]com>",
"fromArn": "arn:aws:ses:us-east-1:123456789012:identity/malicious-organiation[.]com",
"configurationSetName": "gcp-iad-prod-workmail-default-configuration-set",
"rawMessage": {
"data": "HIDDEN_DUE_TO_SECURITY_REASONS"
}
},
"responseElements": null,
"additionalEventData": {
"SignatureVersion": "4",
"sesMessageId": "0100019b3c4a8bb7-50af951c-fbd4-4610-bc94-c7fc35733699-000000"
},
"requestID": "aff61405-04bd-4969-802a-7ce4d5946949",
"eventID": "c34ed12d-5bec-3fdd-aef9-57ae4313ca88",
"readOnly": true,
"resources": [
{
"accountId": "123456789012",
"type": "AWS::SES::ConfigurationSet",
"ARN": "arn:aws:ses:us-east-1:123456789012:configuration-set/gcp-iad-prod-workmail-default-configuration-set"
},
{
"accountId": "123456789012",
"type": "AWS::SES::EmailIdentity",
"ARN": "arn:aws:ses:us-east-1:123456789012:identity/malicious-organiation[.]com"
}
],
"eventType": "AwsApiCall",
"managementEvent": false,
"recipientAccountId": "123456789012",
"sharedEventID": "xxx",
"eventCategory": "xxx"
}
清单 4：通过 AWS WorkMail Web 界面发送邮件后记录的 SendRawEmail 事件
尽管信息有限，但这种遥测数据对于将可疑发送行为与最近创建的 WorkMail 用户或新验证的域名进行关联仍然是有价值的。
2. SMTP访问
或者，攻击者可以直接认证到 WorkMail 的 SMTP 端点，并以编程方式发送消息。通过 SMTP 发送的邮件不会生成 CloudTrail 事件，即使启用了 SES 数据事件也是如此，这为防御者制造了一个显著的盲点。
下方展示了一个用于通过 WorkMail SMTP 发送邮件的 Python 脚本示例：
import smtplib
from email.message import EmailMessage
# Configuration
SMTP_SERVER = "smtp.mail.us-east-1.awsapps.com"
SMTP_PORT = 465
EMAIL_ADDRESS = "[email protected]"
EMAIL_PASSWORD = "****"
# Create the message
msg = EmailMessage()
msg["Subject"] = "WorkMail SMTP"
msg["From"] = EMAIL_ADDRESS
msg["To"] = "<unverified_email>"
msg.set_content("Email Delivered to an Unverified Email via AWS WorkMail")
# Send the email
try:
with smtplib.SMTP_SSL(SMTP_SERVER, SMTP_PORT) as smtp:
smtp.login(EMAIL_ADDRESS, EMAIL_PASSWORD)
smtp.send_message(msg)
print("Email sent successfully!")
except Exception as e:
print(f"Error: {e}")
清单 5：通过 SMTP 使用 AWS WorkMail 发送消息的示例脚本
从攻击者的角度来看，这种方法非常理想：发送量更大、可立即触达外部收件人，且集中式日志记录最少。从防御者的角度来看，这凸显了监控 WorkMail 组织创建、域名验证事件和邮箱配置的重要性，因为这些操作通常先于网络钓鱼活动，而这些活动本身在 CloudTrail 中是不可见的。
四、结论
此次事件说明了攻击者如何滥用更高层级的 AWS 服务，部署与合法企业使用情况高度相似的网络钓鱼和垃圾邮件基础设施。虽然 AWS WorkMail 并非设计用于支持批量邮件操作，但攻击者仍可将其作为 Amazon SES 之外的过渡能力加以利用。通过滥用 WorkMail 已认证的邮箱和宽松的前期控制措施，对手可以在 SES 脱离沙箱以及更高的发送配额获得批准之前，立即开始发送较低数量的邮件。这种分阶段的方法使攻击者能够建立发件人声誉、验证基础设施并保持运营势头，同时绕过了许多 SES 中故意设置的障碍点。
为缓解此类滥用行为，组织应将预防性防护措施与针对性检测结合起来。在不需使用 AWS WorkMail 的情况下，应利用 AWS Organizations 服务控制策略 (SCPs) 明确阻止其使用，以防止组织创建和邮箱配置。在需要使用 WorkMail 的环境中，IAM 策略应强制执行严格的最小权限原则，并将 WorkMail 和 SES 的管理视为需受监控和审批的特权操作。最后，组织应通过实施安全的开发和运维实践来降低初始访问的可能性——例如在代码仓库中进行secrets信息扫描、定期轮换密钥以及尽量减少长期访问密钥的使用——以限制凭证泄露的影响，并防止攻击者将被盗用的凭证转化为可扩展的电子邮件滥用。
五、MITRE ATT&CK 技术映射
| 战术 | 技术 | 详情 |
| — | — | — |
| 初始访问 (Initial Access) | 有效账户：云账户 (T1078.004) | 攻击者使用暴露的长期访问密钥通过 sts:GetCallerIdentity 验证后，认证到 AWS。 |
| 持久化 (Persistence) | 创建账户：云账户 (T1136.003) | 攻击者创建了多个 IAM 用户和 AWS WorkMail 邮箱用户以维持持久访问权限。 |
| 权限提升 (Privilege Escalation) | 账户操纵：额外的云角色 (T1098.003) | 攻击者将 AdministratorAccess 托管策略附加到新创建的 IAM 用户上。 |
| 侦察 (Discovery) | 云基础设施发现 (T1580) | 攻击者通过 API 调用枚举了 IAM 用户，并评估了 Amazon SES 配置和沙箱状态。 |
| 影响 (Impact) | 资源劫持：云服务劫持 (T1496.004) | 攻击者滥用 AWS WorkMail 和 SES，从受害者账户发送大批量的网络钓鱼和垃圾邮件。 |
六、入侵指标 (IOCs)
139.59.117[.]125
3.0.205[.]202
54.151.176[.]0
注意： IP 地址 3.0.205[.]202 和 54.151.176[.]0 属于亚马逊拥有的 IP 地址，因此在应用 IP 封锁时应谨慎处理。
引用链接
[1] 《Threat Actors Using AWS WorkMail in Phishing Campaigns》: https://www.rapid7.com/blog/post/dr-threat-actors-aws-workmail-phishing-campaigns/
[2] Crimson Collective: https://www.rapid7.com/blog/post/tr-crimson-collective-a-new-threat-group-observed-operating-in-the-cloud/
交流群
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：云原生安全指北 Dubito Dubito《绕过SES沙箱：通过AWS WorkMail发起钓鱼攻击的新手法》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论