{
	"id": "11dac5c3-bf44-4616-adc8-b63b17092405",
	"created_at": "2026-04-06T00:06:56.103198Z",
	"updated_at": "2026-04-10T03:21:00.125932Z",
	"deleted_at": null,
	"sha1_hash": "4acd14a82d64ce31885470d75845999631b9dc9c",
	"title": "Permiso | Blog | SES-pionage",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 783747,
	"plain_text": "Permiso | Blog | SES-pionage\r\nBy Nathan Eades\r\nPublished: 2023-01-12 · Archived: 2026-04-05 13:53:59 UTC\r\nCredits: Wilma Miranda\r\nExposed and stolen long lived keys are often the source of incidents we identify in our client’s cloud\r\nenvironments. Detecting the abuse of these keys is an area we focus a lot of effort in. After seeing many of these\r\nincidents, patterns are starting to arise that are somewhat unexpected. We took a poll a few months back to see\r\nwhat service people think is typically first to be targeted by attackers. While most folks guessed IAM, our data\r\nshows that AWS Simple Email Service (SES) is usually hit first. We will use this article to talk through what SES\r\nis, what we have observed, and what you should be on the lookout for!\r\nhttps://permiso.io/blog/s/aws-ses-pionage-detecting-ses-abuse/\r\nPage 1 of 9\n\nInitial Investigation\r\nIn October of 2022, Permiso was investigating an alert which was traced back to an exposed long-lived AWS\r\ncredential or access key (AKIA***) along with its secret key on a public GitHub repository. While we had many\r\nfindings, of particular interest was the following set of SES service actions:\r\n1. GetAccount\r\n2. ListServiceQuotas\r\n3. ListIdentities\r\nSES 101\r\nMany, if not most organizations, especially those that provide a service or application, have their trusty email\r\nrelays (SMTP relay), included as an extension of their email infrastructure. Relays are often used to send\r\nautomated emails, such as those for mass marketing messages and applications, separate from internal email\r\ncommunications. These systems can be difficult to build and maintain and may not be cost effective.\r\nSo is AWS SES an SMTP relay? It is, and more! In short, AWS SES provides the capability of bulk email sending,\r\nthis includes an SMTP interface as well as API, CLI and SDK options.\r\nhttps://permiso.io/blog/s/aws-ses-pionage-detecting-ses-abuse/\r\nPage 2 of 9\n\nWhy then does an attacker want to target SES? This is for the same reason attackers have always targeted email\r\nsystems. Use of phishing and other malicious messages to spread and continue to gain access through a potentially\r\ntrusted entity. Additionally, to the attacker, it’s free, as you the compromised organization now get to float the bill\r\nfor all that activity. In the case of SES it can also be harder on the defensive side to block the activity. See\r\nAppendix: “SES Email Defense” for more on working to block potential malicious activity originating from SES.\r\nSES Footprinting\r\nDue to the potential for abuse, AWS SES has several built in protections. For starters, you can’t just log into AWS,\r\npop over to the portal and start sending emails to everyone. When SES is first spun up, the account is placed into a\r\n“sandbox” environment. AWS maintains a FAQ on what it means to be placed in sandbox:\r\nhttps://docs.aws.amazon.com/ses/latest/dg/request-production-access.html.\r\nYou can only send mail to\r\nverified email addresses and domains\r\n, or to the Amazon SES mailbox simulator.\r\nYou can send a maximum of 200 messages per 24-hour period.\r\nYou can send a maximum of 1 message per second.\r\nFor sending authorization, neither you nor the delegate sender can send email to non-verified email\r\naddresses.\r\nFor account-level suppression, bulk actions and SES API calls related to suppression list management are\r\ndisabled.\r\nAn account outside of the sandbox environment is not held back by the same rate limits and can send emails to\r\nany address while still limited to using “verified senders”.\r\nAll of this is to say that attackers know about these constraints as well and they have means provided by AWS (for\r\nlegitimate means) to check for them. With that, we are back to the discussed SES service actions; GetAccount ,\r\nListServiceQuotas , ListIdentities , and for sake of argument were going to add 4 more, GetSendQuota ,\r\nGetIdentityVerificationAttributes , UpdateAccountSendingEnabled and\r\nGetAccountSendingEnabled .\r\nBreaking the commands down into categories:\r\nhttps://permiso.io/blog/s/aws-ses-pionage-detecting-ses-abuse/\r\nPage 3 of 9\n\nThe use of ListIdentities is meant to provide the attacker with knowledge of how SES senders may be\r\nconfigured within an account. As previously described, a verified domain is more valuable to an attacker as this\r\nprovides endless options for usernames and can make blocking the emails more difficult.\r\nExample ListIdentities Response:\r\n{\r\n \"email\": [\r\n \"example@example.com\",\r\n \"example2@example.com\",\r\n \"example@gmail.com\"\r\n ],\r\n \"domain\": [\r\n \"test-permisosec.awsapps.com\",\r\n \"other-test-permisosec.example.com\"\r\n ]\r\n}\r\nNote that ListIdentites does not provide a verification status. The response includes any identity regardless of\r\nverified status and each has no guarantee to be verified. GetIdentityVerificationAttributes provides this final\r\npiece, providing a status for each identity and allowing an attacker to confirm if there are any verified senders.\r\nListServiceQuotas , GetSendQuota and GetAccount may each be utilized to provide the accounts send quota\r\nfor the SES mailing service. Though what truly matters to the attacker is if the response is not 200. A response of\r\n200 indicates the service is in sandbox mode. The account cannot send to any address that is not verified and is\r\nlimited to only 200 messages over 24 hours.\r\nFinally, UpdateAccountSendingEnabled and GetAccountSendingEnabled have the intent to ensure the\r\ncompromised account is capable of sending messages.\r\nDetection\r\nOur research has found that SES footprinting has been well established and today follows a few typical flows.\r\nhttps://permiso.io/blog/s/aws-ses-pionage-detecting-ses-abuse/\r\nPage 4 of 9\n\nMost SES abuse we have observed originates from a long lived access key (AKIA***). Looking for the following\r\nset of actions from long lived keys will serve as good signal of SES abuse.\r\n1. Sandbox Status enumeration: Using one or many of ListServiceQuotas , GetSendQuota and\r\nGetAccount allows the attacker to reach a reasonable conclusion on whether the account is still in\r\nsandbox. Though keep in mind, even in sandbox, this could be means to spread internally within an\r\norganization through verified addresses / domains.\r\n2. Verified Sender enumeration: ListIdentities will be utilized to gather a list of domains and emails,\r\nsometimes in combination with GetIdentityVerificationAttributes to retrieve the list entries\r\nverification status.\r\nhttps://permiso.io/blog/s/aws-ses-pionage-detecting-ses-abuse/\r\nPage 5 of 9\n\n3. Account Enablement enumeration/modification: Attackers typically leverage\r\nUpdateAccountSendingEnabled to verify and set, if they have the privilege, the account sending status. We\r\nalso want to check for an advanced attacker whom may avoid using a “Write” action if it’s not necessary\r\nthrough the GetAccountSendingEnabled action.\r\nFor Permiso customers, the following alerts are indicative of SES targeting and abuse:\r\nID Description\r\nP0_AWS_SES_ACCESSKEY_GET_ACCOUNT_1\r\nAWS Simple Email Service (SES) Get\r\nAccount performed by long term access\r\nkey.\r\nSES GetAccount may be utilized to\r\nobtain the accounts sending quota to\r\ncheck for a sandbox environment. This\r\nmay signal that the organization is\r\nbeing tested or targeted for use in SES\r\nmailing attacks.\r\nP0_AWS_SES_ACCESSKEY_QUOTA_DETAILS_1\r\nAWS Simple Email Service (SES)\r\nGetSendQuota or ListServiceQuotas of\r\nthe SES service, performed by long\r\nterm access key.\r\nChecking SES quotas is indicative of\r\ntesting for an SES sandbox\r\nenvironment, often performed by\r\nattackers in preparation for an SES\r\nmailing attack.\r\nP0_AWS_SES_ACCESSKEY_LIST_IDENTITIES_1\r\nAWS Simple Email Service (SES) List\r\nIdentities performed by long term\r\naccess key.\r\nSES ListIdentities retrieves available\r\nemail addresses and domains within the\r\naccount. This may signal that the\r\norganization is being tested or targeted\r\nfor use in SES mailing attacks.\r\nhttps://permiso.io/blog/s/aws-ses-pionage-detecting-ses-abuse/\r\nPage 6 of 9\n\nP0_AWS_SES_ACCESSKEY_LIST_IDENTITIES_VERIFIED_1\r\nAWS Simple Email Service (SES) List\r\nIdentities with\r\nGetIdentityVerificationAttributes\r\nperformed by long term access key.\r\nSES ListIdentities with\r\nGetIdentityVerificationAttributes\r\nretrieves available email addresses and\r\ndomains within the account and\r\nprovides their status, such as “verified”.\r\nThis may signal that the organization is\r\nbeing tested or targeted for use in SES\r\nmailing attacks.\r\nP0_AWS_SES_ACCESSKEY_VERIFY_SENDING_STATUS_1\r\nAWS Simple Email Service (SES)\r\nGetAccountSendingEnabled performed\r\nby long term access key.\r\nSES GetAccountSendingEnabled\r\nprovides the disabled or enabled status\r\nof the account. This may signal an\r\nattacker checking the current status in\r\npreparation for use in SES mailing\r\nattacks.\r\nP0_AWS_SES_ACCESSKEY_ENABLE_SENDING_1\r\nAWS Simple Email Service (SES)\r\nUpdateAccountSendingEnabled\r\nperformed by long term access key.\r\nSES UpdateAccountSendingEnabled\r\nallows for updating the status. In this\r\ncase, set to “enabled”. This may signal\r\nan attacker ensuring the use of the\r\naccount in preparation for SES mailing\r\nattacks.\r\nP0_AWS_SES_ACCESSKEY_ABUSE_1 The activity observed is a combination\r\nof events, these events when observed\r\non their own are considered to be\r\nabnormal AWS Simple Email Service\r\nhttps://permiso.io/blog/s/aws-ses-pionage-detecting-ses-abuse/\r\nPage 7 of 9\n\n(SES) activity. When observed together\r\nthe events follow a well known set of\r\nTTPs seen before an account is utilized\r\nin SES abuse.\r\nAppendix:\r\nSES Email Defense:\r\nLets say the header from shows as test@test-permisosec.awsapps.com , pending the SES setup, the attacker\r\nmay be able to use any username section of the email address e.g. test2@testing.test-permisosec.awsapps.com\r\n. This means you are forced to block at the domain level, of course if the compromised organization is heavily\r\nutilized under legitimate circumstance then this presents a business problem. The envelope\r\nfrom, 010001858f7f9534-7ef4928a-f757-455f-9c33-959c7b98864f-000000@[amazonses.com]\r\n(\u003chttp://amazonses.com\u003e) won’t provide any benefit as the username field is a random string and part of the\r\namazonses.com domain used by any organization doing business through the AWS SES service.\r\nFrom the receiving side, one of your best courses of action is to notify your user base and to contact AWS:\r\nabuse@amazonaws.com - “Provide all the necessary information, including logs in plaintext, email headers, and\r\nso on, when you submit your request.”\r\nhttps://aws.amazon.com/premiumsupport/knowledge-center/report-aws-abuse/\r\nhttps://support.aws.amazon.com/#/contacts/report-abuse\r\nPending the compromised organization and readily available abuse points of contact, providing the same data to\r\nthem may be beneficial as well.\r\nSES Verification Methods:\r\nDomain / Email Verification: Even outside of SES sandbox, a sender must be verified. This again is a great\r\ncontrol from AWS to ensure the account owner is in control of the domain or email address being used. Verifying\r\na single email address requires acknowledging receipt of the message from the inbox. Verifying a domain requires\r\nDNS control of the domain as full DKIM verification will be required.\r\nhttps://docs.aws.amazon.com/ses/latest/dg/creating-identities.html\r\nAn example of single email address verification:\r\nhttps://permiso.io/blog/s/aws-ses-pionage-detecting-ses-abuse/\r\nPage 8 of 9\n\nSource: https://permiso.io/blog/s/aws-ses-pionage-detecting-ses-abuse/\r\nhttps://permiso.io/blog/s/aws-ses-pionage-detecting-ses-abuse/\r\nPage 9 of 9",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://permiso.io/blog/s/aws-ses-pionage-detecting-ses-abuse/"
	],
	"report_names": [
		"aws-ses-pionage-detecting-ses-abuse"
	],
	"threat_actors": [],
	"ts_created_at": 1775434016,
	"ts_updated_at": 1775791260,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/4acd14a82d64ce31885470d75845999631b9dc9c.pdf",
		"text": "https://archive.orkl.eu/4acd14a82d64ce31885470d75845999631b9dc9c.txt",
		"img": "https://archive.orkl.eu/4acd14a82d64ce31885470d75845999631b9dc9c.jpg"
	}
}