Skip Navigation
Get a Demo


API abuse in the cloud

Armed with stolen short-term tokens or credentials, adversaries might be spending more time in cloud services providers’ APIs than some administrators.

Pairs With This Song

As businesses across the world have moved to cloud services and built infrastructure on top of cloud providers, adversaries have followed them. Moving to the cloud has huge benefits, such as scalability, security, and developer-friendly application programming interfaces (API). It has also brought new tools in the form of identity and access management (IAM) services, which allow businesses to control their accounts’ permissions in a fine-grained manner. But with all these great benefits comes increased attention from adversaries.

Adversaries have been pivoting into their victims’ cloud environments for years, and they continued to do so in 2023 with gusto. They often leverage open source tools to scan public cloud services, malware to steal access keys from developers and administrators, and cloud APIs to maintain persistence and otherwise satisfy their objectives. Even when adversaries use custom GUIs or are logged into their victims’ web consoles, they use the same APIs as the businesses they’re targeting.

In fact, it’s hard for adversaries to avoid using the APIs provided by the cloud services, since this is often the only way to interact with cloud services. This provides a great opportunity for defenders to detect and respond to attacks in their cloud environments, since most services provide some sort of unified log to analyze events.

What we saw in 2023

A huge benefit of moving to the cloud is the ability to use valid short-term tokens (STS) to authenticate API calls. This is a huge win for defenders, who now don’t have to worry as much about rotating passwords or having their API keys permanently compromised after accidentally leaving them in an open Git repository. However, this doesn’t mean adversaries have stopped tricking users into handing over credentials or stealing them from compromised endpoints entirely. Cloud API abuse by adversaries continued in 2023 with an expanded use of phishing kits and infostealers to collect credentials and/or MFA-signed access tokens.

Many businesses start their transition to the cloud by moving to software-as-a-service (SaaS) versions of existing tools, like M365 for email and productivity applications or IAM services that can handle single sign-on (SSO), MFA, and permissions, such as Okta or Entra ID. Even though the services themselves are cloud-based, the credentials used to access them can still be gathered by more traditional means. In 2023, we saw several families of information-stealing malware, directly and indirectly, looking for access keys and session tokens that would let the operators bypass MFA protections and pivot to cloud environments. Infostealers like RedLine, LummaC2, Stealc, and Vidar were deployed across our customer base and used mainly to steal cookies and active session tokens from web browsers, which have been used to gain access to cloud environments.

Researchers at Cado, Permiso, and Lacework have observed cloud-specific stealers that specifically target AWS credentials. Adversaries then leverage these credentials to perform AWS API actions like creating new users, generating access keys, and escalating permissions through built-in IAM roles. These tools bridge the gap between on-premise threats and cloud environments, and they show that adversaries are leveraging traditional techniques to accomplish new objectives. Importantly, this also means that adversaries don’t necessarily need a user’s password or MFA device to compromise an account. In the case of Azure, an adversary with access to a Primary Refresh Token can leverage that to maintain access and sign in to services across the Microsoft cloud. Tools like AADInternals and ROADToken leverage multiple API endpoints to collect domain information, generate new identities, and more.


One of the more interesting stories of 2023 involved the SCATTERED SPIDER group, which uses many different tactics to infiltrate companies and persist in their cloud environments. Of special note is their tactic of stealing authentication tokens via phishing and abusing credentials to set up new identity providers and persist in victim environments. BeyondTrust’s first-hand account of this attack provides a wealth of details, including how the group gained access by stealing from “a HAR file containing an API request and a session cookie which was uploaded to the Okta support portal.” Even though the account was protected with MFA, the stolen session cookie they used was already authenticated to Okta, so they could make API calls without reauthenticating for a time. And they did. The adversaries generated a new service account with their access and attempted to persist further in the environment.

SCATTERED SPIDER is also known to register domains for phishing Okta credentials, using proxies to authenticate to identity providers, and moving laterally through the judicious use of remote management and monitoring (RMM) tools. An important takeaway from this story is that even if your administrators don’t make direct use of the APIs offered by cloud services, adversaries can. Stealing session cookies can give them the ability to bypass MFA protections and initiate API calls that can do just as much damage to an organization as accessing a web console.

For prevention and mitigation, much of the same strategies applied to phishing can apply here. Applying least privileges to your IAM roles and user accounts will help avoid a single identity compromise from turning into a large incident. Requiring MFA whenever possible (AWS, Entra ID, M365) can prevent adversaries from taking over an account entirely, especially if they are not able to phish the MFA code from your users or you use FIDO authentication tokens. In AWS, use IAM roles and short term tokens to perform activities, as these provide a wealth of security benefits such as automatic expiration of tokens, an easy method for revoking credentials, and the ability to avoid storing secrets in source code. If you do need to store secrets somewhere, use a secrets manager such as Azure Key Vault or AWS Secrets Manager. These are easy to manage and far more secure than rolling your own or storing secrets in source code.

Detection opportunities

A big benefit of the cloud is the ability to analyze an infrastructure’s worth of log data in just a handful of spots at most. There’s no need to manually deploy sensors or packet capture devices across a network; gaining runtime visibility can be achieved through tools offered by the cloud service, or configurations can be created to automatically deploy third-party sensors easily. Most importantly though, is the ability to monitor control plane or audit log activity by tapping into a small number of sources. Every large cloud provider offers the ability to monitor control and data plane activity; AWS offers CloudTrail, GCP has the Cloud Audit Log, and Azure provides Azure Activity and resource logs. On top of that, most SaaS-based identity providers have similar logging capabilities. Okta provides the System Log, Microsoft 365 uses the Unified Audit Log, and Entra ID (formerly Azure Activity Directory) gives a wealth of information in its Sign-in logs, Audit logs, and Graph activity logs (currently in beta). These log sources can be overwhelming in the amount of data they provide, so tuning and filtering based on your environment is key.

