Cloud Accounts

Why do adversaries abuse cloud accounts?

Cloud account compromises are increasing in prevalence as organizations embrace software-as-a-service (SaaS) for critical productivity applications like email, file storage, and messaging, resulting in a substantial volume of data now being stored in the cloud. This shift is mirrored by adversaries too, who are finding just as much value in compromising cloud identities as they have historically in traditional endpoints.

Adversary focus is not limited to SaaS alone; they are showcasing a heightened level of sophistication as they pivot towards compromising accounts within infrastructure-as-a-service (IaaS) platforms like Amazon Web Services, Microsoft Azure, and Google Cloud Platform (to name a few). These accounts serve as gateways to extensive and intricate cloud infrastructure containing critical and sensitive information that’s valuable to enterprises and adversaries alike.

This evolving landscape underscores the critical need for organizations to fortify their defenses by securing the cloud identities that house an ever-expanding amount of sensitive data. As cloud adoption continues to increase, defenders must adapt their strategies to ensure the security of cloud-based assets. Part of this shift includes educating cyber defenders in the latest threats against cloud systems to ensure they are well-equipped to detect and investigate attacks when they do occur.

The motivations for targeting cloud accounts are diverse, reflecting the expansive role these accounts play within organizational ecosystems. As organizations migrate their operations to the cloud, adversaries see an opportunity to exploit the interconnectedness of cloud services. The stakes are high for defenders because adversaries can exfiltrate sensitive data from cloud storage systems, block access to business critical applications, run up the hosting bill by stealing cloud compute for cryptocurrency mining, and abuse enterprise cloud environments in countless other ways.

As organizations migrate their operations to the cloud, adversaries see an opportunity to exploit the interconnectedness of cloud services.

Cloud accounts can be created on a whim with permissions to grant access to numerous applications and systems, posing a significant challenge for defenders. This challenge is magnified in large organizations with thousands of accounts, necessitating meticulous oversight of roles and permissions. Maintaining vigilance is not only a time-consuming endeavor but also costly, underscoring the intricate and expensive nature of securing cloud environments.

Cloud breaches this past year have shown that initial access techniques can be surprisingly unsophisticated, requiring minimal infrastructure setup and cost for adversaries. SMS phishing, also known as “smishing,” emerged as a notable tactic in multiple publicly reported breaches. This method involves adversaries using expendable temporary phone numbers to send text messages, leading to a full escalation chain from credential theft to data exfiltration. Its simplicity lies in the ease with which adversaries can grab a temporary phone number and swiftly deploy text messages to targeted individuals in order for them to enter credentials on their mobile phone.

Defending against SMS phishing attacks proves challenging, as monitoring behaviors of users’ mobile devices is out of reach for most security teams. This makes it imperative for organizations to adopt proactive security awareness training for employees. Keeping staff informed about the latest cyber attack techniques remains a great defensive mechanism against such threats.

How do adversaries use cloud accounts?

It’s important to note that credentials in the cloud extend beyond traditional username and password combinations. While everyday users of SaaS applications—or even small companies—may predominantly rely on these credentials for authentication, the current landscape includes a spectrum of authentication factors. In the era of single sign-on (SSO), users often experience seamless access without the need for frequent manual sign-ins. This encompasses various factors such as API keys, access tokens, X.509 certificates, biometric data, one-time passwords (OTP), and more, contributing to a multifaceted and secure authentication ecosystem.

However, with the proliferation of diverse authentication methods, there is a concurrent increase in potential attack vectors. Adversaries now have a broader range of opportunities to employ sophisticated and even simple tactics to steal these various types of credentials, necessitating heightened vigilance in securing the entire authentication process.

Once in possession of legitimate account access, adversaries can closely mimic the normal behavior of genuine users, making detection a formidable challenge. Newly obtained access is often leveraged through existing web applications, endpoint applications that make use of cloud resources, or even command-line tools. Their focus is mainly to perform reconnaissance within the compromised account to further escalate their permissions.

Using automated scripts, adversaries conduct systematic reconnaissance to explore available access points. This involves leveraging data obtained through accessible web API endpoints within the cloud or SaaS product. By interacting with these APIs, adversaries acquire a thorough understanding of their current position, enabling them to identify additional accounts for potential targeting. This reconnaissance phase serves as a precursor to subsequent attacks, allowing adversaries to socially engineer help desk employees for password resets or take advantage of misconfigurations to access sensitive data. Learn more about this tactic on the API abuse in the cloud trend page.

A good example of this reconnaissance stage is sifting through files and emails in a victim’s mailbox in search for passwords or sensitive data like payroll or banking information. We often identify adversaries taking advantage of their newly gained access almost immediately after compromising the cloud account in “smash and grab” style attacks. Upon login, we often see email attachments as their main target. Additionally we’ve seen an uptick in multi-factor authentication (MFA) factor changes, where the attacker changes the SMS OTP phone number to one under their control to maintain access.

In addition to proactive employee training, it is imperative for corporations to enforce MFA for all cloud accounts. For enhanced defense, consider implementing phish-resistant MFA methods, such as FIDO2 keys, smart cards, or biometric-based authentication.

However, not all MFA factors offer the same level of security. For instance, SMS OTPs are susceptible to breaches wherein adversaries gain access to legitimate credentials and conduct a “SIM swap” to intercept SMS OTP codes. While SMS-based MFA is considered a better-than-nothing approach, it remains a potentially vulnerable mechanism.

