API abuse in the cloud

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.

SCATTERED SPIDER’s web

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.

Microsoft

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.

GCP

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.

AWS

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.