In addition to collecting logs, the largest cloud providers also offer detection tools that can generate alerts on control plane activity and integrate with additional cloud applications. Since identities and access keys are generally the starting point for cloud compromises, any alerts from these tools that indicate an identity is authenticating from an unknown source should be investigated.


Entra ID provides a few detections in the form of Atypical Travel, Anomalous Token, and Anonymous IP. We often find users legitimately tripping these shortly after setting up a phone on a new mobile carrier, using VPNs simultaneously with mobile devices, and logging in to certain services (e.g., Outlook) on a corporate device, switching to a corporate VPN, and then logging in to additional services (e.g., Microsoft Teams). When this activity has been malicious, we’ve observed anomalous User-Agent strings, such as those used by command-line tools when the user typically leverages web browsers, risky anonymizing services like Tor, and web versions of services that they typically log into with a dedicated client, such as Office 365 Online even though they use the Outlook app or Outlook Mobile.


Similarly, GCP offers an Event Threat Detection service that provides detections across many of their most common services. The Access from Anonymizing Proxy detection is similar to Azure’s Anonymous IP detection. They also provide Leaked Service Account Key Used and Dormant Service Account Key Created detections, which can be difficult to replicate without a large Internet monitoring facility or a long history of service account usage, respectively.


In the AWS space, GuardDuty provides some interesting detections that can be difficult to replicate in a SIEM. Namely, EC2 instance credentials used outside AWS, EC2 instance credentials used in another AWS account, and IAM APIs invoked from Tor exit nodes. The instance credential ones in particular have been helpful in linking the activity happening within an EC2 instance and the identity tied to it. In most cases, an instance’s identity should only be making API calls on the instance itself, so identifying when that doesn’t happen can tip you off to a potentially compromised instance or an application hosted on it that is vulnerable to attacks like SSRF.

We have also observed developers leveraging instance credentials from their corporate devices in order to troubleshoot permissions for the role tied to the instance. In these cases, benign APIs associated with the application hosted on the instance are typically used, and the source IP for the calls can be traced back to a corporate device. In benign activity, a lot of read-only commands are issued in a short period of time, and they are typically blocked by AccessDenied errors. Attempts to create or update objects in the IAM service also typically follow, and we use these detection analytics to improve on these alerts:

IAM instance credentials failing to read many resources with AccessDenied errors

The threshold for this can be a bit arbitrary to enable either tighter logic (more events, smaller time frame) or broader logic that is more prone to false positives (fewer events, larger time frame). The below logic looks for 20 denied read events within a five-minute time period.

userIdentity.principalId includes?(“:i-”) 
events where (
eventName starts_with_any?("Get", "List", "Describe") 
errorCode equals?("AccessDenied")
) > 20 in 5 minutes

IAM instance credentials attempting to create IAM entities

This analytic requires some amount of tuning or familiarity with the apps running in your EC2 instances, as there could be legitimate reasons for an instance to create IAM objects like access keys, groups, or roles.

userIdentity.principalId includes?(“:i-”) 
eventName starts_with?("Create”) 
eventSource equals?(“”)


Start testing your defenses against API abuse in the cloud using Atomic Red Team—an open source testing framework of small, highly portable detection tests mapped to MITRE ATT&CK.

Getting started

Testing for API abuse can be a very wide-ranging topic. Existing tools like Atomic Red Team or Stratus Red Team, built by DataDog, are an easy way to integrate detection tests into your cloud environment.

T1136.003 Create Account: Cloud Account

Cloud account creation is a common way to maintain persistence in environments, so it’s a great behavior to monitor for. This collection of tests currently covers Azure and AWS accounts.

T1078.004 Valid Accounts: Cloud Accounts

This technique is exceptionally wide-ranging, since all cloud API calls require a valid cloud account to authorize requests. Just about any invoked API can fall under this, and the current set of tests cover credential creation, automation, and IAM modifications.

T1098.001 Account Manipulation: Additional Cloud Credentials

Since persistence in the cloud generally revolves around identities, creating additional credentials makes sense as a common technique. Service account keys, access tokens, and certificates being created all fall under this category, and most environments only use a couple of credential types at most. Testing your ability to monitor new types of credentials is vital to identifying persistent compromised identities.

T1098.003 Account Manipulation: Additional Cloud Roles

IAM roles in the cloud provide sets of permissions for identities attempting to make changes to an environment. These roles can be extremely flexible, and they do not always follow the same pattern. While built-in roles do exist in the cloud, they are not as commonly used as traditional ones like Domain Admins or Enterprise Admins. Understanding roles and being able to identify over-permissioned ones can be extremely helpful during an investigation.

The next set of techniques revolves around reconnaissance, which can be tricky to detect given the amount of activity that it looks like. Being able to pick the recon needle out of the audit log haystack is most often useful when you have already identified a compromised identity and are trying to work backwards and scope their level of knowledge about your environment.

There are several cloud techniques in MITRE ATT&CK for which there are no Atomic Red Team tests yet. If you’re looking to contribute, please feel free to open a pull request!

Review and repeat

Now that you have executed one or several common tests and checked for the expected results, it’s useful to answer some immediate questions:

  • Were any of your actions detected?
  • Were any of your actions blocked or prevented?
  • Were your actions visible in logs or other defensive telemetry?

Repeat this process, performing additional tests related to this technique. You can also create and contribute tests of your own.

Back to Top