Similar concerns apply to push notification approvals, where users manually accept prompts on their mobile devices. The term “MFA fatigue” has been coined as adversaries bombard users with push notifications, hoping for prompt acceptance and unauthorized access. Although less common, this MFA factor is still susceptible to account takeover. Nevertheless, any MFA implementation is better than none, and adherence to MFA principles is crucial:

• Something you know: password or personal identification number (PIN)
• Something you have: smart card, mobile token, or hardware token
• Some form of biometric factor: fingerprint, palm print, or voice recognition

Note: The visibility sections in this report are mapped to MITRE ATT&CK data sources and components.

Most SaaS applications or cloud providers offer a rich set of logs that can be used to track system and user behaviors. The issue, as is the case with all security-related log sources, comes down to the value proposition that comes with storing them as they can be high in volume leading to high storage costs. We suggest you make every effort to collect these logs and store them for retroactive hunting and investigations. Placing them into some sort of cold storage for later retrieval is a decent strategy to decrease cost while also maintaining that high value proposition.

User Account and Logon Sessions

User Accounts and Logon Sessions are great high level data source categories for observing cloud account authentication activity that is, by definition, a prerequisite for adversaries seeking to abuse Cloud Accounts.

Cloud Service, Application Log, and Web Credential

Of course a Cloud Account can perform functions and make modifications, so in addition to the authentication logs, we suggest closely taking a look at the Cloud Service, Application Log, and Web Credential data sources  as they will be highly valuable during your post- breach investigations.

Note: The collection sections of this report showcase specific log sources from native event logs, third-party tools, and elsewhere that you can use to collect relevant security information.

The Cloud Accounts ATT&CK technique encompasses various identity types, across various different vendors and platforms, which prompted us to compile high level key telemetry sources that offer significant insights. The ensuing logs we’ll discuss share a commonality: they capture a multitude of actions executed by Cloud Accounts. These actions extend beyond mere authentication and, during the detection process, it becomes crucial to align all logic with the origin of an action—consistently tying it back to a specific Cloud Account. This strategic approach ensures comprehensive visibility into the diverse activities performed within the cloud environment. Below are some important log sources we have found provide the most value.

AWS

CloudTrail is AWS’s overarching management and control plane level log source. Its value within security operations teams cannot be overstated as it is often seen as a journal for all user and system behavior operating within an AWS account. It records thousands of different types of events including AWS console login events, new long term access token creations, role assumptions, and much more. For a more in-depth view we highly suggest you check out Red Canary’s AWS Visibility Guide. In this guide we cover different types of recorded CloudTrail events including those that may lead to the discovery of suspicious or potentially malicious activity.

In addition to the CloudTrail control plane logs exists another layer of visibility. These are called data plane operations and include activity occurring within a given resource as opposed to operationalization modifications (control plane). Not every AWS service has data plane records made available, but a lot of them do like Amazon S3 and Amazon RDS. Enabling data plane operations greatly increases log volume so keep that in mind.

Microsoft

Providing a comprehensive understanding of Azure logging intricacies is challenging without addressing Entra ID (formerly known as Azure AD). Azure serves as the foundational resource and cloud infrastructure housing elements such as Virtual Machines and Storage, while Entra ID is responsible for identity and access management (IAM). Both platforms incorporate role-based access control mechanisms, but these mechanisms fundamentally rely on the identities established within Entra ID. Each platform provides various log sources, necessitating a segmented approach for clarity. To help untangle these log sources effectively, it is necessary to differentiate between the two platforms and distinguish what you should expect from them in terms of telemetry generation.

Entra ID houses all of the identities and cloud accounts that access Azure resources like applications, service principals, managed identities, and users. Within Entra ID there exists categories of authentication logs that are recorded by default and cannot be disabled. These include Interactive user sign-in, non-interactive sign-in, service principal sign-in, and managed identity sign-in logs. On top of authentication logs, an audit log exists that constantly records tenant-level modifications and cannot be disabled. In essence, the Entra ID logs offer a comprehensive overview of the behaviors exhibited by your cloud accounts.

Beyond these default logs, additional layers of visibility exist that may need to be manually enabled, though access may necessitate the appropriate license level. One intriguing new source we are eager to explore is the Graph Activity Logs, which can be seen as a sort of data plane record for their SaaS-related products. These logs offer a more profound insight into the Microsoft Graph API, the foundational interface for numerous Microsoft SaaS products like Outlook, SharePoint, and Teams. They provide detailed records of the identities involved in initiating direct HTTP requests to the Graph API, along with the corresponding request URIs and the application responsible for the request. This granular information can unveil reconnaissance activities following a compromise of a cloud account. This holds particular significance, as in cases where adversaries refrain from making direct changes within the SaaS product, conventional logs might only capture a login event.

Azure offers the capability to deploy resources in a manner similar to AWS. The Azure Activity log serves as a record capturing modifications to your resources and noteworthy role-based access control (RBAC) assignments, such as the granting of administrative or owner level privileges within Azure’s RBAC model. Notably, the activity log cannot be disabled. In addition to this, within the majority of Azure resources, there exists the option to also activate supplementary data plane logging similar to AWS, often termed as resource logs or diagnostic logs. These logs meticulously document resource usage, such as when someone accesses a secret or recovers a key from the vault. All of these records include the originating cloud account and can be very high in volume depending on your organization’s specific resource utilization.