Commodity threat actors have recently begun to exploit cloud environments for smishing campaigns, employing techniques strikingly similar to those used in SES enumeration and abuse, as we've discussed in previous articles on the permiso.io blog. As this trend gains traction in the wild, we feel it's crucial to share some insights and detection strategies to help our readers stay ahead of these evolving threats.

Our Initial Lead

March 2023, an alert and suspicious user agent led to an investigation by the P0 team. As is most common, exposure of an AWS long-lived credential or access key (AKIA***) lead to this compromise. Exposure of keys in code repositories is common place, however, in this instance the occurrence began with a newly published version of a mobile application. Through monitoring and scraping, the attacker found and went about their usual processes to test and utilize the key. What peaked our interest was a failed action for GetSMSAttributes, which suggested the attacker was leveraging Simple Notification Service (SNS) to target Short Message Service (SMS) capabilities.

Why Target SNS SMS?

Skipping ahead, ultimately, the attackers goal is phishing or under the context of SMS, smishing. With that in mind, all of what is expected from successful phishing campaigns are a potential outcome:

• Compromise credentials (Personal and/or Organizational)

• Steal financial details (Credit Cards, Bank Account Details, etc)

• Spread of malware (Links, Drive-by-downloads, Watering hole attacks).

The attacker doesn’t need their own infrastructure, they now have yours and can use this trusted source to complete all these tasks.

Outside of what the attacker can obtain, they may inadvertently or purposefully cause ‘destruction’ in an environment. The attack may exhaust quotas making the service unusable for legitimate means. All these outcomes from successful attacks may result in damage to the compromised organizations reputation and potential legal and regulatory consequences.

In the following sections we’ll discuss the ins and outs of what an attacker may do in an environment, leading to compromise of the SNS service and SMS capability as well as what to look out for in detecting the threat.

How SNS SMS is Targeted?

Naturally the P0 team wanted to verify the use of GetSMSAttributes and what data is returned. If someone obtains keys, why run this command? GetSMSAttributes primary response is for MonthlySpendLimit, that attribute represents the total dollar value in a month that an account can spend on SMS messages before the service will stop sending.

The default for an unused SNS account is ‘1’. The default status of ‘1’ signifies the account is in the SMS sandbox. Like the SES service, an AWS account SNS SMS status always begins in a sandbox status to avoid misuse. AWS describes the following restrictions in sandbox:

• You can send SMS messages only to verified destination phone numbers.

• You can have up to 10 verified destination phone numbers.

• You can delete destination phone numbers only after 24 or more hours have passed since verification or the last verification attempt.

Unwritten in these restrictions for SMS sandbox are the other requirements to utilize SNS SMS. This includes registration requirements for origination numbers such as Toll-Free. An origination number is what is used to send the SMS message. At the time of writing, AWS documentation is mixed on this, depending on the service documentation that is reviewed, the documentation will say registration is not or might be required. While other documentation will say it is undoubtedly required. From our own tests, the latter is most accurate.

An attacker has other avenues to check for the sandbox status as well, some are a bit more obvious, such as GetSMSSandboxAccountStatus:

Utilizing the following breakdown we can go from the actions used to verify the SNS SMS status to reviewing the accounts capability.

An account in sandbox or not, will first only be able to deliver any messages once it has obtained a verified origination number capable of SMS. An attacker would check this status through ListOriginationNumbers. The API will return a list of any phone numbers set in the account, if Status is ‘Active’ and includes NumberCapabilities of ‘SMS’ then we know this account is capable of SMS:

CloudSecurityTests ~ %% **aws sns list-origination-numbers** 
{
    "PhoneNumbers": [
        {
            "CreatedAt": "2023-03-29T17:59:53+00:00",
            "PhoneNumber": "+REDACTED FOR BLOG",
            "Status": "Active",
            "Iso2CountryCode": "US",
            "RouteType": "Promotional",
            "NumberCapabilities": [
                "SMS"
            ]
        },
        {
            "CreatedAt": "2023-04-12T00:06:50+00:00",
            "PhoneNumber": "+REDACTED FOR BLOG",
            "Status": "Pending",
            "Iso2CountryCode": "US",
            "RouteType": "Promotional",
            "NumberCapabilities": [
                "VOICE"
            ]
        }
    ]
}

In initializing the attack, there are two (2) methods. The simplest in fitting with common attacks today such as the P0 Labs previously reported SES scenarios, is to utilize the SNS Publish action and send a message to any provided phone number. With this an attacker could run through any list of numbers they already have and abuse the compromised infrastructure. This would require a publish action for every phone number.

The second method involves SNS topics and subscriptions. Our research began due to an exposed key in a mobile application, it’s fitting an attacker would look to see if SNS SMS is available from where the key was discovered. With mobile applications, registration, confirmation, and other use cases are common through SMS. Using AWS SNS as the example, if you provide your number to an application to complete registration, then you may have also subscribed yourself to an SNS subscription(s). Subscriptions are associated to a topic and tell the topic how and to whom to deliver a published message. The attacker could understand this relationship and simply publish a message to an existing topic, allowing the compromised infrastructure to send a malicious message out to all subscribers through all subscriptions associated to the topic. This could mean, hundreds or thousands of recipients with little effort from the attacker.

Detection

SNS SMS abuse the P0 Labs team has observed originates from a long lived access key (AKIA***). Looking for the following set of actions from long lived keys will serve as valuable signals of SNS abuse.

1. Sandbox status enumeration

   Using one or both of GetSMSAttributes and GetSMSSandboxAccountStatus allows the attacker to reach a conclusion on whether the account is still in sandbox.

2. Verify account capabilities

   ListOriginationNumbers will be utilized to verify usable origination phone numbers necessary for sending SMS messages. ListTopics & ListSubscriptions, each is utilized to identify existing SNS infrastructure in use by an account. The latter two (2) could be loudest pending any legitimate application use of SNS in your environment.

Furthermore, monitoring regular ‘publish’ activity and detecting unusual spikes within a measured period such as a 24-hour time frame could reveal a potentially compromised account.

For Permiso customers, the following alerts are indicative of SNS SMS targeting and abuse: